RE: scan problem

[Aygon, Bertrand]

Hi,

> > OFONO_AT_DEBUG=1 ./src/ofonod -n -d '*'
> 
> Awesome! The log is attached: 1st I run `./enable-modem /wavecom_q_0` than
> wait for few seconds and run `./online-modem /wavecom_q_0` which gives me
> Setting modem /wavecom_q_0 online...
> Traceback (most recent call last):
>   File "./online-modem", line 17, in 
> modem.SetProperty("Online", dbus.Boolean(1), timeout = 120)
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__
> **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.ofono.Error.NotImplemented:
> Implementation not provided

So your modem doesn't reply to the first AT command sent.

Can you try to open one of the many /dev/ttyUSB1 to /dev/ttyUSB16 using minicom 
and send some AT command to see if you got an answer?

Regards,

Bertrand
-
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: scan problem

[Aygon, Bertrand]

Hi,

> OFONO_AT_DEBUG=1 ./src/ofonod -n -d plugins/*

Can you please start ofonod using this cmd line:

OFONO_AT_DEBUG=1 ./src/ofonod -n -d '*'

Thanks,

Bertrand
-
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: scan problem

[Aygon, Bertrand]

Hi,

> > Ok,  so your modem is enabled, but not online (Online = 0).
> >
> > You should online it by doing "./online-modem /wavecom_q_0"
> 
> ./online-modem /wavecom_q_0
> Setting modem /wavecom_q_0 online...
> Traceback (most recent call last):
>   File "./online-modem", line 17, in 
> modem.SetProperty("Online", dbus.Boolean(1), timeout = 120)
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__
> **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.ofono.Error.NotImplemented:
> Implementation not provided
> 
> That's odd. Could it be some sort of build problem with my installation?
> How can I troubleshoot that?
> 
> > You can add a var arg OFONO_AT_DEBUG=1 to enable AT logging.
> 
> Thanks. Although this gave me only AT command for ./enable-modem which
> works anyway :)

Can you please send the log from beginning to ./enable-modem with AT command, 
so we can have a look at what is going on?

Thanks,

Bertrand
-
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: scan problem

[Aygon, Bertrand]

Hi,

> > Can you please give more details?
> 
> Sure thing but I'll need some guidance on how obtain relevant information 
> since
> I'm complete newbie to ofono stack.

No problem.

> Btw, I'm trying to use this monstrous http://shop.sysmocom.de/products/load-
> tester16
> assembly :)
> 
> > Is your modem enabled and online?
> 
> I think so - at least "./enable-modem /wavecom_q_0" returned no errors and
> changed modem status to following:
> 
> [ /wavecom_q_0 ]
> Features = sim
> Emergency = 0
> Powered = 1
> Lockdown = 0
> Interfaces = org.ofono.SimManager
> Online = 0
> Type = hardware
> [ org.ofono.SimManager ]
> Retries =
> FixedDialing = 0
> SubscriberNumbers =
> BarredDialing = 0
> LockedPins =
> PinRequired = none
> Present = 1

Ok,  so your modem is enabled, but not online (Online = 0).

You should online it by doing "./online-modem /wavecom_q_0"

> > Can you please attach a log?
> 
> Adding -n -d to ofonod revealed nothing interesting besides absence of
> /etc/ofono/phonesim.conf - which seems unlikely to be the culprit. What's the
> recommended procedure for log collection?

You can add a var arg OFONO_AT_DEBUG=1 to enable AT logging.

Regards,

Bertrand
-
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: scan problem

[Aygon, Bertrand]

Hi,

> I've got following error while trying to scan for operator with ofono from 
> git:
> 
> ./scan-for-operators /wavecom_q_0
> Scanning operators on modem /wavecom_q_0...
> Traceback (most recent call last):
>   File "./scan-for-operators", line 20, in 
> operators = netreg.Scan(timeout=100);
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__
> **keywords)
>   File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
> Method "Scan" with signature "" on interface "org.ofono.NetworkRegistration"
> doesn't exist
> 
> Is this some known bug or some sort of misconfiguration on my side?

Can you please give more details?

Is your modem enabled and online?

Can you please attach a log?

Thanks,

Bertrand
-
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: [PATCH v2] SpeedUp: enable online/offline

[Aygon, Bertrand]

Hi Denis,

> > @@ -232,12 +236,122 @@ static int speedup_disable(struct ofono_modem
> *modem)
> > g_at_chat_cancel_all(data->aux);
> > g_at_chat_unregister_all(data->aux);
> >
> > +   /* Cleanup potential online enable polling */
> > +   if (data->online_poll_source > 0) {
> > +   g_source_remove(data->online_poll_source);
> > +   data->online_poll_source = 0;
> > +
> > +   g_free(data->online_cbd);
> > +   data->online_cbd = NULL;
> > +   }
> > +
> 
> This looks fine, but it is actually in the wrong place.  The core doesn't 
> allow
> concurrent online and disable operations.  This really belongs in
> speedup_remove so that you take care of the case where the modem is
> physically yanked out.

Ok, I see. In fact, I used Huawei plugin as example, so I will also fix it :)

Regards,

Bertrand
-
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: [PATCH] SpeedUp: enable online/offline

[Aygon, Bertrand]

Hi Denis,

> On 04/06/2012 08:34 AM, Bertrand Aygon wrote:
> > Add speedup_set_online.
> > Add a polling mechanism since most speedup dongles failed in couple 
> > of AT commands following the CFUN=1 when they are offline.
> >
> > ---
> >  plugins/speedup.c |  106
> > +
> >  1 files changed, 106 insertions(+), 0 deletions(-)
> >
> > diff --git a/plugins/speedup.c b/plugins/speedup.c index
> > ca6ed13..905f462 100644
> > --- a/plugins/speedup.c
> > +++ b/plugins/speedup.c
> > @@ -47,12 +47,16 @@
> >  #include   #include 
> > 
> >
> > +static const char *creg_prefix[] = { "+CREG:", NULL };
> >  static const char *none_prefix[] = { NULL };
> >
> >  struct speedup_data {
> > GAtChat *modem;
> > GAtChat *aux;
> > gboolean have_sim;
> > +   guint online_poll_source;
> > +   guint online_poll_count;
> > +   struct cb_data *online_cbd;
> 
> You need to free these in case the modem is removed when the online 
> operation is in progress.

Ok, I will do this.


> > struct at_util_sim_state_query *sim_state_query;  };
> >
> > @@ -238,6 +242,107 @@ static int speedup_disable(struct ofono_modem
> *modem)
> > return -EINPROGRESS;
> >  }
> >
> > +static gboolean creg_online_check(gpointer user_data);
> > +
> > +static void creg_online_cb(gboolean ok, GAtResult *result,
> > +   gpointer user_data)
> > +{
> > +   struct speedup_data *data = user_data;
> > +   ofono_modem_online_cb_t cb = data->online_cbd->cb;
> > +
> > +   if (ok) {
> > +   CALLBACK_WITH_SUCCESS(cb, data->online_cbd->data);
> > +   goto done;
> > +   }
> > +
> > +   data->online_poll_count++;
> > +
> > +   if (data->online_poll_count > 15)
> > +   goto failure;
> > +
> > +   data->online_poll_source = g_timeout_add_seconds(2,
> > +   creg_online_check, data);
> > +   return;
> > +
> > +failure:
> > +   CALLBACK_WITH_FAILURE(cb, data->online_cbd->data);
> > +
> > +done:
> > +   g_free(data->online_cbd);
> > +   data->online_cbd = NULL;
> > +}
> > +
> > +static gboolean creg_online_check(gpointer user_data) {
> > +   struct speedup_data *data = user_data;
> > +
> > +   data->online_poll_source = 0;
> > +
> > +   g_at_chat_send(data->aux, "AT+CREG=?", creg_prefix,
> > +   creg_online_cb, data, NULL);
> 
> Just for my understanding, the modem stops responding to all commands 
> when
> CFUN=1 is issued, hence you're polling that CREG is supported?

It responds errors. Here are some logs. First log without the polling mechanism.

...
ofonod[8096]: src/network.c:ofono_netreg_strength_notify() strength 40
ofonod[8096]: Aux: > AT+CGATT=1\r
ofonod[8096]: Aux: < \r\nOK\r\n
ofonod[8096]: src/gprs.c:gprs_attach_callback() /speedup_3 error = 0
ofonod[8096]: Aux: > AT+CIND?\r
ofonod[8096]: Aux: < \r\n+CIND: 5,2,1,0,0,0,1,0\r\n\r\nOK\r\n
ofonod[8096]: Aux: > AT+CRSM=192,28437,0,0,255\r
ofonod[8096]: Aux: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
ofonod[8096]: Aux: > AT+COPS=3,0\r
ofonod[8096]: Aux: < \r\nOK\r\n
ofonod[8096]: Aux: > AT+COPS?\r
ofonod[8096]: Aux: < \r\n+COPS: 0,0,"F SFR",2\r\n\r\nOK\r\n
ofonod[8096]: drivers/atmodem/network-registration.c:cops_cb() cops_cb: 
F SFR, 208 10 2
ofonod[8096]: src/network.c:current_operator_callback() 0x9c696e0, (nil)
ofonod[8096]: src/gprs.c:netreg_status_changed() 1
ofonod[8096]: src/cbs.c:cbs_location_changed() 1, 48101, 20894309, -1, 20810
ofonod[8096]: src/cbs.c:cbs_location_changed() 1, 0, 0
ofonod[8096]: Aux: > AT+CGREG?\r
ofonod[8096]: Aux: < \r\n+CGREG: 2,1, BBE5, 13ED265\r\n\r\nOK\r\n
ofonod[8096]: src/gprs.c:registration_status_cb() /speedup_3 error 0 status 1
ofonod[8096]: src/gprs.c:ofono_gprs_status_notify() /speedup_3 status 1

... going offline

ofonod[8096]: plugins/speedup.c:speedup_set_online() modem 0x9c59cc0 offline
ofonod[8096]: Aux: > AT+CFUN=4\r
ofonod[8096]: Aux: < \r\nOK\r\n
ofonod[8096]: src/modem.c:modem_change_state() old state: 3, new state: 2
ofonod[8096]: src/modem.c:flush_atoms()
ofonod[8096]: src/ussd.c:ussd_remove() atom: 0x9c594b0
ofonod[8096]: src/network.c:__ofono_netreg_remove_status_watch() 0x9c696e0
ofonod[8096]: src/cbs.c:cbs_remove() atom: 0x9c59408
ofonod[8096]: src/sim.c:ofono_sim_remove_spn_watch() 0x9c6a140
ofonod[8096]: src/network.c:netreg_remove() atom: 0x9c59198
ofonod[8096]: Aux: < \r\n+CREG: 0\r\n\r\n+CGREG: 0\r\n
ofonod[8096]: src/gprs.c:ofono_gprs_status_notify() /speedup_3 status 0

... going online

ofonod[8096]: plugins/speedup.c:speedup_set_online() modem 0x9c59cc0 online
ofonod[8096]: Aux: > AT+CFUN=1\r
ofonod[8096]: Aux: < \r\nOK\r\n
ofonod[8096]: src/modem.c:modem_change_state() old state: 2, new state: 3
ofonod[8096]: Aux: > AT+CREG=?\r
ofonod[8096]: Aux: < \r\nERROR\r\n
ofonod[8096]: Unable to initialize Network Registration
ofonod[8096]: src/network.c:netreg_remove() atom: 0x9c5aa80
ofonod[8096]: Aux: > AT+CSCB=?\r
ofonod[8096]: Aux: < \r\nERROR\r\n
ofonod[8096]: CSC

RE: [PATCH] sim: Use quoted string with AT+CRSM data parameter

[Aygon, Bertrand]

Hi,

> > Fix issue with some modems preventing to update elementary files
> > (speedup, ZTE, huawei, MBM)
> > ---
> >  drivers/atmodem/sim.c |   52
> ++--
> >  1 files changed, 45 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c index
> > 8ee9822..f307708 100644
> > --- a/drivers/atmodem/sim.c
> > +++ b/drivers/atmodem/sim.c
> > @@ -305,18 +305,38 @@ static void at_sim_update_binary(struct
> > ofono_sim *sim, int fileid,  {
> > struct sim_data *sd = ofono_sim_get_data(sim);
> > struct cb_data *cbd = cb_data_new(cb, data);
> > -   char *buf = g_try_new(char, 36 + length * 2);
> > +   char *buf;
> > int len, ret;
> > +   int size = 36 + length * 2;
> >
> > +   if (sd->vendor == OFONO_VENDOR_MBM ||
> > +   sd->vendor == OFONO_VENDOR_ZTE ||
> > +   sd->vendor == OFONO_VENDOR_HUAWEI ||
> > +   sd->vendor == OFONO_VENDOR_SPEEDUP)
> > +   size += 2; /*Add quotes*/
> 
> this is better done with a switch statement. And please fix the comment style 
> to
> adhere to the coding style.
> 
> > +
> > +   buf = g_try_new(char, size);
> > if (buf == NULL)
> > goto error;
> >
> > len = sprintf(buf, "AT+CRSM=214,%i,%i,%i,%i,", fileid,
> > start >> 8, start & 0xff, length);
> >
> > +   if (sd->vendor == OFONO_VENDOR_MBM ||
> > +   sd->vendor == OFONO_VENDOR_ZTE ||
> > +   sd->vendor == OFONO_VENDOR_HUAWEI ||
> > +   sd->vendor == OFONO_VENDOR_SPEEDUP)
> > +   sprintf(buf + len, "\"");
> > +
> 
> I am getting a little bit worried about spreading sd->vendor checks at many
> places here. Maybe this can be done smarter and cleaner.

Maybe you can always add the 2 bytes for the memory allocation, whatever the 
modem is. The cost is not so high, and the memory is freed at the end of the 
function.

And then, you can create a small function that 'append' the hex value. So the 
modem check would be only in this function, instead of being in 
at_sim_update_binary, at_sim_update_binary and at_sim_update_cyclic.

Doing this, you will have 2 modem checks instead of 9.

Regards,

Bertrand
-
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: [PATCH 1/3] n950: Add modem plugin for the N950

[Aygon, Bertrand]

Hi,

> -Original Message-
> From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On
> Behalf Of marko.sau...@gmail.com
> Sent: Monday, December 12, 2011 12:40 PM
> To: ofono@ofono.org
> Subject: [PATCH 1/3] n950: Add modem plugin for the N950
> 
> From: Aki Niemi 
> 
> ---
>  Makefile.am  |3 +
>  plugins/n900.c   |   12 +-
>  plugins/n950.c   |  563
> ++
>  plugins/nokia-gpio.c |  105 --
>  plugins/nokia-gpio.h |   38 +++-
>  5 files changed, 651 insertions(+), 70 deletions(-)  create mode 100644
> plugins/n950.c
> 

I would say that this patch doesn't add N950 plugin, but first rename some 
nokia gpio function, update N900 plugin and then introduce the N950.

So I would propose to split this patches in multiple:
 - a first one which modify nokia gpio APIs,
 - a second one that modify the N900 to reflect the changes
 - a third one that introduce the N950, wich may include your third patch that 
disable the CBS
 - a fourth one that include the N950 plugin in the makefile.

Regards,

Bertrand.
-
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: [PATCH_v0 1/3] doc: Add RoamingAllowed property

[Aygon, Bertrand]

Hi,

> > > + boolean RoamingAllowed [readwrite]
> > > +
> > > + Contains whether data roaming is allowed.  In the off
> > > + setting, if the packet radio registration state
> > > + indicates that the modem is roaming, oFono will
> > > + automatically shutdown connection and no further
> > > + connection establishment will be possible.
> > > +
> >
> > I'm still not convinced this is really needed.  Can you discuss a
> > specific usecase you are trying to take care of here?
> 
> I do not know CDMA but I do not see why this would be needed at all at the
> ConnectionManager atom level. If this is about pricing, it should probably be 
> a
> per-context property instead, both for CDMA and GSM.

There is a RoamingAllowed property in the connman atom, and this property is 
used to set if the user want to do some data call while in roaming mode.

Some months ago has been introduced a cdma-connman atom, but currently, there 
is no RoamingAllowed property in this version.

The goal of this patch is to add the same property, so when doing a CDMA data 
call, if we are in roaming, we can check if the user still want to do the data 
call or not.

In CDMA, there is no context as in GSM.

Regards,

Bertrand
-
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: [PATCH_v0 1/3] doc: Add RoamingAllowed property

[Aygon, Bertrand]

Hi Denis,

> > +   boolean RoamingAllowed [readwrite]
> > +
> > +   Contains whether data roaming is allowed.  In the off
> > +   setting, if the packet radio registration state
> > +   indicates that the modem is roaming, oFono will
> > +   automatically shutdown connection and no further
> > +   connection establishment will be possible.
> > +
> 
> I'm still not convinced this is really needed.  Can you discuss a specific 
> usecase
> you are trying to take care of here?

This is the same use case as with GSM/3G network. During our testing in 
Indonesia, we have seen some situation where we were in roaming mode.
So roaming mode is supported in CDMA, and I guess that this would have 
incidence on the billing (I will try to get some confirmation about this).

Regards,

Bertrand
-
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_v0] sierra: Add SIM state polling

[Aygon, Bertrand]

Hi Guillaume,

>  static void sierra_debug(const char *str, void *user_data) @@ -79,6 +81,12
> @@ static void sierra_remove(struct ofono_modem *modem)
> 
>   ofono_modem_set_data(modem, NULL);
> 
> + /* Cleanup potential SIM state polling */
> + at_util_sim_state_query_free(data->sim_state_query);
> +
> + /* Cleanup after hot-unplug */
> + g_at_chat_unref(data->chat);

Seems that you found an issue not related to your change. Maybe a dedicated 
submit would be nice.

> +
>   g_free(data);
>  }
> 
> @@ -115,6 +123,21 @@ static GAtChat *open_device(struct ofono_modem
> *modem,
>   return chat;
>  }
> 
> +static void sim_state_cb(gboolean present, gpointer user_data) {
> + struct ofono_modem *modem = user_data;
> + struct sierra_data *data = ofono_modem_get_data(modem);
> +
> + at_util_sim_state_query_free(data->sim_state_query);
> + data->sim_state_query = NULL;
> +
> + data->have_sim = present;
> +
> + ofono_modem_set_powered(modem, TRUE);
> +
> + g_at_chat_send(data->chat, "AT&C0", NULL, NULL, NULL, NULL); }
> +
>  static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)  
> {
>   struct ofono_modem *modem = user_data; @@ -127,7 +150,8 @@
> static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
>   data->chat = NULL;
>   }
> 
> - ofono_modem_set_powered(modem, ok);
> + data->sim_state_query = at_util_sim_state_query_new(data->chat,
> + 2, 20, sim_state_cb, modem);

So in case of cfun_enable failure, you will query for SIM state?

>  }
> 
>  static int sierra_enable(struct ofono_modem *modem)
> --

Regards,

Bertrand
-
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: [PATCH 3/5] cdma-providers: add driver APIs implementation

[Aygon, Bertrand]

Hi Philippe,

> diff --git a/src/cdma-providers.c b/src/cdma-providers.c new file mode 100644
> index 000..d02d41c
> --- /dev/null
> +++ b/src/cdma-providers.c
> @@ -0,0 +1,80 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2011  Nokia Corporation and/or its subsidiary(-ies).

Same comment about copyright.

> + *
> + *  This program is free software; you can redistribute it and/or
> +modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> +02110-1301  USA
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include 
> +#endif
> +
> +#include 
> +#include 
> +#include "ofono.h"
> +
> +static GSList *g_drivers = NULL;
> +
> +ofono_bool_t __ofono_cdma_providers_get_name(const char *sid, char
> +**name) {
> + GSList *d;
> +
> + if (sid == NULL || strlen(sid) == 0)
> + return FALSE;
> +
> + for (d = g_drivers; d != NULL; d = d->next) {
> + const struct ofono_cdma_providers_driver *driver = d->data;
> +
> + if (driver->get_provider_name == NULL)
> + continue;
> +
> + DBG("Calling providers plugin '%s'", driver->name);
> +
> + if (driver->get_provider_name(sid, name) < 0)
> + continue;
> +
> + return TRUE;
> + }
> +
> + return FALSE;
> +}
> +
> +static gint compare_priority(gconstpointer a, gconstpointer b) {
> + const struct ofono_cdma_providers_driver *plugin1 = a;
> + const struct ofono_cdma_providers_driver *plugin2 = b;
> +
> + return plugin2->priority - plugin1->priority; }
> +
> +int ofono_cdma_providers_driver_register(
> + const struct ofono_cdma_providers_driver *driver) {
> + DBG("driver: %p name: %s", driver, driver->name);
> +
> + g_drivers = g_slist_insert_sorted(g_drivers, (void *) driver,
> + compare_priority);
> + return 0;
> +}
> +
> +void ofono_cdma_providers_driver_unregister(
> + const struct ofono_cdma_providers_driver *driver) {
> + DBG("driver: %p name: %s", driver, driver->name);
> +
> + g_drivers = g_slist_remove(g_drivers, driver); }
> --
> 1.7.1

Regards,

Bertrand
-
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: [PATCH 1/5] cdma-providers: add driver APIs header

[Aygon, Bertrand]

Hi Philippe,

> diff --git a/include/cdma-providers.h b/include/cdma-providers.h new file mode
> 100644 index 000..8ee9e1e
> --- /dev/null
> +++ b/include/cdma-providers.h
> @@ -0,0 +1,44 @@
> +/*
> + *
> + *  oFono - Open Telephony stack for Linux
> + *
> + *  Copyright (C) 2011  Nokia Corporation and/or its subsidiary(-ies).

Are you sure about the copyright?

> + *
> + *  This program is free software; you can redistribute it and/or
> +modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> +02110-1301  USA
> + *
> + */
> +
> +#ifndef __OFONO_CDMA_PROVIDERS_H
> +#define __OFONO_CDMA_PROVIDERS_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +struct ofono_cdma_providers_driver {
> + const char *name;
> + int priority;
> + int (*get_provider_name)(const char *sid, char **name); };
> +
> +int ofono_cdma_providers_driver_register(
> + const struct ofono_cdma_providers_driver *driver); void
> +ofono_cdma_providers_driver_unregister(
> + const struct ofono_cdma_providers_driver *driver);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* __OFONO_CDMA_PROVIDERS_H */
> --
> 1.7.1

Regards,

Bertrand
-
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: How to set access technology for CDMA modem

[Aygon, Bertrand]

Hi,

>Here we got problem with CDMA dongle (CDMA2000/EVDO/HSIA), in Windows dialer 
>we can >select the network type as following: Netconnect +, High speed 1x or 
>HYBRID.
>I assume Netconnect+ stands for CDMA2000, and High Speed 1x stands for CDMA 
>EVFDO >1x. 

>And the dialer will show in an icon to tell what mode is select or can be 
>supported >currently. If select an unsupported type, it could fail to connect 
>to the network.

>But when trying to modify the radio access technology in ofono, I cannot see 
>the >according options, what is there is GSM, UMTS, ANY, etc.
>Could anybody tell me how to issue the script set-tech-reference to force 
>ofono to >work in desired network type?

oFono CDMA support is not complete, and RAT (Radio Access Technology) is not 
supported yet, so you cannot configure this.

Regards,

Bertrand
-
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: [PATCH 1/2] gatppp: save dumpfile into ppp info to start recording during open phase.

[Aygon, Bertrand]

Hi,

> > @@ -541,6 +542,8 @@ gboolean g_at_ppp_open(GAtPPP *ppp, GAtIO
> *io)
> > if (ppp->hdlc == NULL)
> > return FALSE;
> >
> > +   g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> > +
> >>>
> >>> I force the start of the recording in the ppp_open.
> >>>
> >>> Without this change, if we call g_at_ppp_set_record before
> >> g_at_ppp_open, as it's done in gsmdial, it's totaly useless.
> >> g_at_ppp_set_record will call g_at_hdlc_set_recording, and
> >> g_at_hdlc_set_recording will check ppp->hdlc. But ppp->hdlc is set
> in
> >> g_at_ppp_open.
> >>>
> >>
> >> Then at least do this everywhere g_at_hdlc is created...
> >
> > Agreed.
> >
> > ppp->suspended = FALSE;
> > g_at_hdlc_set_receive(ppp->hdlc, ppp_receive, ppp);
> > g_at_hdlc_set_suspend_function(ppp->hdlc,
> > @@ -593,7 +596,11 @@ void g_at_ppp_set_recording(GAtPPP *ppp,
> const
>  char *filename)
> > if (ppp == NULL)
> > return;
> >
> > -   g_at_hdlc_set_recording(ppp->hdlc, filename);
> > +   g_free(ppp->dumpfile);
> > +
> > +   ppp->dumpfile = g_strdup(filename);
> > +
> > +   g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> 
>  I'm failing to see the point in making this change.  Why do you
> need
> >> to
>  save the dump filename inside gatppp?
> >>>
> >>> So in the g_at_ppp_set_recording, I store the file. And during the
> >> ppp_open, I start the recording immediately. So with this change, we
> >> cannot miss a PPP frame. Because without the change, if we start the
> >> recording after the ppp_open, we might loose some info.
> >>>
> >>
> >> However, I'm still not convinced we want to pay the price of storing
> >> the
> >> filename.  Setting recording after ppp_open should be fine, all
> GAtHDLC
> >> writes are deferred until the next poll/select fires, which implies
> >> going into the main event loop.  So no data will be lost.
> >
> > Up to you to decide. If you think that we will not lose any frames if
> you do the set_recording just after the open, let's do it this way. I
> agree that it will save some memory, and so it's better.
> >
> 
> Please do it this way:
> 
> g_at_ppp_set_recording:
>   if (ppp->hdlc == NULL)
>   ppp->recording_filename = g_strdup(filename);
>   return;
> 
>   g_at_hdlc_set_recording(filename);
> 
> and whenever you open hdlc, free recording_filename and set it to NULL
> after calling g_at_hdlc_set_recording.
> 
> Free in unref as well if for some reason we fail to open/listen to to
> the ppp object.

Good compromise :)

Regards,

Bertrand
-
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: [PATCH 1/2] gatppp: save dumpfile into ppp info to start recording during open phase.

[Aygon, Bertrand]

Hi Denis,

> >>> @@ -541,6 +542,8 @@ gboolean g_at_ppp_open(GAtPPP *ppp, GAtIO *io)
> >>>   if (ppp->hdlc == NULL)
> >>>   return FALSE;
> >>>
> >>> + g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> >>> +
> >
> > I force the start of the recording in the ppp_open.
> >
> > Without this change, if we call g_at_ppp_set_record before
> g_at_ppp_open, as it's done in gsmdial, it's totaly useless.
> g_at_ppp_set_record will call g_at_hdlc_set_recording, and
> g_at_hdlc_set_recording will check ppp->hdlc. But ppp->hdlc is set in
> g_at_ppp_open.
> >
> 
> Then at least do this everywhere g_at_hdlc is created...

Agreed.

> >>>   ppp->suspended = FALSE;
> >>>   g_at_hdlc_set_receive(ppp->hdlc, ppp_receive, ppp);
> >>>   g_at_hdlc_set_suspend_function(ppp->hdlc,
> >>> @@ -593,7 +596,11 @@ void g_at_ppp_set_recording(GAtPPP *ppp, const
> >> char *filename)
> >>>   if (ppp == NULL)
> >>>   return;
> >>>
> >>> - g_at_hdlc_set_recording(ppp->hdlc, filename);
> >>> + g_free(ppp->dumpfile);
> >>> +
> >>> + ppp->dumpfile = g_strdup(filename);
> >>> +
> >>> + g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> >>
> >> I'm failing to see the point in making this change.  Why do you need
> to
> >> save the dump filename inside gatppp?
> >
> > So in the g_at_ppp_set_recording, I store the file. And during the
> ppp_open, I start the recording immediately. So with this change, we
> cannot miss a PPP frame. Because without the change, if we start the
> recording after the ppp_open, we might loose some info.
> >
> 
> However, I'm still not convinced we want to pay the price of storing
> the
> filename.  Setting recording after ppp_open should be fine, all GAtHDLC
> writes are deferred until the next poll/select fires, which implies
> going into the main event loop.  So no data will be lost.

Up to you to decide. If you think that we will not lose any frames if you do 
the set_recording just after the open, let's do it this way. I agree that it 
will save some memory, and so it's better.

Regards,

Bertrand
-
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: [PATCH 1/2] gatppp: save dumpfile into ppp info to start recording during open phase.

[Aygon, Bertrand]

Hi Denis,

> > @@ -541,6 +542,8 @@ gboolean g_at_ppp_open(GAtPPP *ppp, GAtIO *io)
> > if (ppp->hdlc == NULL)
> > return FALSE;
> >
> > +   g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> > +

I force the start of the recording in the ppp_open.

Without this change, if we call g_at_ppp_set_record before g_at_ppp_open, as 
it's done in gsmdial, it's totaly useless. g_at_ppp_set_record will call 
g_at_hdlc_set_recording, and g_at_hdlc_set_recording will check ppp->hdlc. But 
ppp->hdlc is set in g_at_ppp_open.

> > ppp->suspended = FALSE;
> > g_at_hdlc_set_receive(ppp->hdlc, ppp_receive, ppp);
> > g_at_hdlc_set_suspend_function(ppp->hdlc,
> > @@ -593,7 +596,11 @@ void g_at_ppp_set_recording(GAtPPP *ppp, const
> char *filename)
> > if (ppp == NULL)
> > return;
> >
> > -   g_at_hdlc_set_recording(ppp->hdlc, filename);
> > +   g_free(ppp->dumpfile);
> > +
> > +   ppp->dumpfile = g_strdup(filename);
> > +
> > +   g_at_hdlc_set_recording(ppp->hdlc, ppp->dumpfile);
> 
> I'm failing to see the point in making this change.  Why do you need to
> save the dump filename inside gatppp?

So in the g_at_ppp_set_recording, I store the file. And during the ppp_open, I 
start the recording immediately. So with this change, we cannot miss a PPP 
frame. Because without the change, if we start the recording after the 
ppp_open, we might loose some info.

> >  }
> >
> >  void g_at_ppp_set_connect_function(GAtPPP *ppp, GAtPPPConnectFunc
> func,
> > @@ -745,6 +752,8 @@ void g_at_ppp_unref(GAtPPP *ppp)
> >
> > g_at_hdlc_unref(ppp->hdlc);
> >
> > +   g_free(ppp->dumpfile);
> > +
> > g_free(ppp);
> >  }
> >

Regards,

Bertrand
-
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: [PATCH] speedup: blacklist the NO CARRIER terminator for control channel

[Aygon, Bertrand]

Hi,

> > > > Some Speedup cards will send the NO CARRIER in the control
> channel.
> > >
> > > please include a trace. I am not sure how this effect anything
> since we
> > > are not supporting online/offline mode with these cards.
> >
> > Ok, no problem. What kind of test do you want me to do?
> >
> > I make a data call that failed and then I disable the modem?
> 
> you are proposing to blacklist this terminator. So you should know
> where
> it causes a problem. I only blacklisted it modems that were supporting
> online mode and where switching offline caused a problem that NO
> CARRIER
> came before OK. Do you have that problem?

No I don't, because as you said, speedup doesn't support offline/online mode.

I have proposed to blacklist it, because this NO CARRIER has nothing to do in 
control channel, and I do not want it to cause any trouble. I know, this is 
rude :)

Regards,

Bertrand
-
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: [PATCH] speedup: blacklist the NO CARRIER terminator for control channel

[Aygon, Bertrand]

Hi,

> > Some Speedup cards will send the NO CARRIER in the control channel.
> 
> please include a trace. I am not sure how this effect anything since we
> are not supporting online/offline mode with these cards.

Ok, no problem. What kind of test do you want me to do?

I make a data call that failed and then I disable the modem?

Regards,

Bertrand
-
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: [PATCH] atutil: put CME ERROR 10 in CPIN polling.

[Aygon, Bertrand]

Hi,

> -Original Message-
> From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On
> Behalf Of Bertrand Aygon
> Sent: Thursday, August 04, 2011 6:07 PM
> To: ofono@ofono.org
> Subject: [PATCH] atutil: put CME ERROR 10 in CPIN polling.
> 
> Some modem also return CME ERROR 10 during boot, until SIM is ready.
> 
> ofonod[5073]: Modem: > ATE0 +CMEE=1\r
> ofonod[5073]: Aux: > ATE0 +CMEE=1\r
> ofonod[5073]: Aux: < \r\nOK\r\n
> ofonod[5073]: Aux: > AT+CFUN=1\r
> ofonod[5073]: Modem: < \r\nOK\r\n
> ofonod[5073]: Aux: <
> \r\nUSAT_OP_FINISH\r\n\r\n+STRSP:0x14\r\n\r\nOK\r\n
> ofonod[5073]: plugins/speedup.c:cfun_enable()
> ofonod[5073]: Aux: > AT+CPIN?\r
> ofonod[5073]: Aux: < \r\n+CME ERROR: 10\r\n
> ofonod[5073]: Aux: > AT+CPIN?\r
> ofonod[5073]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
> ---
>  drivers/atmodem/atutil.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/atmodem/atutil.c b/drivers/atmodem/atutil.c
> index 63b1301..34e2d3e 100644
> --- a/drivers/atmodem/atutil.c
> +++ b/drivers/atmodem/atutil.c
> @@ -527,11 +527,11 @@ static void cpin_check_cb(gboolean ok, GAtResult
> *result, gpointer userdata)
>   goto done;
> 
>   switch (error.error) {
> - case 10:
> - case 13:
> + case 13: /* SIM failure */
>   goto done;
> 
> - case 14:
> + case 10: /* SIM not inserted */
> + case 14: /* SIM Busy */
>   goto tryagain;
> 
>   default:
> --
> 1.7.4.1
> 

I have attached the full log, to see the problem clearly.

Thanks,

Bertrand

-
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.
ofonod[5073]: src/modem.c:get_modem_property() modem 0x8acfab8 property Modem
ofonod[5073]: plugins/speedup.c:open_device() Modem /dev/ttyUSB4
ofonod[5073]: src/modem.c:get_modem_property() modem 0x8acfab8 property Aux
ofonod[5073]: plugins/speedup.c:open_device() Aux /dev/ttyUSB1
ofonod[5073]: Modem: > ATE0 +CMEE=1\r
ofonod[5073]: Aux: > ATE0 +CMEE=1\r
ofonod[5073]: Aux: < ATE0 +CMEE=1\r
ofonod[5073]: plugins/udev.c:udev_event() subsystem tty add
ofonod[5073]: src/modem.c:get_modem_property() modem 0x8acfab8 property Path
ofonod[5073]: plugins/udev.c:add_modem() 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/ttyUSB0/tty/ttyUSB0 
(speedup)
ofonod[5073]: plugins/udev.c:add_speedup() modem 0x8acfab8
ofonod[5073]: src/modem.c:get_modem_property() modem 0x8acfab8 property 
ModemRegistered
ofonod[5073]: src/modem.c:get_modem_property() modem 0x8acfab8 property 
AuxRegistered
ofonod[5073]: plugins/udev.c:udev_event() subsystem tty finished
ofonod[5073]: Aux: < \r\nOK\r\n
ofonod[5073]: Aux: > AT+CFUN=1\r
ofonod[5073]: Modem: < \r\nOK\r\n
ofonod[5073]: Aux: < \r\nOK\r\n
ofonod[5073]: plugins/speedup.c:cfun_enable() 
ofonod[5073]: Aux: > AT+CPIN?\r
ofonod[5073]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[5073]: examples/emulator.c:powered_watch() Adding modem 0x8acfab8 to the 
list
ofonod[5073]: examples/emulator.c:create_tcp() Created server_watch: 46
ofonod[5073]: examples/emulator.c:create_tcp() Created server_watch: 47
ofonod[5073]: src/modem.c:modem_change_state() old state: 0, new state: 1
ofonod[5073]: plugins/speedup.c:speedup_pre_sim() 0x8acfab8
ofonod[5073]: Aux: > AT+GCAP\r
ofonod[5073]: Modem: > AT&C0\r
ofonod[5073]: src/sim.c:ofono_sim_add_state_watch() 0x8ad0010
ofonod[5073]: src/sim.c:ofono_sim_add_state_watch() 0x8ad0010
ofonod[5073]: src/sim.c:ofono_sim_add_state_watch() 0x8ad0010
ofonod[5073]: Aux: < \r\n+GCAP: +CGSM,+FCLASS,+DS\r\n\r\nOK\r\n
ofonod[5073]: Aux: > AT&C0\r
ofonod[5073]: Modem: < \r\nOK\r\n
ofonod[5073]: Aux: < \r\nOK\r\n
ofonod[5073]: Aux: > AT+CRSM=192,12258,0,0,255\r
ofonod[5073]: Aux: < \r\n+CRSM: 
144,0,"62178202412183022FE28A01058B032F06098002000A880110"\r\n\r\nOK\r\n
ofonod[5073]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 25
ofonod[5073]: Aux: > AT+CGMI\r
ofonod[5073]: Aux: < \r\nOK\r\n
ofonod[5073]: Aux: > AT+CRSM=176,12258,0,0,10\r
ofonod[5073]: Aux: < \r\n+CRSM: 144,0,"98331002637013441307"\r\n\r\nOK\r\n
ofonod[5073]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 10
ofonod[5073]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, 
tocopy: 10
ofonod[5073]: Aux: > AT+CGMM\r
ofonod[5073]: Aux: < \r\nSU-8000\r\n\r\nOK\r\n
ofonod[5073]: Aux: > AT+CRSM=192,28421,0,0,255\r
ofonod[5073]: Aux: < \r\n+CRSM: 
144,0,"62178202412183026F058A01058B036F06098002000A880110"\r\n\r\nOK\r\n
ofonod[5073]: drivers/atmodem/sim.c:at_crsm_info_cb() c

RE: [PATCH] udev: add support for Olive HSDPA modem, which seems to be a SpeedUP.

[Aygon, Bertrand]

Hi,

> >  plugins/ofono.rules |9 ++---
> >  1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> > index 27a6316..4e697af 100644
> > --- a/plugins/ofono.rules
> > +++ b/plugins/ofono.rules
> > @@ -385,7 +385,10 @@ ATTRS{idVendor}=="1c9e",
> ATTRS{idProduct}=="9800",
> > ENV{ID_USB_INTERFACE_NUM}=="0
> >  ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> > ENV{ID_USB_INTERFACE_NUM}=="00", ENV{OFONO_SPEEDUP_TYPE}="modem"
> >  ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> > ENV{ID_USB_INTERFACE_NUM}=="03", ENV{OFONO_SPEEDUP_TYPE}="aux"
> >
> > -# SpeedUp 8000
> > +# SpeedUp
> > +ATTRS{idVendor}=="2020", ATTRS{idProduct}=="1005",
> > ENV{ID_USB_INTERFACE_NUM}=="03", ENV{OFONO_SPEEDUP_TYPE}="modem"
> > +ATTRS{idVendor}=="2020", ATTRS{idProduct}=="1005",
> > ENV{ID_USB_INTERFACE_NUM}=="01", ENV{OFONO_SPEEDUP_TYPE}="aux"
> > +
> 
> This modem seems to have an issue with PPP. The NO CARRIER is sent only
> in one channel, and not the same as the ATD. So I think that I have to
> swith the tty.
> 
> Please wait before applying this patch.

Finally, I will keep the tty because if I switch, it's even worse :(
If modem is on tty 0, we are never receiving any PPP data from the modem.

So I will kept this patch as it is.

And I will make one to black list the NO CARRIER for speedup...

Thanks for the review,

Bertrand
-
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: [PATCH 4/4] atmodem: Add support for the PIN counter command AT+CPNNUM

[Aygon, Bertrand]

Hi,

> > > >  drivers/atmodem/sim.c |   95
> > > +
> > > >  1 files changed, 95 insertions(+), 0 deletions(-)
> > >
> > > please include an OFONO_AT_DEBUG trace of this AT command.
> >
> > I have attached a full log from a SpeedUp dongle, but here is the AT
> command that we are looking at:
> >
> > ofonod[2534]: Aux: > AT+CPNNUM\r
> > ofonod[2534]: Aux: < \r\nPIN1=3; PUK1=10; PIN2=3; PUK2=10\r\r\nOK\r\n
> 
> this is so ugly. I sometimes really question the manufactures on why
> nobody can create proper AT commands. Also one fun fact, if you issue
> this one on the wrong TTY, you get the answer on the other one. That
> will screw up our parse big time ;)

AT command protocol is s complex :)

> Nevertheless, I added a patch for this now.

Thanks,

Bertrand
-
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: [PATCH] udev: add support for Olive HSDPA modem, which seems to be a SpeedUP.

[Aygon, Bertrand]

Hi,

>  plugins/ofono.rules |9 ++---
>  1 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> index 27a6316..4e697af 100644
> --- a/plugins/ofono.rules
> +++ b/plugins/ofono.rules
> @@ -385,7 +385,10 @@ ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9800",
> ENV{ID_USB_INTERFACE_NUM}=="0
>  ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> ENV{ID_USB_INTERFACE_NUM}=="00", ENV{OFONO_SPEEDUP_TYPE}="modem"
>  ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> ENV{ID_USB_INTERFACE_NUM}=="03", ENV{OFONO_SPEEDUP_TYPE}="aux"
> 
> -# SpeedUp 8000
> +# SpeedUp
> +ATTRS{idVendor}=="2020", ATTRS{idProduct}=="1005",
> ENV{ID_USB_INTERFACE_NUM}=="03", ENV{OFONO_SPEEDUP_TYPE}="modem"
> +ATTRS{idVendor}=="2020", ATTRS{idProduct}=="1005",
> ENV{ID_USB_INTERFACE_NUM}=="01", ENV{OFONO_SPEEDUP_TYPE}="aux"
> +

This modem seems to have an issue with PPP. The NO CARRIER is sent only in one 
channel, and not the same as the ATD. So I think that I have to swith the tty.

Please wait before applying this patch.

Sorry,

Bertrand.

-
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: [PATCH 4/4] atmodem: Add support for the PIN counter command AT+CPNNUM

[Aygon, Bertrand]

Hi,

> >  drivers/atmodem/sim.c |   95
> +
> >  1 files changed, 95 insertions(+), 0 deletions(-)
> 
> please include an OFONO_AT_DEBUG trace of this AT command.

I have attached a full log from a SpeedUp dongle, but here is the AT command 
that we are looking at:

ofonod[2534]: Aux: > AT+CPNNUM\r
ofonod[2534]: Aux: < \r\nPIN1=3; PUK1=10; PIN2=3; PUK2=10\r\r\nOK\r\n

Regards,

Bertrand
-
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.
ofonod[2534]: src/modem.c:get_modem_property() modem 0x86e9a28 property Modem
ofonod[2534]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
ofonod[2534]: src/modem.c:get_modem_property() modem 0x86e9a28 property Aux
ofonod[2534]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
ofonod[2534]: Modem: > ATE0 +CMEE=1\r
ofonod[2534]: Aux: > ATE0 +CMEE=1\r
ofonod[2534]: Aux: < ATE0 +CMEE=1\r\r\nOK\r\n
ofonod[2534]: Aux: > AT+CFUN=1\r
ofonod[2534]: Modem: < \r\nOK\r\n
ofonod[2534]: Aux: < \r\nOK\r\n
ofonod[2534]: plugins/speedup.c:cfun_enable() 
ofonod[2534]: Aux: > AT+CPIN?\r
ofonod[2534]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[2534]: Aux: > AT+CPIN?\r
ofonod[2534]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[2534]: Aux: > AT+CPIN?\r
ofonod[2534]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[2534]: examples/emulator.c:powered_watch() Adding modem 0x86e9a28 to the 
list
ofonod[2534]: examples/emulator.c:create_tcp() Created server_watch: 50
ofonod[2534]: examples/emulator.c:create_tcp() Created server_watch: 51
ofonod[2534]: src/modem.c:modem_change_state() old state: 0, new state: 1
ofonod[2534]: plugins/speedup.c:speedup_pre_sim() 0x86e9a28
ofonod[2534]: Aux: > AT+GCAP\r
ofonod[2534]: Modem: > AT&C0\r
ofonod[2534]: src/sim.c:ofono_sim_add_state_watch() 0x86ea1d8
ofonod[2534]: src/sim.c:ofono_sim_add_state_watch() 0x86ea1d8
ofonod[2534]: src/sim.c:ofono_sim_add_state_watch() 0x86ea1d8
ofonod[2534]: Modem: < \r\nOK\r\n
ofonod[2534]: Aux: < \r\n+GCAP: +CGSM,+DS,+ES\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT&C0\r
ofonod[2534]: Aux: < \r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,12258\r
ofonod[2534]: Aux: < \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0
ofonod[2534]: Aux: > AT+CGMI\r
ofonod[2534]: Aux: < \r\nManufacturer\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,28421\r
ofonod[2534]: Aux: < \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0
ofonod[2534]: Aux: > AT+CGMM\r
ofonod[2534]: Aux: < \r\nHSPA USB MODEM\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,12037\r
ofonod[2534]: Aux: < \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0
ofonod[2534]: Aux: > AT+CGMR\r
ofonod[2534]: Aux: < \r\nLWA6R04.1.0_MG35\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CPIN?\r
ofonod[2534]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_cpin_cb() crsm_pin_cb: READY
ofonod[2534]: drivers/atmodem/sim.c:at_pin_retries_query() 
ofonod[2534]: Aux: > AT+CGSN\r
ofonod[2534]: Aux: < \r\n355132040087829\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CPNNUM\r
ofonod[2534]: Aux: < \r\nPIN1=3; PUK1=10; PIN2=3; PUK2=10\r\r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,28590\r
ofonod[2534]: Aux: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,28589\r
ofonod[2534]: Aux: < \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0
ofonod[2534]: Aux: > AT+CRSM=192,28438\r
ofonod[2534]: Aux: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CRSM=192,28472\r
ofonod[2534]: Aux: < \r\n+CRSM: 144,0,""\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0
ofonod[2534]: Aux: > AT+CIMI\r
ofonod[2534]: Aux: < \r\n208012901711415\r\n\r\nOK\r\n
ofonod[2534]: drivers/atmodem/sim.c:at_cimi_cb() cimi_cb: 208012901711415
ofonod[2534]: src/modem.c:modem_change_state() old state: 1, new state: 2
ofonod[2534]: plugins/speedup.c:speedup_post_sim() 0x86e9a28
ofonod[2534]: drivers/atmodem/gprs-context.c:at_gprs_context_probe() 
ofonod[2534]: Example History Probe for modem: 0x86e9a28
ofonod[2534]: Example Network Time Probe for modem: 0x86e9a28
ofonod[2534]: src/modem.c:modem_change_state() old state: 2, new state: 3
ofonod[2534]: Aux: > AT+CREG=?\r
ofonod[2534]: Aux: < \r\n+CREG: (0-2)\r\n\r\nOK\r\n
ofonod[2534]: Aux: > AT+CSCB=?\r
ofonod[2534]: Aux: < \r\n+CSCB: (0-1)\r\n\r\nOK\r\n
ofon

RE: [PATCH] huawei: cleanup sim polling when the modem is removed.

[Aygon, Bertrand]

Hi Marcel,

> > > > > We call disable before we call remove, but the only thing that
> I
> > > have
> > > > > not checked is what happens to this if we have not succeeded
> with
> > > > > enable
> > > > > yet. So if I remember this right, then disable is always called
> > > (even
> > > > > if
> > > > > enable has not yet called set_powered), but I need Denis to
> confirm
> > > > > this.
> > > >
> > > > Except in the unplug test.
> > >
> > > it is just the race condition for the time enable is running. Once
> the
> > > modem is properly enabled, even the unplug case is fine.
> > >
> > > ofonod[14344]: plugins/udev.c:udev_event() subsystem net remove
> > > ofonod[14344]: plugins/udev.c:remove_modem()
> > > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/net/wwan0
> > > ofonod[14344]: src/modem.c:get_modem_property() modem 0x7beff0
> property
> > > Path
> > > ofonod[14344]: src/modem.c:ofono_modem_remove() 0x7beff0
> > > ofonod[14344]: src/modem.c:modem_unregister() 0x7beff0
> > > ofonod[14344]: src/modem.c:modem_change_state() old state: 2, new
> > > state: 0
> > > ofonod[14344]: src/modem.c:flush_atoms()
> > > ofonod[14344]: Example Network Time Remove for modem: 0x7beff0
> > > ofonod[14344]: Example History Remove for modem: 0x7beff0
> > > ofonod[14344]: src/gprs.c:gprs_context_unregister() 0x7be230,
> 0x7bc8c0
> > > ofonod[14344]: src/gprs.c:gprs_context_remove() atom: 0x7be270
> > > ofonod[14344]: drivers/atmodem/gprs-
> context.c:at_gprs_context_remove()
> > > ofonod[14344]: Unregistered handle for channel 1: 0x1
> > > ofonod[14344]: src/gprs.c:gprs_unregister() 0x7bc8c0
> > > ofonod[14344]: src/gprs.c:gprs_remove() atom: 0x7bd840
> > > ofonod[14344]: plugins/push-
> notification.c:push_notification_cleanup()
> > > 0x7ba6a0
> > > ofonod[14344]: plugins/smart-messaging.c:smart_messaging_cleanup()
> > > 0x7ba640
> > > ofonod[14344]: src/sms.c:sms_remove() atom: 0x7bf300
> > > ofonod[14344]: src/radio-settings.c:radio_settings_remove() atom:
> > > 0x7bea90
> > > ofonod[14344]: src/phonebook.c:phonebook_remove() atom: 0x7ba400
> > > ofonod[14344]: src/sim.c:sim_remove() atom: 0x7b8b00
> > > ofonod[14344]: src/modem.c:devinfo_remove() atom: 0x7b8d00
> > > ofonod[14344]: plugins/huawei.c:huawei_disable() 0x7beff0
> > > ofonod[14344]: plugins/huawei.c:huawei_remove() 0x7beff0
> > >
> > > We do call disable before we call remove in the "clean" unplug
> case. So
> > > that is not the problem.
> >
> > Ok, I get it.
> 
> I will check with Denis if we are going to do something more
> sophisticated or leave this up to the modem plugins to figure it out.
> However I went back through the code and came up with this conclusion.
> 
> We do not need to check anything in the disable callback, since if
> enable succeeds or fails, we clean up the poll sources. And if enable
> never succeeds, then disable is never called. So that should be just
> fine. No leaks here.
> 
> The only thing that I have not checked is if we can actually call the
> disable modem D-Bus function while enable is in progress and what
> happens in that case. I just do not have had time to confirm this case
> and what is the order of callbacks and events in that case. Or if we
> just block that D-Bus.
> 
> So right now, when we have to clean something up, the only rare case is
> that when enabling was in progress and we unplug the dongle during
> that.
> This means that your original patches were correct and fixed this case.
> I did some simplification in the SIM state polling free function and
> added comments to all of them and applied them.
> 
> While doing that, I realized also another race condition in the Huawei
> modem plugin, where the online enabling polling might race against some
> calling disable. I fixed that one as well.

Ok this is perfect.

Thanks for the 'complete' fix.

Regards,

Bertrand
-
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: [PATCH] huawei: cleanup sim polling when the modem is removed.

[Aygon, Bertrand]

Hi Marcel,

> > > We call disable before we call remove, but the only thing that I
> have
> > > not checked is what happens to this if we have not succeeded with
> > > enable
> > > yet. So if I remember this right, then disable is always called
> (even
> > > if
> > > enable has not yet called set_powered), but I need Denis to confirm
> > > this.
> >
> > Except in the unplug test.
> 
> it is just the race condition for the time enable is running. Once the
> modem is properly enabled, even the unplug case is fine.
> 
> ofonod[14344]: plugins/udev.c:udev_event() subsystem net remove
> ofonod[14344]: plugins/udev.c:remove_modem()
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/net/wwan0
> ofonod[14344]: src/modem.c:get_modem_property() modem 0x7beff0 property
> Path
> ofonod[14344]: src/modem.c:ofono_modem_remove() 0x7beff0
> ofonod[14344]: src/modem.c:modem_unregister() 0x7beff0
> ofonod[14344]: src/modem.c:modem_change_state() old state: 2, new
> state: 0
> ofonod[14344]: src/modem.c:flush_atoms()
> ofonod[14344]: Example Network Time Remove for modem: 0x7beff0
> ofonod[14344]: Example History Remove for modem: 0x7beff0
> ofonod[14344]: src/gprs.c:gprs_context_unregister() 0x7be230, 0x7bc8c0
> ofonod[14344]: src/gprs.c:gprs_context_remove() atom: 0x7be270
> ofonod[14344]: drivers/atmodem/gprs-context.c:at_gprs_context_remove()
> ofonod[14344]: Unregistered handle for channel 1: 0x1
> ofonod[14344]: src/gprs.c:gprs_unregister() 0x7bc8c0
> ofonod[14344]: src/gprs.c:gprs_remove() atom: 0x7bd840
> ofonod[14344]: plugins/push-notification.c:push_notification_cleanup()
> 0x7ba6a0
> ofonod[14344]: plugins/smart-messaging.c:smart_messaging_cleanup()
> 0x7ba640
> ofonod[14344]: src/sms.c:sms_remove() atom: 0x7bf300
> ofonod[14344]: src/radio-settings.c:radio_settings_remove() atom:
> 0x7bea90
> ofonod[14344]: src/phonebook.c:phonebook_remove() atom: 0x7ba400
> ofonod[14344]: src/sim.c:sim_remove() atom: 0x7b8b00
> ofonod[14344]: src/modem.c:devinfo_remove() atom: 0x7b8d00
> ofonod[14344]: plugins/huawei.c:huawei_disable() 0x7beff0
> ofonod[14344]: plugins/huawei.c:huawei_remove() 0x7beff0
> 
> We do call disable before we call remove in the "clean" unplug case. So
> that is not the problem.

Ok, I get it.

Thanks,

Bertrand
-
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: [PATCH] huawei: cleanup sim polling when the modem is removed.

[Aygon, Bertrand]

Hi Marcel,

> >  plugins/huawei.c |3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/plugins/huawei.c b/plugins/huawei.c
> > index 1380369..eaf8b07 100644
> > --- a/plugins/huawei.c
> > +++ b/plugins/huawei.c
> > @@ -107,6 +107,9 @@ static void huawei_remove(struct ofono_modem
> *modem)
> > /* Cleanup after hot-unplug */
> > g_at_chat_unref(data->pcui);
> >
> > +   if (data->sysinfo_poll_source)
> > +   g_source_remove(data->sysinfo_poll_source);
> > +
> > g_free(data);
> >  }
> 
> so actually you do not wanna do this in the remove callback. You wanna
> do this in the disable callback just before you cancel all pending
> commands.

Ok, but it will not fix the crash I have saw and that conclude to this fix. If 
we unplug the modem during the init, we go directly to remove_modem, and not 
going through disable_modem.

So maybe we have to put this in both places.

> Doing this in the remove callback has the potential problem that you
> might poll CPIN while trying to execute CFUN. In theory this does not
> matter since GAtChat will not execute commands at the same time, but
> why
> bother keeping the timeout running if we already know that we are going
> to shutdown the device.
> 
> We call disable before we call remove, but the only thing that I have
> not checked is what happens to this if we have not succeeded with
> enable
> yet. So if I remember this right, then disable is always called (even
> if
> enable has not yet called set_powered), but I need Denis to confirm
> this.

Except in the unplug test.

Regards,

Bertrand
-
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: [PATCH 1/2] cbs: split the topics list for ZTE modem.

[Aygon, Bertrand]

Hi,

> > > > /* For the Qualcomm based devices it is required to clear
> > > >  * the list of topics first.  Otherwise setting the new
> > > > @@ -128,14 +180,40 @@ static void at_cbs_set_topics(struct
> ofono_cbs
> > > *cbs, const char *topics,
> > > > g_at_chat_send(data->chat, "AT+CSCB=1", none_prefix,
> > > > NULL, NULL, NULL);
> > > > break;
> > > > +   case OFONO_VENDOR_ZTE:
> > > > +   data->string_limit = 50;
> > > > +   g_at_chat_send(data->chat, "AT+CSCB=1", none_prefix,
> > > > +   NULL, NULL, NULL);
> > > > +   break;
> > >
> > > Why are we copying the Qualcomm quirk over for ZTE?
> >
> > Because previously, ZTE modem is using QUALCOMM vendor for CBS
> creation.
> > So I do not want to change this behaviour.
> 
> test it again. I am not even 100% that ZTE needs this behavior if the
> limitation was on the command line length. However it might. So please
> double check and comment it properly.


Ok, so ZTE require the CSCB=1 in case the topic is already set:

at+cscb=1
OK
AT+CSCB=0,"2000,3000,4000,5000,6000,7000,8000,9000,1"

OK
at+cscb?
+CSCB: 0, "1,9000,8000,7000,6000,5000,4000,3000,2000",""

OK
AT+CSCB=0,"2000,3000,4000,5000,6000,7000,8000,9000,1"

+CMS ERROR: 302

Regards,

Bertrand
-
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: [PATCH 1/2] cbs: split the topics list for ZTE modem.

[Aygon, Bertrand]

Hi Marcel,

Thanks for your review.

> >  drivers/atmodem/cbs.c |   86
> +++--
> >  1 files changed, 83 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/atmodem/cbs.c b/drivers/atmodem/cbs.c
> > index e2e1ca4..3c250d2 100644
> > --- a/drivers/atmodem/cbs.c
> > +++ b/drivers/atmodem/cbs.c
> > @@ -47,6 +47,8 @@ struct cbs_data {
> > GAtChat *chat;
> > gboolean cscb_mode_1;
> > unsigned int vendor;
> > +   unsigned int string_limit;
> > +   gchar *rt; /* remaining topics */
> 
> Using rt is not a good variable name.

Ok, I will use r_topics. I would prefer to avoid remaining_topics, to help with 
80c limitation.

> >  };
> >
> >  static void at_cbm_notify(GAtResult *result, gpointer user_data)
> > @@ -105,6 +107,56 @@ static void at_cscb_set_cb(gboolean ok,
> GAtResult *result, gpointer user_data)
> > cb(&error, cbd->data);
> >  }
> >
> > +static void at_cscb_set_cb_split(gboolean ok, GAtResult *result,
> gpointer user_data)
> > +{
> > +   struct cb_data *cbd = user_data;
> > +   struct cbs_data *data = ofono_cbs_get_data(cbd->user);
> > +   ofono_cbs_set_cb_t cb = cbd->cb;
> > +   char *buf;
> > +   unsigned int id;
> > +
> > +   DBG("%s", data->rt);
> 
> Where is the handling if this command responds with ERROR?

Oops, I missed it. I will include it.

> 
> > +   if (strlen(data->rt) > data->string_limit) {
> > +   gchar *topics_split  = g_strndup(data->rt, data-
> >string_limit);
> > +   gchar *new_rt;
> > +
> > +   if (data->rt[data->string_limit] != ',') {
> > +   char *token = strrchr(topics_split, ',');
> > +   *token = 0;
> > +   }
> > +
> > +   new_rt = g_strdup((char *) ((void *) data->rt +
> > +   strlen(topics_split) + 1));
> > +
> > +   g_free(data->rt);
> > +   data->rt = new_rt;
> 
> This is code duplication. Split it our into a proper helper function.

Ok.

> > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", topics_split);
> > +
> > +   id = g_at_chat_send(data->chat, buf, none_prefix,
> > +   at_cscb_set_cb_split, cbd, NULL);
> > +
> > +   g_free(topics_split);
> > +   } else {
> > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", data->rt);
> > +
> > +   id = g_at_chat_send(data->chat, buf, none_prefix,
> > +   at_cscb_set_cb, cbd, NULL);
> 
> This is a memory leak btw. Who is freeing cbd?

I will add the g_free is the GDestroyNotify.

> > +   g_free(data->rt);
> > +   }
> > +
> > +   g_free(buf);
> > +
> > +   if (id > 0)
> > +   return;
> > +
> > +   g_free(cbd);
> > +
> > +   CALLBACK_WITH_FAILURE(cb, user_data);
> > +}
> > +
> >  static void at_cbs_set_topics(struct ofono_cbs *cbs, const char
> *topics,
> > ofono_cbs_set_cb_t cb, void *user_data)
> >  {
> > @@ -113,7 +165,7 @@ static void at_cbs_set_topics(struct ofono_cbs
> *cbs, const char *topics,
> > char *buf;
> > unsigned int id;
> >
> > -   DBG("");
> > +   DBG("%s", topics);
> >
> > /* For the Qualcomm based devices it is required to clear
> >  * the list of topics first.  Otherwise setting the new
> > @@ -128,14 +180,40 @@ static void at_cbs_set_topics(struct ofono_cbs
> *cbs, const char *topics,
> > g_at_chat_send(data->chat, "AT+CSCB=1", none_prefix,
> > NULL, NULL, NULL);
> > break;
> > +   case OFONO_VENDOR_ZTE:
> > +   data->string_limit = 50;
> > +   g_at_chat_send(data->chat, "AT+CSCB=1", none_prefix,
> > +   NULL, NULL, NULL);
> > +   break;
> 
> Why are we copying the Qualcomm quirk over for ZTE?

Because previously, ZTE modem is using QUALCOMM vendor for CBS creation.
So I do not want to change this behaviour.

> > default:
> > break;
> > }
> >
> > -   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", topics);
> > +   if (data->string_limit && strlen(topics) > data->string_limit) {
> > +   gchar *topics_split = g_strndup(topics, data-
> >string_limit);
> > +
> > +   if (topics[data->string_limit] != ',') {
> > +   char *token = strrchr(topics_split, ',');
> > +   *token = 0;
> > +   }
> > +
> > +   data->rt = g_strdup((char *) ((void *) topics +
> > +   strlen(topics_split) + 1));
> > +
> > +   cbd->user = cbs;
> >
> > -   id = g_at_chat_send(data->chat, buf, none_prefix,
> > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", topics_split);
> > +
> > +   id = g_at_chat_send(data->chat, buf, none_prefix,
> > +   at_cscb_set_cb_split, cbd, NULL);
> > +
> > +   g_free(topics_split);
> > +   } else {
> > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", topics);
> > +
> > +   id = g_at_chat_send(data->chat, buf, none

RE: [PATCH 1/2] cbs: send topics one by one for ZTE modem.

[Aygon, Bertrand]

Hi,

> > > > +
> > > > +   if (send_by_one) {
> > > > +   gchar **topic_list = NULL;
> > > > +   gchar **topic_list_orig = NULL;
> > > > +
> > > > +   topic_list = topic_list_orig = g_strsplit_set(topics, 
> > > > ",",
> -1);
> > > > +
> > > > +   for (; *topic_list; topic_list++) {
> > > > +   struct cb_data *cbd = cb_data_new(cb, 
> > > > user_data);
> > > > +
> > > > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"",
> *topic_list);
> > > >
> > > > -   id = g_at_chat_send(data->chat, buf, none_prefix,
> > > > +   id = g_at_chat_send(data->chat, buf, 
> > > > none_prefix,
> > > > at_cscb_set_cb, cbd, g_free);
> > >
> > > So this is not going to work out as nicely as you might think it would.
> > > You keep calling ofono_cbs_set_cb_t callback now for every single topic
> > > you send. And also as a result, the D-Bus call returns successful after
> > > the first one.
> >
> > OK, I see.
> >
> > > You need to properly queue this and properly fail and roll back in case
> > > of a failure.
> >
> > Roll back? You means that if there is a failure in the middle of sending,
> you want to send AT command to remove the first topics?
> 
> at minimum clear all topics again.

Ok, I will do this.

> > > I addition to that, I would prefer to send as many topics at once as
> > > possible. So how many can ZTE set at once?
> >
> > I can do some test, but I think that it's not related to topics, but to AT
> command length. And we cannot guaranty to find another model more restrictive.
> Sending one by one seems to be the 'safest' solution.
> 
> Please check this. And AT command length limitation would be funny. Not
> unlikely, but funny.
> 
> And while at it, please check if it is actually capable of handling any
> kind of topic ranges properly. You currently only split the topics, but
> have no special handling for ranges. So if the modem does not handle
> topic ranges, then you have a problem here.

Topic range is OK. You can have a look at the log.

ofonod[2040]: Aux: > AT+CSCB=0,"4352-4356"\r
ofonod[2040]: Aux: < \r\nOK\r\n

> For example if it can only set 10 topics at once, and you give 1-11. Is
> this 11 topics and the modem can handle it. Or it can handle only 10
> topics and would fail.
> 
> Another thing that came to mind, please check that it actually adds the
> topics and not just overwrites it. Some manufactures don't read the AT
> command specification carefully.

Seems to be fine.

So as you can see in the log, I have found the 'limit'.

at+cscb=0, "4352-4356,11000,1,9000,8000,7000,6000,5000,1,2"

OK

at+cscb=0, "4352-4356,11000,1,9000,8000,7000,6000,5000,1,21"

ERROR

50 characters inside the string is OK, but 51 not.

So do you prefer to use such limit, instead of sending one by one?

Regards,

Bertrand


-
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.
ofonod[2040]: Aux: > AT+CSCB=1\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"0"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"11"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"30"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"50"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"53"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"97"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"101"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"130"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"237"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"2000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"3000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"4000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"5000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"6000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"7000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"8000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"9000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"1"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"11000"\r
ofonod[2040]: Aux: < \r\nOK\r\n
ofonod[2040]: Aux: > AT+CSCB=0,"4352-4356"\r
ofonod[2040]: Aux: < \r\nOK\r\n

Using minicom:

at+cscb?

+CSCB: 

RE: [PATCH 1/2] cbs: send topics one by one for ZTE modem.

[Aygon, Bertrand]

Hi Marcel,

> >  drivers/atmodem/cbs.c |   58 ++
> --
> >  1 files changed, 50 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/atmodem/cbs.c b/drivers/atmodem/cbs.c
> > index e2e1ca4..4673a77 100644
> > --- a/drivers/atmodem/cbs.c
> > +++ b/drivers/atmodem/cbs.c
> > @@ -109,9 +109,9 @@ static void at_cbs_set_topics(struct ofono_cbs *cbs,
> const char *topics,
> > ofono_cbs_set_cb_t cb, void *user_data)
> >  {
> > struct cbs_data *data = ofono_cbs_get_data(cbs);
> > -   struct cb_data *cbd = cb_data_new(cb, user_data);
> > char *buf;
> > -   unsigned int id;
> > +   unsigned int id = 0;
> > +   gboolean send_by_one = FALSE;
> >
> > DBG("");
> >
> > @@ -125,6 +125,7 @@ static void at_cbs_set_topics(struct ofono_cbs *cbs,
> const char *topics,
> > switch (data->vendor) {
> > case OFONO_VENDOR_GOBI:
> > case OFONO_VENDOR_QUALCOMM_MSM:
> > +   case OFONO_VENDOR_ZTE:
> > g_at_chat_send(data->chat, "AT+CSCB=1", none_prefix,
> > NULL, NULL, NULL);
> > break;
> > @@ -132,17 +133,58 @@ static void at_cbs_set_topics(struct ofono_cbs *cbs,
> const char *topics,
> > break;
> > }
> >
> > -   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", topics);
> > +   /* Some ZTE modem doesn't support sending a long AT command
> > +* so we send topics one by one
> > +*/
> > +   switch (data->vendor) {
> > +   case OFONO_VENDOR_ZTE:
> > +   send_by_one = TRUE;
> > +   break;
> > +   default:
> > +   break;
> > +   }
> 
> so we already have a vendor switch statement a few lines above. Why
> bother introducing another one here?

Ok, I will use the first one.

> > +
> > +   if (send_by_one) {
> > +   gchar **topic_list = NULL;
> > +   gchar **topic_list_orig = NULL;
> > +
> > +   topic_list = topic_list_orig = g_strsplit_set(topics, ",", -1);
> > +
> > +   for (; *topic_list; topic_list++) {
> > +   struct cb_data *cbd = cb_data_new(cb, user_data);
> > +
> > +   buf = g_strdup_printf("AT+CSCB=0,\"%s\"", *topic_list);
> >
> > -   id = g_at_chat_send(data->chat, buf, none_prefix,
> > +   id = g_at_chat_send(data->chat, buf, none_prefix,
> > at_cscb_set_cb, cbd, g_free);
> 
> So this is not going to work out as nicely as you might think it would.
> You keep calling ofono_cbs_set_cb_t callback now for every single topic
> you send. And also as a result, the D-Bus call returns successful after
> the first one.

OK, I see.

> You need to properly queue this and properly fail and roll back in case
> of a failure.

Roll back? You means that if there is a failure in the middle of sending, you 
want to send AT command to remove the first topics?

> I addition to that, I would prefer to send as many topics at once as
> possible. So how many can ZTE set at once?

I can do some test, but I think that it's not related to topics, but to AT 
command length. And we cannot guaranty to find another model more restrictive. 
Sending one by one seems to be the 'safest' solution.

Regards,

Bertrand
-
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

Huawei E398 and E367

[Aygon, Bertrand]

Hi Marcel,

I saw that you add an oFono.rules to support E398 Huawei modem. And for this 
modem, you are using interface 0 for Modem and 1 for Pcui. This mode has a 
VID/PID after switch 12d1:1506.

But I have a Huawei E367, which also switch to 12d1:1506, but which is not 
using the same tty.

The E3667 has five tty, but only ttyUSB0 and ttyUSB4 can send/recv AT command.

Is your dongle also have a ttUSB4 that could be used?

How can we handle such cases?

Thanks,

Bertrand.

--
Bertrand Aygon  Engineering Manager
bertrand.ay...@intel.comOpen 
Source Technology Center, Intel Corporation

-
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: [PATCH] speedup: during enable, we have to go offline first.

[Aygon, Bertrand]

Hi,

> > > > Some other comments along the lines for this modem:
> > > >
> > > > ofonod[26439]: Aux: > AT+CSCB=?\r
> > > > ofonod[26439]: Aux: < \r\nERROR\r\n
> > > > ofonod[26439]: CSCB not supported
> > > >
> > > > Since CBS is not supported, do not even bother creating that atom.
> > >
> > > As I explained, all those errors are due to the CPIN=1. If we are in
> CFUN=4,
> > it seems that we have to wait after sending the CFUN=1 to goes online.
> > >
> > > I have attached a full log with only CFUN=1 and no CFUN=4. I have replaced
> > the CFUN=4 by a CFUN=1.
> > >
> > > You will see that CBS is supported, USSD also...
> >
> > if this hardware can not deal with online/offline mode changes proper
> > then just remove the set_online modem driver callback and treat it like
> > a really dumb stupid device.
> >
> > Only then you can go directly into CFUN=1 and stay there. Otherwise you
> > are violating online/offline semantics of oFono.
> 
> Ok, I will do this.

Here is the result. I have attach the log, and everything looks fine.

Thanks again, I am preparing the patch.

Regards,

Bertrand
-
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.
ofonod[28720]: src/modem.c:ofono_modem_create() name: (null), type: speedup
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property Path
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property 
Registered
ofonod[28720]: plugins/udev.c:add_modem() 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.1/ttyUSB1/tty/ttyUSB1 
(speedup)
ofonod[28720]: plugins/udev.c:add_speedup() modem 0x904db70
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
ModemRegistered
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
AuxRegistered
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property Modem
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property 
ModemRegistered
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property Path
ofonod[28720]: plugins/udev.c:add_modem() 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.2/ttyUSB2/tty/ttyUSB2 
(speedup)
ofonod[28720]: plugins/udev.c:add_speedup() modem 0x904db70
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
ModemRegistered
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
AuxRegistered
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property Aux
ofonod[28720]: src/modem.c:set_modem_property() modem 0x904db70 property 
AuxRegistered
ofonod[28720]: plugins/speedup.c:speedup_probe() 0x904db70
ofonod[28720]: plugins/hfp_ag.c:modem_watch() modem: 0x904db70, added: 1
ofonod[28720]: plugins/dun_gw.c:modem_watch() modem: 0x904db70, added: 1
ofonod[28720]: examples/emulator.c:modem_watch() modem: 0x904db70, added: 1
ofonod[28720]: plugins/smart-messaging.c:modem_watch() modem: 0x904db70, added: 
1
ofonod[28720]: plugins/push-notification.c:modem_watch() modem: 0x904db70, 
added: 1
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property Path
ofonod[28720]: plugins/udev.c:add_modem() 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/ttyUSB0/tty/ttyUSB0 
(speedup)
ofonod[28720]: plugins/udev.c:add_speedup() modem 0x904db70
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
ModemRegistered
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property 
AuxRegistered
ofonod[28720]: plugins/speedup.c:speedup_enable() 0x904db70
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property Modem
ofonod[28720]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
ofonod[28720]: src/modem.c:get_modem_property() modem 0x904db70 property Aux
ofonod[28720]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
ofonod[28720]: Modem: > ATE0 +CMEE=1\r
ofonod[28720]: Aux: > ATE0 +CMEE=1\r
ofonod[28720]: Aux: < ATE0 +CMEE=1\r\r\nOK\r\n
ofonod[28720]: Aux: > AT+CFUN=1\r
ofonod[28720]: Modem: < \r\nOK\r\n
ofonod[28720]: Aux: < \r\nOK\r\n
ofonod[28720]: plugins/speedup.c:cfun_enable() 
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28720]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28720]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28720]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28720]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28720]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[28720]: Aux: > AT+CPIN?\r
ofonod[28

RE: [PATCH] speedup: during enable, we have to go offline first.

[Aygon, Bertrand]

Hi,

> > > Some other comments along the lines for this modem:
> > >
> > > ofonod[26439]: Aux: > AT+CSCB=?\r
> > > ofonod[26439]: Aux: < \r\nERROR\r\n
> > > ofonod[26439]: CSCB not supported
> > >
> > > Since CBS is not supported, do not even bother creating that atom.
> >
> > As I explained, all those errors are due to the CPIN=1. If we are in CFUN=4,
> it seems that we have to wait after sending the CFUN=1 to goes online.
> >
> > I have attached a full log with only CFUN=1 and no CFUN=4. I have replaced
> the CFUN=4 by a CFUN=1.
> >
> > You will see that CBS is supported, USSD also...
> 
> if this hardware can not deal with online/offline mode changes proper
> then just remove the set_online modem driver callback and treat it like
> a really dumb stupid device.
> 
> Only then you can go directly into CFUN=1 and stay there. Otherwise you
> are violating online/offline semantics of oFono.

Ok, I will do this.

Thanks for your support,

Bertrand
-
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: [PATCH] speedup: during enable, we have to go offline first.

[Aygon, Bertrand]

Hi Marcel,

> > > > >  plugins/speedup.c |2 +-
> > > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/plugins/speedup.c b/plugins/speedup.c
> > > > > index 90ca5e3..a7aa43c 100644
> > > > > --- a/plugins/speedup.c
> > > > > +++ b/plugins/speedup.c
> > > > > @@ -177,7 +177,7 @@ static int speedup_enable(struct ofono_modem
> *modem)
> > > > >   g_at_chat_send(data->modem, "ATE0 &C0 +CMEE=1", NULL, NULL, 
> > > > > NULL,
> > > > NULL);
> > > > >   g_at_chat_send(data->aux, "ATE0 &C0 +CMEE=1", NULL, NULL, NULL,
> NULL);
> > > > >
> > > > > - g_at_chat_send(data->aux, "AT+CFUN=1", NULL,
> > > > > + g_at_chat_send(data->aux, "AT+CFUN=4", NULL,
> > > > >   cfun_enable, modem, NULL);
> > > >
> > > > this is not a correct fix. You are messing up the logic here. You are
> > > > still in offline mode from an oFono point of view, but your modem is
> > > > actually online.
> > > >
> > > > Try the same that we did for ZTE with sending +CFUN=1;+CFUN=4 if that
> > > > works out.
> > >
> > > This is not working:
> > >
> > > ofonod[17315]: plugins/speedup.c:speedup_enable() 0x9ae1af8
> > > ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property
> Modem
> > > ofonod[17315]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
> > > ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property
> Aux
> > > ofonod[17315]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
> > > ofonod[17315]: Modem: > ATE0 +CMEE=1\r
> > > ofonod[17315]: Aux: > ATE0 +CMEE=1\r
> > > ofonod[17315]: Aux: < ATE0 +CMEE=1\r
> > > ofonod[17315]: Modem: < \r\nOK\r\n
> > > ofonod[17315]: Aux: < \r\nOK\r\n
> > > ofonod[17315]: Aux: > AT+CFUN=1;+CFUN=4\r
> > > ofonod[17315]: Aux: < \r\n+CME ERROR: 0\r\n
> > > ofonod[17315]: plugins/speedup.c:cfun_enable()
> > >
> > >
> > > > If not, then check if we can go CFUN=1 first and then after SIM query
> > > > succeeded, we go into CFUN=4. We do this for Huawei actually.
> > >
> > > I will try this...
> >
> > I have attach the log. There is an issue. The AT command just after the
> CFUN=1 to go online are failing. I guess that we have to do some timing stuff,
> because if I use minicom to send the AT+CREG=? Later, the answer is correct.
> 
> actually you can only do set_powered() after the CFUN=4 succeeded. You
> need to feed that into your modem enabling procedure.
> 
> ofonod[26439]: src/modem.c:modem_change_state() old state: 0, new state: 1
> ofonod[26439]: plugins/speedup.c:speedup_pre_sim() 0x8909ae0
> ofonod[26439]: Aux: > AT+GCAP\r
> ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
> ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
> ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
> ofonod[26439]: Aux: < \r\n+GCAP: +CGSM,+FCLASS,+DS\r\n\r\nOK\r\n
> ofonod[26439]: Aux: > AT+CFUN=4\r
> ofonod[26439]: Aux: < \r\nOK\r\n
> 
> The log clearly shows that you power on the modem before sending CFUN=4.
> Try to change that.
> 
> Some other comments along the lines for this modem:
> 
> ofonod[26439]: Aux: > AT+CSCB=?\r
> ofonod[26439]: Aux: < \r\nERROR\r\n
> ofonod[26439]: CSCB not supported
> 
> Since CBS is not supported, do not even bother creating that atom.

As I explained, all those errors are due to the CPIN=1. If we are in CFUN=4, it 
seems that we have to wait after sending the CFUN=1 to goes online.

I have attached a full log with only CFUN=1 and no CFUN=4. I have replaced the 
CFUN=4 by a CFUN=1.

You will see that CBS is supported, USSD also...

Regards,

Bertrand
-
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.
ofonod[27494]: plugins/speedup.c:speedup_enable() 0x8c50b50
ofonod[27494]: src/modem.c:get_modem_property() modem 0x8c50b50 property Modem
ofonod[27494]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
ofonod[27494]: src/modem.c:get_modem_property() modem 0x8c50b50 property Aux
ofonod[27494]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
ofonod[27494]: Modem: > ATE0 +CMEE=1\r
ofonod[27494]: Aux: > ATE0 +CMEE=1\r
ofonod[27494]: Aux: < ATE0 +CMEE=1\r\r\nOK\r\n
ofonod[27494]: Aux: > AT+CFUN=1\r
ofonod[27494]: Modem: < \r\nOK\r\n
ofonod[27494]: Aux: < \r\nOK\r\n
ofonod[27494]: plugins/speedup.c:cfun_enable() 
ofonod[27494]: Aux: > AT+CPIN?\r
ofonod[27494]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[27494]: Aux: > AT+CPIN?\r
ofonod[27494]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[27494]: examples/emulator.c:powered_watch() Adding modem 0x8c50

RE: [PATCH] speedup: during enable, we have to go offline first.

[Aygon, Bertrand]

Hi Marcel,

> > >  plugins/speedup.c |2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/plugins/speedup.c b/plugins/speedup.c
> > > index 90ca5e3..a7aa43c 100644
> > > --- a/plugins/speedup.c
> > > +++ b/plugins/speedup.c
> > > @@ -177,7 +177,7 @@ static int speedup_enable(struct ofono_modem *modem)
> > >   g_at_chat_send(data->modem, "ATE0 &C0 +CMEE=1", NULL, NULL, NULL,
> > NULL);
> > >   g_at_chat_send(data->aux, "ATE0 &C0 +CMEE=1", NULL, NULL, NULL, NULL);
> > >
> > > - g_at_chat_send(data->aux, "AT+CFUN=1", NULL,
> > > + g_at_chat_send(data->aux, "AT+CFUN=4", NULL,
> > >   cfun_enable, modem, NULL);
> >
> > this is not a correct fix. You are messing up the logic here. You are
> > still in offline mode from an oFono point of view, but your modem is
> > actually online.
> >
> > Try the same that we did for ZTE with sending +CFUN=1;+CFUN=4 if that
> > works out.
> 
> This is not working:
> 
> ofonod[17315]: plugins/speedup.c:speedup_enable() 0x9ae1af8
> ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property Modem
> ofonod[17315]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
> ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property Aux
> ofonod[17315]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
> ofonod[17315]: Modem: > ATE0 +CMEE=1\r
> ofonod[17315]: Aux: > ATE0 +CMEE=1\r
> ofonod[17315]: Aux: < ATE0 +CMEE=1\r
> ofonod[17315]: Modem: < \r\nOK\r\n
> ofonod[17315]: Aux: < \r\nOK\r\n
> ofonod[17315]: Aux: > AT+CFUN=1;+CFUN=4\r
> ofonod[17315]: Aux: < \r\n+CME ERROR: 0\r\n
> ofonod[17315]: plugins/speedup.c:cfun_enable()
> 
> 
> > If not, then check if we can go CFUN=1 first and then after SIM query
> > succeeded, we go into CFUN=4. We do this for Huawei actually.
> 
> I will try this...

I have attach the log. There is an issue. The AT command just after the CFUN=1 
to go online are failing. I guess that we have to do some timing stuff, because 
if I use minicom to send the AT+CREG=? Later, the answer is correct.

> > If none of these work, then you need to remove the set_online callback
> > like we do for Nokia. If you can not support online/offline mode, then
> > don't even try to.
> >
> > And please show proper OFONO_AT_DEBUG traces. They can be part of the
> > commit message actually.
> >
 
Regards,

Bertrand
-
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.
ofonod[26439]: plugins/speedup.c:speedup_enable() 0x8909ae0
ofonod[26439]: src/modem.c:get_modem_property() modem 0x8909ae0 property Modem
ofonod[26439]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
ofonod[26439]: src/modem.c:get_modem_property() modem 0x8909ae0 property Aux
ofonod[26439]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
ofonod[26439]: Modem: > ATE0 +CMEE=1\r
ofonod[26439]: Aux: > ATE0 +CMEE=1\r
ofonod[26439]: Aux: < ATE0 +CMEE=1\r
ofonod[26439]: Modem: < \r\nOK\r\n
ofonod[26439]: Aux: < \r\nOK\r\n
ofonod[26439]: Aux: > AT+CFUN=1\r
ofonod[26439]: Aux: < \r\nOK\r\n
ofonod[26439]: plugins/speedup.c:cfun_enable() 
ofonod[26439]: Aux: > AT+CPIN?\r
ofonod[26439]: Aux: < \r\n+CME ERROR: 14\r\n
ofonod[26439]: Aux: > AT+CPIN?\r
ofonod[26439]: Aux: < \r\n+CPIN: READY\r\n\r\nOK\r\n
ofonod[26439]: examples/emulator.c:powered_watch() Adding modem 0x8909ae0 to 
the list
ofonod[26439]: examples/emulator.c:create_tcp() Created server_watch: 47
ofonod[26439]: examples/emulator.c:create_tcp() Created server_watch: 48
ofonod[26439]: src/modem.c:modem_change_state() old state: 0, new state: 1
ofonod[26439]: plugins/speedup.c:speedup_pre_sim() 0x8909ae0
ofonod[26439]: Aux: > AT+GCAP\r
ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
ofonod[26439]: src/sim.c:ofono_sim_add_state_watch() 0x890a348
ofonod[26439]: Aux: < \r\n+GCAP: +CGSM,+FCLASS,+DS\r\n\r\nOK\r\n
ofonod[26439]: Aux: > AT+CFUN=4\r
ofonod[26439]: Aux: < \r\nOK\r\n
ofonod[26439]: Aux: > AT+CGMI\r
ofonod[26439]: Aux: < \r\nManufacturer\r\n\r\nOK\r\n
ofonod[26439]: Aux: > AT+CRSM=192,12258,0,0,255\r
ofonod[26439]: Aux: < \r\n+CRSM: 
144,0,"62178202412183022FE28A01058B032F06158002000A880110"\r\n\r\nOK\r\n
ofonod[26439]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 25
ofonod[26439]: Aux: > AT+CGMM\r
ofonod[26439]: Aux: < \r\nHSPA USB MODEM\r\n\r\nOK\r\n
ofonod[26439]: Aux: > AT+CRSM=176,12258,0,0,10\r
ofonod[26439]: Aux: < \r\n+CRSM: 144,0,"98330133018086504021"\r\n\r\nOK\r\n
ofonod[26

RE: [PATCH] udev: Add support for SpeedUp 7300 EVDO modem.

[Aygon, Bertrand]

Hi Marcel,

> > > > diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> > > > index f8e485b..ab21f57 100644
> > > > --- a/plugins/ofono.rules
> > > > +++ b/plugins/ofono.rules
> > > > @@ -422,11 +422,15 @@ ATTRS{idVendor}=="19d2", ENV{OFONO_DRIVER}="zte"
> > > >
> > > >  ATTRS{idVendor}=="19d2", ATTRS{serial}=="1234567890ABCDEF",
> > > ENV{ID_SERIAL_SHORT}=""
> > > >
> > > > -# SpeedUp
> > > > -ATTRS{idVendor}=="1c9e", ENV{OFONO_DRIVER}="speedup"
> > > > +# SpeedUp 7300
> > > > +ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> > > ENV{OFONO_DRIVER}="speedupcdma"
> > > > +
> > > > +# SpeedUp 9800
> > > > +ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9800",
> > > ENV{OFONO_DRIVER}="speedup"
> > > >
> > > >  ATTRS{idVendor}=="1c9e", ATTRS{serial}=="1234567890ABCDEF",
> > > ENV{ID_SERIAL_SHORT}=""
> > >
> > > did you send the usb-devices output for these dongles to confirm that
> > > this serial number hack is still needed?
> >
> > Here it is:
> >
> > T:  Bus=02 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 20 Spd=480 MxCh= 0
> > D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > P:  Vendor=1c9e ProdID=9800 Rev=00.00
> > S:  Manufacturer=USB Modem
> > S:  Product=USB Modem
> > S:  SerialNumber=1234567890ABCDEF
> > C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
> > I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> > I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> > I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> > I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> > I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> 
> are you sure that SpeedUp for GSM is just not a re-branded ZTE dongle.
> They look as broken as the ZTE ones.
> 
> Same as SpeedUp for CDMA might be just a re-branded Huawei dongle.

I don't know. How can I check this?

I have not enough knowledge/background on ZTE/Huawei modem to tell you.

Did I just resubmit the patch with product id?

Regards,

Bertrand
-
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: [PATCH] speedup: during enable, we have to go offline first.

[Aygon, Bertrand]

Hi,

> >  plugins/speedup.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/plugins/speedup.c b/plugins/speedup.c
> > index 90ca5e3..a7aa43c 100644
> > --- a/plugins/speedup.c
> > +++ b/plugins/speedup.c
> > @@ -177,7 +177,7 @@ static int speedup_enable(struct ofono_modem *modem)
> > g_at_chat_send(data->modem, "ATE0 &C0 +CMEE=1", NULL, NULL, NULL,
> NULL);
> > g_at_chat_send(data->aux, "ATE0 &C0 +CMEE=1", NULL, NULL, NULL, NULL);
> >
> > -   g_at_chat_send(data->aux, "AT+CFUN=1", NULL,
> > +   g_at_chat_send(data->aux, "AT+CFUN=4", NULL,
> > cfun_enable, modem, NULL);
> 
> this is not a correct fix. You are messing up the logic here. You are
> still in offline mode from an oFono point of view, but your modem is
> actually online.
> 
> Try the same that we did for ZTE with sending +CFUN=1;+CFUN=4 if that
> works out.

This is not working:

ofonod[17315]: plugins/speedup.c:speedup_enable() 0x9ae1af8
ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property Modem
ofonod[17315]: plugins/speedup.c:open_device() Modem /dev/ttyUSB1
ofonod[17315]: src/modem.c:get_modem_property() modem 0x9ae1af8 property Aux
ofonod[17315]: plugins/speedup.c:open_device() Aux /dev/ttyUSB2
ofonod[17315]: Modem: > ATE0 +CMEE=1\r
ofonod[17315]: Aux: > ATE0 +CMEE=1\r
ofonod[17315]: Aux: < ATE0 +CMEE=1\r
ofonod[17315]: Modem: < \r\nOK\r\n
ofonod[17315]: Aux: < \r\nOK\r\n
ofonod[17315]: Aux: > AT+CFUN=1;+CFUN=4\r
ofonod[17315]: Aux: < \r\n+CME ERROR: 0\r\n
ofonod[17315]: plugins/speedup.c:cfun_enable()


> If not, then check if we can go CFUN=1 first and then after SIM query
> succeeded, we go into CFUN=4. We do this for Huawei actually.

I will try this...

> If none of these work, then you need to remove the set_online callback
> like we do for Nokia. If you can not support online/offline mode, then
> don't even try to.
> 
> And please show proper OFONO_AT_DEBUG traces. They can be part of the
> commit message actually.
> 

Regards,

Bertrand
-
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: [PATCH] udev: Add support for SpeedUp 7300 EVDO modem.

[Aygon, Bertrand]

Hi Marcel,

> > diff --git a/plugins/ofono.rules b/plugins/ofono.rules
> > index f8e485b..ab21f57 100644
> > --- a/plugins/ofono.rules
> > +++ b/plugins/ofono.rules
> > @@ -422,11 +422,15 @@ ATTRS{idVendor}=="19d2", ENV{OFONO_DRIVER}="zte"
> >
> >  ATTRS{idVendor}=="19d2", ATTRS{serial}=="1234567890ABCDEF",
> ENV{ID_SERIAL_SHORT}=""
> >
> > -# SpeedUp
> > -ATTRS{idVendor}=="1c9e", ENV{OFONO_DRIVER}="speedup"
> > +# SpeedUp 7300
> > +ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9e00",
> ENV{OFONO_DRIVER}="speedupcdma"
> > +
> > +# SpeedUp 9800
> > +ATTRS{idVendor}=="1c9e", ATTRS{idProduct}=="9800",
> ENV{OFONO_DRIVER}="speedup"
> >
> >  ATTRS{idVendor}=="1c9e", ATTRS{serial}=="1234567890ABCDEF",
> ENV{ID_SERIAL_SHORT}=""
> 
> did you send the usb-devices output for these dongles to confirm that
> this serial number hack is still needed?

Here it is:

T:  Bus=02 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 20 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9800 Rev=00.00
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=1234567890ABCDEF
C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

> > +# SpeedUp 8000
> >  ATTRS{idVendor}=="2020", ENV{OFONO_DRIVER}="speedup"
> 
> While you are changing this here anyway, please include the product ID
> as well.

Ok, I will add the ProductId 0x1800.

> >  ATTRS{idVendor}=="2020", ATTRS{serial}=="1234567890ABCDEF",
> ENV{ID_SERIAL_SHORT}=""
> 
> Same here.

Regards,

Bertrand
-
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: CDMA SIM atom

[Aygon, Bertrand]

Hi,

> > > > We are working on CDMA to enable some USB dongle, and we need to get the
> > > IMSI for the ConnMan interface, to create the interface name.
> > > >
> > > > We could use the AT SIM atom, since there should be no big difference
> > > between a CDMA SIM and a GSM SIM (same kind of functionality for SIM
> > > lock/unlock, same IMSI info).
> > > >
> > > > But we could also create a CDMA dedicated one. This will duplicate some
> > > code, but will be 'cleaner'.
> > > >
> > > > I would prefer the solution of a CDMA SIM atom, so CDMA plugins use only
> > > CDMA atom, but I would prefer to have the oFono community opinion before
> going
> > > into the code.
> > >
> > > you do not need an IMSI for ConnMan. You just need a proper unique
> > > identifier that is consistent. Using the hardware serial number in case
> > > of CDMA should be a good enough interim solution.
> >
> > The user can change its SIM card and put it in another dongle
> >
> > > We are using the IMSI for GSM since we wanna bind stored settings
> > > towards the SIM card. So that hardware swapping has no effect on the
> > > user experience.
> >
> > This is exactly what we also want to do with CDMA dongle.
> 
> I know CDMA dongles in theory have a SIM card, but not in practice. Or
> are you telling me the CDMA dongles you have, have SIM cards? And these
> SIM cards are used for anything?

The SpeedUp 7300 EVDA has a SIM card.
And I also got a Huawei CDMA dongle with SIM card, but I do not remember the 
model, I will give it to you later.

> > > With CDMA we could neglect this actually. So far all
> > > CDMA account are still bound to the hardware itself.
> >
> > Why do you want to neglect this?
> >
> > We should be consistent have have the same behaviour for this. If someone
> unplug and replug its dongle, he do not want to re-insert the data call
> parameter, as with a GSM dongle.
> 
> I still don't believe that any CDMA operator so far really uses SIM
> cards. I heard about some cases with Verizon where they have CDMA + LTE
> in deployment.

The SpeedUp 7300 cannot register to the network without the SIM, and so make a 
data call.

We can retrieve the IMSI on this dongle, the AT+CIMI command works correctly.

I don't know if they are using it for anything else.

And SpeedUp AT spec for this dongle show CPIN command, but I do not have try 
them.

> 
> > And what about PIN?
> 
> Good question. It is not a SIM PIN, it is a hardware PIN in the first
> place. And only if you have a SIM, you have SIM PIN.

I do not have test this, but I will do this asap.

> So the same question stays, where is your SIM card in CDMA hardware that
> you have right now?

I will send you some picture of those dongle and SIM card.

Regards,

Bertrand
-
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: CDMA SIM atom

[Aygon, Bertrand]

Hi,

> > We are working on CDMA to enable some USB dongle, and we need to get the
> IMSI for the ConnMan interface, to create the interface name.
> >
> > We could use the AT SIM atom, since there should be no big difference
> between a CDMA SIM and a GSM SIM (same kind of functionality for SIM
> lock/unlock, same IMSI info).
> >
> > But we could also create a CDMA dedicated one. This will duplicate some
> code, but will be 'cleaner'.
> >
> > I would prefer the solution of a CDMA SIM atom, so CDMA plugins use only
> CDMA atom, but I would prefer to have the oFono community opinion before going
> into the code.
> 
> you do not need an IMSI for ConnMan. You just need a proper unique
> identifier that is consistent. Using the hardware serial number in case
> of CDMA should be a good enough interim solution.

The user can change its SIM card and put it in another dongle

> We are using the IMSI for GSM since we wanna bind stored settings
> towards the SIM card. So that hardware swapping has no effect on the
> user experience.

This is exactly what we also want to do with CDMA dongle.
 
> With CDMA we could neglect this actually. So far all
> CDMA account are still bound to the hardware itself.

Why do you want to neglect this?

We should be consistent have have the same behaviour for this. If someone 
unplug and replug its dongle, he do not want to re-insert the data call 
parameter, as with a GSM dongle.

And what about PIN?

Regards,

Bertrand
-
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: [PATCH] cdmamodem: create vendor.h file.

[Aygon, Bertrand]

Hi,

> > > >  Makefile.am|3 ++-
> > > >  drivers/cdmamodem/vendor.h |   25 +
> > > >  2 files changed, 27 insertions(+), 1 deletions(-)
> > > >  create mode 100644 drivers/cdmamodem/vendor.h
> > > >
> > > > diff --git a/Makefile.am b/Makefile.am
> > > > index e00f73b..f1ef96c 100644
> > > > --- a/Makefile.am
> > > > +++ b/Makefile.am
> > > > @@ -270,7 +270,8 @@ builtin_sources += drivers/cdmamodem/cdmamodem.h \
> > > > drivers/cdmamodem/voicecall.c \
> > > > drivers/cdmamodem/devinfo.c \
> > > > drivers/cdmamodem/connman.c \
> > > > -   drivers/cdmamodem/network-registration.c
> > > > +   drivers/cdmamodem/network-registration.c \
> > > > +   drivers/cdmamodem/vendor.h
> > > >  endif
> > > >
> > > >  builtin_modules += g1
> > > > diff --git a/drivers/cdmamodem/vendor.h b/drivers/cdmamodem/vendor.h
> > > > new file mode 100644
> > > > index 000..3b00bbf
> > > > --- /dev/null
> > > > +++ b/drivers/cdmamodem/vendor.h
> > > > @@ -0,0 +1,25 @@
> > > > +/*
> > > > + *
> > > > + *  oFono - Open Source Telephony
> > > > + *
> > > > + *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
> > > > + *
> > > > + *  This program is free software; you can redistribute it and/or
> modify
> > > > + *  it under the terms of the GNU General Public License version 2 as
> > > > + *  published by the Free Software Foundation.
> > > > + *
> > > > + *  This program is distributed in the hope that it will be useful,
> > > > + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > > + *  GNU General Public License for more details.
> > > > + *
> > > > + *  You should have received a copy of the GNU General Public License
> > > > + *  along with this program; if not, write to the Free Software
> > > > + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-
> 1301
> > > USA
> > > > + *
> > > > + */
> > > > +
> > > > +enum ofono_vendor {
> > > > +   OFONO_VENDOR_GENERIC = 0,
> > > > +   OFONO_VENDOR_SPEEDUP,
> > > > +};
> > >
> > > do not bother with this until it is really needed. Vendor quirks are the
> > > last resort to avoid massive code duplication. In a lot of cases a
> > > vendor specific atom driver is the better choice.
> > >
> > > And you can just share the atmodem ones in this case anyway.
> >
> > I am thinking again to this file, and I think we will definitely need a
> Vendor.h for CDMA.
> >
> > As we said in another discussion, there is no standard in CDMA, so we should
> have vendor specific code in any atom. And creating an atom per modem will
> duplicate a lot of code.
> >
> > And I don't know if we should set an OFONO_VENDOR_GENERIC for CDMA. I think
> that if 2 modems are using the same AT command (CPIN for example), we should
> do a switch or if/else with all the different vendor.
> >
> > Another exemple. We are working on ConnMan atom. The 2 kind of dongle we
> have used, Huawei and SpeedUp, are using ^DORMANT for dormant mode
> notification. I don't think that we have to duplicate the ConnMan atom. We
> should be using the same atom, and use vendor define to set the AT command to
> register.
> >
> > What do you think about this?
> 
> are you sure that the SpeedUp and Huawei dongle are really different.
> Maybe it is just a re-branded version of the other. They could be
> different and just share the same AT command set, but even then we might
> not just bother here.

I do not remember exactly, I will have to go through my log, but from what I 
remember, they are sharing lot of command.

> And from were I am standing, feel free to share the vendor quirks from
> atmodem/vendor.h. At least until we have the rest figured out.

Ok, and what about the GENERIC, are we creating one? I don't think that this is 
a good idea.

Regards,

Bertrand
-
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

CDMA SIM atom

[Aygon, Bertrand]

Hi,

We are working on CDMA to enable some USB dongle, and we need to get the IMSI 
for the ConnMan interface, to create the interface name.

We could use the AT SIM atom, since there should be no big difference between a 
CDMA SIM and a GSM SIM (same kind of functionality for SIM lock/unlock, same 
IMSI info).

But we could also create a CDMA dedicated one. This will duplicate some code, 
but will be 'cleaner'.

I would prefer the solution of a CDMA SIM atom, so CDMA plugins use only CDMA 
atom, but I would prefer to have the oFono community opinion before going into 
the code.

Thanks,

Bertrand


--
Bertrand Aygon  Engineering Manager
bertrand.ay...@intel.comOpen 
Source Technology Center, Intel Corporation

-
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: [PATCH] cdmamodem: create vendor.h file.

[Aygon, Bertrand]

Hi Marcel,

> >  Makefile.am|3 ++-
> >  drivers/cdmamodem/vendor.h |   25 +
> >  2 files changed, 27 insertions(+), 1 deletions(-)
> >  create mode 100644 drivers/cdmamodem/vendor.h
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index e00f73b..f1ef96c 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -270,7 +270,8 @@ builtin_sources += drivers/cdmamodem/cdmamodem.h \
> > drivers/cdmamodem/voicecall.c \
> > drivers/cdmamodem/devinfo.c \
> > drivers/cdmamodem/connman.c \
> > -   drivers/cdmamodem/network-registration.c
> > +   drivers/cdmamodem/network-registration.c \
> > +   drivers/cdmamodem/vendor.h
> >  endif
> >
> >  builtin_modules += g1
> > diff --git a/drivers/cdmamodem/vendor.h b/drivers/cdmamodem/vendor.h
> > new file mode 100644
> > index 000..3b00bbf
> > --- /dev/null
> > +++ b/drivers/cdmamodem/vendor.h
> > @@ -0,0 +1,25 @@
> > +/*
> > + *
> > + *  oFono - Open Source Telephony
> > + *
> > + *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
> > + *
> > + *  This program is free software; you can redistribute it and/or modify
> > + *  it under the terms of the GNU General Public License version 2 as
> > + *  published by the Free Software Foundation.
> > + *
> > + *  This program is distributed in the hope that it will be useful,
> > + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + *  GNU General Public License for more details.
> > + *
> > + *  You should have received a copy of the GNU General Public License
> > + *  along with this program; if not, write to the Free Software
> > + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301
> USA
> > + *
> > + */
> > +
> > +enum ofono_vendor {
> > +   OFONO_VENDOR_GENERIC = 0,
> > +   OFONO_VENDOR_SPEEDUP,
> > +};
> 
> do not bother with this until it is really needed. Vendor quirks are the
> last resort to avoid massive code duplication. In a lot of cases a
> vendor specific atom driver is the better choice.
> 
> And you can just share the atmodem ones in this case anyway.

I am thinking again to this file, and I think we will definitely need a 
Vendor.h for CDMA.

As we said in another discussion, there is no standard in CDMA, so we should 
have vendor specific code in any atom. And creating an atom per modem will 
duplicate a lot of code.

And I don't know if we should set an OFONO_VENDOR_GENERIC for CDMA. I think 
that if 2 modems are using the same AT command (CPIN for example), we should do 
a switch or if/else with all the different vendor.

Another exemple. We are working on ConnMan atom. The 2 kind of dongle we have 
used, Huawei and SpeedUp, are using ^DORMANT for dormant mode notification. I 
don't think that we have to duplicate the ConnMan atom. We should be using the 
same atom, and use vendor define to set the AT command to register.

What do you think about this?

Regards,

Bertrand
-
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: [PATCH_v2 2/3] cdmamodem: Create network registration atom.

[Aygon, Bertrand]

Hi Denis,


<>
 
> And why are we using a Huawei specific command inside the generic
> cdmamodem driver without at least a vendor if/switch somewhere?

We have SpeedUp dongle that also support this command...

I know this is not the best answer, but there is no standard for CDMA, so many 
customer seems to se the same AT command.

Regards,

Bertrand
-
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: [PATCH] cdmamodem: create vendor.h file.

[Aygon, Bertrand]

Hi,

Sorry I have just see that this patch require my previous patch on CDMA Network 
Registration.

Please ignore it for now.

Regards,

Bertrand

> -Original Message-
> From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
> Bertrand Aygon
> Sent: Saturday, July 23, 2011 1:04 PM
> To: ofono@ofono.org
> Subject: [PATCH] cdmamodem: create vendor.h file.
> 
> ---
>  Makefile.am|3 ++-
>  drivers/cdmamodem/vendor.h |   25 +
>  2 files changed, 27 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/cdmamodem/vendor.h
> 
> diff --git a/Makefile.am b/Makefile.am
> index e00f73b..f1ef96c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -270,7 +270,8 @@ builtin_sources += drivers/cdmamodem/cdmamodem.h \
>   drivers/cdmamodem/voicecall.c \
>   drivers/cdmamodem/devinfo.c \
>   drivers/cdmamodem/connman.c \
> - drivers/cdmamodem/network-registration.c
> + drivers/cdmamodem/network-registration.c \
> + drivers/cdmamodem/vendor.h
>  endif
> 
>  builtin_modules += g1
> diff --git a/drivers/cdmamodem/vendor.h b/drivers/cdmamodem/vendor.h
> new file mode 100644
> index 000..3b00bbf
> --- /dev/null
> +++ b/drivers/cdmamodem/vendor.h
> @@ -0,0 +1,25 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301
> USA
> + *
> + */
> +
> +enum ofono_vendor {
> + OFONO_VENDOR_GENERIC = 0,
> + OFONO_VENDOR_SPEEDUP,
> +};
> --
> 1.7.4.1
> 
> -
> 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
-
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: [PATCH] SpeedUp CDMA: querying SIM state during powering on phase.

[Aygon, Bertrand]

Hi,

> > > This is wrong code. So in case CFUN=1 fails, you still go ahead and
> > > query the SIM state. That is rather pointless and might result on
> > > unforseen feedback from the modem.
> > >
> > > In addition you do not handle the set_powered in case ^SYSINFO fails or
> > > you have polled max attempts.
> > >
> > > Now looking over this. I do not like this at all. Please do not copy any
> > > code from Huawei plugin and write this from scratch based on actual
> > > traces and the documentation.
> >
> > I totally agree, I will rework this part.
> >
> > I will set the powered flag after CFUN, and use the SYSINFO to broadcast SIM
> info (available or not).
> 
> please post OFONO_AT_DEBUG traces to the mailing list first.
> 
> If you wanna handle some fake CDMA SIM states, then we might need a
> simplified SIM atom driver for CDMA as well. Or something only CDMA
> specific.

No. In fact modems seems to react correctly. There is SIM state notification, 
but we got it once over 10. So I do not want to rely on.

SYSINFO will give me the info, and it's always correct so I do not need a 
polling mechanism. 

> Otherwise the check for a valid CDMA SIM, ROM SIM or whatever they call
> it should be done during the enable callback handling. If it is not
> there, then it is not there. Nothing you can do about it anyway. Failing
> the modem enabling seems to be the best approach in my book.

Exactly, I have to check for SIM available or not. I will send once the SYSINFO 
in the cfun callback, and based on the result notify the availability of the 
SIM.

Regards,

Bertrand
-
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: [PATCH] SpeedUp CDMA: querying SIM state during powering on phase.

[Aygon, Bertrand]

Hi Marcel,

> please do not make up new commit prefixes. Use simple lower case strings
> like the modem plugin name, the subdirectory in drivers or for the core
> the logical name.

Ok, I will do this.

> 
> >  plugins/speedupcdma.c |  102
> -
> >  1 files changed, 100 insertions(+), 2 deletions(-)
> >
> > diff --git a/plugins/speedupcdma.c b/plugins/speedupcdma.c
> > index b7e54a1..1dcff88 100644
> > --- a/plugins/speedupcdma.c
> > +++ b/plugins/speedupcdma.c
> > @@ -41,11 +41,25 @@
> >  #include 
> >
> >  static const char *none_prefix[] = { NULL };
> > +static const char *sysinfo_prefix[] = { "^SYSINFO:", NULL };
> > +
> > +enum speedupcdma_sim_state {
> > +   SPEEDUPCDMA_SIM_STATE_VALID =   1,
> > +   SPEEDUPCDMA_SIM_STATE_ROMSIM =  240,
> > +   SPEEDUPCDMA_SIM_STATE_NOT_EXISTENT =255
> 
> Add last , as well. We do this for enum so that if they get extended the
> patches look cleaner and not have to reshuffle.

I see.

> > +};
> >
> >  struct speedupcdma_data {
> > GAtChat *chat;
> > +   enum speedupcdma_sim_state sim_state;
> > +   guint sim_poll_timeout;
> > +   guint sim_poll_count;
> >  };
> >
> > +#define MAX_SIM_POLL_COUNT 5
> > +
> > +static gboolean query_sim_state(gpointer user_data);
> > +
> >  static void speedupcdma_debug(const char *str, void *data)
> >  {
> > const char *prefix = data;
> > @@ -79,6 +93,90 @@ static void speedupcdma_remove(struct ofono_modem *modem)
> > g_free(data);
> >  }
> >
> > +static gboolean notify_sim_state(struct ofono_modem *modem,
> > +   enum speedupcdma_sim_state sim_state)
> > +{
> > +   struct speedupcdma_data *data = ofono_modem_get_data(modem);
> > +
> > +   DBG("%d", sim_state);
> > +
> > +   data->sim_state = sim_state;
> > +
> > +   switch (sim_state) {
> > +   case SPEEDUPCDMA_SIM_STATE_NOT_EXISTENT:
> > +   /* SIM is not ready, try again a bit later */
> > +   return TRUE;
> > +   case SPEEDUPCDMA_SIM_STATE_VALID:
> > +   case SPEEDUPCDMA_SIM_STATE_ROMSIM:
> > +   if (data->sim_poll_timeout) {
> > +   g_source_remove(data->sim_poll_timeout);
> > +   data->sim_poll_timeout = 0;
> > +   }
> > +
> > +   ofono_modem_set_powered(modem, TRUE);
> 
> Use break; here.
> 
> And can you include OFONO_AT_DEBUG traces to show what is going on.
> > +
> > +   return FALSE;
> > +   }
> > +
> > +   return FALSE;
> > +}
> > +
> > +static void sysinfo_cb(gboolean ok, GAtResult *result, gpointer user_data)
> > +{
> > +   struct ofono_modem *modem = user_data;
> > +   struct speedupcdma_data *data = ofono_modem_get_data(modem);
> > +   gboolean rerun;
> > +   gint sim_state;
> > +   GAtResultIter iter;
> > +
> > +   if (!ok)
> > +   return;
> > +
> > +   g_at_result_iter_init(&iter, result);
> > +
> > +   if (!g_at_result_iter_next(&iter, "^SYSINFO:"))
> > +   return;
> > +
> > +   if (!g_at_result_iter_skip_next(&iter))
> > +   return;
> > +
> > +   if (!g_at_result_iter_skip_next(&iter))
> > +   return;
> > +
> > +   if (!g_at_result_iter_skip_next(&iter))
> > +   return;
> > +
> > +   if (!g_at_result_iter_skip_next(&iter))
> > +   return;
> > +
> > +   if (!g_at_result_iter_next_number(&iter, &sim_state))
> > +   return;
> > +
> > +   rerun = notify_sim_state(modem, (enum speedupcdma_sim_state)
> sim_state);
> > +
> > +   if (rerun && data->sim_poll_count < MAX_SIM_POLL_COUNT) {
> > +   data->sim_poll_count++;
> > +   data->sim_poll_timeout = g_timeout_add_seconds(2,
> > +   query_sim_state,
> > +   modem);
> > +   }
> > +}
> 
> This logic is copied from the Huawei GSM plugin and there I am not even
> sure that it is correct. Please show us AT command traces. Since I do
> not think that it is this complicated for CDMA.

I also think so.

After a full day of testing (while implementing NetworkRegistration for CDMA), 
I have found a best way to handle this. In fact the correct way. As you said, I 
have copy/paste this code from Huawei driver, and I have simply some part but 
not all. And I have to rework this.

> The Huawei plugin is a bad example to copy code from.
> 
> > +static gboolean query_sim_state(gpointer user_data)
> > +{
> > +   struct ofono_modem *modem = user_data;
> > +   struct speedupcdma_data *data = ofono_modem_get_data(modem);
> > +
> > +   DBG("");
> > +
> > +   data->sim_poll_timeout = 0;
> > +
> > +   g_at_chat_send(data->chat, "AT^SYSINFO", sysinfo_prefix,
> > +   sysinfo_cb, modem, NULL);
> > +
> > +   return FALSE;
> > +}
> > +
> >  static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
> >  {
> > struct ofono_modem *modem = user_data;
> > @@ -93,8 +191,6 @@ static void cfun_enable(gboolean ok, GAtResult *result,
> gpointer user_data)
> >  

RE: [PATCH 1/2] speedup: add cpin polling mechanism

[Aygon, Bertrand]

Hi,

>  plugins/speedup.c |   64
> -
>  1 files changed, 63 insertions(+), 1 deletions(-)
> 
> diff --git a/plugins/speedup.c b/plugins/speedup.c
> index 7e89b6f..23ba173 100644
> --- a/plugins/speedup.c
> +++ b/plugins/speedup.c
> @@ -49,10 +49,14 @@
>  #include 
> 
>  static const char *none_prefix[] = { NULL };
> +static const char *cpin_prefix[] = { "+CPIN:", NULL };
> 
>  struct speedup_data {
>   GAtChat *modem;
>   GAtChat *aux;
> + guint cpin_poll_source;
> + guint cpin_poll_count;
> + gboolean have_sim;
>   struct ofono_gprs *gprs;
>   struct ofono_gprs_context *gc;
>  };
> @@ -83,6 +87,9 @@ static void speedup_remove(struct ofono_modem *modem)
>   g_at_chat_unref(data->modem);
>   g_at_chat_unref(data->aux);
> 
> + if (data->cpin_poll_source > 0)
> + g_source_remove(data->cpin_poll_source);
> +
>   g_free(data);
>  }
> 
> @@ -152,13 +159,68 @@ static void speedup_disconnect(gpointer user_data)
>   ofono_gprs_add_context(data->gprs, data->gc);
>  }
> 
> +static gboolean init_simpin_check(gpointer user_data);
> +
> +static void simpin_check(gboolean ok, GAtResult *result, gpointer user_data)
> +{
> + struct ofono_modem *modem = user_data;
> + struct speedup_data *data = ofono_modem_get_data(modem);
> + struct ofono_error error;
> +
> + DBG("");
> +
> + decode_at_error(&error, g_at_result_final_response(result));
> +
> + /* Modem returns an error if SIM is not ready. */
> + switch (error.error) {
> + case 10:
> + case 13:
> + data->have_sim = FALSE;
> + break;
> + case 14: /* SIM Busy, wait and check again the SIM pin status */
> + if (data->cpin_poll_count++ < 5) {
> + data->cpin_poll_source =
> + g_timeout_add_seconds(1, init_simpin_check,
> + modem);
> + return;
> + }
> + /*SIM card is present but not accessible*/
> + data->have_sim = FALSE;
> + break;
> + default:
> + data->have_sim = TRUE;
> + }
> +
> + data->cpin_poll_count = 0;
> +
> + ofono_modem_set_powered(modem, TRUE);
> +}
> +
> +static gboolean init_simpin_check(gpointer user_data)
> +{
> + struct ofono_modem *modem = user_data;
> + struct speedup_data *data = ofono_modem_get_data(modem);
> +
> + data->cpin_poll_source = 0;
> +
> + g_at_chat_send(data->modem, "AT+CPIN?", cpin_prefix,
> + simpin_check, modem, NULL);

The command need to be sent to Aux at chat and not Modem. Modem should be used 
only for the data call.

> +
> + return FALSE;
> +}
> +
>  static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
>  {
>   struct ofono_modem *modem = user_data;
> 
>   DBG("");
> 
> - ofono_modem_set_powered(modem, ok);
> + if (!ok) {
> + ofono_modem_set_powered(modem, FALSE);
> + return;
> + }
> +
> + init_simpin_check(modem);
>  }
> 
>  static int speedup_enable(struct ofono_modem *modem)

Thanks,

Bertrand
-
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: [PATCH] CDMA ConnMan API: add username and password for PPP authentication.

[Aygon, Bertrand]

Hi,

>fair enough. That is enough for me to confirm that it is used in real
>networks. We do not like to add APIs for something that is not used
>anymore only because some specification or RFC says so ;)

I agree.

>Patch has been applied now. However I changed the commit prefix back to
>doc: to make it look cleaner.

Thanks.

>For you two TTY cases. That is normal. Huawei treats the first TTY as
>modem to issue PPP on it. And the second one (PCUI) is used for
>notifications. So yes, oFono needs to open both. You will need the
>second one for network registration updates.

But I think that if you send ATD on a channel, you should receive the CONNECT 
in the same channel. It's an answer, not a notification.

Regards,

Bertrand

-
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: [PATCH] CDMA ConnMan API: add username and password for PPP authentication.

[Aygon, Bertrand]

Hi,

>Have you tried empty strings like "". Have you tried random values? Do
>they have to be really specific ones.
>
>Is the password checked? Or just the username? Maybe they treat the
>username as pseudo APN of some sort, but the password means nothing.
>
>OFONO_PPP_DEBUG for starters. And then using cdmadial to create a full
>pppdump compatible log would be good idea. Something that we can open in
>Wireshark.

Here are cdmadial result with multiple possibility. The one with 2 tty is funy 
;)

So from the result, I can tell that both login and password are checked.

If you want another test or if I missed one interesting, feel free to ask.

Regards,

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
-
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.
bertrand@bertrand-Latitude-E5410:ofono (master *%)$ sudo ./gatchat/cdmadial 
--control /dev/ttyUSB0 --username a...@aha.co.id
Control: /dev/ttyUSB0
APN: (null)
CID: 0
: > ATE0Q0V1\r
: < \r\nOK\r\n
: > AT+CFUN?\r
: < \r\n+CFUN: 1\r\n\r\nOK\r\n
Current modem mode is 1
: > ATD#777\r
: < \r\nCONNECT 310\r\n
Username: a...@aha.co.id
Password: (null)
PPP: lcp: pppcp_generate_event: current state 0:INITIAL
PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED)
PPP: lcp: pppcp_generate_event: current state 2:CLOSED
PPP: event: 2 (Open), action: 1026, new_state: 6 (REQSENT)
PPP: lcp: pppcp_initialize_restart_count: current state 2:CLOSED
PPP: lcp: pppcp_send_configure_request: current state 2:CLOSED
PPP: gatchat/gatppp.c:ppp_enter_phase() 1
PPP: lcp: pppcp_timeout: current state 6:REQSENT
PPP: lcp: pppcp_generate_event: current state 6:REQSENT
PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
PPP: lcp: pppcp_timeout: current state 6:REQSENT
PPP: lcp: pppcp_generate_event: current state 6:REQSENT
PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
PPP: lcp: pppcp_process_configure_request: current state 6:REQSENT
PPP: lcp: pppcp_generate_event: current state 6:REQSENT
PPP: event: 7 (RCR-), action: 4006, new_state: 6 (REQSENT)
PPP: lcp: pppcp_send_configure_nak: current state 6:REQSENT
PPP: lcp: pppcp_process_configure_request: current state 6:REQSENT
PPP: lcp: pppcp_generate_event: current state 6:REQSENT
PPP: event: 6 (RCR+), action: 2008, new_state: 8 (ACKSENT)
PPP: lcp: pppcp_send_configure_ack: current state 6:REQSENT
PPP: lcp: pppcp_timeout: current state 8:ACKSENT
PPP: lcp: pppcp_generate_event: current state 8:ACKSENT
PPP: event: 4 (TO+), action: 1008, new_state: 8 (ACKSENT)
PPP: lcp: pppcp_send_configure_request: current state 8:ACKSENT
PPP: lcp: pppcp_process_configure_ack: current state 8:ACKSENT
PPP: lcp: pppcp_generate_event: current state 8:ACKSENT
PPP: event: 8 (RCA), action: 129, new_state: 9 (OPENED)
PPP: lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
PPP: gatchat/gatppp.c:ppp_enter_phase() 2
PPP: lcp: pppcp_generate_event: current state 9:OPENED
PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
PPP: lcp: pppcp_initialize_restart_count: current state 9:OPENED
PPP: lcp: pppcp_send_terminate_request: current state 9:OPENED
PPP: gatchat/gatppp.c:ppp_enter_phase() 5
PPP: lcp: pppcp_process_terminate_request: current state 4:CLOSING
PPP: lcp: pppcp_generate_event: current state 4:CLOSING
PPP: event: 10 (RTR), action: 10004, new_state: 4 (CLOSING)
PPP: lcp: pppcp_send_terminate_ack: current state 4:CLOSING
PPP: gatchat/gatppp.c:sta_sent() 
PPP: lcp: pppcp_process_terminate_ack: current state 4:CLOSING
PPP: lcp: pppcp_generate_event: current state 4:CLOSING
PPP: event: 11 (RTA), action: 802, new_state: 2 (CLOSED)
PPP: lcp: pppcp_this_layer_finished: current state 2:CLOSED
PPP: gatchat/gatppp.c:ppp_enter_phase() 0
PPP: gatchat/gatppp.c:ppp_dead() 
PPP Link down: 1


bertrand@bertrand-Latitude-E5410:ofono (master *%)$ sudo ./gatchat/cdmadial 
--control /dev/ttyUSB0 --username a...@aha.co.id --password aha
Control: /dev/ttyUSB0
APN: (null)
CID: 0
: > ATE0Q0V1\r
: < \r\nOK\r\n
: > AT+CFUN?\r
: < \r\n+CFUN: 1\r\n\r\nOK\r\n
Current modem mode is 1
: > ATD#777\r
: < \r\nCONNECT 153600\r\n
Username: a...@aha.co.id
Password: aha
PPP: lcp: pppcp_generate_event: current state 0:INITIAL
PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED)
PPP: lcp: pppcp_generate_event: current state 2:CLOSED
PPP: event: 2 (Open), action: 1026, new

RE: [PATCH] CDMA ConnMan API: add username and password for PPP authentication.

[Aygon, Bertrand]

Hi,

>as with the previous attempt to add these fields, are they really really
>needed? Or is an empty username + password in CHAP also working just
>fine?

They are really needed.

>For GPRS for example all operators are just ignoring these values. At
>least the few I have known that required them, gave up on it by now.

We are in Indonesia, and for AHA operator, we have to give a username and a 
password. If we do not specify them, the PPP negotiation fails.

>So please try with an empty username + password and show us logs of what
>is happening on a real network.

Which log? Pppd log?

Regards,

Bertrand


-
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: [PATCH] Create a SpeedUp plugin, using standard AT Modem, and add corresponding udev rules

[Aygon, Bertrand]

Hi,

There has been an update on usb_modeswitch 2 days ago, and now SU9800 are 
recognized automatically.

This is working great!

Just take 1.1.8 and latest data.

Regards,

Bertrand.

-
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: [PATCH] Create a SpeedUp plugin, using standard AT Modem, and add corresponding udev rules

[Aygon, Bertrand]

Hi,

>I tried with the code, but my speedup dongle still failed to work.
>
>Until I issue command manually: modprobe usbserial vendor=0x1c9e 
>product=0x9800, then the driver is >attached and ttyUSB0, 1, 2 devices are 
>created, and ofono starts to probe the device.
>After ofono starts to initialize the Speedup modem, the registration process 
>failed. I attach the >log here with AT debug info.
>
>Question: why the usbserial driver cannot probe and installed with the speedup 
>dongle automatically?  

Yes I know, and I am working on it.

I don't know why we have to do the modprobe manually. If someone has some info, 
I would be very happy to get them.

Regards,

Bertrand
-
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: [PATCH] Create a SpeedUp plugin, using standard AT Modem, and add corresponding udev rules

[Aygon, Bertrand]

Hi Denis,

Thanks for those comment, I will apply.

One point, the speedup.c is a copy of zte.c.

Do you want me to apply also for zte.c?

Regards,

Bertrand

-
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: Patches not accepted :(

[Aygon, Bertrand]

Hi,

>I have sent few patches couple of days ago on this list but it seems no one is
>looking after it. These patches has fixed few issues related to ofono crash 
>with
>Linktop devices.

Thanks for your patches and your work, but review can take longer than 2 days. 
Maintainers have lots of patches to review, and they take sometimes vacation.

>Here is the link to the archived mailing list thread:
>
>http://lists.ofono.org/pipermail/ofono/2011-June/010537.html
>
>Would you please consider the patches for review? Do I need to resubmit the
>patches?
>

You do not have to resend them. Please wait for at least one week before 
'pinging' maintainers about patches.
You can also use IRC to see if they are online and ask for update.

Regards,

Bertrand
-
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: Adding New contact failed in Ofono

[Aygon, Bertrand]

Hi,

>I am doing this work for ST Ericsson modem.
>
>Now i registered callback function for result handling and added quotes in 
>cmd. Now cmd is
>
>AT+CPBW=10,"123456789",129,"Testing"
>
>Log message:
>
>Control @ Command is AT+CPBW=10,"123456789",129,"Testing"
>Add New contact number in Sim
> Status is 69
> Saving contact on Sim is failed

Please do not top-post on the mailing list.

Can you please provide AT log (export OFONO_AT_DEBUG=1)?

Did you also select the appropriate phonebook storage because writing, and make 
sure that the phonebook is 'ready'?

Regards,

Bertrand.

-
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: Adding New contact failed in Ofono

[Aygon, Bertrand]

Hi,

>Hi All,
>
>I am trying to add new contact in sim via following sample code
>
>
>static  int new_contact(struct ofono_phonebook *pb,char 
>*num,ofono_phonebook_cb_t cb)
>{
>struct pb_data *pbd = ofono_phonebook_get_data(pb);
>char cmd[50];int return_value;
>sprintf(cmd,"AT+CPBW=10,%s,129,Testing", num);
>printf("Command is %s\n",cmd);
>return_value=g_at_chat_send(pbd->chat,cmd, none_prefix,
>   NULL,NULL, NULL);
>printf("Add New contact number in Sim\n Status is %d\n",return_value);
>return return_value;
>}
>
>
>If i try to add new contact  my Return status is  69 or 70
>
>
>what is does mean?
>
>I verified  in my Sim. Contact is not added

Do you have the AT log?

One thing I have in mind, is that phone number and name must be a quoted string:
sprintf(cmd,"AT+CPBW=10,\"%s\",129,\"Testing\"", num);

Regards,

Bertrand
-
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: Unint var with GCC 4.5.2

[Aygon, Bertrand]

Hi Andrzej,

>That one is a bug.  I remember it caught my eye at some point but
>later I forgot about it.  This is more or less how I'd try to fix it:

Thanks for handling this. Your fix looks OK regarding the bug and the 
uninitialized var, but I do not have enough background on oFono and SIM file 
management to tell you if everything will works. You should submit this patch 
and let Denis validate it.

Are you using PhoneSim to validate your fix? Or a modem?

Regards,

Bertrand
-
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: Unint var with GCC 4.5.2

[Aygon, Bertrand]

Hi Denis,

>> 
>> The unint var is 'unsigned short iidf_id;'
>> 
>> If the image is in the cache, we will go to the watch directly, and if
>> there is no watch, we will add one with an invalid iidf_id.
>> 
>
>This is a bug.  We need to add a watch to the proper iidf_id, which we
>need to obtain from the EFimg look up table.  In the case of a cached
>image, we're not doing that.

Thanks for the clarification. This was my first thought, but getting info from 
the writer is always better ;)

Like last time I have found an issue, I guess that you have already make the 
fix... ;)

>> So is it possible to have an image in the cache without watch?
>
>Yes, the cache is persistent (stored in IMSI-keyed filesystem location).
> The logic is supposed to work somewhat like this:
>
>1. Upon sim-atom init, read EFimg and populate its contents in a look up
>table.
>
>2a. When an application requests an icon with a particular id, look it
>up in cache or read it from the SIM.  Each icon is assigned to a
>particular EFiidf_n file.  So record application's interest in that file
>by assigning a file watch.
>
>2b. If an EFiidf file is refreshed via STK Refresh, call the file watch
>and remove the file watch.  The file watch will be re-added again once
>the application requests the icon.
>
>However, we have not seen any SIMs with SIM icons, so this part of the
>code has not been stress tested...

This cannot tested using PhoneSim?

Regards,

Bertrand
-
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

Unint var with GCC 4.5.2

[Aygon, Bertrand]

Hi,

I have switched my dev environment to Ubuntu 11.04, and so I am using GCC 4.5.2.

Building oFono returns 2 erros due to uninit var. One is a false negative, so I 
have fix it with the 'magic define', and will send the patch soon (VPN is dead 
so I cannot send it).
But for the second one, I am not sure it's a false negative, so I would like to 
have the thought of the mailing list, and even better the author or guys who 
has some knowledge on this part of the code.

Here it's:

939
 static void sim_get_image(struct ofono_sim *sim, unsigned char id,
940
 gpointer user_data)
941
 {
942
 unsigned char *efimg;
943
 char *image;
944
 unsigned short iidf_id;
945
 unsigned short iidf_offset;
946
 unsigned short iidf_len;
947
948
 image = sim_fs_get_cached_image(sim->simfs, id);
949
950
 if (image != NULL) {
951
 sim_get_image_cb(sim, id, image, FALSE);
952
 goto watch;
953
 }
954
955
 if (sim->efimg_length <= (id * 9)) {
956
 sim_get_image_cb(sim, id, NULL, FALSE);
957
 return;
958
 }
959
960
 efimg = &sim->efimg[id * 9];
961
962
 iidf_id = efimg[3] << 8 | efimg[4];
963
 iidf_offset = efimg[5] << 8 | efimg[6];
964
 iidf_len = efimg[7] << 8 | efimg[8];
965
966
 /* read the image data */
967

RE: Dedug Log for Huawei EC168C

[Aygon, Bertrand]

Hi,

>PFA, the debug log with AT commands
>
>I am still getting a timeout on enable-modem operation
>
>and list-modem gives following o/p
>
>$ ./list-modems
>[ /huawei0 ]
>Features =
>Emergency = 0
>Powered = 0
>Lockdown = 0
>Interfaces =
>Online = 0
>
>Regards,
>Rajesh

We have one idea to fix this. It seems that this modem has never been tested or 
used with oFono, and so oFono is not handling it.
How did you get ofonod? Did you build it?
If so, can you please modify file plugins/huawei.c, line 208, and insert:
case 240:

You should have:
...
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:
case 240:
if (data->sim_poll_timeout) {
g_source_remove(data->sim_poll_timeout);
data->sim_poll_timeout = 0;
}
...

Thanks,

Bertrand
-
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: [PATCH] Add send vcal test

[Aygon, Bertrand]

>Patch has been applied, however you forgot to add this to the build.  I
>fixed this in a follow-on patch for you ;)

Damn, sorry, second times...

Thanks for the fix.

Bertrand

-
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: [PATCH 3/4] connman: add plugin in oFono to request request/release private network

[Aygon, Bertrand]

Hi Frederic,

Please remember to not French top post :)

Bertrand.

-- 
Bertrand Aygon  Engineering Manager 
bertrand.ay...@intel.comOpen Source Technology Center, Intel 
Corporation

Great thoughts come from reason. Domie So

-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of 
Frédéric Dalleau
Sent: Friday, April 22, 2011 1:02 PM
To: ofono@ofono.org
Subject: Re: [PATCH 3/4] connman: add plugin in oFono to request 
request/release private network

2 remarques à vue de nez

On 04/22/2011 12:02 PM, Guillaume Zajac wrote:
> ---
>   plugins/connman.c |  239 
> +
>   1 files changed, 239 insertions(+), 0 deletions(-)
>   create mode 100644 plugins/connman.c
>
> diff --git a/plugins/connman.c b/plugins/connman.c
> new file mode 100644
> index 000..eec0940
> --- /dev/null
> +++ b/plugins/connman.c
> @@ -0,0 +1,239 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  
> USA
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include
> +#endif
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define CONNMAN_SERVICE  "net.connman"
> +#define CONNMAN_PATH "/net/connman"
> +
> +#define CONNMAN_DEBUG_INTERFACE  CONNMAN_SERVICE ".Debug"
> +#define CONNMAN_ERROR_INTERFACE  CONNMAN_SERVICE ".Error"
> +#define CONNMAN_AGENT_INTERFACE  CONNMAN_SERVICE ".Agent"
> +#define CONNMAN_COUNTER_INTERFACECONNMAN_SERVICE ".Counter"
> +
> +#define CONNMAN_MANAGER_INTERFACECONNMAN_SERVICE ".Manager"
> +#define CONNMAN_MANAGER_PATH "/"
> +
> +#define CONNMAN_TASK_INTERFACE   CONNMAN_SERVICE ".Task"
> +#define CONNMAN_PROFILE_INTERFACECONNMAN_SERVICE ".Profile"
> +#define CONNMAN_SERVICE_INTERFACECONNMAN_SERVICE ".Service"
> +#define CONNMAN_PROVIDER_INTERFACE   CONNMAN_SERVICE ".Provider"
> +#define CONNMAN_TECHNOLOGY_INTERFACE CONNMAN_SERVICE ".Technology"
> +#define CONNMAN_SESSION_INTERFACECONNMAN_SERVICE ".Session"
> +#define CONNMAN_NOTIFICATION_INTERFACE   CONNMAN_SERVICE ".Notification"
> +
> +static DBusConnection *connection;
> +static guint modemwatch_id;
> +static GList *modems;
> +
> +static void request_pn(struct ofono_error *error, int *out_fd,
> + const char **out_server_ip,
> + const char **out_peer_ip,
> + const char **out_primary_dns,
> + const char **out_secondary_dns)
> +{
> + DBusMessageIter array, dict, entry;
> + DBusMessage *message, *reply;
> + DBusError dbus_error;
> +
> + DBG("");
> +
> + error->type = OFONO_ERROR_TYPE_NO_ERROR;
> +
> + message = dbus_message_new_method_call(CONNMAN_SERVICE,
> +  CONNMAN_MANAGER_PATH,
> +  CONNMAN_MANAGER_INTERFACE,
> +  "RequestPrivateNetwork");
> +
> + if (message == NULL)
> + goto error;
> +
> + dbus_error_init(&dbus_error);
> +
> + reply = dbus_connection_send_with_reply_and_block(connection, message,
> + -1,&dbus_error);
> +
> + dbus_message_unref(message);
> +
> + if (!reply) {
> + if (dbus_error_is_set(&dbus_error)) {
> + g_print("1. %s\n", dbus_error.message);
> + dbus_error_free(&dbus_error);
> + } else {
> + g_print("Request() failed");
> + }
> +
> + goto error;
> + }
> +
> + if (dbus_message_iter_init(reply,&array) == FALSE)
> + goto error;
> +
> + if (dbus_message_iter_get_arg_type(&array) != DBUS_TYPE_UNIX_FD)
> + goto error;
> +
> + dbus_message_iter_get_basic(&array, out_fd);
> + g_print("Fildescriptor = %d\n", *out_fd);
> +
> + dbus_message_iter_next(&array);
> +
> + if (dbus_message_iter_get_arg_type(&array) != DBUS_TYPE_ARRAY)
> + goto error;
> +
> + dbus_message_iter_recurse(&arra

RE: [PATCH] doc: add emergency-call-handling.txt

[Aygon, Bertrand]

Hi,

>Full funcationality will be activated by entering the correct PIN.

Thanks for the confirmation.

Regards,

Bertrand.
-
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: [PATCH] doc: add emergency-call-handling.txt

[Aygon, Bertrand]

Hi Jeevaka,

One 'minor bug', I guess that there is a missing 'Post SIM and Post online 
atoms are not created.' For case 2.

And one question. For case 2 and 3, the 'Modem remains in online mode but the 
functionalities will be limited.'. What is the procedure to activate all 
functionalities? Do we just have to enter the PIN, to create post SIM and post 
online atoms?

Thanks for the information,

Bertrand.

-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of 
Jeevaka Badrappan
Sent: Wednesday, April 13, 2011 7:05 PM
To: ofono@ofono.org
Subject: [PATCH] doc: add emergency-call-handling.txt

---
 doc/emergency-call-handling.txt |  113 +++
 1 files changed, 113 insertions(+), 0 deletions(-)
 create mode 100644 doc/emergency-call-handling.txt

diff --git a/doc/emergency-call-handling.txt b/doc/emergency-call-handling.txt
new file mode 100644
index 000..69b217d
--- /dev/null
+++ b/doc/emergency-call-handling.txt
@@ -0,0 +1,113 @@
+This document explains what is expected from applications and what oFono
+will do for an emergency call request in different states.
+
+Case 1: Call in offline and SIM present state
+
+Expected from UI/applications:
+
+   - Online property of org.ofono.Modem interface should be set to TRUE.
+   - Dial method should be called with the dialled number.
+
+What oFono will do:
+
+   - Modem will be set to online.
+   - Post online atoms will be created.
+   - Upon reception of Dial request, Emergency mode is activated.
+   - Once the call is ended, Emergency mode is deactivated.
+   - Modem remains in online mode with full funcationality.
+
+Case 2: Call in SIM Present and PIN required state
+
+Expected from UI/applications:
+
+   - If the user enters emergency number in the PIN entry dialog, then
+ Online property on org.ofono.Modem interface should be set to TRUE.
+   - List of Emergency numbers can be known from the
+ EmergencyNumbers property on the org.ofono.VoiceCallManager
+ interface.
+   - Dial method should be called with the dialled number
+
+What oFono will do:
+
+   - Modem will be set to online.
+   - Upon reception of Dial request, Emergency mode is activated.
+   - Once the call is ended, Emergency mode is deactivated.
+   - Modem remains in online mode but the functionalities will be
+ limited.
+
+Case 3: Call in SIM Present and PIN required state - Dial cancelled by user
+
+Expected from UI/applications:
+
+   - If the user enters emergency number in the PIN entry dialog, then
+ Online property on org.ofono.Modem interface should be set to TRUE.
+   - List of Emergency numbers can be known from the
+ EmergencyNumbers property on the org.ofono.VoiceCallManager
+ interface.
+   - Dial method should be called with the dialled number
+   - Upon dial cancellation by user, HangupAll should be called.
+
+What oFono will do:
+
+   - Modem will be set to online.
+   - Post SIM and Post online atoms are not created.
+   - Upon reception of Dial request, Emergency mode is activated.
+   - Upon dial cancellation(HangupAll request), Emergency mode is
+ deactivated.
+   - Modem remains in online mode but the functionalities will be
+ limited.
+
+Case 4: Call in No SIM state
+
+Expected from UI/applications:
+
+   - Online property on org.ofono.Modem interface should be set to TRUE.
+   - Dial method should be called with the dialled number
+
+What oFono will do:
+
+   - Modem will be set to online.
+   - Post SIM and Post online atoms not created.
+   - If the dialed number is an Emergeny number, Emergency mode is
+ activated.
+   - Once the call is ended, Emergency mode is deactivated.
+   - Modem remains in online mode but the functionalities will be
+ limited.
+
+Case 5: Call in No SIM state - PIN disabled SIM inserted during emergency call
+
+Expected from UI/applications:
+
+   - Online property on org.ofono.Modem interface should be set to TRUE.
+   - Dial method should be called with the dialled number
+
+What oFono will do:
+
+   - Modem will be set to online.
+   - Post SIM and Post online atoms are not created.
+   - If the dialed number is an Emergeny number, Emergency mode is
+ activated.
+   - Upon PIN disabled SIM detection, Post SIM and Post online
+ atoms are created.
+   - Once the call is ended, Emergency mode is deactivated.
+   - Modem remains in online mode with full functionality.
+
+Case 6: Call in No SIM state - PIN enabled SIM inserted during emergency call
+
+Expected from UI/applications:
+
+   - Online property on org.ofono.Modem interface should be set to TRUE.
+   - Dial method should be called with the dialled number
+
+What oFono will do:
+
+   - Modem

Crash in oFono, in src/call-forwarding.c:call_forwarding_remove

[Aygon, Bertrand]

Hi,

While looking into Bugzilla, I have found this bug: 
https://bugs.meego.com/show_bug.cgi?id=15124

And looking at logs, I have found this:
ofonod[746]: src/call-forwarding.c:call_forwarding_remove() atom: 0x819b5b0
ofonod[746]: Aborting (signal 11)
ofonod[746]:  backtrace 
ofonod[746]: [0]: [0xb770c400]
ofonod[746]: [1]: /lib/libglib-2.0.so.0(g_slist_remove+0x22) [0x46038b12]
ofonod[746]: [2]: ofonod() [0x80ed26b]
ofonod[746]: [3]: ofonod() [0x80ba690]
ofonod[746]: [4]: ofonod() [0x80ba75b]
ofonod[746]: [5]: ofonod() [0x80aab33]
ofonod[746]: [6]: ofonod() [0x8071352]
ofonod[746]: [7]: ofonod() [0x8072156]
ofonod[746]: [8]: ofonod() [0x8074317]
ofonod[746]: [9]: /lib/libglib-2.0.so.0() [0x4603193f]
ofonod[746]: [10]: /lib/libglib-2.0.so.0(g_main_context_dispatch+0x1ae) 
[0x45ffcc34]
ofonod[746]: [11]: /lib/libglib-2.0.so.0() [0x45ffd258]
ofonod[746]: [12]: /lib/libglib-2.0.so.0(g_main_loop_run+0x221) [0x45ffd7f6]
ofonod[746]: [13]: ofonod() [0x80b8fb9]
ofonod[746]: [14]: /lib/libc.so.6(__libc_start_main+0xe7) [0x45e0fbb7]
ofonod[746]: [15]: ofonod() [0x8052af1]
ofonod[746]: +++

It seems that this crash occurs when repeating on/off of the modem.

After some look into the code, I may have found an idea, but I would like to 
share it before proposing a patch.

When  call_forwarding atom is created, the cf_conditions list is not 
initialized. And the list is populated when the query_cf_callback is called. So 
I guess that this is when we receive the answer of the AT command to query call 
forwarding. And this command could take times.

If we turn off the modem before receiving the answer, we might go through the 
call_forwarding_remove before populating the list.
And in the call_forwarding_remove, we do a cf_clear_all, that will clear the 
list, without checking if the list exist or not.

So the crash might be there.

I would propose to add an if(cf->cf_conditions[i]) before the 
cf_list_clear(cf->cf_conditions[i]), line 195.

If this seems a good thought, please tell me and I will create a patch.

Regards,

Bertrand.


--
Bertrand Aygon  Engineering Manager
bertrand.ay...@intel.comOpen 
Source Technology Center, Intel Corporation

-
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: Qualcomm Gobi 2000 Modem Issues

[Aygon, Bertrand]

Hi,

>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.

This second issue looks like an issue reported a couple of days ago.

Can you please check in oFono logs if there is not something like this:

ofonod[2329]: drivers/atmodem/gprs-context.c:at_gprs_context_probe()
ofonod[2329]: Missing support for TUN/TAP devices

And if so, it means that your kernel doesn't have support for TUN enabled.

Regards,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>> From what I can see when you do the 'list-modem', your modem is already 
>> enabled and online, so you do not have to do the >>./enable_modem and 
>> ./online-modem.
>>
>> The PS context is also created (looking at ./list-contexts answer).
>>
>> So just the ./activate-context should be fine.
>>
>> But there is an error ... From what I can see in the source code, it should 
>> be enable 'post sim'. And still according to source code, >>the Huawei modem 
>> seems to skip some SIM status during warm start.
>>
>> So, can you please unplug replug the USB key, wait a few, just execute 
>> ./list-modems and ./list-contexts (nothing else).
>> You should see the modem enabled and online, and your context created. 
>> If so, just execute ./activate-context
>
>I have made the test proposed, I still recive the same error :)
>
>I have attacched the new log of test. Ofono create the connection context, but 
>on activation it repond with not implemented.

Sorry, I have no idea, I have try all I have in mind, but now, we need the help 
of someone else.

Huawei modem should support data call. The AT log looks correct. Why there is a 
not implemented error, I don't know...

Sorry again,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>> 1) Connect 3G key and wait for umts coverage (blue led)
>>
>> I activated the 3g connection, but ofono response is
>>
>> Error org.ofono.Error.NotImplemented: Implementation not provided

>From what I can see when you do the 'list-modem', your modem is already 
>enabled and online, so you do not have to do the ./enable_modem and 
>./online-modem.

The PS context is also created (looking at ./list-contexts answer).

So just the ./activate-context should be fine.

But there is an error ... From what I can see in the source code, it should be 
enable 'post sim'. And still according to source code, the Huawei modem seems 
to skip some SIM status during warm start.

So, can you please unplug replug the USB key, wait a few, just execute 
./list-modems and ./list-contexts (nothing else).
You should see the modem enabled and online, and your context created. If so, 
just execute ./activate-context

Regards,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi again,

> 1) Connect 3G key and wait for umts coverage (blue led)
>
> I activated the 3g connection, but ofono response is
>
> Error org.ofono.Error.NotImplemented: Implementation not provided
 Can you please send the full log for this case, and also the term output, 
 so I can see what you are exactly doing.
>>> I have attached the log on test 1 and 2.
>> Can you please add the full output of the oFono test scripts (since the 
>> ./list_modems to the error you have)?
>I have attacced the log for utms, for gprs I have some trouble to get the 
>signal now.

Mail has been sent to fast.

After the step 2 (Enable the modem), can you please do ./list-contexts ?

For step 3, you can do ./create-internet-context ibox.tim.it

And for step 4, you can do ./active-context

Regards,

Bertrand.
-
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
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

> 1) Connect 3G key and wait for umts coverage (blue led)
>
> I activated the 3g connection, but ofono response is
>
> Error org.ofono.Error.NotImplemented: Implementation not provided
 Can you please send the full log for this case, and also the term output, 
 so I can see what you are exactly doing.
>>> I have attached the log on test 1 and 2.
>> Can you please add the full output of the oFono test scripts (since the 
>> ./list_modems to the error you have)?
>I have attacced the log for utms, for gprs I have some trouble to get the 
>signal now.

Thanks.

After the step 2 (Enable the modem), can you please do ./list-contexts ?

And for step 4, you can do ./active-context

Regards,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>>> 1) Connect 3G key and wait for umts coverage (blue led)
>>>
>>> I activated the 3g connection, but ofono response is
>>>
>>> Error org.ofono.Error.NotImplemented: Implementation not provided
>> Can you please send the full log for this case, and also the term output, so 
>> I can see what you are exactly doing.
>
>I have attached the log on test 1 and 2.

Can you please add the full output of the oFono test scripts (since the 
./list_modems to the error you have)?

Thanks,

Bertrand.

-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>Ok thanks for pointing this out.
>We did not use the cage anymore, and simply moving the dongle around we are 
>able to make it use UMTS or GPRS, since the UMTS signal is >pretty low in this 
>area.
>
>This way we are able to test both scenarios, but still we observe the behavior 
>that we reported in the previous email:

Gentle reminder to not top post on the mailing list.

>> 1) Connect 3G key and wait for umts coverage (blue led)
>>
>> I activated the 3g connection, but ofono response is
>>
>> Error org.ofono.Error.NotImplemented: Implementation not provided
>>

Can you please send the full log for this case, and also the term output, so I 
can see what you are exactly doing.

>> I have tested the 3g connection on umts on windows and works connectly.
>>
>> 2) Connect 3G key and wait for gprs coverage (green led)
>>
>> I activated the 3g connection, but ofono response is
>>
>> Error org.ofono.Error.NotAttached: GPRS is not attached

And same for this test.

But one question, are you able to do a data call using this 3G SUB key 
connected to a Windows PC?

Regards,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>We work in a zone with limited utms coverage, some times it use gprs
>(green blinking led). The test 1 is the normal case with good umts coverage, 
>for test 2 i force gprs using for
>example a simple Faraday Cage.

If you use a Faraday Cage, you will lose all network capabilities, and not just 
UMTS.

According to oFono source code, Huwei modem doesn't support the radio settings, 
so there is no way to 'force' UMTS or GPRS. So you will have what the network 
will assign to you, based on your coverage, and the network capabilities.

So please do not use a Faraday Cage, this will not help at all.

Regards,

Bertrand.
-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>I have performed 2 tests
>
>1) Connect 3G key and wait for umts coverage (blue led)
>
>I activated the 3g connection, but ofono response is
>
>Error org.ofono.Error.NotImplemented: Implementation not provided
>
>Attacched there is the log of ofono test_umts.log
>
>I have tested the 3g connection on umts on windows and works connectly.
>
>2) Connect 3G key and wait for gprs coverage (green led)
>
>I activated the 3g connection, but ofono response is
>
>Error org.ofono.Error.NotAttached: GPRS is not attached
>
>Attacched there is the log of ofono test_gprs.log

I am not familiar with Huwai modem, and still learning oFono.

But one question: how do you make difference between test 1 and test 2? How did 
you force UMTS and then GPRS?
It seems that during test 1, you got network service. But not during test 2.

Can you please tell me exactly what you did for test 1, and what you did for 
test 2?

Regards,

Bertrand.


-
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: Trouble using Huwei E160G

[Aygon, Bertrand]

Hi,

>5) Activate the connection context 1  (adding the apn), but ofono respond with
>
>"Active" "GPRS is not attached"
>
>Some suggestions ?
>
>I have attached the log of ofono launched with debug option.

According to AT log, it seems that you are out of coverage.
Please try again, in a different place, and wait a few between the online and 
the active GPRS.

Regards,

Bertrand

-
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

USSD network initiated support

[Aygon, Bertrand]

Hi,

In doc/overview.txt , I could see that there is some work in progress about 
USSD network initiated. But I couldn't find anything about if in the TODO.

Does that means that USSD network initiated support is just something that we 
should work on, but no one is looking into? Or is someone working on it, but 
the TODO has not been updated?

Thanks,

Bertrand.

--
Bertrand Aygon  Engineering Manager
bertrand.ay...@intel.comOpen 
Source Technology Center, Intel Corporation

-
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: [PATCH 3/3] gprs.c: add list contexts for emulator

[Aygon, Bertrand]

Hi Denis,

>> Thanks Denis for your feedback.
>> The idea behind this code is to propose the complete support of the
>> usual AT+CGDCONT in the emulator. I think the best solution might be to
>> stick on contexts exposed over DBus, but this could lead to problems
>> like : a context is delete throught the DBus interface... how to handle
>> this change in the AT emulator, and avoid the use of the deleted context ?
>
>Personally I'm not convinced CGDCONT management is even a good idea.
>The typical usecase is for DUN clients to send a CGDCONT string, but
>this can simply be accepted and ignored (for instance).

We are not looking at DUN only, but to the 'global' AT Emulator, that will be 
used during GCF/PTCRB certification.
During certification, a lot of test require to set some GPRS context with 
specific parameters. And this cannot go 'directly' to the modem, without going 
through AP, because the test would not be relevant, or worse will failed, due 
to disconnect between oFono and modem.

>Just overwriting oFono's context store is not a good idea anyway as you
>lose certain valuable information.  For instance whether this context is
>used for internet (and ConnMan should pay attention to it) or it is used
>for mms, etc.
>
>It is also possible for the dial up client to provide context details
>that are identical to a context already defined in oFono.  In which case
>those details should be used instead (for the reasons outlined in the
>previous paragraph)

So from my point of view, all context must be in sync, in oFono side and modem 
side.

Regards,

Bertrand.
-
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: Setting PDP mode

[Aygon, Bertrand]

> Hi,
>
> It's possible to set the pdp mode through ofono ? I need to set the pdp
> mode to auto, ip and ppp,
>
> What are the dbus interface and properties to use ?

Hi,

You should have a look at doc/connman-api.txt.

In the org.ofono.ConnectionContext interface, there is a 'Protocol' properties.

But I am not so familiar with oFono yet, and it seems that only IP is 
supported. IPv6 works seems in progress.

And from what I could have seen in the sources, oFono only 'discuss' with modem 
making IP data call. For PPP, oFono use its own PPP stack.

So to conclude, I don't think that you can change the PDP mode, but I hope that 
someone with a biggest background, which should be very easy to found, will 
give us some more detailed info.

Regards,

Bertrand.
-
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: Request for info for issuing AT commands

[Aygon, Bertrand]

> Thanks Bertrand for your mail. I am working on the Audio Gateway side & I am 
> looking for APIs for receiving AT commands like AT+ATA, 
> AT+CHUP, AT+BLDN, AT+Ddd...dd, AT+VGS, AT+VGM, etc & for sending events like 
> VGM,VGS,CIEV, etc.
>
> Any informations on how to build a application for these will be really 
> helpful.

An application?

Some people (Frederic Danis and Frederic Dalleau) are currently working on the 
HFP support inside oFono. You can have a look at the oFono TODO file. There 
will be an atom inside oFono that will do this.

If you want to do this outside oFono, you will have to write an application 
that will analyze AT command received from BlueZ, and translate them into oFono 
APIs.

Regards,

Bertrand.

-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of 
Aygon, Bertrand
Sent: Thursday, March 10, 2011 4:15 PM
To: ofono@ofono.org
Subject: RE: Request for info for issuing AT commands

Hi,

> Hi Everyone,
>
> I am new to this list.

Welcome!

> I am looking for the oFono APIs that I can use to issue the AT commands for 
> HFP. I could not found much info on the oFono site. 
> It will be great help if someone can guide to any links/documents.

Can you please clarify this. What can of APIs are you looking at, and for which 
purpose?

We are working on HFP support in oFono, and on the AT Emulator to support all 
mandatory AT command for HFP.
But there should be no dedicated API for HFP inside oFono.

Regards,

Bertrand.
-
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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
-
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: Request for info for issuing AT commands

[Aygon, Bertrand]

Hi,

> Hi Everyone,
>
> I am new to this list.

Welcome!

> I am looking for the oFono APIs that I can use to issue the AT commands for 
> HFP. I could not found much info on the oFono site. 
> It will be great help if someone can guide to any links/documents.

Can you please clarify this. What can of APIs are you looking at, and for which 
purpose?

We are working on HFP support in oFono, and on the AT Emulator to support all 
mandatory AT command for HFP.
But there should be no dedicated API for HFP inside oFono.

Regards,

Bertrand.
-
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