Re: [PATCH v5 4/4] Detect SARA R4 QMI device

[Jonas Bonn]

Hi Denis,

This patch is fine, with one little fix below.

Patch message:

All QMI devices are currently piggy-backing on the 'gobi' driver to set 
up the QMI atoms.  For the SARA R4, this works with the addition of a quirk.


This patch adds the handling of a SARA R4 quirk to the 'gobi' driver.

On 12/05/2021 09:40, Bing Jupiter wrote:

---
  plugins/gobi.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/plugins/gobi.c b/plugins/gobi.c
index 9b5d7cff..5472dd83 100644
--- a/plugins/gobi.c
+++ b/plugins/gobi.c
@@ -47,6 +47,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -496,9 +497,17 @@ static void gobi_post_online(struct ofono_modem *modem)
struct gobi_data *data = ofono_modem_get_data(modem);
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
+const char* quirk;
+unsigned int vendor = 0;
  
  	DBG("%p", modem);
  
+quirk = ofono_modem_get_string(modem, "Quirk");

+if (quirk) {


Probably should have done:

if (quirk && !strcmp(quirk, "SARAR4")) {

/Jonas



+   DBG("Debug: vendor = OFONO_VENDOR_UBLOX_SARA_R4");
+vendor = OFONO_VENDOR_UBLOX_SARA_R4;
+}
+
if (data->features & GOBI_NAS) {
ofono_netreg_create(modem, 0, "qmimodem", data->device);
ofono_netmon_create(modem, 0, "qmimodem", data->device);
@@ -508,7 +517,7 @@ static void gobi_post_online(struct ofono_modem *modem)
ofono_ussd_create(modem, 0, "qmimodem", data->device);
  
  	if (data->features & GOBI_WDS) {

-   gprs = ofono_gprs_create(modem, 0, "qmimodem", data->device);
+   gprs = ofono_gprs_create(modem, vendor, "qmimodem", 
data->device);
gc = ofono_gprs_context_create(modem, 0, "qmimodem",
data->device);
  


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v5 3/4] Detect SARA R4 QMI device

[Jonas Bonn]

The SARA R4 modem detaches permanently from the network when the NAS 
Detach action is called.  This is problematic because ofono calls Detach 
when network connectivity is temporarily lost resulting in the modem 
never attempting to reattach again when the network once again becomes 
available.


In testing it was discovered, that the call to Attach doesn't appear to 
be required either.


This patch adds a quirk to the QMI GPRS atom to not call the NAS 
attach/detach actions for the uBlox SARA R4 device.


This has been tested on several SARA R4 devices that are running in 
long-term connectivity tests.  With this patch, the modem reconnects as 
the network comes and goes; without the patch, the modem goes idle the 
first time network connectivity is lost.


/Jonas

On 12/05/2021 09:40, Bing Jupiter wrote:

---
  drivers/qmimodem/gprs.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/qmimodem/gprs.c b/drivers/qmimodem/gprs.c
index 896a9e4c..fa20b809 100644
--- a/drivers/qmimodem/gprs.c
+++ b/drivers/qmimodem/gprs.c
@@ -26,6 +26,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "qmi.h"

  #include "nas.h"
@@ -35,6 +36,7 @@
  #include "qmimodem.h"
  
  struct gprs_data {

+unsigned int vendor;
struct qmi_device *dev;
struct qmi_service *nas;
struct qmi_service *wds;
@@ -284,6 +286,13 @@ static void qmi_set_attached(struct ofono_gprs *gprs, int 
attached,
  
  	DBG("attached %d", attached);
  
+if (data->vendor == OFONO_VENDOR_UBLOX_SARA_R4) {

+   DBG("Debug vendor = OFONO_VENDOR_UBLOX_SARA_R4");
+CALLBACK_WITH_SUCCESS(cb, cbd->data);
+g_free(cbd);
+return;
+}
+
if (attached)
action = QMI_NAS_ATTACH_ACTION_ATTACH;
else
@@ -406,6 +415,7 @@ static int qmi_gprs_probe(struct ofono_gprs *gprs,
DBG("");
  
  	data = g_new0(struct gprs_data, 1);

+data->vendor = vendor;
  
  	ofono_gprs_set_data(gprs, data);
  


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v5 2/4] Detect SARA R4 QMI device

[Jonas Bonn]

Add vendor tag for uBlox SARA R4 modems.

This device is actually a Qualcomm part so it doesn't fall under the 
uBlox category of devices, at all.


/Jonas

On 12/05/2021 09:40, Bing Jupiter wrote:

---
  drivers/atmodem/vendor.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/atmodem/vendor.h b/drivers/atmodem/vendor.h
index 82284e44..38613679 100644
--- a/drivers/atmodem/vendor.h
+++ b/drivers/atmodem/vendor.h
@@ -48,6 +48,7 @@ enum ofono_vendor {
OFONO_VENDOR_QUECTEL_EC2X,
OFONO_VENDOR_QUECTEL_SERIAL,
OFONO_VENDOR_UBLOX,
+OFONO_VENDOR_UBLOX_SARA_R4,
OFONO_VENDOR_XMM,
OFONO_VENDOR_GEMALTO,
  };


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v5 1/4] Detect SARA R4 QMI device

[Jonas Bonn]

Hi Denis,

On 12/05/2021 09:40, Bing Jupiter wrote:

A comment along these lines might be appropriate:

Unlike other uBlox, the SARA R4 is actually a Qualcomm part and supports 
the QMI protocol mostly as implemented in ofono.  The AT command set for 
this modem does not correspond to that used by other uBlox modems; 
furthermore, it is quirky to a degree that it doesn't really play well 
with ofono.


This patch adds support for the uBlox SARA R4 modem as a QMI device.

/Jonas



---
  plugins/udevng.c | 42 ++
  1 file changed, 42 insertions(+)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 34ac1cc0..46bf5532 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1194,6 +1194,46 @@ static gboolean setup_ublox(struct modem_info *modem)
return TRUE;
  }
  
+static gboolean setup_ubloxqmi(struct modem_info *modem) {

+   const char *qmi = NULL, *net = NULL, *gps = NULL, *aux = NULL;
+   GSList *list;
+
+   DBG("%s", modem->syspath);
+
+   for (list = modem->devices; list; list = g_slist_next(list)) {
+   struct device_info *info = list->data;
+
+   DBG("%s %s %s %s %s", info->devnode, info->interface,
+   info->number, info->label, info->subsystem);
+
+   if (g_strcmp0(info->interface, "255/255/255") == 0 &&
+   g_strcmp0(info->number, "03") == 0) {
+   if (g_strcmp0(info->subsystem, "net") == 0)
+   net = info->devnode;
+   else if (g_strcmp0(info->subsystem, "usbmisc") == 0)
+   qmi = info->devnode;
+   }
+   }
+
+   DBG("qmi=%s net=%s", qmi, net);
+
+   if (qmi == NULL || net == NULL)
+   return FALSE;
+
+   DBG("qmi=%s net=%s", qmi, net);
+
+   ofono_modem_set_string(modem->modem, "Device", qmi);
+   ofono_modem_set_string(modem->modem, "NetworkInterface", net);
+ofono_modem_set_string(modem->modem, "Quirk", "SARAR4");
+
+
+   DBG("gps=%s aux=%s", gps, aux);
+
+   ofono_modem_set_driver(modem->modem, "gobi");
+
+   return TRUE;
+}
+
  static gboolean setup_gemalto(struct modem_info* modem)
  {
const char *app = NULL, *gps = NULL, *mdm = NULL,
@@ -1441,6 +1481,7 @@ static struct {
{ "quectel",  setup_quectel   },
{ "quectelqmi",   setup_quectelqmi},
{ "ublox",setup_ublox },
+{ "ubloxqmi",   setup_ubloxqmi  },
{ "gemalto",  setup_gemalto   },
{ "xmm7xxx",  setup_xmm7xxx   },
{ "mbim", setup_mbim  },
@@ -1850,6 +1891,7 @@ static struct {
{ "ublox","cdc_ncm","1546", "110a"  },
{ "ublox","rndis_host", "1546", "1146"  },
{ "ublox","cdc_acm","1546", "1146"  },
+{ "ubloxqmi",   "qmi_wwan", "05c6", "90b2"  },
{ "gemalto",  "option", "1e2d",   "0053"},
{ "gemalto",  "cdc_wdm","1e2d",   "0053"},
{ "gemalto",  "qmi_wwan",   "1e2d",   "0053"},


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v5 0/4]

[Jonas Bonn]

Hi Denis,

If we're going to get anywhere with this, the onus probably falls on you 
to do some cleanup work on these patches.  I'll write some comments on 
the patches and maybe you can munge those into the commit messages...?


Bing Jupiter has been running this modem (uBlox SARA R4) for well over a 
year with these patches so they are somewhat tested.  That said, this 
modem isn't without issues, but it appears to me that those are mostly 
firmware related at this point.  Yeah, not great advertising for the 
product; probably best to stay away from it altogether, really...


/Jonas

On 12/05/2021 09:40, Bing Jupiter wrote:

Cleaned up comments and resubmit

Bing Jupiter (4):
   Detect SARA R4 QMI device
   Detect SARA R4 QMI device
   Detect SARA R4 QMI device
   Detect SARA R4 QMI device

  drivers/atmodem/vendor.h |  1 +
  drivers/qmimodem/gprs.c  | 10 ++
  plugins/gobi.c   | 11 ++-
  plugins/udevng.c | 42 
  4 files changed, 63 insertions(+), 1 deletion(-)


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v2 4/4] Make SARA R4 vendor ID conditional being attach and detach

[Jonas Bonn]

Hi,

On 24/02/2021 09:39, Bing Jupiter wrote:

---
  drivers/qmimodem/gprs.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/qmimodem/gprs.c b/drivers/qmimodem/gprs.c
index 896a9e4c..90203dd3 100644
--- a/drivers/qmimodem/gprs.c
+++ b/drivers/qmimodem/gprs.c
@@ -26,6 +26,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "qmi.h"

  #include "nas.h"
@@ -35,6 +36,7 @@
  #include "qmimodem.h"
  
  struct gprs_data {

+   unsigned int vendor;
struct qmi_device *dev;
struct qmi_service *nas;
struct qmi_service *wds;
@@ -284,6 +286,18 @@ static void qmi_set_attached(struct ofono_gprs *gprs, int 
attached,
  
  	DBG("attached %d", attached);
  
+	if (data->vendor == OFONO_VENDOR_UBLOX_SARA_R4) {

+   /* This assumes neither 'attach' nor 'detach' are
+* necessary... if 'attach' is required, then you'll
+* need to make this section conditional on the action
+* being 'detach'
+*/


Assuming you've tested this, you'll know whether 'attach' is required or 
not.  As such, fix accordingly and remove the above comment.


/Jonas



+   DBG("Debug vendor = OFONO_VENDOR_UBLOX_SARA_R4");
+   CALLBACK_WITH_SUCCESS(cb, cbd->data);
+   g_free(cbd);
+   return;
+   }
+
if (attached)
action = QMI_NAS_ATTACH_ACTION_ATTACH;
else
@@ -406,6 +420,7 @@ static int qmi_gprs_probe(struct ofono_gprs *gprs,
DBG("");
  
  	data = g_new0(struct gprs_data, 1);

+   data->vendor = vendor;
  
  	ofono_gprs_set_data(gprs, data);
  


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v2 1/4] SARA R4 QMI support

[Jonas Bonn]

Hi Jupiter,

Please add a description to your patch.  Something along these lines:

This adds support for the uBlox SARA-R4 modem.

Unlike other uBlox devices, this modem is actually a Qualcomm part and 
therefore supports the QMI protocol.  For that reason, this doesn't just 
jack into the usual uBlox modem framework.


The modem has a quirk in that it fails to reconnect to the network if a 
NAS detach is issued when connectivity is lost; therefore, we need to 
add some 'vendor' handling to the QMI gprs atom to account for this.


This has been tested... how?

Hope that helps,
Jonas

On 24/02/2021 09:39, Bing Jupiter wrote:

---
  plugins/udevng.c | 41 +
  1 file changed, 41 insertions(+)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 34ac1cc0..9941145f 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1194,6 +1194,45 @@ static gboolean setup_ublox(struct modem_info *modem)
return TRUE;
  }
  
+static gboolean setup_ubloxqmi(struct modem_info *modem) {

+   const char *qmi = NULL, *net = NULL, *gps = NULL, *aux = NULL;
+   GSList *list;
+
+   DBG("%s", modem->syspath);
+
+   for (list = modem->devices; list; list = g_slist_next(list)) {
+   struct device_info *info = list->data;
+
+   DBG("%s %s %s %s %s", info->devnode, info->interface,
+   info->number, info->label, info->subsystem);
+
+   if (g_strcmp0(info->interface, "255/255/255") == 0 &&
+   g_strcmp0(info->number, "03") == 0) {
+   if (g_strcmp0(info->subsystem, "net") == 0)
+   net = info->devnode;
+   else if (g_strcmp0(info->subsystem, "usbmisc") == 0)
+   qmi = info->devnode;
+   }
+   }
+
+   DBG("qmi=%s net=%s", qmi, net);
+
+   if (qmi == NULL || net == NULL)
+   return FALSE;
+
+   DBG("qmi=%s net=%s", qmi, net);
+
+   ofono_modem_set_string(modem->modem, "Device", qmi);
+   ofono_modem_set_string(modem->modem, "NetworkInterface", net);
+   ofono_modem_set_string(modem->modem, "Quirk", "SARAR4");
+
+   DBG("gps=%s aux=%s", gps, aux);
+
+   ofono_modem_set_driver(modem->modem, "gobi");
+
+   return TRUE;
+}
+
  static gboolean setup_gemalto(struct modem_info* modem)
  {
const char *app = NULL, *gps = NULL, *mdm = NULL,
@@ -1441,6 +1480,7 @@ static struct {
{ "quectel",  setup_quectel   },
{ "quectelqmi",   setup_quectelqmi},
{ "ublox",setup_ublox },
+   { "ubloxqmi",   setup_ubloxqmi  },
{ "gemalto",  setup_gemalto   },
{ "xmm7xxx",  setup_xmm7xxx   },
{ "mbim", setup_mbim  },
@@ -1850,6 +1890,7 @@ static struct {
{ "ublox","cdc_ncm","1546", "110a"  },
{ "ublox","rndis_host", "1546", "1146"  },
{ "ublox","cdc_acm","1546", "1146"  },
+   { "ubloxqmi",   "qmi_wwan", "05c6", "90b2"  },
{ "gemalto",  "option", "1e2d",   "0053"},
{ "gemalto",  "cdc_wdm","1e2d",   "0053"},
{ "gemalto",  "qmi_wwan",   "1e2d",   "0053"},


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Failed to reconnect after 4G LTE signaling strength level is back

[Jonas Bonn]

Hi,

On 27/11/2020 10:47, Jupiter wrote:

Hi Jonas,

Thanks for the response and kind helps.


and the modem continues to reset itself.  Is this coincidental with
you removing the antenna... I can't tell?


My apology, a watchdog to monitor and to restart ofono when it lost
register was still running.


That would explain it...



I attached a new log which disabled watchdog.

Here is the issue when the antenna was pulled out (simulating to lose
signalling), the modem was unregistered but it stuck at rssi callback:

ofonod[27530]: ../ofono-1.30/src/gprs.c:ofono_gprs_status_notify()
/ubloxqmi_0 status unregistered (0)
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: 
../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: 
../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
.

It then stuck and repeated following statements forever:

ofonod[27530]: 
../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0

static void qmi_netmon_request_update(struct ofono_netmon *netmon,
ofono_netmon_cb_t cb, void *user_data) invokes get_rssi_cb:
if (qmi_service_send(data->nas, QMI_NAS_GET_RSSI, param, get_rssi_cb,
cbd, g_free) > 0)

static void get_rssi_cb(struct qmi_result *result, void *user_data)
checks signalling RSSI, RSRQ, RSRP, obviously there is no valid
signaling streangh as the modem is in unregistered status.



I wouldn't worry about these netmon functions.  It's the 
network-registration driver that you should be looking at.  'netmon' is 
only for information, I think.



My question is, where and how does ofono or qmimodem check modem
register status? Calling rssi_cb is not capable of finding modem
register status. Is the register status in src/modem.c?


ss_info_notify() gets called when you get network information 
notifications from the modem.  That's where the magic happens.




Appreciate to shed light on how should ofono or qmimodme to handle
modem register status changes.
Thank you.


Looking at the log, it sure does seem like the modem just stops sending 
network status indications.  What happens if you re-assert interest in 
these notifications regularly... something like this?


--- a/drivers/qmimodem/network-registration.c
+++ b/drivers/qmimodem/network-registration.c
@@ -211,6 +211,9 @@ static void ss_info_notify(struct qmi_result 
*result, void *user_data)

return;

status = remember_ss_info(data, status, lac, cellid, roaming);
+
+   qmi_service_register(data->nas, QMI_NAS_SS_INFO_IND,
+   ss_info_notify, netreg, NULL);

ofono_netreg_status_notify(netreg, status, data->lac, data->cellid,

 tech);

The log file is in quite a readable state now.  It would be great if 
somebody else could take a look at it...  I'm a bit out of the loop with 
ofono, currently, so getting a bit rusty!


/Jonas




Kind regards,

- jupiter


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Failed to reconnect after 4G LTE signaling strength level is back

[Jonas Bonn]

Hi,

On 20/11/2020 06:26, Jupiter wrote:

Hmm, strange, I tried to restart ofonod several times, the last one
was able to reconnect the 4G and network automatically after removing
the antenna to lose network, then adding the antenna, the only
difference was there were many messages popped out in the console
screen:

[33383.892047] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33383.961208] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
[33385.634408] mwifiex_sdio mmc0:0001:1: info: trying to associate to 'JupiterIo
T' bssid 34:08:04:12:b1:a2
[33385.658542] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:b
1:a2 successfully
[33385.800544] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[33385.874181] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
[33453.714288] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from 34
:08:04:12:b1:a2: reason code 3
[33453.771463] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33453.836374] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready


You're probably grounding something when disconnecting the antenna...




it looks like when it did not work that some monitoring and callback
process was not activated, when it worked, the some process was
activated.

What I might missing here? Please see the attached log file
ofono_debug6.txt which is able to reconnect.



Again, this log shows a bunch of modem resets.

This pattern is repeated a couple of times:

ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify() 
signal with 40%(-77 dBm) on 8
ofonod[20465]: 
../ofono-1.30/src/network.c:ofono_netreg_strength_notify() strength 40
ofonod[20465]: ../ofono-1.30/src/modem.c:get_modem_property() modem 
0x567908 property SystemPath
ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[20465]: QMI: > 01 11 00 00 03 01 00 45 01 20 00 05 00 10 02 00 
...E. ..
ofonod[20465]: QMI:   ff 00 
..
ofonod[20465]: QMI: NAS_req msg=32 len=5 
[client=1,type=0,tid=325,len=17]

ofonod[20465]: QMI:{type=16,len=2}
ofonod[20465]: QMI: < 01 48 00 80 03 01 02 45 01 20 00 3c 00 02 04 00 
.H.E. .<
ofonod[20465]: QMI:   00 00 00 00 01 02 00 b3 08 11 04 00 01 00 4d 08 
..M.
ofonod[20465]: QMI:   12 04 00 01 00 3f 08 13 04 00 96 ff ff ff 14 01 
.?..
ofonod[20465]: QMI:   00 08 15 05 00 01 00 ff ff 08 16 02 00 f2 08 17 

ofonod[20465]: QMI:   02 00 fe ff 18 02 00 96 ff 
.
ofonod[20465]: QMI: NAS_resp msg=32 len=60 
[client=1,type=2,tid=325,len=72]
ofonod[20465]: QMI:{type=2,error=NONE} {type=1,len=2} 
{type=17,len=4} {type=18,len=4}
ofonod[20465]: QMI:{type=19,len=4} {type=20,len=1} 
{type=21,len=5} {type=22,len=2}

ofonod[20465]: QMI:{type=23,len=2} {type=24,len=2}
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() 
RSSI: 77 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() Bit 
error rate: 65535 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() 
RSRQ: -14 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() Got 
LTE RSRP: -106
ofonod[20465]: QMI: < 01 11 00 80 03 01 04 0c 00 02 00 05 00 10 02 00 

ofonod[20465]: QMI:   b7 08 
..

ofonod[20465]: QMI: NAS_ind msg=2 len=5 [client=1,type=4,tid=12,len=17]
ofonod[20465]: QMI:{type=16,len=2}
ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify() 
signal with 60%(-73 dBm) on 8
ofonod[20465]: 
../ofono-1.30/src/network.c:ofono_netreg_strength_notify() strength 60
ofonod[20465]: ../ofono-1.30/src/modem.c:modem_change_state() old state: 
3, new state: 0

ofonod[20465]: ../ofono-1.30/src/modem.c:flush_atoms()
ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_context_unregister() 
0x565c00, 0x55b7f0

ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_context_remove() atom: 0x565c28
ofonod[20465]: 
../ofono-1.30/drivers/qmimodem/gprs-context.c:qmi_gprs_context_remove()

ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_unregister() 0x55b7f0
ofonod[20465]: 
../ofono-1.30/src/network.c:__ofono_netreg_remove_status_watch() 0x5549a8

ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_remove() atom: 0x55e198
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/gprs.c:qmi_gprs_remove()
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_remove()
ofonod[20465]: ../ofono-1.30/src/sim.c:ofono_sim_remove_spn_watch() 0x55e060
ofonod[20465]: ../ofono-1.30/src/network.c:netreg_remove() atom: 0x573510
...

...and the modem continues to reset itself.  Is this coincidental with 
you removing the antenna... I can't tell?


/Jonas


I'll do more test, something is not stable or miss

Re: Failed to reconnect after 4G LTE signaling strength level is back

[Jonas Bonn]

Hi,

On 20/11/2020 00:39, Jupiter wrote:

Hi,

I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
functional well, but there is one problem, it failed to be reconnected
when the 4G LTE signaling strength level is back to normal. Here is
what I tested:

- Connect antenna, it was running fine, network is connected.

- Remove the antenna, the network is down.

- Wait for a while, reconnect the antenna, the ofono could not
reconnect, the driver was still there.

- If I restart ofnono the connection would be back.

I tested the same sequence on SARA EVK which is not running ofono, it
is capable of re-register automatically.

Appreciate your sight comments if it is ofono issue or QMI issue or
something else, please find the attached debug file.


You really need to annotate the log file because I can't see the problem 
you're describing there.


The log file shows the modem being reset a couple of times; there is no 
loss of signal before those events though.  My first thought was that 
you were crashing the modem while removing the antenna; however, it 
seems to me that the the reset is more controlled than that so it seems 
more likely that you are disabling the modem from some other program.


Like I said... annotate the logged events with some description of 
what's going on around them so that the problem can be debugged.


/Jonas



Thank you.

Kind regards,

- jupiter


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Change code and commit process

[Jonas Bonn]

Hi,

On 23/11/2020 06:45, Jupiter wrote:

How to commit code change, who should I contact for approving code change?


- prepare your patches in git on top of origin/master
- create a patch series

$ git format-patch --cover-letter origin/master -o patches

- edit the cover letter file, explaining what your patch series aims to do
- send the patches to the list

$ git send-email --to ofono@ofono.org patches

Roughly like that... double-check the commands because I might have 
missed something.


/Jonas



Thank you.

Kind regards,

- jupiter
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: 4G LTE GPRS Attach error?

[Jonas Bonn]

On 20/11/2019 10:39, JH wrote:

Sorry missing the subject, I further checked, it is not SIM issue,
then I am confused, does the 4G LTE is really using the old 2G GRPS?

Appreciate comments what is that error really means?

Thank you.

- jh

On 11/20/19, JH  wrote:

Hi,

I have two 4G LTE devices, one can connect to 4G network, one could
not and has following error from connman log file:

Failed to change property: /ubloxqmi_0/context1
org.ofono.ConnectionContext.Active: org.ofono.Error.AttachInProgress
GPRS Attach is in progress

Does the error indicate the SIM is not activated? Or what could be the
problem?


No, quite the opposite.  It pretty much indicates that the SIM is 
activated and it is in the process of connecting to the network.


Don't be confused by the GPRS terminology, there.  I think even for LTE 
you'll get this message while attaching to the default bearer.


Is that the last message in the log?  If yes, I would run with debug 
output and check what's going on in more detail.


/Jonas



Thank you.

Kind regards,

- jh


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: How accuracy to get 4G LTE RSSI via connman dbus query?

[Jonas Bonn]

Hi,

On 09/12/2019 07:50, JH wrote:

Hi,

I get 4G LTE RSSI from dbus connman service, I usually got about -61 I 
thought it was accurate. But today, we are doing a test to check 4G LTE 
RSSI based on different antennas, when connected to a antenna, the RSSI 
is about -61, when I did not connect to an antenna, the RSSI = -40 but 
the 4G LTE connection lost:


kernel: qmi_wwan 1-1:1.3: nonzero urb status received: -71.


Here your modem has probably crashed, right?



Apparently that RSSI = -40 was wrong in the situation of without antenna 
connection. I tried to build qmicli, but I could not get it running. 
googling Internet, people pointed out, it could not be run if the qmi is 
running by other services (ofono is running qmi on /dev/cdc-wdm0).


# qmicli --nas-get-signal-strength --device=/dev/cdc-wdm0
error: couldn't create client for the 'nas' service: CID allocation 
failed in the CTL client: Transaction timed out


Just make sure ofono is stopped before running ofono.

# systemctl stop ofono

/Jonas



Appreciate tips how to get qmicli running.

Thank you.

Kind regards,

- jh

___
connman mailing list -- conn...@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org


___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

[Jonas Bonn]

Hi Martin,

On 25/09/2019 09:27, Martin Hundebøll wrote:

Hi Jonas,

On 9/25/19 5:44 AM, Jonas Bonn wrote:

On 24/09/2019 21:20, Martin Hundebøll wrote:

On 24/09/2019 20.09, Martin Hundebøll wrote:

On 24/09/2019 19.23, Denis Kenzior wrote:
Furthermore, there's not an AT command sent every 500 ms.  The 
command gets requeued after 500ms, but it doesn't actually go out 
until the modem responds to the first one... not quite sure why 
this works, to be honest.




Funny.  But not real confidence inspiring :)

Martin, any ideas what could be going wrong here?


The code looks quite familiar :)


For good reason! :)



Jonas, do you have a log with OFONO_AT_DEBUG=1 set?




ofonod[31545]: Aux: > AT\r
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: plugins/ublox.c:init_cmd_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: Aux: < \r\n+AT: READY\r\n
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > ATE0\r
ofonod[31545]: Aux: < ATE0
ofonod[31545]: Aux: < \r\r\nOK\r\n



For the record, here one from my setup:

UART: > AT\r
UART: < \371\013s\001\222\371
../git/plugins/quectel.c:init_timeout_cb() 0x61000d40
UART: > AT\r
UART: < \r\nOK\r\n
../git/plugins/quectel.c:init_cmd_cb() 0x61000d40
../git/src/modem.c:get_modem_property() modem 0x61000d40 property 
RtsCts

UART: > ATE0\r
UART: < \r\nOK\r\n



So yours looks a bit different... you really do lose the first AT 
command into a black hole.  The uBlox modem seems to not lose anything 
sent over the USB bus but rather buffers it up and responds later.  
That said, according to the documentation it _could_ lose the AT 
command so one cannot rely on the response just turning up eventually.


Could it be safe to assume that it will lose only a single AT command? 
In that case, it should be enough to send just two AT's. Once the first 
OK is received, you could wait 500 ms for the second OK, or retry the 
second AT in case of a timeout?


No lost AT:
  > AT   // Send first
  > AT   // Send second and wait
  < OK   // Wait 500 ms
  < OK   // Start initialization

One lost AT
  > AT   // Send first
  > AT   // Send second and wait
  < OK   // Wait 500 ms
  > AT   // Retry second
  < OK   // Start initialization


That's pretty much what we've got, isn't it?




The thing that wasn't clear to me, though, was why every invocation of 
init_timeout_cb doesn't result in a new AT command being sent?  It's 
like the command is set to be retried in the first invocation, but it 
never gets sent so the subsequent retries amount to no-ops.  This 
behaviour is agreeable in this case, but I don't quite understand why 
it works this way...


Can the usb-to-serial driver block further writes until the modem is ready?


Not the driver but the modem.  If the USB bulk endpoint on the modem 
side decides it is busy (for example, because it's buffers are full), it 
can NAK subsequent packets until it's ready to receive again.  It's not 
out of the question that Linux is smart enough to return EAGAIN for a 
write in that case... but I would suspect that the OS would normally 
buffer the write() for more than one AT command before this happened. 
For that reason, I can't see why ofono would be able to detect this... 
from ofono's point of view it should just look like there's a series of 
AT commands going out and no responses coming back.  There must be some 
magic in g_io_...???


/Jonas



// Martin

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

[Jonas Bonn]

On 25/09/2019 08:40, Richard Röjfors wrote:
Den tis 24 sep. 2019 kl 21:55 skrev Pavel Machek <mailto:pa...@ucw.cz>>:


On Tue 2019-09-24 18:01:26, Jonas Bonn wrote:
 > uBlox devices present their USB interfaces well before those
interfaces
 > are ready to respond to any commands.  The documentation says to
monitor
 > the 'greeting text' to detect readiness, but this 'greeting text'
is not
 > actually specified for any device other than the TOBY L4.

Collecting "greeting texts" from all the modems we want to support
should not be hard, right?


...given that one has access to all the devices!

Honestly, I suspect the documentation is garbage.  There are no greeting 
texts for devices other than the L4; probing is just a matter of waiting 
for AT to respond to with OK.





I don't think that's a good idea. What if ofono is restated and the 
modem is still running?


In this case, the TOBY-L4 does not provide a greeting text.

/Jonas




--Richard

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v3 1/3] ublox: consolidate teardown in common function

[Jonas Bonn]

The code for closing all the modem devices and flagging the modem as
unpowered is repeated several times in the driver... this patch puts
this code into a common helper for readability.
---
 plugins/ublox.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 9ee38a6b..60a734ce 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -102,19 +102,25 @@ static void ublox_remove(struct ofono_modem *modem)
g_free(data);
 }
 
+static void close_devices(struct ofono_modem* modem)
+{
+   struct ublox_data * data = ofono_modem_get_data(modem);
+
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
 static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem *modem = user_data;
-   struct ublox_data * data = ofono_modem_get_data(modem);
 
DBG("ok %d", ok);
 
if (!ok) {
-   g_at_chat_unref(data->aux);
-   data->aux = NULL;
-   g_at_chat_unref(data->modem);
-   data->modem = NULL;
-   ofono_modem_set_powered(modem, FALSE);
+   close_devices(modem);
return;
}
 
@@ -165,11 +171,7 @@ retry:
return;
 
 error:
-   g_at_chat_unref(data->aux);
-   data->aux = NULL;
-   g_at_chat_unref(data->modem);
-   data->modem = NULL;
-   ofono_modem_set_powered(modem, FALSE);
+   close_devices(modem);
 }
 
 static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
@@ -216,11 +218,7 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
 
 fail:
-   g_at_chat_unref(data->aux);
-   data->aux = NULL;
-   g_at_chat_unref(data->modem);
-   data->modem = NULL;
-   ofono_modem_set_powered(modem, FALSE);
+   close_devices(modem);
 }
 
 static int ublox_enable(struct ofono_modem *modem)
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v3 2/3] ublox: use common close_devices when modem disabled

[Jonas Bonn]

Just reshuffling the code a bit and the 'disable' path can use the
close_devices() helper to finish up.  This also prevents a bug should
the CFUN command fail to disable the modem whereby the 'aux' device
remains open but the 'modem' device has already been closed.
---
 plugins/ublox.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 60a734ce..22350462 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -269,15 +269,15 @@ static int ublox_enable(struct ofono_modem *modem)
 static void cfun_disable(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem *modem = user_data;
-   struct ublox_data *data = ofono_modem_get_data(modem);
 
DBG("");
 
-   g_at_chat_unref(data->aux);
-   data->aux = NULL;
+   if (!ok) {
+   ofono_error("Failed to disable modem");
+   return;
+   }
 
-   if (ok)
-   ofono_modem_set_powered(modem, FALSE);
+   close_devices(modem);
 }
 
 static int ublox_disable(struct ofono_modem *modem)
@@ -288,8 +288,6 @@ static int ublox_disable(struct ofono_modem *modem)
 
g_at_chat_cancel_all(data->modem);
g_at_chat_unregister_all(data->modem);
-   g_at_chat_unref(data->modem);
-   data->modem = NULL;
 
g_at_chat_cancel_all(data->aux);
g_at_chat_unregister_all(data->aux);
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v3 0/3] ublox device initialisation

[Jonas Bonn]

Changed in v3:
- consolidate device closing into a common helper
- remove timeout in disable function

Jonas Bonn (3):
  ublox: consolidate teardown in common function
  ublox: use common close_devices when modem disabled
  ublox: rework device initialization sequence

 plugins/ublox.c | 155 
 1 file changed, 118 insertions(+), 37 deletions(-)

-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v3 3/3] ublox: rework device initialization sequence

[Jonas Bonn]

uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands.  The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.

What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding.  The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.

It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried.  This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.

Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:

i)  it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval

This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
---
 plugins/ublox.c | 113 ++--
 1 file changed, 99 insertions(+), 14 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 22350462..efcd40cf 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define OFONO_API_SUBJECT_TO_CHANGE
 #include 
@@ -66,6 +67,10 @@ struct ublox_data {
 
const struct ublox_model *model;
int flags;
+
+   struct l_timeout *init_timeout;
+   int init_count;
+   guint init_cmd;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -221,6 +226,72 @@ fail:
close_devices(modem);
 }
 
+static void init_cmd_cb(gboolean ok, GAtResult *result, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   if (!ok)
+   goto fail;
+
+   /* When the 'init command' succeeds, we insert an additional
+* delay of 1 second before proceeding with the actual
+* intialization of the device.  We reuse the init_timeout
+* instance for this, just clearing the command to indicate
+* that additional retries aren't necessary.
+*/
+   data->init_cmd = 0;
+   data->init_count = 0;
+   l_timeout_modify_ms(data->init_timeout, 1000);
+
+   return;
+
+fail:
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   close_devices(modem);
+}
+
+static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   /* As long as init_cmd is set we need to either keep retrying
+* or fail everything after excessive retries
+*/
+   if (data->init_cmd && data->init_count++ < 20) {
+   g_at_chat_retry(data->aux, data->init_cmd);
+   l_timeout_modify_ms(timeout, 1000);
+   return;
+   }
+
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   if (data->init_cmd) {
+   ofono_error("failed to init modem after 20 attempts");
+   goto fail;
+   }
+
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
+   NULL, NULL, NULL);
+
+   if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
+   query_model_cb, modem, NULL) > 0)
+   return;
+
+fail:
+   close_devices(modem);
+}
+
 static int ublox_enable(struct ofono_modem *modem)
 {
struct ublox_data *data = ofono_modem_get_data(modem);
@@ -248,22 +319,34 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_send(data->modem, "AT&C0", NULL, NULL, NULL, NULL);
}
 
-   /* The modem can take a while to wake up if just powered on. */
-   g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
-
-   g_at_chat_send(data->aux, "ATE0", none_prefix,
-   NULL, NULL, NULL);
-   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
-   NULL, NULL, NULL);
-
-   if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
-   query_model_cb, modem, NULL) > 0)
-   return -EINPROGRESS;
+   /*
+* uBlox devices present their USB interfaces well before those
+* interfaces are ac

Re: [PATCH] ublox: network-registration: Check ureg for tech also for L2 modems

[Jonas Bonn]

Hi Richard,

On 24/09/2019 18:11, richard.rojf...@gmail.com wrote:

From: Richard Röjfors 

It seems like the CREG reporting from the L2 modems are quite
buggy. An example for a L210 where CREG reports UTRAN while
COPS and UREG reports LTE. A manual poll also indicates LTE.

I also found that the technology mapping was incorrect,
probably confused with enum packet_bearer.

A commented log showing where CREG is not trustable:

UREG indicates LTE
21:59:29 : < \r\n+UREG: 7\r\n
21:59:29 : < \r\n+CIEV: 9,2\r\n
21:59:29 : < \r\n+CGEV: NW MODIFY 1,0,0\r\n
21:59:31 : < \r\n+CIEV: 2,2\r\n
21:59:39 : < \r\n+CIEV: 2,3\r\n
21:59:44 : < \r\n+CIEV: 2,2\r\n
22:01:38 : < \r\n+CIEV: 2,3\r\n
22:01:43 : < \r\n+CIEV: 2,2\r\n

A CREG indicating UTRAN with HSDPA and HSUPA
22:29:39 : < \r\n+CREG: 5,"","",6\r\n
22:29:39 : > AT\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS=3,2\r
22:29:39 : < \r\n+CIEV: 9,2\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS?\r

An immediate cops indicating LTE
22:29:39 : < \r\n+COPS: 0,2,"24007",7\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CSQ\r
22:29:39 : < \r\n+CIEV: 2,4\r\n
22:29:39 : < \r\n+CSQ: 26,4\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CGATT=1\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS=3,0\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS?\r

Another cops also indicates LTE
22:29:39 : < \r\n+COPS: 0,0,"Tele2",7\r\n <- 7: LTE
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CGREG?\r

CGREG indicates unknown -> normal on LTE
22:29:39 : < \r\n+CGREG: 2,4\r\n
22:29:39 : < \r\nOK\r\n
22:29:44 : < \r\n+CIEV: 9,2\r\n
22:29:46 : < \r\n+CIEV: 2,2\r\n
22:56:23 : < \r\n+CIEV: 2,3\r\n
22:56:28 : < \r\n+CIEV: 2,2\r\n
22:59:40 : < \r\n+CIEV: 2,4\r\n

Manual poll shows we are running LTE
at+creg?
+CREG: 2,5,"2AFC","01DB0206",7

OK


For the TOBY-L4, RAT changes won't trigger a CREG URC... for whatever 
reason, this command is so brittle that they needed to bypass it with a 
UREG command.  For the L2, they don't bother to document this, but it 
appears to suffer from the same deficiencies as the L4.  CGREG and 
friends appear to suffer from the same ailment... they don't have a firm 
grasp of the overall state so they return "unknown" as a fallback.




---
  drivers/ubloxmodem/network-registration.c | 34 +++
  1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/ubloxmodem/network-registration.c 
b/drivers/ubloxmodem/network-registration.c
index 64ef8076..69af4644 100644
--- a/drivers/ubloxmodem/network-registration.c
+++ b/drivers/ubloxmodem/network-registration.c
@@ -58,6 +58,7 @@ struct tech_query {
int status;
int lac;
int ci;
+   int tech;
struct ofono_netreg *netreg;
  };
  
@@ -235,20 +236,40 @@ static void ublox_query_tech_cb(gboolean ok, GAtResult *result,

return;
  
  	switch (state) {

+   case 0:
+   /* Not registered for PS, then we have to trust CREG... */
+   tech = tq->tech;
+   break;
+   case 1:
+   tech = ACCESS_TECHNOLOGY_GSM;
+   break;
+   case 2:
+   tech = ACCESS_TECHNOLOGY_GSM_EGPRS;
+   break;
+   case 3:
+   tech = ACCESS_TECHNOLOGY_UTRAN;
+   break;
case 4:
-   tech = 5;
+   tech = ACCESS_TECHNOLOGY_UTRAN_HSDPA;
break;
case 5:
-   tech = 4;
+   tech = ACCESS_TECHNOLOGY_UTRAN_HSUPA;
+   break;
+   case 6:
+   tech = ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA;
+   break;
+   case 7:
+   tech = ACCESS_TECHNOLOGY_EUTRAN;
break;
case 8:
-   tech = 1;
+   tech = ACCESS_TECHNOLOGY_GSM;
break;
case 9:
-   tech = 2;
+   tech = ACCESS_TECHNOLOGY_GSM_EGPRS;
break;
default:
-   tech = state;
+   /* Not registered for PS or something unknown, trust CREG... */
+   tech = tq->tech;
}
  
  error:

@@ -270,12 +291,13 @@ static void creg_notify(GAtResult *result, gpointer 
user_data)
if (status != 1 && status != 5)
goto notify;
  
-	if (ublox_is_toby_l4(nd->model)) {

+   if (ublox_is_toby_l4(nd->model) || ublox_is_toby_l2(nd->model)) {
tq = g_new0(struct tech_query, 1);
  
  		tq->status = status;

tq->lac = lac;
tq->ci = ci;
+   tq->tech = tech;
tq->netreg = netreg;
  
  		if (g_at_chat_send(nd->at_data.chat, "AT+UREG?", ureg_prefix,




+1, looks good.  I'm even inclined to say we should do this for all 
u-Blox modems, but since I don't have access to any other models it's 
probably best to just add them to this list one by one as they become 
available for test.


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailma

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

[Jonas Bonn]

Hi Martin,

On 24/09/2019 21:20, Martin Hundebøll wrote:

Hi,

On 24/09/2019 20.09, Martin Hundebøll wrote:

On 24/09/2019 19.23, Denis Kenzior wrote:
Furthermore, there's not an AT command sent every 500 ms.  The 
command gets requeued after 500ms, but it doesn't actually go out 
until the modem responds to the first one... not quite sure why this 
works, to be honest.




Funny.  But not real confidence inspiring :)

Martin, any ideas what could be going wrong here?


The code looks quite familiar :)


For good reason! :)



Jonas, do you have a log with OFONO_AT_DEBUG=1 set?




ofonod[31545]: Aux: > AT\r
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: plugins/ublox.c:init_cmd_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: Aux: < \r\n+AT: READY\r\n
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > ATE0\r
ofonod[31545]: Aux: < ATE0
ofonod[31545]: Aux: < \r\r\nOK\r\n



For the record, here one from my setup:

UART: > AT\r
UART: < \371\013s\001\222\371
../git/plugins/quectel.c:init_timeout_cb() 0x61000d40
UART: > AT\r
UART: < \r\nOK\r\n
../git/plugins/quectel.c:init_cmd_cb() 0x61000d40
../git/src/modem.c:get_modem_property() modem 0x61000d40 property 
RtsCts

UART: > ATE0\r
UART: < \r\nOK\r\n



So yours looks a bit different... you really do lose the first AT 
command into a black hole.  The uBlox modem seems to not lose anything 
sent over the USB bus but rather buffers it up and responds later.  That 
said, according to the documentation it _could_ lose the AT command so 
one cannot rely on the response just turning up eventually.


The thing that wasn't clear to me, though, was why every invocation of 
init_timeout_cb doesn't result in a new AT command being sent?  It's 
like the command is set to be retried in the first invocation, but it 
never gets sent so the subsequent retries amount to no-ops.  This 
behaviour is agreeable in this case, but I don't quite understand why it 
works this way...


/Jonas



___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

[Jonas Bonn]

On 24/09/2019 18:32, Richard Röjfors wrote:

Hi Jonas,

Den tis 24 sep. 2019 kl 18:01 skrev Jonas Bonn <mailto:jo...@norrbonn.se>>:


uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands.  The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.

What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding.  The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.

It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried.  This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.

Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:

i)  it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval

This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
---

Changed in v2:
- drop return statement
- drop superfluous empty line

  plugins/ublox.c | 119 ++--
  1 file changed, 105 insertions(+), 14 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 9ee38a6b..5be9d4cc 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 

  #define OFONO_API_SUBJECT_TO_CHANGE
  #include 
@@ -66,6 +67,10 @@ struct ublox_data {

         const struct ublox_model *model;
         int flags;
+
+       struct l_timeout *init_timeout;


Shouldn't this should be removed in disable in case its still available..

+       int init_count;
+       guint init_cmd;
  };

  static void ublox_debug(const char *str, void *user_data)
@@ -223,6 +228,80 @@ fail:
         ofono_modem_set_powered(modem, FALSE);
  }

+static void init_cmd_cb(gboolean ok, GAtResult *result, void
*user_data)
+{
+       struct ofono_modem *modem = user_data;
+       struct ublox_data *data = ofono_modem_get_data(modem);
+
+       DBG("%p", modem);
+
+       if (!ok)
+               goto fail;
+
+       /* When the 'init command' succeeds, we insert an additional
+        * delay of 1 second before proceeding with the actual
+        * intialization of the device.  We reuse the init_timeout
+        * instance for this, just clearing the command to indicate
+        * that additional retries aren't necessary.
+        */
+       data->init_cmd = 0;
+       data->init_count = 0;
+       l_timeout_modify_ms(data->init_timeout, 1000);
+
+       return;
+
+fail:
+       l_timeout_remove(data->init_timeout);
+       data->init_timeout = NULL;
+
+       g_at_chat_unref(data->aux);
+       data->aux = NULL;
+       g_at_chat_unref(data->modem);
+       data->modem = NULL;
+       ofono_modem_set_powered(modem, FALSE);
+}
+
+static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
+{
+       struct ofono_modem *modem = user_data;
+       struct ublox_data *data = ofono_modem_get_data(modem);
+
+       DBG("%p", modem);
+
+       /* As long as init_cmd is set we need to either keep retrying
+        * or fail everything after excessive retries
+        */
+       if (data->init_cmd && data->init_count++ < 20) {
+               g_at_chat_retry(data->aux, data->init_cmd);
+               l_timeout_modify_ms(timeout, 1000);
+               return;
+       }
+
+       l_timeout_remove(data->init_timeout);
+       data->init_timeout = NULL;
+
+       if (data->init_cmd) {
+               ofono_error("failed to init modem after 20 attempts");
+               goto fail;
+       }
+
+       g_at_chat_send(data->aux, "ATE0", none_prefix,
+                                       NULL, NULL, NULL);
+       g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
+                                       NUL

[PATCH v2 1/1] ublox: rework device initialization sequence

[Jonas Bonn]

uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands.  The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.

What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding.  The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.

It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried.  This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.

Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:

i)  it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval

This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
---

Changed in v2:
- drop return statement
- drop superfluous empty line

 plugins/ublox.c | 119 ++--
 1 file changed, 105 insertions(+), 14 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 9ee38a6b..5be9d4cc 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define OFONO_API_SUBJECT_TO_CHANGE
 #include 
@@ -66,6 +67,10 @@ struct ublox_data {
 
const struct ublox_model *model;
int flags;
+
+   struct l_timeout *init_timeout;
+   int init_count;
+   guint init_cmd;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -223,6 +228,80 @@ fail:
ofono_modem_set_powered(modem, FALSE);
 }
 
+static void init_cmd_cb(gboolean ok, GAtResult *result, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   if (!ok)
+   goto fail;
+
+   /* When the 'init command' succeeds, we insert an additional
+* delay of 1 second before proceeding with the actual
+* intialization of the device.  We reuse the init_timeout
+* instance for this, just clearing the command to indicate
+* that additional retries aren't necessary.
+*/
+   data->init_cmd = 0;
+   data->init_count = 0;
+   l_timeout_modify_ms(data->init_timeout, 1000);
+
+   return;
+
+fail:
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   /* As long as init_cmd is set we need to either keep retrying
+* or fail everything after excessive retries
+*/
+   if (data->init_cmd && data->init_count++ < 20) {
+   g_at_chat_retry(data->aux, data->init_cmd);
+   l_timeout_modify_ms(timeout, 1000);
+   return;
+   }
+
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   if (data->init_cmd) {
+   ofono_error("failed to init modem after 20 attempts");
+   goto fail;
+   }
+
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
+   NULL, NULL, NULL);
+
+   if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
+   query_model_cb, modem, NULL) > 0)
+   return;
+
+fail:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
 static int ublox_enable(struct ofono_modem *modem)
 {
struct ublox_data *data = ofono_modem_get_data(modem);
@@ -250,22 +329,34 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_send(data->modem, "AT&C0", NULL, NULL, NULL, NULL);
}
 
-   /* The modem can take a while to wake up if just powered on. */
-   g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
-
-   g_at_chat_send(data->aux, "ATE0", none_prefix,
-   NULL, NULL, NULL);
-   g_a

Re: [PATCH 3/3] ublox: rework device initialization sequence

[Jonas Bonn]

On 24/09/2019 17:05, Denis Kenzior wrote:

Hi Jonas,

On 9/24/19 6:33 AM, Jonas Bonn wrote:

uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands.  The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.

What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding.  The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.

It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried.  This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.

Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:

i)  it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval

This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
---
  plugins/ublox.c | 121 ++--
  1 file changed, 107 insertions(+), 14 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 9ee38a6b..656dc553 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #define OFONO_API_SUBJECT_TO_CHANGE
  #include 
@@ -66,6 +67,10 @@ struct ublox_data {
  const struct ublox_model *model;
  int flags;
+
+    struct l_timeout *init_timeout;
+    int init_count;
+    guint init_cmd;
  };
  static void ublox_debug(const char *str, void *user_data)
@@ -223,6 +228,82 @@ fail:
  ofono_modem_set_powered(modem, FALSE);
  }
+static void init_cmd_cb(gboolean ok, GAtResult *result, void *user_data)
+{
+    struct ofono_modem *modem = user_data;
+    struct ublox_data *data = ofono_modem_get_data(modem);
+
+    DBG("%p", modem);
+
+    if (!ok)
+    goto fail;
+
+    /* When the 'init command' succeeds, we insert an additional
+ * delay of 1 second before proceeding with the actual
+ * intialization of the device.  We reuse the init_timeout
+ * instance for this, just clearing the command to indicate
+ * that additional retries aren't necessary.
+ */
+    data->init_cmd = 0;
+    data->init_count = 0;
+    l_timeout_modify_ms(data->init_timeout, 1000);
+
+    return;
+
+fail:
+    l_timeout_remove(data->init_timeout);
+    data->init_timeout = NULL;
+
+    g_at_chat_unref(data->aux);
+    data->aux = NULL;
+    g_at_chat_unref(data->modem);
+    data->modem = NULL;
+    ofono_modem_set_powered(modem, FALSE);
+}
+
+static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
+{
+    struct ofono_modem *modem = user_data;
+    struct ublox_data *data = ofono_modem_get_data(modem);
+
+    DBG("%p", modem);
+
+    /* As long as init_cmd is set we need to either keep retrying
+ * or fail everything after excessive retries
+ */
+    if (data->init_cmd && data->init_count++ < 20) {
+    g_at_chat_retry(data->aux, data->init_cmd);
+    l_timeout_modify_ms(timeout, 1000);
+    return;
+    }


Can data->init_cmd be 0 here?


Yes... init_cmd gets cleared in init_cmd_cb when the command succeeds. 
We reuse the callback to get an extra 1 second delay (which we require) 
before continuing with the initialization.  There's a comment about this 
in init_cmd_cb above.





+
+    l_timeout_remove(data->init_timeout);
+    data->init_timeout = NULL;
+
+    if (data->init_cmd) {


Or here?


Yes.




+    ofono_error("failed to init modem after 20 attempts");
+    goto fail;
+    }
+
+    g_at_chat_send(data->aux, "ATE0", none_prefix,
+    NULL, NULL, NULL);
+    g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
+    NULL, NULL, NULL);
+
+    if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
+    query_model_cb, modem, NULL) > 0)
+    return;
+
+fail:
+    g_at_chat_unref(data->aux);
+    data->aux = NULL;
+    g_at_chat_unref(data->modem);
+    data->modem = NULL;
+    ofono_modem_set_powered(modem, FALSE);
+    return;


This return isn't needed, and you may want to just put these statements 
into a common utility since you copy-paste this in two places.


Yes, but it's not needed anywhere else... are you requiring a stati

[PATCH 2/3] ublox: raise call to open device

[Jonas Bonn]

---
 plugins/ublox.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index b65bc52a..9ee38a6b 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -102,13 +102,6 @@ static void ublox_remove(struct ofono_modem *modem)
g_free(data);
 }
 
-static GAtChat *open_device(struct ofono_modem *modem,
-   const char *key, char *debug)
-{
-   return at_util_open_device(modem, key, ublox_debug, debug,
-   NULL);
-}
-
 static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem *modem = user_data;
@@ -236,17 +229,20 @@ static int ublox_enable(struct ofono_modem *modem)
 
DBG("%p", modem);
 
-   data->aux = open_device(modem, "Aux", "Aux: ");
+   data->aux = at_util_open_device(modem, "Aux",
+   ublox_debug, "Aux: ", NULL);
/* If this is a serial modem then the device may be behind
 * the 'Device' attribute instead...
 */
if (data->aux == NULL) {
-   data->aux = open_device(modem, "Device", "Aux: ");
+   data->aux = at_util_open_device(modem, "Device",
+   ublox_debug, "Aux: ", NULL);
if (data->aux == NULL)
return -EINVAL;
}
 
-   data->modem = open_device(modem, "Modem", "Modem: ");
+   data->modem = at_util_open_device(modem, "Modem",
+   ublox_debug, "Modem: ", NULL);
if (data->modem) {
g_at_chat_set_slave(data->modem, data->aux);
g_at_chat_send(data->modem, "ATE0 +CMEE=1", none_prefix,
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 3/3] ublox: rework device initialization sequence

[Jonas Bonn]

uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands.  The documentation says to monitor
the 'greeting text' to detect readiness, but this 'greeting text' is not
actually specified for any device other than the TOBY L4.

What seems to work is to probe the device with 'AT' commands until the
device responds, and then to wait an additional second before
proceeding.  The TOBY L4 reliably sends its 'greeting text' (+AT: READY)
within this interval.

It would be more rigorous to actually wait for the 'READY' indication
for the TOBY L4, but that would require knowing the device model before
the device model is actually queried.  This is doable via the USB
product ID, but overkill when the above heuristic seems to work
reliably.

Before this patch, the ublox plugin was trying to achieve something like
the above with the g_at_chat_set_wakeup_command() function, but that had
some issues:

i)  it did not work reliably, in particular failing badly on the TOBY L4
with responses getting out of sync with commands
ii) it was an inappropriate use of the wakeup_command which is intended
for devices that may sleep when there is no communication during some
interval

This patch adds an init sequence that probes the device for readiness
before continuing with initialization.
---
 plugins/ublox.c | 121 ++--
 1 file changed, 107 insertions(+), 14 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 9ee38a6b..656dc553 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define OFONO_API_SUBJECT_TO_CHANGE
 #include 
@@ -66,6 +67,10 @@ struct ublox_data {
 
const struct ublox_model *model;
int flags;
+
+   struct l_timeout *init_timeout;
+   int init_count;
+   guint init_cmd;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -223,6 +228,82 @@ fail:
ofono_modem_set_powered(modem, FALSE);
 }
 
+static void init_cmd_cb(gboolean ok, GAtResult *result, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   if (!ok)
+   goto fail;
+
+   /* When the 'init command' succeeds, we insert an additional
+* delay of 1 second before proceeding with the actual
+* intialization of the device.  We reuse the init_timeout
+* instance for this, just clearing the command to indicate
+* that additional retries aren't necessary.
+*/
+   data->init_cmd = 0;
+   data->init_count = 0;
+   l_timeout_modify_ms(data->init_timeout, 1000);
+
+   return;
+
+fail:
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
+   /* As long as init_cmd is set we need to either keep retrying
+* or fail everything after excessive retries
+*/
+   if (data->init_cmd && data->init_count++ < 20) {
+   g_at_chat_retry(data->aux, data->init_cmd);
+   l_timeout_modify_ms(timeout, 1000);
+   return;
+   }
+
+   l_timeout_remove(data->init_timeout);
+   data->init_timeout = NULL;
+
+   if (data->init_cmd) {
+   ofono_error("failed to init modem after 20 attempts");
+   goto fail;
+   }
+
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
+   NULL, NULL, NULL);
+
+   if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
+   query_model_cb, modem, NULL) > 0)
+   return;
+
+fail:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+   return;
+}
+
+
 static int ublox_enable(struct ofono_modem *modem)
 {
struct ublox_data *data = ofono_modem_get_data(modem);
@@ -250,22 +331,34 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_send(data->modem, "AT&C0", NULL, NULL, NULL, NULL);
}
 
-   /* The modem can take a while to wake up if just powered on. */
-   g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
-
-   g_at_chat_send(data->aux, "ATE0", none_prefix,
-   NULL, NULL, NULL);
-   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
-   

[PATCH 1/3] quectel: remove unused variable

[Jonas Bonn]

---
 plugins/quectel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/plugins/quectel.c b/plugins/quectel.c
index d4947489..1d21d6dd 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -1147,7 +1147,6 @@ static void quectel_set_online(struct ofono_modem *modem, 
ofono_bool_t online,
 static void quectel_pre_sim(struct ofono_modem *modem)
 {
struct quectel_data *data = ofono_modem_get_data(modem);
-   struct ofono_sim *sim;
 
DBG("%p", modem);
 
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH] ublox: gprs: React on context deactivation

[Jonas Bonn]

On Tue, Sep 3, 2019, 16:11 Richard Röjfors 
wrote:

> Hi,
>
> An example log when this happened. In this case ofono thought context 4
> was still activated
> even though it was deactivated
>

Yes, I've seen this, too, and have a similar patch that I never got around
to sending. Please apply.

/Jonas


> 12:47:52 info: Aux: < \r\n+CIEV: 9,2\r\n
> 12:50:37 info: Aux: < \r\n+CIEV: 2,2\r\n
> 12:50:42 info: Aux: < \r\n+CIEV: 2,1\r\n
> 12:51:06 info: Aux: < \r\n+CIEV: 2,0\r\n
> 12:51:08 info: Aux: < \r\n+CGREG: 5,"004B","E404",6,"01"\r\n
> 12:51:08 debug: ../git/src/gprs.c:ofono_gprs_status_notify() /ublox_0
> status roaming (5)
> 12:51:08 info: Aux: < \r\n+UREG: 6\r\n
> 12:51:08 info: Aux: < \r\n+CIEV: 9,2\r\n
> 12:51:08 info: Aux: < \r\n+CIEV: 9,1\r\n
> 12:51:09 info: Aux: < \r\n+CGEV: NW MODIFY 4,0,0\r\n
> 12:51:16 info: Aux: < \r\n+CREG: 0\r\n
> 12:51:16 debug: ../git/src/network.c:ofono_netreg_status_notify() /ublox_0
> status 0 tech -1 lac -1 ci -1
> 12:51:16 debug: ../git/src/network.c:current_operator_callback() 0x6f2440,
> 0x6f2fe8
> 12:51:16 debug: ../git/src/gprs.c:netreg_status_changed() 0 (unregistered)
> 12:51:16 debug: ../git/src/gprs.c:gprs_netreg_update() attach: 0,
> driver_attached: 1
> 12:51:16 debug: ../git/src/gprs.c:netreg_status_changed() 0 (unregistered)
> 12:51:16 debug: ../git/src/gprs.c:gprs_netreg_update() attach: 0,
> driver_attached: 0
> 12:51:16 info: Aux: > AT\r
> 12:51:16 info: Aux: < \r\n+CIEV: 7,0\r\n
> 12:51:16 info: Aux: < \r\nOK\r\n
> 12:51:16 info: Aux: Finally woke up the modem
> 12:51:16 info: Aux: > AT+CGATT=0\r
> 12:51:16 info: Aux: < \r\n+CGREG: 4\r\n
> 12:51:16 debug: ../git/src/gprs.c:ofono_gprs_status_notify() /ublox_0
> status unknown (4)
> 12:51:16 info: Aux: < \r\n+UREG: 0\r\n
> 12:51:16 info: Aux: < \r\n+CIEV: 9,1\r\n
> 12:51:16 info: Aux: < \r\nOK\r\n
> 12:51:16 debug: ../git/src/gprs.c:gprs_attach_callback() /ublox_0 error = 0
> 12:51:16 info: Aux: > AT+CGREG?\r
> 12:51:16 info: Aux: < \r\n+CGREG: 2,4\r\n
> 12:51:16 info: Aux: < \r\nOK\r\n
> 12:51:16 debug: ../git/src/gprs.c:registration_status_cb() /ublox_0 error
> 0 status 4
> 12:51:16 debug: ../git/src/gprs.c:ofono_gprs_status_notify() /ublox_0
> status unknown (4)
> 12:51:27 info: Aux: < \r\n+CREG: 0\r\n
> 12:51:27 debug: ../git/src/network.c:ofono_netreg_status_notify() /ublox_0
> status 0 tech -1 lac -1 ci -1
> 12:51:27 debug: ../git/src/network.c:current_operator_callback() 0x6f2440,
> (nil)
> 12:51:27 debug: ../git/src/gprs.c:netreg_status_changed() 0 (unregistered)
> 12:51:27 debug: ../git/src/gprs.c:gprs_netreg_update() attach: 0,
> driver_attached: 0
> 12:51:27 info: Aux: < \r\n+CIEV: 2,2\r\n
> 12:51:30 info: Aux: < \r\n+CTZE: +08,1,"19/09/03,14:51:29"\r\n
> 12:51:30 debug:
> ../git/drivers/ubloxmodem/network-registration.c:ctze_notify() tz +08 dst 1
> time 19/09/03,14:51:29
> 12:51:30 debug: ../git/src/network.c:ofono_netreg_time_notify() net time
> 2019-09-03 14:51:29 utcoff 7200 dst 1
> 12:51:30 info: Aux: < \r\n+CREG: 5,"0080","0006",2\r\n
> 12:51:30 debug: ../git/src/network.c:ofono_netreg_status_notify() /ublox_0
> status 5 tech 2 lac 128 ci 6
> 12:51:30 debug: ../git/src/gprs.c:netreg_status_changed() 5 (roaming)
> 12:51:30 debug: ../git/src/gprs.c:gprs_netreg_update() attach: 1,
> driver_attached: 0
> 12:51:30 info: Aux: > AT\r
> 12:51:30 info: Aux: < \r\n+CIEV: 7,1\r\n
> 12:51:30 info: Aux: < \r\nOK\r\n
> 12:51:30 info: Aux: Finally woke up the modem
> 12:51:30 info: Aux: > AT+COPS=3,2\r
> 12:51:30 info: Aux: < \r\nOK\r\n
> 12:51:30 info: Aux: > AT+COPS?\r
> 12:51:30 info: Aux: < \r\n+COPS: 0,2,"24002",2\r\n
> 12:51:30 info: Aux: < \r\nOK\r\n
> 12:51:30 debug:
> ../git/drivers/atmodem/network-registration.c:cops_numeric_cb() Cops
> numeric got mcc: 240, mnc: 02
> 12:51:30 info: Aux: > AT+CSQ\r
> 12:51:30 info: Aux: < \r\n+CSQ: 11,1\r\n
> 12:51:30 info: Aux: < \r\nOK\r\n
> 12:51:30 debug: ../git/drivers/atmodem/network-registration.c:csq_cb()
> csq_cb: 11
> 12:51:30 debug: ../git/src/network.c:ofono_netreg_strength_notify()
> strength 35
> 12:51:30 info: Aux: > AT+CGATT=1\r
> 12:51:37 info: Aux: < \r\n+CME ERROR: 148\r\n
> 12:51:37 debug: ../git/src/gprs.c:gprs_attach_callback() /ublox_0 error = 1
> 12:51:37 info: Aux: > AT+COPS=3,0\r
> 12:51:37 info: Aux: < \r\n+CIEV: 2,3\r\n
> 12:51:37 info: Aux: < \r\n+CREG: 0\r\n
> 12:51:37 debug: ../git/src/network.c:ofono_netreg_status_notify() /ublox_0
> status 0 tech -1 lac -1 ci -1
> 12:51:37 debug: ../git/src/network.c:current_operator_callback() 0x6f2440,
> (nil)
> 12:51:37 debug: ../git/src/gprs.c:netreg_status_changed() 0 (unregistered)
> 12:51:37 debug: ../git/src/gprs.c:gprs_netreg_update() attach: 0,
> driver_attached: 0
> 12:51:37 info: Aux: < \r\n+CIEV: 7,0\r\n\r\n+CREG: 3\r\n
> 12:51:37 debug: ../git/src/network.c:ofono_netreg_status_notify() /ublox_0
> status 3 tech -1 lac -1 ci -1
> 12:51:37 debug: ../git/src/network.c:current_operator_callback() 0x6f2440,
> (nil)
> 12:51:37 debug: ../git/src/gprs.c:netreg_status_changed() 3 (de

Re: [PATCH v2 3/3] Revert "gprs: _cid_activated is an 'attaching' state"

[Jonas Bonn]

Hi Richard,

On 20/08/2019 17:56, richard.rojf...@gmail.com wrote:

From: Richard Röjfors 

This reverts commit 1fd419e5b4b3a87673f8e0219edb0f3ed9fca774.


This patch is fine and certainly necessary in the context of this 
series.  Posting it as a 'revert', however, is a bit unsavoury.


A reverted patch implies that it was somehow wrong or inappropriate. 
That's not the case here.  This code has become superfluous in the face 
of other changes that have been made in the tree.


Just squash these two revert patches into one "forward looking" patch. 
The fact that the change effectively constitutes a 'revert' is moot.


/Jonas



Since gprs_attached_update now guarantees that we
will not get attached without having a context activated
in LTE, this is not needed anymore. It also potentially
interferes in case the driver was actually attaching.
---
  src/gprs.c | 18 +-
  1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/src/gprs.c b/src/gprs.c
index bd9b3680..de172979 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -913,7 +913,6 @@ static void pri_read_settings_callback(const struct 
ofono_error *error,
  {
struct pri_context *pri_ctx = data;
struct ofono_gprs_context *gc = pri_ctx->context_driver;
-   struct ofono_gprs *gprs = pri_ctx->gprs;
DBusConnection *conn = ofono_dbus_get_connection();
dbus_bool_t value;
  
@@ -938,18 +937,11 @@ static void pri_read_settings_callback(const struct ofono_error *error,
  
  	value = pri_ctx->active;
  
-	gprs->flags &= ~GPRS_FLAG_ATTACHING;

-
-   gprs_set_attached_property(gprs, TRUE);
+   gprs_set_attached_property(pri_ctx->gprs, TRUE);
  
  	ofono_dbus_signal_property_changed(conn, pri_ctx->path,

OFONO_CONNECTION_CONTEXT_INTERFACE,
"Active", DBUS_TYPE_BOOLEAN, &value);
-
-   if (gprs->flags & GPRS_FLAG_RECHECK) {
-   gprs->flags &= ~GPRS_FLAG_RECHECK;
-   gprs_netreg_update(gprs);
-   }
  }
  
  static DBusMessage *pri_set_apn(struct pri_context *ctx, DBusConnection *conn,

@@ -2038,14 +2030,6 @@ void ofono_gprs_cid_activated(struct ofono_gprs  *gprs, 
unsigned int cid,
DBUS_TYPE_STRING, &apn);
}
  
-	/* Prevent ofono_gprs_status_notify from changing the 'attached'

-* state until after the context has been set to 'active' in
-* the pri_read_settings_callback; this prevents a race where
-* the connection manager sees the modem as attached before there
-* is an active context.
-*/
-   gprs->flags |= GPRS_FLAG_ATTACHING;
-
gc->driver->read_settings(gc, cid, pri_read_settings_callback, pri_ctx);
  }
  


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Unsalble cellular connection

[Jonas Bonn]

Hi Michael,

Re-adding JH and mailing lists to conversation...

On 19/08/2019 10:00, Michael Nazzareno Trimarchi wrote:

Hi

On Mon, Aug 19, 2019 at 9:51 AM Jonas Bonn  wrote:




On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:

Can be chattering and rush current? Even are you sure that you don't have
some reset our of the ofono service that send an at command that
restart the modem?


Just to try to prevent us from going down the wrong rabbit hole here:
i)  The modem is a QMI device so there are no AT commands being sent


Ok, so the uart used as ttyUSB0 and ttyUSB1 they don't support any AT command?
Is qmi part only the network interface?


ttyUSB0 and ttyUSB1 _do_ support AT commands, but are complementary to 
the QMI interface which is a complete communication channel to the modem 
in itself.  The network interface is _only_ for the QMI channel:  the 
network packets are carried on a dedicated endpoint of the USB interface 
supporting QMI.


I think the question of QMI vs AT is moot here.  Internally the modem 
does pretty much the same thing; it's just the interface that looks a 
bit different.


In JH's case, only the 'qmimisc' device and the 'network' interface are 
in play via ofono.  These are separate endpoints on a single USB 
interface, all managed by the qmi-wwan driver in the kernel.


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Unsalble cellular connection

[Jonas Bonn]

On 19/08/2019 09:50, Jonas Bonn wrote:



On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:

Hi

On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn  wrote:

The kernel log has this:

Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
converter now disconnected from ttyUSB0
Aug 17 08:51:46 solar kernel: option 1-1:1.0: device disconnected
Aug 17 08:51:46 solar kernel: option1 ttyUSB1: GSM modem (1-port)
converter now disconnected from ttyUSB1
Aug 17 08:51:46 solar kernel: option 1-1:1.2: device disconnected
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status
received: -71

That's a USB communication failure!

Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 
bytes

Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback -
usb_submit_urb failed with result -19
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device

Below, the device (modem) is reenumerated, which would indicate to me
that it has restarted.  I don't think the kernel automatically sends a
reset to a device on comm failures...???  This explains the
communication failure, at least.


Can be chattering and rush current? Even are you sure that you don't have
some reset our of the ofono service that send an at command that
restart the modem?


Just to try to prevent us from going down the wrong rabbit hole here:
i)  The modem is a QMI device so there are no AT commands being sent
ii)  The ofono log should show any such command if it were being 
transmitted (unfortunately, JH hasn't been able to produce a proper log 
around this event, yet)
iii)  I'm pretty certain that the QMI (gobi) driver in ofono doesn't 
support any 'reset' command


My inclination would be to look elsewhere.

i)  figure out what reset signalling the modem does and put a scope on it.
ii)  try to eliminate ofono and connman from the picture entirely by 
running the modem manually... what's the utility called, qmictl?  comes 
with libqmi, in any case.  Presumably, if it's a hardware issue, the 
problem will show itself under these circumstances, as well.




Is the problem reproducible with the EVK?  If not, you've pretty much 
eliminated software as the cause of the issue... it's the same device, 
but with an independent power supply.


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Unsalble cellular connection

[Jonas Bonn]

On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:

Hi

On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn  wrote:

The kernel log has this:

Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
converter now disconnected from ttyUSB0
Aug 17 08:51:46 solar kernel: option 1-1:1.0: device disconnected
Aug 17 08:51:46 solar kernel: option1 ttyUSB1: GSM modem (1-port)
converter now disconnected from ttyUSB1
Aug 17 08:51:46 solar kernel: option 1-1:1.2: device disconnected
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status
received: -71

That's a USB communication failure!

Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback -
usb_submit_urb failed with result -19
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device

Below, the device (modem) is reenumerated, which would indicate to me
that it has restarted.  I don't think the kernel automatically sends a
reset to a device on comm failures...???  This explains the
communication failure, at least.


Can be chattering and rush current? Even are you sure that you don't have
some reset our of the ofono service that send an at command that
restart the modem?


Just to try to prevent us from going down the wrong rabbit hole here:
i)  The modem is a QMI device so there are no AT commands being sent
ii)  The ofono log should show any such command if it were being 
transmitted (unfortunately, JH hasn't been able to produce a proper log 
around this event, yet)
iii)  I'm pretty certain that the QMI (gobi) driver in ofono doesn't 
support any 'reset' command


My inclination would be to look elsewhere.

i)  figure out what reset signalling the modem does and put a scope on it.
ii)  try to eliminate ofono and connman from the picture entirely by 
running the modem manually... what's the utility called, qmictl?  comes 
with libqmi, in any case.  Presumably, if it's a hardware issue, the 
problem will show itself under these circumstances, as well.


/Jonas




Michael



Aug 17 08:51:49 solar kernel: usb 1-1: new high-speed USB device number
4 using ci_hdrc
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device found,
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device strings: Mfr=3,
Product=2, SerialNumber=4
Aug 17 08:51:50 solar kernel: usb 1-1: Product: Qualcomm CDMA
Technologies MSM
Aug 17 08:51:50 solar kernel: usb 1-1: Manufacturer: Qualcomm, Incorporated
Aug 17 08:51:50 solar kernel: usb 1-1: SerialNumber: 5ff10299
Aug 17 08:51:50 solar kernel: option 1-1:1.0: GSM modem (1-port)
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now
attached to ttyUSB0
Aug 17 08:51:50 solar kernel: option 1-1:1.2: GSM modem (1-port)
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now
attached to ttyUSB1
Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3: cdc-wdm0: USB WDM device
Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3 wwan0: register
'qmi_wwan' at usb-ci_hdrc.1-1, WWAN/QMI device, f6:0d:90:fa:af:24

ofono should _definitely_ show this device reenumeration in its logs.
Why is that not there???

---

Subsequently, the kernel log shows:

Aug 17 11:32:43 solar kernel: usb 1-1: USB disconnect, device number 4
Aug 17 11:32:43 solar kernel: option1 ttyUSB0: GSM modem (1-port)
converter now disconnected from ttyUSB0
Aug 17 11:32:43 solar kernel: option 1-1:1.0: device disconnected
Aug 17 11:32:43 solar kernel: option1 ttyUSB1: GSM modem (1-port)
converter now disconnected from ttyUSB1
Aug 17 11:32:43 solar kernel: option 1-1:1.2: device disconnected
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status
received: -71

Again, comm error.

Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback -
usb_submit_urb failed with result -19
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device

Modem has rebooted and is reenumerated below.

Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device number
5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
Technologies MSM
Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
Aug 17 11:32:45 solar kernel: option 1-1:1.0: GSM modem (1-port)
converter detected
Aug 17 11:32:45 solar kernel: usb 1-1: GSM modem (1-port) converte

Re: Unsalble cellular connection

[Jonas Bonn]

Hi JH,

On 19/08/2019 03:51, JH wrote:

Hi  Michael,

On 8/18/19, Michael Nazzareno Trimarchi  wrote:

Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
number 5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
Technologies MSM
Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299

Here seems that reboot in bootloader mode. I have couple of disconnect
and reconnect and I don't know if connman
send some power on/off at command and make this strange behavior. The
fact that start in bootloader mode can be a power
issue? can you try to connect using a powered HUB?


I did a couple of restarting ofonod and connmand during the debug, one
or two times power recycling manually, not clear if it was me to cause
those reboot or not.

Like Daniel said, it was unlikely that connman would run reboot, it
might just record some messages from kernel.


Neither connman nor ofono are currently capable of rebooting the modem.



Just talked to the hardware engineer, he said who is very concerning
we are using kernel 5.1.0, he said we should use kernel 4.9.123, could
the kernel 5.1.0 cause that issue? Jonas what is your comments?


I find the advice rather concerning!  Hope you're not getting investment 
advice from this guy, too...


The kernel log has this:

Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port) 
converter now disconnected from ttyUSB0

Aug 17 08:51:46 solar kernel: option 1-1:1.0: device disconnected
Aug 17 08:51:46 solar kernel: option1 ttyUSB1: GSM modem (1-port) 
converter now disconnected from ttyUSB1

Aug 17 08:51:46 solar kernel: option 1-1:1.2: device disconnected
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status 
received: -71


That's a USB communication failure!

Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 
usb_submit_urb failed with result -19
Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister 
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device


Below, the device (modem) is reenumerated, which would indicate to me 
that it has restarted.  I don't think the kernel automatically sends a 
reset to a device on comm failures...???  This explains the 
communication failure, at least.


Aug 17 08:51:49 solar kernel: usb 1-1: new high-speed USB device number 
4 using ci_hdrc
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device found, 
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 08:51:50 solar kernel: usb 1-1: New USB device strings: Mfr=3, 
Product=2, SerialNumber=4
Aug 17 08:51:50 solar kernel: usb 1-1: Product: Qualcomm CDMA 
Technologies MSM

Aug 17 08:51:50 solar kernel: usb 1-1: Manufacturer: Qualcomm, Incorporated
Aug 17 08:51:50 solar kernel: usb 1-1: SerialNumber: 5ff10299
Aug 17 08:51:50 solar kernel: option 1-1:1.0: GSM modem (1-port) 
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now 
attached to ttyUSB0
Aug 17 08:51:50 solar kernel: option 1-1:1.2: GSM modem (1-port) 
converter detected
Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now 
attached to ttyUSB1

Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3: cdc-wdm0: USB WDM device
Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3 wwan0: register 
'qmi_wwan' at usb-ci_hdrc.1-1, WWAN/QMI device, f6:0d:90:fa:af:24


ofono should _definitely_ show this device reenumeration in its logs. 
Why is that not there???


---

Subsequently, the kernel log shows:

Aug 17 11:32:43 solar kernel: usb 1-1: USB disconnect, device number 4
Aug 17 11:32:43 solar kernel: option1 ttyUSB0: GSM modem (1-port) 
converter now disconnected from ttyUSB0

Aug 17 11:32:43 solar kernel: option 1-1:1.0: device disconnected
Aug 17 11:32:43 solar kernel: option1 ttyUSB1: GSM modem (1-port) 
converter now disconnected from ttyUSB1

Aug 17 11:32:43 solar kernel: option 1-1:1.2: device disconnected
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status 
received: -71


Again, comm error.

Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 
usb_submit_urb failed with result -19
Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister 
'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device


Modem has rebooted and is reenumerated below.

Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device number 
5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found, 
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Aug 17 11:32:45 solar kernel: usb 1-1: New USB de

Re: Unsalble cellular connection

[Jonas Bonn]

Hi JH,

On 17/08/2019 13:55, JH wrote:

On 8/17/19, JH  wrote:

On 8/16/19, Daniel Wagner  wrote:

The NTP code is just telling it can't reach the server. This has no
direct connenction to the next entry.


So that from NTP, don't need to worry about it.


This message is from the kernel via RTNL interface. The kernel tells
ConnMan the interface state has changed.


OK, all from kernel, what could make the kernel to delete the link?


What does the kernel log show?





connmand[213]: Skipping disconnect of /ubloxqmi_0/context1, network is
connecting.
connmand[213]: ipconfig state 2 ipconfig method 1



Your log does not contain the debug information (connmand -d).


I attached two log files running in debug, doesn't seem

$ OFONO_QMI_DEBUG=1 ofonod -d

$ connmand -d


Oops, pressed wrong key, both debug log files attached, looks even
less information from running ofono -n and connman -n by systemd.



It looks like you've multiple instances of connman and ofono running 
there, that's why you've got nothing in the logs.  Give this another try.


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Unsalble cellular connection

[Jonas Bonn]

Hi JH,

On 14/08/2019 13:11, JH wrote:

Hi Jonas,

On 8/14/19, Jonas Bonn  wrote:

So you have no traffic over the LTE link?  How do you know that it goes
down after 1-2 hours... maybe it went down after 5 minutes?


I logged link status every 10 minutes.


How?  Not clear from what you posted earliest how you can tell that the 
link has gone down.  The default route is set to go over WiFi so a 
generic ping isn't sufficient.  What exactly are you monitoring?





Cloud messages are as good as a ping... a packet's a packet.
The link is configured by connman, not ofono.  ofono just publishes the
address details so that connman can set it up.


So, it is back to connman?


Well, the log _seemed_ to indicate that connman does an NTP request to a 
server that isn't available and thereby decides to take the link down... 
off the top of my head I can't say whether that's something connman 
actually does so hopefully somebody else will jump in here.  Did ofono 
indicate the context as still established after that?





No Address?  No Interface?  Running ofono with debug output will
probably shed some light on what's going on here.


I think that could be because I only ran it once, if I ran
list-contexts 4 times consecutively, every time it displayed different
results included address and interface, is it the normal behaviour of
list-contexts?


Sounds broken...???


Which one is broken, ofono or connman or something else? There is not
much configurations for both ofono and connman,


I was referring to the DBus response containing incomplete Settings 
objects.  A random set of properties at each request is not the 
documented behaviour.




Can the defect hardware particularly the system power supply caused
the link down? I have only one test device, I cannot prove it. The
SATA chip has a pin for power up, During the boot, a command to set
the power up before ofono is running. When the link is down, either I
restart the ofonod or I called the command to turn the power up again,
both can bring the link back. I cannot image the chip could lose
power, but if the system power supply is not stable in some stage too
low to support the SARA chip, will it trig the power down? I talked to
the hardware engineer who rejected that it did not make sense because
WiFi was running fine, he is pointing the figure to the modem manager
and connection manager.


Seeing the issue with complete logs would be useful.  I thought your 
previous logs indicated connman trying to deactivate the context when it 
took the link down, but the ofono logs didn't show any of that... what's 
going on there?


/Jonas



Thank you.

Kind regards,

- jh


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Unsalble cellular connection

[Jonas Bonn]

CC: ofono mailing list.

Please don't drop the mailing list from the conversation.


On 13/08/2019 13:51, JH wrote:

Hi Jonas,

On 8/13/19, Jonas Bonn  wrote:

Hi JH,

Aug 01 08:09:39 connmand[181]: wwan0 {add} route 0.0.0.0 gw
10.114.23.146 scope 0 
Aug 01 08:09:45 connmand[181]: Online check failed for 0xa71cf8 Telstra



Online check failed... was the network connection ever working?


Yes, it usually in good LTE connection when power up, then it dropped
connection in about 1 - 2 hours.


Aug 01 09:34:11 connmand[181]: Time request for server 10.114.23.146
failed (101/Network is unreachable)



Is this attempt to check the time server causing the modem to discover that the 
connection
isn't working?  Who sets the network interface DOWN here... the QMI Linux 
driver?  Why
  doesn't the modem signal something on the QMI communication channel when this
happens... maybe it does but the message is just being silently ignored?


$ ping 10.114.23.146
--- 10.114.23.146 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Cannot reache that IP address??


That address is the gateway address for that link... there's unlikely a 
timeserver running there.  Why does connman think there's a timeserver 
there?





There's very little traffic on the link... is the PDP context silently expiring 
due to inactivity?

  > What happens if you ping something every minute or so when the link
is active?

That because all traffic went to WiFi, the application is sending a
message to Cloud every minitue, should that be better than to ping?


So you have no traffic over the LTE link?  How do you know that it goes 
down after 1-2 hours... maybe it went down after 5 minutes?


Cloud messages are as good as a ping... a packet's a packet.





Aug 01 09:34:11 connmand[181]: wwan0 {del} address 10.114.23.145/30 label wwan0
Aug 01 09:34:11 connmand[181]: Skipping disconnect of
/ubloxqmi_0/context1, network is connecting.



Here I think ofono and connman just get out of sync because connman seems to 
know that
the network is down while ofono doesn't...


Does that alude it is not the ofono caused link down?


The link is configured by connman, not ofono.  ofono just publishes the 
address details so that connman can set it up.





Sure... there's not much to go on in the logs you've posted, just an
assertion that the LTE connection was silently dropped.  It would be
better if you could show the behaviour with more complete debug output:

ofonod -d

The issue could be (perhaps) that there's a QMI message that ofono
doesn't handle and is silently ignoring... dumping the QMI communication
might useful:

OFONO_QMI_DEBUG=1 ofonod -d


Before running following commands, the LTE connection dropped, after
running following commands, LTE connection came back, it is wired that
the LTE is more stable than running by system service where
ExecStart=/usr/sbin/ofonod -u", LTE connection has not been dropped
for more than 6 hours, I'll run it over night and let you know if the
connection will be dropped or not. Why running OFONO_QMI_DEBUG=1
ofonod -d makes it more stable? Can I say that LTE drop off is caused
by the ofono?






# systemctl stop ofono
# OFONO_QMI_DEBUG=1 ofonod -d
# ip addr
1: lo:  mtu 65536 qdisc noqueue qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE:  mtu 1480 qdisc noop qlen 1000
 link/sit 0.0.0.0 brd 0.0.0.0
3: mlan0:  mtu 1500 qdisc mq qlen 1000
 link/ether d4:ca:6e:64:e3:61 brd ff:ff:ff:ff:ff:ff
 inet 192.168.0.101/24 brd 192.168.0.255 scope global mlan0
valid_lft forever preferred_lft forever
 inet6 fe80::d6ca:6eff:fe64:e361/64 scope link
valid_lft forever preferred_lft forever
4: wwan0:  mtu 1500 qdisc pfifo_fast q0
 link/[65534]
 inet 10.114.34.107/29 brd 10.114.34.111 scope global wwan0
valid_lft forever preferred_lft forever

The LTE connection came up with IP address:

wwan0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0
   inet addr:10.114.34.107  P-t-P:10.114.34.107  Mask:255.255.255.248
   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
   RX packets:253 errors:0 dropped:0 overruns:0 frame:0
   TX packets:348 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:28788 (28.1 KiB)  TX bytes:3 (36.8 KiB)


There is not much about the dump message:

# journalctl -u ofono
-- Logs begin at Fri 2019-07-05 05:07:43 UTC, end at Tue 2019-08-13 09:15:10 UT-
Aug 11 12:07:12 systemd[1]: Starting Telephony service...
Aug 11 12:07:13 ofonod[189]: oFono version 1.24
Aug 11 12:07:14 systemd[1]: Started Telephony service.
Aug 11 12:07:19 ofonod[189]: Interface org.ofono.All

Re: Unsalble cellular connection

[Jonas Bonn]

Hi JH,

On 13/08/2019 00:09, JH wrote:

Hi Jonas,

Do you have any comments about it?


Sure... there's not much to go on in the logs you've posted, just an 
assertion that the LTE connection was silently dropped.  It would be 
better if you could show the behaviour with more complete debug output:


ofonod -d

The issue could be (perhaps) that there's a QMI message that ofono 
doesn't handle and is silently ignoring... dumping the QMI communication 
might useful:


OFONO_QMI_DEBUG=1 ofonod -d




Thank you.

Kind regards,

- jupiter

On 8/12/19, JH  wrote:

Hi Giacinto,

On 8/11/19, Giacinto Cifelli  wrote:


can you check with the ofono script test/list-contexts if the method
is static or dhcp?


# ofono/test/list-contexts
[ /ubloxqmi_0 ]
 [ /ubloxqmi_0/context1 ]
 Name = Internet
 Type = internet
 AuthenticationMethod = chap
 Settings = { Method=static Gateway=10.116.103.22
Netmask=255.255.255.25}


No Address?  No Interface?  Running ofono with debug output will 
probably shed some light on what's going on here.



 Username =
 AccessPointName = telstra.m2m
 Password =
 Protocol = ip
 IPv6.Settings = { }
 Active = 1

Looks like it is static, how can change it to a correct one (dynamic

)? Or any workarounds?


static is correct.  ofono configures the local network interface 
appropriately for the established context.


Given that ofono isn't reporting either an address nor interface above, 
I wonder what the network interface has been configured to.  What do 'ip 
link' and 'ip addr' show?






I believe this can be the problem: if ofono managed to get an IP
address, likely with at+cgpaddr and/or at+cgcontrdp,
then it passes it to connman, and then it is set on the interface...
static, with no lease expiration.


I don't think the SARA R4 support DHCP... correct me if I'm wrong.




There are two devices for the SARA-R4 modem, /dev/ttyUSB0 is used for
QMI which is currently using as default protocol. /dev/ttyUSB1 is for
AT,


No, the QMI device is another USB endpoint that presents interfaces in 
two separate Linux subsystems:  one network device and one qmimisc 
device.  The ttyUSB devices are for AT functionality which you won't be 
using if you are using the QMI channel.



 let me know if you like to check AT command, I have never tried to

write / read AT command, are the following commands correct?

echo "at+cgpaddr" > /dev/ttyUSB1
cat < /dev/ttyUSB1


Try using minicom or something similar if you want to play with AT 
commands directly.


/Jonas



Thank you very much Giacinto.

-- jupiter


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 1/1] ublox: detect and support LARA R2 series

[Jonas Bonn]

---
 drivers/ubloxmodem/ubloxmodem.c | 9 +
 drivers/ubloxmodem/ubloxmodem.h | 3 ++-
 plugins/udevng.c| 2 ++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 719c77a0..034f7db1 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -77,6 +77,15 @@ const struct ublox_model ublox_models[] = {
.name = "TOBY-L4906",
.flags = UBLOX_F_TOBY_L4,
},
+   /* LARA L2 series */
+   {
+   .name = "LARA-R202",
+   .flags = UBLOX_F_LARA_R2,
+   },
+   {
+   .name = "LARA-R211",
+   .flags = UBLOX_F_LARA_R2,
+   },
{ /* sentinel */ },
 };
 
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 81fe9481..0bd7ef23 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -26,7 +26,8 @@
 enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
UBLOX_F_TOBY_L4 = (1 << 1),
-   UBLOX_F_HAVE_USBCONF= (1 << 2),
+   UBLOX_F_LARA_R2 = (1 << 2),
+   UBLOX_F_HAVE_USBCONF= (1 << 3),
 };
 
 struct ublox_model {
diff --git a/plugins/udevng.c b/plugins/udevng.c
index 35354a16..1b54b4a2 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1759,6 +1759,8 @@ static struct {
{ "ublox",  "cdc_acm",  "1546", "1010"  },
{ "ublox",  "cdc_ncm",  "1546", "1010"  },
{ "ublox",  "cdc_acm",  "1546", "1102"  },
+   { "ublox",  "cdc_acm",  "1546", "110a"  },
+   { "ublox",  "cdc_ncm",  "1546", "110a"  },
{ "ublox",  "rndis_host",   "1546", "1146"  },
{ "ublox",  "cdc_acm",  "1546", "1146"  },
{ "gemalto","option",   "1e2d", "0053"  },
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 1/2] ublox: network-registration atom

[Jonas Bonn]

For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient.  This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementations.
---
 Makefile.am   |   1 +
 drivers/ubloxmodem/network-registration.c | 426 ++
 drivers/ubloxmodem/ubloxmodem.c   |   2 +
 drivers/ubloxmodem/ubloxmodem.h   |   3 +
 4 files changed, 432 insertions(+)
 create mode 100644 drivers/ubloxmodem/network-registration.c

diff --git a/Makefile.am b/Makefile.am
index 39777abc..7fb45d35 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -471,6 +471,7 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/ubloxmodem/ubloxmodem.h \
drivers/ubloxmodem/ubloxmodem.c \
drivers/ubloxmodem/gprs-context.c \
+   drivers/ubloxmodem/network-registration.c \
drivers/ubloxmodem/netmon.c \
drivers/ubloxmodem/lte.c
 
diff --git a/drivers/ubloxmodem/network-registration.c 
b/drivers/ubloxmodem/network-registration.c
new file mode 100644
index ..968f83d4
--- /dev/null
+++ b/drivers/ubloxmodem/network-registration.c
@@ -0,0 +1,426 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
+ *  Copyright (C) 2010  ST-Ericsson AB.
+ *  Copyright (C) 2019  Norrbonn AB
+ *
+ *  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 
+#include 
+
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include "common.h"
+#include "ubloxmodem.h"
+#include "drivers/atmodem/vendor.h"
+
+#include "drivers/atmodem/network-registration.h"
+
+static const char *none_prefix[] = { NULL };
+static const char *cmer_prefix[] = { "+CMER:", NULL };
+static const char *ureg_prefix[] = { "+UREG:", NULL };
+
+struct netreg_data {
+   struct at_netreg_data at_data;
+
+   const struct ublox_model *model;
+};
+
+struct tech_query {
+   int status;
+   int lac;
+   int ci;
+   struct ofono_netreg *netreg;
+};
+
+static void ciev_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int strength, ind;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CIEV:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &ind))
+   return;
+
+   if (ind != nd->signal_index)
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &strength))
+   return;
+
+   if (strength == nd->signal_invalid)
+   strength = -1;
+   else
+   strength = (strength * 100) / (nd->signal_max - nd->signal_min);
+
+   ofono_netreg_strength_notify(netreg, strength);
+}
+
+static gboolean notify_time(gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+
+   nd->nitz_timeout = 0;
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+
+   return FALSE;
+}
+
+static void ctzdst_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int dst;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CTZDST:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &dst))
+   return;
+
+   DBG("dst %d", dst);
+
+   nd->time.dst = dst;
+
+   if (nd->nitz_timeout > 0) {
+   g_source_remove(nd->nitz_timeout);
+   nd->nitz_timeout = 0;
+   }
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+}
+
+static void ctzv_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int year, mon, mday, hour, min, sec

[PATCH 2/2] ublox: use custom netreg atom

[Jonas Bonn]

---
 plugins/ublox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 231578fb..b65bc52a 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -406,7 +406,8 @@ static void ublox_post_online(struct ofono_modem *modem)
 {
struct ublox_data *data = ofono_modem_get_data(modem);
 
-   ofono_netreg_create(modem, data->vendor_family, "atmodem", data->aux);
+   ofono_netreg_create(modem,
+   ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 
ofono_netmon_create(modem, data->vendor_family, "ubloxmodem", 
data->aux);
 }
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 07/10] ublox: create only 1 gprs context

[Jonas Bonn]

Some uBlox modems support multiple, simultaneously active contexts.  These
contexts are either bridged to the network interface or handled
transparently by the modem acting like a router.

The problem with this approach is that ofono and ofono clients (e.g.
mmsd) expect a dedicated _local_ network interface for each context.

As such, it doesn't make sense for ofono to set up the multiple gprs
contexts.
---
 plugins/ublox.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index c6ff7eaa..1da7101e 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -357,8 +357,6 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
const char *driver;
-   /* Toby L2: Create same number of contexts as supported PDP contexts. */
-   int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
const char *iface;
int variant;
 
@@ -376,14 +374,9 @@ static void ublox_post_sim(struct ofono_modem *modem)
variant = OFONO_VENDOR_UBLOX;
}
 
-   while (ncontexts) {
-   gc = ofono_gprs_context_create(modem, variant, driver, chat);
-
-   if (gprs && gc)
-   ofono_gprs_add_context(gprs, gc);
-
-   --ncontexts;
-   }
+   gc = ofono_gprs_context_create(modem, variant, driver, chat);
+   if (gprs && gc)
+   ofono_gprs_add_context(gprs, gc);
 
ofono_lte_create(modem,
ublox_model_to_id(data->model), "ubloxmodem", data->aux);
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 03/10] ublox: network-registration atom

[Jonas Bonn]

For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient.  This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementations.
---
 drivers/ubloxmodem/network-registration.c | 425 ++
 drivers/ubloxmodem/ubloxmodem.c   |   2 +
 drivers/ubloxmodem/ubloxmodem.h   |   3 +
 3 files changed, 430 insertions(+)
 create mode 100644 drivers/ubloxmodem/network-registration.c

diff --git a/drivers/ubloxmodem/network-registration.c 
b/drivers/ubloxmodem/network-registration.c
new file mode 100644
index ..cfd194a9
--- /dev/null
+++ b/drivers/ubloxmodem/network-registration.c
@@ -0,0 +1,425 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
+ *  Copyright (C) 2010  ST-Ericsson AB.
+ *
+ *  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 
+#include 
+
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include "common.h"
+#include "ubloxmodem.h"
+#include "drivers/atmodem/vendor.h"
+
+#include "drivers/atmodem/network-registration.h"
+
+static const char *none_prefix[] = { NULL };
+static const char *cmer_prefix[] = { "+CMER:", NULL };
+static const char *ureg_prefix[] = { "+UREG:", NULL };
+
+struct netreg_data {
+   struct at_netreg_data at_data;
+
+   const struct ublox_model *model;
+};
+
+struct tech_query {
+   int status;
+   int lac;
+   int ci;
+   struct ofono_netreg *netreg;
+};
+
+static void ciev_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int strength, ind;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CIEV:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &ind))
+   return;
+
+   if (ind != nd->signal_index)
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &strength))
+   return;
+
+   if (strength == nd->signal_invalid)
+   strength = -1;
+   else
+   strength = (strength * 100) / (nd->signal_max - nd->signal_min);
+
+   ofono_netreg_strength_notify(netreg, strength);
+}
+
+static gboolean notify_time(gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+
+   nd->nitz_timeout = 0;
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+
+   return FALSE;
+}
+
+static void ctzdst_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int dst;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CTZDST:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &dst))
+   return;
+
+   DBG("dst %d", dst);
+
+   nd->time.dst = dst;
+
+   if (nd->nitz_timeout > 0) {
+   g_source_remove(nd->nitz_timeout);
+   nd->nitz_timeout = 0;
+   }
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+}
+
+static void ctzv_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
+   int year, mon, mday, hour, min, sec;
+   const char *tz, *time;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CTZV:"))
+   return;
+
+   if (!g_at_result_iter_next_unquoted_string(&iter, &tz))
+   return;
+
+   if (!g_at_result_iter_next_string(&iter, &time))
+   return;
+
+   DBG("tz %s time %s", tz, time);
+
+   if (sscanf(time, "%u/%u/%u,%u:%u:%u", &year, &mon, &mday,
+   &hour, &min, &sec) != 6)
+   return;
+
+   nd->time.sec = sec;
+   nd->

[PATCH 05/10] ublox: use custom netreg atom

[Jonas Bonn]

---
 plugins/ublox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index ff08a6a1..918bd3ec 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -399,7 +399,8 @@ static void ublox_post_online(struct ofono_modem *modem)
 {
struct ublox_data *data = ofono_modem_get_data(modem);
 
-   ofono_netreg_create(modem, data->vendor_family, "atmodem", data->aux);
+   ofono_netreg_create(modem,
+   ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 
ofono_netmon_create(modem, data->vendor_family, "ubloxmodem", 
data->aux);
 }
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 10/10] ublox: be explicit about lack of IPv6

[Jonas Bonn]

The TOBY L4 has no IPv6 support whatsoever.
---
 drivers/ubloxmodem/gprs-context.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ubloxmodem/gprs-context.c 
b/drivers/ubloxmodem/gprs-context.c
index c5b789b6..ff78a42a 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@ -388,6 +388,14 @@ static void ublox_gprs_activate_primary(struct 
ofono_gprs_context *gc,
 {
struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
 
+   if (ublox_is_toby_l4(gcd->model)) {
+   /* TOBY L4 does not support IPv6 */
+   if (ctx->proto != OFONO_GPRS_PROTO_IP) {
+   CALLBACK_WITH_FAILURE(cb, data);
+   return;
+   }
+   }
+
/* IPv6 support not implemented */
if (ctx->proto != OFONO_GPRS_PROTO_IP) {
CALLBACK_WITH_FAILURE(cb, data);
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 04/10] Makefile

[Jonas Bonn]

---
 Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.am b/Makefile.am
index 39777abc..7fb45d35 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -471,6 +471,7 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/ubloxmodem/ubloxmodem.h \
drivers/ubloxmodem/ubloxmodem.c \
drivers/ubloxmodem/gprs-context.c \
+   drivers/ubloxmodem/network-registration.c \
drivers/ubloxmodem/netmon.c \
drivers/ubloxmodem/lte.c
 
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 08/10] ublox: add voicecall support

[Jonas Bonn]

---
 plugins/ublox.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 1da7101e..6e867666 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -41,6 +41,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -356,6 +362,7 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
+   struct ofono_message_waiting *mw;
const char *driver;
const char *iface;
int variant;
@@ -380,6 +387,16 @@ static void ublox_post_sim(struct ofono_modem *modem)
 
ofono_lte_create(modem,
ublox_model_to_id(data->model), "ubloxmodem", data->aux);
+
+   ofono_ussd_create(modem, 0, "atmodem", data->aux);
+   ofono_call_forwarding_create(modem, 0, "atmodem", data->aux);
+   ofono_call_settings_create(modem, 0, "atmodem", data->aux);
+   ofono_call_meter_create(modem, 0, "atmodem", data->aux);
+   ofono_call_barring_create(modem, 0, "atmodem", data->aux);
+
+   mw = ofono_message_waiting_create(modem);
+   if (mw)
+   ofono_message_waiting_register(mw);
 }
 
 static void ublox_post_online(struct ofono_modem *modem)
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 06/10] ublox: determine gprs-context driver from network interface

[Jonas Bonn]

Some u-blox devices present a USB network class device for data and some
just switch to PPP on (one of) the communication channel(s).  Whether
the atmodem or ubloxmodem gprs-context driver should be used depends on
whether or not the network interface is present; check this condition
directly when deciding which driver to us.
---
 plugins/ublox.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 918bd3ec..c6ff7eaa 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -359,6 +359,7 @@ static void ublox_post_sim(struct ofono_modem *modem)
const char *driver;
/* Toby L2: Create same number of contexts as supported PDP contexts. */
int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
+   const char *iface;
int variant;
 
DBG("%p", modem);
@@ -366,17 +367,10 @@ static void ublox_post_sim(struct ofono_modem *modem)
gprs = ofono_gprs_create(modem, data->vendor_family, "atmodem",
data->aux);
 
-   if (ublox_is_toby_l4(data->model)) {
+   iface = ofono_modem_get_string(modem, "NetworkInterface");
+   if (iface) {
driver = "ubloxmodem";
variant = ublox_model_to_id(data->model);
-   } else if (ublox_is_toby_l2(data->model)) {
-   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE) {
-   driver = "ubloxmodem";
-   variant = ublox_model_to_id(data->model);
-   } else {
-   driver = "atmodem";
-   variant = OFONO_VENDOR_UBLOX;
-   }
} else {
driver = "atmodem";
variant = OFONO_VENDOR_UBLOX;
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 09/10] ublox: add SMS support

[Jonas Bonn]

---
 plugins/ublox.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 6e867666..b65bc52a 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -388,6 +389,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
ofono_lte_create(modem,
ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 
+   ofono_sms_create(modem, 0, "atmodem", data->aux);
+
ofono_ussd_create(modem, 0, "atmodem", data->aux);
ofono_call_forwarding_create(modem, 0, "atmodem", data->aux);
ofono_call_settings_create(modem, 0, "atmodem", data->aux);
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 01/10] atmodem: export generic netreg funcs

[Jonas Bonn]

An upcoming netreg driver for uBlox modems will need to override the
probe method in order to set itself up, but for further functionality
the "generic" AT implementations are sufficient.  The easiest way to do
this is to just set up a vtable with a custom probe implementation and
defer all other methods to the common/generic methods.

The problem is that the AT methods are not actually exported.  This
generic AT functionality was not intended to be hooked directly into
other drivers.

This patch exports all the methods of the atmodem network-registration
driver implementation so that they can be used as generic/common
implementations for other drivers.
---
 drivers/atmodem/network-registration.c | 16 +---
 drivers/atmodem/network-registration.h | 17 +
 2 files changed, 26 insertions(+), 7 deletions(-)
 create mode 100644 drivers/atmodem/network-registration.h

diff --git a/drivers/atmodem/network-registration.c 
b/drivers/atmodem/network-registration.c
index 67380b73..0f83977b 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -41,6 +41,8 @@
 #include "atmodem.h"
 #include "vendor.h"
 
+#include "network-registration.h"
+
 static const char *none_prefix[] = { NULL };
 static const char *creg_prefix[] = { "+CREG:", NULL };
 static const char *cops_prefix[] = { "+COPS:", NULL };
@@ -270,7 +272,7 @@ static void option_tech_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
nd->tech = -1;
 }
 
-static void at_registration_status(struct ofono_netreg *netreg,
+void at_registration_status(struct ofono_netreg *netreg,
ofono_netreg_status_cb_t cb,
void *data)
 {
@@ -450,7 +452,7 @@ error:
g_free(cbd);
 }
 
-static void at_current_operator(struct ofono_netreg *netreg,
+void at_current_operator(struct ofono_netreg *netreg,
ofono_netreg_operator_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -589,7 +591,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
g_free(list);
 }
 
-static void at_list_operators(struct ofono_netreg *netreg,
+void at_list_operators(struct ofono_netreg *netreg,
ofono_netreg_operator_list_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -615,7 +617,7 @@ static void register_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
cb(&error, cbd->data);
 }
 
-static void at_register_auto(struct ofono_netreg *netreg,
+void at_register_auto(struct ofono_netreg *netreg,
ofono_netreg_register_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -630,7 +632,7 @@ static void at_register_auto(struct ofono_netreg *netreg,
CALLBACK_WITH_FAILURE(cb, data);
 }
 
-static void at_register_manual(struct ofono_netreg *netreg,
+void at_register_manual(struct ofono_netreg *netreg,
const char *mcc, const char *mnc,
ofono_netreg_register_cb_t cb, void *data)
 {
@@ -1228,7 +1230,7 @@ static void csq_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
cb(&error, strength, cbd->data);
 }
 
-static void at_signal_strength(struct ofono_netreg *netreg,
+void at_signal_strength(struct ofono_netreg *netreg,
ofono_netreg_strength_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -2144,7 +2146,7 @@ static int at_netreg_probe(struct ofono_netreg *netreg, 
unsigned int vendor,
return 0;
 }
 
-static void at_netreg_remove(struct ofono_netreg *netreg)
+void at_netreg_remove(struct ofono_netreg *netreg)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
 
diff --git a/drivers/atmodem/network-registration.h 
b/drivers/atmodem/network-registration.h
new file mode 100644
index ..0f622411
--- /dev/null
+++ b/drivers/atmodem/network-registration.h
@@ -0,0 +1,17 @@
+#pragma once
+
+void at_registration_status(struct ofono_netreg *netreg,
+   ofono_netreg_status_cb_t cb,
+   void *data);
+void at_current_operator(struct ofono_netreg *netreg,
+   ofono_netreg_operator_cb_t cb, void *data);
+void at_list_operators(struct ofono_netreg *netreg,
+   ofono_netreg_operator_list_cb_t cb, void *data);
+void at_register_auto(struct ofono_netreg *netreg,
+   ofono_netreg_register_cb_t cb, void *data);
+void at_register_manual(struct ofono_netreg *netreg,
+   const char *mcc, const char *mnc,
+   ofono_netreg_register_cb_t cb, void *data);
+void at_signal_strength(struct ofono_netreg *netreg,
+  

[PATCH 02/10] atmodem: export struct netreg

[Jonas Bonn]

In order to do inheritance by composition.
---
 drivers/atmodem/network-registration.c | 94 +++---
 drivers/atmodem/network-registration.h | 14 
 2 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/atmodem/network-registration.c 
b/drivers/atmodem/network-registration.c
index 0f83977b..cc702c2c 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -53,20 +53,6 @@ static const char *smoni_prefix[] = { "^SMONI:", NULL };
 static const char *zpas_prefix[] = { "+ZPAS:", NULL };
 static const char *option_tech_prefix[] = { "_OCTI:", "_OUWCTI:", NULL };
 
-struct netreg_data {
-   GAtChat *chat;
-   char mcc[OFONO_MAX_MCC_LENGTH + 1];
-   char mnc[OFONO_MAX_MNC_LENGTH + 1];
-   int signal_index; /* If strength is reported via CIND */
-   int signal_min; /* min strength reported via CIND */
-   int signal_max; /* max strength reported via CIND */
-   int signal_invalid; /* invalid strength reported via CIND */
-   int tech;
-   struct ofono_network_time time;
-   guint nitz_timeout;
-   unsigned int vendor;
-};
-
 struct tech_query {
int status;
int lac;
@@ -211,7 +197,7 @@ static void at_creg_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_netreg_status_cb_t cb = cbd->cb;
int status, lac, ci, tech;
struct ofono_error error;
-   struct netreg_data *nd = cbd->user;
+   struct at_netreg_data *nd = cbd->user;
 
decode_at_error(&error, g_at_result_final_response(result));
 
@@ -252,7 +238,7 @@ static void zte_tech_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
 {
struct cb_data *cbd = user_data;
struct ofono_netreg *netreg = cbd->data;
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
 
if (ok)
nd->tech = zte_parse_tech(result);
@@ -264,7 +250,7 @@ static void option_tech_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
 {
struct cb_data *cbd = user_data;
struct ofono_netreg *netreg = cbd->data;
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
 
if (ok)
nd->tech = option_parse_tech(result);
@@ -276,7 +262,7 @@ void at_registration_status(struct ofono_netreg *netreg,
ofono_netreg_status_cb_t cb,
void *data)
 {
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
struct cb_data *cbd = cb_data_new(cb, data);
 
cbd->user = nd;
@@ -339,7 +325,7 @@ void at_registration_status(struct ofono_netreg *netreg,
 static void cops_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct cb_data *cbd = user_data;
-   struct netreg_data *nd = ofono_netreg_get_data(cbd->user);
+   struct at_netreg_data *nd = ofono_netreg_get_data(cbd->user);
ofono_netreg_operator_cb_t cb = cbd->cb;
struct ofono_network_operator op;
GAtResultIter iter;
@@ -400,7 +386,7 @@ error:
 static void cops_numeric_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct cb_data *cbd = user_data;
-   struct netreg_data *nd = ofono_netreg_get_data(cbd->user);
+   struct at_netreg_data *nd = ofono_netreg_get_data(cbd->user);
ofono_netreg_operator_cb_t cb = cbd->cb;
GAtResultIter iter;
const char *str;
@@ -455,7 +441,7 @@ error:
 void at_current_operator(struct ofono_netreg *netreg,
ofono_netreg_operator_cb_t cb, void *data)
 {
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
struct cb_data *cbd = cb_data_new(cb, data);
gboolean ok;
 
@@ -594,7 +580,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
 void at_list_operators(struct ofono_netreg *netreg,
ofono_netreg_operator_list_cb_t cb, void *data)
 {
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
struct cb_data *cbd = cb_data_new(cb, data);
 
if (g_at_chat_send(nd->chat, "AT+COPS=?", cops_prefix,
@@ -620,7 +606,7 @@ static void register_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
 void at_register_auto(struct ofono_netreg *netreg,
ofono_netreg_register_cb_t cb, void *data)
 {
-   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
struct cb_data *cbd = cb_data_new(cb, data);
 
if (g_at_chat_send(nd->chat, "AT+COPS=0", none_prefix,
@@ -636,7 +622,7 @@ void at_register_manual(

Re: [PATCH 1/1] ublox: detect and support LARA R2 series

[Jonas Bonn]

Hi Krishna,

First of all, don't top-post to this mailing list.


On 21/06/2019 11:28, Krishna wrote:

Hi Jonas,

Thanks for the patch.

Withyour patch, ofono is ableto recognize LARA modems.





Setting modem /ublox_0 online...

root@imx:/usr/lib/ofono/test# ./activate-context

*Error activating /ublox_0/context1: org.ofono.Error.NotAttached: GPRS 
is not attached***


Without ofono,I am able to activate the context and get GPRS.With ofono 
only I am getting belowerror.


If you run ofono as:

OFONO_AT_DEBUG=1 ofonod -d -n

then you'll get more info on what AT commands are being sent and which 
ones are failing.  If you could do so and post the log here then we can 
maybe see what's going on.




Let me know if I am missing any configuration.

Insourcecode(drivers/ubloxmodem/lte.c), I found AT commands specific to 
TOBY module for configuring the PDP context(Eg:*UCGDFLT*).


Whether any flowneed to be modified for LARA-R2?


Possibly... we'll need to check what the LARA R2 wants there.

/Jonas

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: ofono.service failure

[Jonas Bonn]

On 02/05/2019 17:03, JH wrote:

Hi,

The official ofono recipe ofono.inc defines SYSTEMD_SERVICE_${PN} =
"ofono.service", but the ofonod is not started by system service
automatically, I have to start the ofonod manually, what could be the
issue?


This question should be directed to the OpenEmbedded mailing list as it 
has nothing to do with ofono, per se.


That said:
i)  it works for me on all recent versions of OE
ii) including some relevant logging (journalctl, etc.) is generally 
helpful in debugging these matters; both the log of the ofono service, 
in case it fails to start due to crashes, and the log from systemd 
itself, in case systemd is deciding not to start the service for some 
reason.


/Jonas



Thank you.

Kind regards,

- jupiter
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC at-export 0/2] Export AT-modem functions to other drivers

[Jonas Bonn]

Hi Denis,

On 22/04/2019 17:52, Denis Kenzior wrote:

What is actually different for uBlox that requires such a drastic 
approach?  Right now I'm seeing a duplication of CMER/CIEV and NITZ 
logic.  Not much else.


For the TOBY L4 I hit this:
ofono_error("This driver is not setup with Signal Strength reporting"
" via CIND indications, please write proper netreg"
" handling for this device");

This device requires _polling_ ECSQ to get this info (no async signal 
strenght reporting).  Other uBlox models don't have this issue.


So we need to have UBLOX_TOBY_L4, UBLOX_TOBY_L2, etc. "vendor" types to 
differentiate not only the vendor but the model.  Is that ok?  Not 
enough to warrant a custom driver?


Is NITZ really a thing?  I interpreted it as "No immediate timezone"...

/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[RFC at-export 1/2] atmodem: export generic netreg funcs

[Jonas Bonn]

An upcoming netreg driver for uBlox modems will need to override the
probe method in order to set itself up, but for further functionality
the "generic" AT implementations are sufficient.  The easiest way to do
this is to just set up a vtable with a custom probe implementation and
defer all other methods to the common/generic methods.

The problem is that the AT methods are not actually exported.  This
generic AT functionality was not intended to be hooked directly into
other drivers.

This patch exports all the methods of the atmodem network-registration
driver implementation so that they can be used as generic/common
implementations for other drivers.
---
 drivers/atmodem/network-registration.c | 16 +---
 drivers/atmodem/network-registration.h | 17 +
 2 files changed, 26 insertions(+), 7 deletions(-)
 create mode 100644 drivers/atmodem/network-registration.h

diff --git a/drivers/atmodem/network-registration.c 
b/drivers/atmodem/network-registration.c
index 67380b73..0f83977b 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -41,6 +41,8 @@
 #include "atmodem.h"
 #include "vendor.h"
 
+#include "network-registration.h"
+
 static const char *none_prefix[] = { NULL };
 static const char *creg_prefix[] = { "+CREG:", NULL };
 static const char *cops_prefix[] = { "+COPS:", NULL };
@@ -270,7 +272,7 @@ static void option_tech_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
nd->tech = -1;
 }
 
-static void at_registration_status(struct ofono_netreg *netreg,
+void at_registration_status(struct ofono_netreg *netreg,
ofono_netreg_status_cb_t cb,
void *data)
 {
@@ -450,7 +452,7 @@ error:
g_free(cbd);
 }
 
-static void at_current_operator(struct ofono_netreg *netreg,
+void at_current_operator(struct ofono_netreg *netreg,
ofono_netreg_operator_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -589,7 +591,7 @@ static void cops_list_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
g_free(list);
 }
 
-static void at_list_operators(struct ofono_netreg *netreg,
+void at_list_operators(struct ofono_netreg *netreg,
ofono_netreg_operator_list_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -615,7 +617,7 @@ static void register_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
cb(&error, cbd->data);
 }
 
-static void at_register_auto(struct ofono_netreg *netreg,
+void at_register_auto(struct ofono_netreg *netreg,
ofono_netreg_register_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -630,7 +632,7 @@ static void at_register_auto(struct ofono_netreg *netreg,
CALLBACK_WITH_FAILURE(cb, data);
 }
 
-static void at_register_manual(struct ofono_netreg *netreg,
+void at_register_manual(struct ofono_netreg *netreg,
const char *mcc, const char *mnc,
ofono_netreg_register_cb_t cb, void *data)
 {
@@ -1228,7 +1230,7 @@ static void csq_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
cb(&error, strength, cbd->data);
 }
 
-static void at_signal_strength(struct ofono_netreg *netreg,
+void at_signal_strength(struct ofono_netreg *netreg,
ofono_netreg_strength_cb_t cb, void *data)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
@@ -2144,7 +2146,7 @@ static int at_netreg_probe(struct ofono_netreg *netreg, 
unsigned int vendor,
return 0;
 }
 
-static void at_netreg_remove(struct ofono_netreg *netreg)
+void at_netreg_remove(struct ofono_netreg *netreg)
 {
struct netreg_data *nd = ofono_netreg_get_data(netreg);
 
diff --git a/drivers/atmodem/network-registration.h 
b/drivers/atmodem/network-registration.h
new file mode 100644
index ..0f622411
--- /dev/null
+++ b/drivers/atmodem/network-registration.h
@@ -0,0 +1,17 @@
+#pragma once
+
+void at_registration_status(struct ofono_netreg *netreg,
+   ofono_netreg_status_cb_t cb,
+   void *data);
+void at_current_operator(struct ofono_netreg *netreg,
+   ofono_netreg_operator_cb_t cb, void *data);
+void at_list_operators(struct ofono_netreg *netreg,
+   ofono_netreg_operator_list_cb_t cb, void *data);
+void at_register_auto(struct ofono_netreg *netreg,
+   ofono_netreg_register_cb_t cb, void *data);
+void at_register_manual(struct ofono_netreg *netreg,
+   const char *mcc, const char *mnc,
+   ofono_netreg_register_cb_t cb, void *data);
+void at_signal_strength(struct ofono_netreg *netreg,
+  

[RFC at-export 0/2] Export AT-modem functions to other drivers

[Jonas Bonn]

Hi Denis,

I'm writing a custom network-registration driver for uBlox modems and
I'd like to know if you will choke on the following approach:

i)  export method implementations from atmodem driver
ii) set up uBlox netreg vtable with custom probe method and exported
atmodem implementations for rest

If you can't accept this approach, please let me know of an alternative
method that would be preferable that (hopefully) doesn't entail just
copying all the code from one driver to the other (1000+ lines to keep
in sync going forward).

Best regards,
Jonas

PS:  This is an RFC... patches are not quite done.  That said, feel free
to patch review if you've got a moment; the final result shouldn't
differ all that much from what's here.

Jonas Bonn (2):
  atmodem: export generic netreg funcs
  ublox: network-registration atom

 drivers/atmodem/network-registration.c|  16 +-
 drivers/atmodem/network-registration.h|  17 +
 drivers/ubloxmodem/network-registration.c | 413 ++
 drivers/ubloxmodem/ubloxmodem.c   |   2 +
 drivers/ubloxmodem/ubloxmodem.h   |   3 +
 5 files changed, 444 insertions(+), 7 deletions(-)
 create mode 100644 drivers/atmodem/network-registration.h
 create mode 100644 drivers/ubloxmodem/network-registration.c

-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[RFC at-export 2/2] ublox: network-registration atom

[Jonas Bonn]

For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient.  This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementations.
---
 drivers/ubloxmodem/network-registration.c | 413 ++
 drivers/ubloxmodem/ubloxmodem.c   |   2 +
 drivers/ubloxmodem/ubloxmodem.h   |   3 +
 3 files changed, 418 insertions(+)
 create mode 100644 drivers/ubloxmodem/network-registration.c

diff --git a/drivers/ubloxmodem/network-registration.c 
b/drivers/ubloxmodem/network-registration.c
new file mode 100644
index ..55adaff1
--- /dev/null
+++ b/drivers/ubloxmodem/network-registration.c
@@ -0,0 +1,413 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2011  Intel Corporation. All rights reserved.
+ *  Copyright (C) 2010  ST-Ericsson AB.
+ *
+ *  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 
+#include 
+
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include "common.h"
+#include "ubloxmodem.h"
+#include "drivers/atmodem/vendor.h"
+
+#include "drivers/atmodem/network-registration.h"
+
+static const char *none_prefix[] = { NULL };
+static const char *cmer_prefix[] = { "+CMER:", NULL };
+static const char *ureg_prefix[] = { "+UREG:", NULL };
+
+
+/* This needs to be kept compatible with the version in
+ * atmodem/network-registration.  Add ublox-specific fields only to
+ * the end of the struct.
+ */
+struct netreg_data {
+   GAtChat *chat;
+   char mcc[OFONO_MAX_MCC_LENGTH + 1];
+   char mnc[OFONO_MAX_MNC_LENGTH + 1];
+   int signal_index; /* If strength is reported via CIND */
+   int signal_min; /* min strength reported via CIND */
+   int signal_max; /* max strength reported via CIND */
+   int signal_invalid; /* invalid strength reported via CIND */
+   int tech;
+   struct ofono_network_time time;
+   guint nitz_timeout;
+   unsigned int vendor;
+
+   const struct ublox_model *model;
+};
+
+struct tech_query {
+   int status;
+   int lac;
+   int ci;
+   struct ofono_netreg *netreg;
+};
+
+static void ciev_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   int strength, ind;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CIEV:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &ind))
+   return;
+
+   if (ind != nd->signal_index)
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &strength))
+   return;
+
+   if (strength == nd->signal_invalid)
+   strength = -1;
+   else
+   strength = (strength * 100) / (nd->signal_max - nd->signal_min);
+
+   ofono_netreg_strength_notify(netreg, strength);
+}
+
+static gboolean notify_time(gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+
+   nd->nitz_timeout = 0;
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+
+   return FALSE;
+}
+
+static void ctzdst_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   int dst;
+   GAtResultIter iter;
+
+   g_at_result_iter_init(&iter, result);
+
+   if (!g_at_result_iter_next(&iter, "+CTZDST:"))
+   return;
+
+   if (!g_at_result_iter_next_number(&iter, &dst))
+   return;
+
+   DBG("dst %d", dst);
+
+   nd->time.dst = dst;
+
+   if (nd->nitz_timeout > 0) {
+   g_source_remove(nd->nitz_timeout);
+   nd->nitz_timeout = 0;
+   }
+
+   ofono_netreg_time_notify(netreg, &nd->time);
+}
+
+static void ctzv_notify(GAtResult *result, gpointer user_data)
+{
+   struct ofono_netreg *netreg = user_data;
+   struct netreg_data *nd = ofono_netreg_get_data(netreg);
+   int year, mon, mday, hour, min, sec;
+   const cha

[PATCH 1/1] ublox: detect and support LARA R2 series

[Jonas Bonn]

---

Hi Krishna,

This patch isn't tested, but this is roughly what you'd need to get the
LARA R2 detected and running.  After that, it's just a matter of going
through the details of where ofono has issues.

>From what I can see at a quick glance at the documentation, there's
nothing that particularly stands out here so I suspect things will
mostly just work.  Give the patch a try and let me know how it goes.

Regards,
Jonas

 drivers/ubloxmodem/ubloxmodem.c | 9 +
 drivers/ubloxmodem/ubloxmodem.h | 1 +
 plugins/udevng.c| 2 ++
 3 files changed, 12 insertions(+)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index a52a67ea..85d72684 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -77,6 +77,15 @@ const struct ublox_model ublox_models[] = {
.name = "TOBY-L4906",
.flags = UBLOX_F_TOBY_L4,
},
+   /* LARA L2 series */
+   {
+   .name = "LARA-R202",
+   .flags = UBLOX_F_LARA_R2,
+   },
+   {
+   .name = "LARA-R211",
+   .flags = UBLOX_F_LARA_R2,
+   },
{ /* sentinel */ },
 };
 
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 2c5b7433..7fe58df3 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -27,6 +27,7 @@ enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
UBLOX_F_TOBY_L4 = (1 << 1),
UBLOX_F_HAVE_USBCONF= (1 << 2),
+   UBLOX_F_LARA_R2 = (1 << 3),
 };
 
 struct ublox_model {
diff --git a/plugins/udevng.c b/plugins/udevng.c
index f689b756..397ac931 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1700,6 +1700,8 @@ static struct {
{ "ublox",  "cdc_acm",  "1546", "1010"  },
{ "ublox",  "cdc_ncm",  "1546", "1010"  },
{ "ublox",  "cdc_acm",  "1546", "1102"  },
+   { "ublox",  "cdc_acm",  "1546", "110a"  },
+   { "ublox",  "cdc_ncm",  "1546", "110a"  },
{ "ublox",  "rndis_host",   "1546", "1146"  },
{ "ublox",  "cdc_acm",  "1546", "1146"  },
{ "gemalto","option",   "1e2d", "0053"  },
-- 
2.20.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: Ofono for ublox LARA-R211

[Jonas Bonn]

Hi Krishna,

On 11/04/2019 13:47, Krishna wrote:

Hi All,

Whether anyone tried ofono framework with u-blox LARA-R211 or LARA-202?


ofono currently does not support these modems, but looking quickly at 
the documentation I don't see any difficulty at all in getting this to 
work.  You just need to add the USB model ID ('110a') to 
plugins/udevng.c and the modem identifiers to plugins/ublox.c (the model 
ID strings).


/Jonas



Regards,

Krishna

*From:*Krishna [mailto:krishn...@iwavesystems.com]
*Sent:* Friday, March 22, 2019 08:09 PM
*To:* 'ofono@ofono.org' 
*Subject:* Ofono for ublox LARA-R211

Hi All,

Whether I can use ofono for LARA-R211 or LARA-202?

I have added ofono package to the yocto and enabled required 
configurations in Linux kernel.


I have referred below link for the configuration.

https://embexus.com/2017/06/04/add-a-mobile-broadband-connectivity-to-embedded-linux/

However ./list-modem is not returning anything.

Let me know if I am missing any configuration.

Regards,

Krishna


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH] ublox: Do not leave vendor_family unset

[Jonas Bonn]

Hi Richard,

On 31/03/2019 23:19, richard.rojf...@gmail.com wrote:

From: Richard Röjfors 

In a recent patch vendor family was only set if the device
did not support USBCONF, but that resulted in drivers
being registered the "generic" vendor. That caused
for instance netreg to use incorrect cmer mode and fail
on TOBY-L210.


This patch is correct.  Please apply it, Denis.

Thanks for testing and reporting, Richard.

/Jonas


---
  plugins/ublox.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index dc001765..355bdf9e 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -227,6 +227,8 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
  
  	DBG("Model: %s", data->model->name);
  
+	data->vendor_family = OFONO_VENDOR_UBLOX;

+
if (data->model->flags & UBLOX_F_HAVE_USBCONF) {
if (g_at_chat_send(data->aux, "AT+UUSBCONF?", uusbconf_prefix,
query_usbconf_cb, modem, NULL))
@@ -234,8 +236,6 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
  
  		ofono_error("Unable to query USB configuration");

goto fail;
-   } else {
-   data->vendor_family = OFONO_VENDOR_UBLOX;
}
  
  	if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,



___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH 1/1] ublox: create only 1 gprs context

[Jonas Bonn]

Hi Denis,

On 15/03/2019 17:28, Denis Kenzior wrote:





uBlox is just being too smart here.  The whole bridged vs router stuff 
was never intended by 27.007.  They made this all up themselves. Neither 
oFono nor ConnMan were designed to handle such a setup.


The main issue will be for contexts used for MMS / OMA DM.  My memory 
from the Meego / Tizen days is fuzzy, but from what I recall we designed 
oFono with the assumption that we will always get an IP address and a 
separate interface for the MMS context.


There's also the proxy.  MMS contexts frequently have a proxy associated 
with them.  Again, we assumed that if a proxy is set, then it is also in 
a form of an IP address.  The proxy is then added as a route on the 
interface by oFono (see pri_setproxy for details).  And in practical 
terms there is no domain name resolution for these contexts.  Everything 
just goes to the proxy.


This was how e.g. mmsd was designed to work.  See 
https://git.kernel.org/pub/scm/network/ofono/mmsd.git.  That project has 
not been touched in some time though, but there are others that act very 
similar.




OK, thanks for digging that out despite the cobwebs!

So, this is where I end up then:

i)  MMS (and other) contexts are just IP endpoints, but they are all 
identified by a "type"

ii)  connman handles "Internet" contexts and ignores everything else...
iii) other applications (like mmsd) handle contexts of other types
iv)  mmsd, unlike connman, expects the network interface associated with 
the context to be fully configured... IP address, route, etc.


ofono is designed to expect a network interface for each context.  For 
this reason, it's pretty heavy-handed in its setup of the interface:  it 
assumes the interface isn't shared by other contexts and isn't careful 
about maintaining settings coming from other contexts.


So the real impedance mismatch here for the case where a modem puts 
multiple contexts behind a single network interface is the way ofono is 
implemented.


ofono could be re-implemented here to add multiple IP addresses to a 
single interface and to set routing accordingly (for MMS contexts only, 
apparently... it looks like ofono does nothing currently for other 
context types).


Another alternative is to have the gprs-context driver for affected 
devices create "virtual network devices" (is this still a thing?) with 
static IP addresses for all contexts.  For the u-blox "router mode" 
case, though, I can't figure out who runs the DHCP client... (and the 
TOBY L4 is router-mode-only, so requiring bridge-mode is not an option).


Either way, this is a reasonably big undertaking.  I don't think I want 
to take this on without a concrete use-case presenting itself, first! :)


So given that, the right thing to do here is probably to just drop 
multiple context support from the u-blox driver until ofono is modified 
(someday) to handle multiple contexts behind a single network interface. 
 I will send a patch.


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [RFC PATCH 1/1] ublox: create only 1 gprs context

[Jonas Bonn]

Hi Denis,

On 15/03/2019 02:27, Denis Kenzior wrote:

Hi Jonas,

On 03/14/2019 05:37 PM, Jonas Bonn wrote:

---



Funny, I was looking at this code today and thought it was wrong.  Was 
going to point this out to you, but you beat me to it ;)



Here's something that I'm having trouble understanding.  The ublox
plugin creates 8 gprs_context atoms.  As far as I can tell, this means
that ofono will allow it to activate 8 contexts simultaneously... right?



Correct.  Each context driver added to gprs allows a concurrent context 
to be activated.  E.g. if you have 2 drivers, you can activate 2 
contexts simultaneously.  Obviously you need a high speed / ppp 
interface for each active context.



Why is the ublox plugin the only one that does this?  Do other modems
not support multiple active contexts?  Or is this plugin wrong?


 From what I recall, ublox does claim to support multiple PDP contexts 
active at the same time.  However, I don't know how this works in 
practice as you need a unique network interface for each one.  As it 
stands today, given the udevng detection logic, this plugin is wrong.


Right, so the way this works is that the modem looks like either a 
"bridge" or a "router".  If configured as a "bridge", the outbound 
packet's source address is used to determine which context to use; if 
configured as a "router", the outbound packet's destination _network_ is 
used to determine which context to use and a default route is set via 
the _first activated context_ for packets that don't match the network 
of any active context.  That's a mouthful...!!!


The short of it is that this probably works in practice.

Is it ok for the connection manager interface to see multiple active 
contexts with the same Interface and the IP settings set to method 
"dhcp".  Will it run a DHCP client on each interface or is it expected 
to be smart enough to recognize the common interface???  What would the 
point be since the only thing that differs the contexts is the APN and 
the connection manager shouldn't care about that particular detail...??? 
 This all applies to "router" mode only, really.


In "bridge" mode, the above is probably moot since each context would 
announce different IP settings and the connection manager would be 
expected to apply those settings to the common interface.  No idea if 
this works in practice.


Do you know how these multiple, active contexts are used in practice? 
In particular with regard to ofono?






If I were to follow the model of other plugins, the below patch would
seem appropriate...

A bit of insight here would be appreciated.


There are drivers for USB based modems that do this properly.  See 
xmm7xxx for example.  Multiple PDP context support was added to that 
recently.


Modems that used multiplexing had support for multiple PDP contexts for 
quite some time.  E.g. plugins/ifx, etc.


Anyway, patch looks fine to me.  Let me know if you want me to apply it 
or you want to take a stab at fixing the detection logic.


From this, it sounds like the multiple gprs-context atoms are probably 
correct.  I'll take a look at the xmm7xxx driver and see how it handles 
things.


Thanks,
Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[RFC PATCH 1/1] ublox: create only 1 gprs context

[Jonas Bonn]

---

Here's something that I'm having trouble understanding.  The ublox
plugin creates 8 gprs_context atoms.  As far as I can tell, this means
that ofono will allow it to activate 8 contexts simultaneously... right?

Why is the ublox plugin the only one that does this?  Do other modems
not support multiple active contexts?  Or is this plugin wrong?

If I were to follow the model of other plugins, the below patch would
seem appropriate...

A bit of insight here would be appreciated.

Thanks,
Jonas

 plugins/ublox.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index dc001765..3ce60236 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -384,8 +384,6 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
const char *driver;
-   /* Toby L2: Create same number of contexts as supported PDP contexts. */
-   int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
int variant;
 
DBG("%p", modem);
@@ -409,14 +407,9 @@ static void ublox_post_sim(struct ofono_modem *modem)
variant = OFONO_VENDOR_UBLOX;
}
 
-   while (ncontexts) {
-   gc = ofono_gprs_context_create(modem, variant, driver, chat);
-
-   if (gprs && gc)
-   ofono_gprs_add_context(gprs, gc);
-
-   --ncontexts;
-   }
+   gc = ofono_gprs_context_create(modem, variant, driver, chat);
+   if (gprs && gc)
+   ofono_gprs_add_context(gprs, gc);
 
ofono_lte_create(modem,
ublox_model_to_id(data->model), "ubloxmodem", data->aux);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 4/5] ublox: gprs-context: query networking mode for TOBY L2

[Jonas Bonn]

The TOBY L2 may run in either "bridge" mode or "router" mode.  For this
model, query the configured mode so that the appropriate settings are
communicated when the context is activated.
---

Only compile tested... I don't actually have a TOBY L2.

/Jonas

 drivers/ubloxmodem/gprs-context.c | 54 ++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/ubloxmodem/gprs-context.c 
b/drivers/ubloxmodem/gprs-context.c
index 389868c1..35abae02 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@ -43,6 +43,12 @@
 static const char *none_prefix[] = { NULL };
 static const char *cgcontrdp_prefix[] = { "+CGCONTRDP:", NULL };
 static const char *uipaddr_prefix[] = { "+UIPADDR:", NULL };
+static const char *ubmconf_prefix[] = { "+UBMCONF:", NULL };
+
+enum netmode {
+   NETWORKING_MODE_ROUTER,
+   NETWORKING_MODE_BRIDGE,
+};
 
 struct gprs_context_data {
const struct ublox_model *model;
@@ -50,6 +56,7 @@ struct gprs_context_data {
unsigned int active_context;
ofono_gprs_context_cb_t cb;
void *cb_data;
+   enum netmode networking_mode;
 };
 
 static void uipaddr_cb(gboolean ok, GAtResult *result, gpointer user_data)
@@ -240,7 +247,7 @@ static void ublox_gprs_read_settings(struct 
ofono_gprs_context *gc,
 
DBG("cid %u", cid);
 
-   if (ublox_is_toby_l4(gcd->model)) {
+   if (gcd->networking_mode == NETWORKING_MODE_ROUTER) {
/* Use DHCP */
gcd->active_context = cid;
set_gprs_context_interface(gc);
@@ -471,6 +478,42 @@ static void cgev_notify(GAtResult *result, gpointer 
user_data)
gcd->active_context = 0;
 }
 
+static void at_ubmconf_read_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
+{
+   struct ofono_gprs_context *gc = user_data;
+   struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
+   GAtResultIter iter;
+   int mode;
+
+   if (!ok)
+   goto error;
+
+   g_at_result_iter_init(&iter, result);
+   if (!g_at_result_iter_next(&iter, "+UBMCONF:"))
+   goto error;
+
+   if (!g_at_result_iter_next_number(&iter, &mode))
+   goto error;
+
+   switch (mode) {
+   case 1:
+   gcd->networking_mode = NETWORKING_MODE_ROUTER;
+   break;
+   case 2:
+   gcd->networking_mode = NETWORKING_MODE_BRIDGE;
+   break;
+   default:
+   goto error;
+   }
+
+   return;
+
+error:
+   ofono_error("AT+UBMCONF? failed; assuming router mode");
+   gcd->networking_mode = NETWORKING_MODE_ROUTER;
+}
+
 static int ublox_gprs_context_probe(struct ofono_gprs_context *gc,
unsigned int model_id, void *data)
 {
@@ -491,6 +534,15 @@ static int ublox_gprs_context_probe(struct 
ofono_gprs_context *gc,
 
ofono_gprs_context_set_data(gc, gcd);
 
+   if (ublox_is_toby_l2(gcd->model)) {
+   g_at_chat_send(chat, "AT+UBMCONF?", ubmconf_prefix,
+   at_ubmconf_read_cb, gc, NULL);
+   } else if (ublox_is_toby_l4(gcd->model)) {
+   gcd->networking_mode = NETWORKING_MODE_ROUTER;
+   } else {
+   gcd->networking_mode = NETWORKING_MODE_ROUTER;
+   }
+
g_at_chat_register(chat, "+CGEV:", cgev_notify, FALSE, gc, NULL);
 
return 0;
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 2/5] ublox: pass model_id to gprs-context driver

[Jonas Bonn]

Depending on the transport used on the data connection we want either
the "atmodem" (PPP) driver or the "ubloxmodem".  For the "ubloxmodem",
we want to pass the model data so this patch wrangles some parameters to
make sure that right driver and right variant data are passed.
---
 plugins/ublox.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 1c74fe09..8100dfba 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -388,19 +388,34 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
-   const char *driver = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ?
-   "ubloxmodem" : "atmodem";
+   const char *driver;
/* Toby L2: Create same number of contexts as supported PDP contexts. */
int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
+   int variant;
 
DBG("%p", modem);
 
gprs = ofono_gprs_create(modem, data->vendor_family, "atmodem",
data->aux);
 
+   if (ublox_is_toby_l4(data->model)) {
+   driver = "ubloxmodem";
+   variant = ublox_model_to_id(data->model);
+   } else if (ublox_is_toby_l2(data->model)) {
+   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE) {
+   driver = "ubloxmodem";
+   variant = ublox_model_to_id(data->model);
+   } else {
+   driver = "atmodem";
+   variant = OFONO_VENDOR_UBLOX;
+   }
+   } else {
+   driver = "atmodem";
+   variant = OFONO_VENDOR_UBLOX;
+   }
+
while (ncontexts) {
-   gc = ofono_gprs_context_create(modem, data->vendor_family,
-   driver, chat);
+   gc = ofono_gprs_context_create(modem, variant, driver, chat);
 
if (gprs && gc)
ofono_gprs_add_context(gprs, gc);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 1/5] ublox: gprs-context: take model parameter

[Jonas Bonn]

---
 drivers/ubloxmodem/gprs-context.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/ubloxmodem/gprs-context.c 
b/drivers/ubloxmodem/gprs-context.c
index 1b4e17f5..bbf8627a 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@ -45,6 +45,7 @@ static const char *cgcontrdp_prefix[] = { "+CGCONTRDP:", NULL 
};
 static const char *uipaddr_prefix[] = { "+UIPADDR:", NULL };
 
 struct gprs_context_data {
+   const struct ublox_model *model;
GAtChat *chat;
unsigned int active_context;
ofono_gprs_context_cb_t cb;
@@ -462,7 +463,7 @@ static void cgev_notify(GAtResult *result, gpointer 
user_data)
 }
 
 static int ublox_gprs_context_probe(struct ofono_gprs_context *gc,
-   unsigned int vendor, void *data)
+   unsigned int model_id, void *data)
 {
GAtChat *chat = data;
struct gprs_context_data *gcd;
@@ -473,6 +474,10 @@ static int ublox_gprs_context_probe(struct 
ofono_gprs_context *gc,
if (gcd == NULL)
return -ENOMEM;
 
+   gcd->model = ublox_model_from_id(model_id);
+   if (!gcd->model)
+   return -EINVAL;
+
gcd->chat = g_at_chat_clone(chat);
 
ofono_gprs_context_set_data(gc, gcd);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 3/5] ublox: TOBY L4 supports only router mode

[Jonas Bonn]

The TOBY L4 supports only "router mode" where the modem presents a
network interface that one can run a DHCP client against.  Behind this
interface, the modem takes care of routing packets via NAT by:

i)  selecting the relevant context based on destination IP
ii) using the first activated context as the default route

In order to have the connection manager, thus, do the right thing, the
context only needs to report itself as being active and with the IP
settings set to method "dhcp".  There's no need for the connection manager
to know details like what IP address the context was assigned.

Tested with connman that does the right thing when it finds an active
"dhcp" context.
---
 drivers/ubloxmodem/gprs-context.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/ubloxmodem/gprs-context.c 
b/drivers/ubloxmodem/gprs-context.c
index bbf8627a..389868c1 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@ -240,6 +240,15 @@ static void ublox_gprs_read_settings(struct 
ofono_gprs_context *gc,
 
DBG("cid %u", cid);
 
+   if (ublox_is_toby_l4(gcd->model)) {
+   /* Use DHCP */
+   gcd->active_context = cid;
+   set_gprs_context_interface(gc);
+   ofono_gprs_context_set_ipv4_address(gc, NULL, 0);
+   CALLBACK_WITH_SUCCESS(cb, data);
+   return;
+   }
+
gcd->active_context = cid;
gcd->cb = cb;
gcd->cb_data = data;
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 5/5] ublox: do not set bridge mode for TOBY L2

[Jonas Bonn]

Trying to set the networking mode to "bridge" mode in the plugin is bogus
because the setting does not apply until after the device has been
reset.  Instead, the current setting should be queried.

If a user wants to set the modem networking mode, the setting should be
made outside of ofono.

The gprs-context driver has already been adjusted to query the
networking mode and to set things up accordingly.
---
 plugins/ublox.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 8100dfba..dc001765 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -145,11 +145,6 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
}
 
-   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE)
-   /* use bridged mode until routed mode support is added */
-   g_at_chat_send(data->aux, "AT+UBMCONF=2", none_prefix,
-   NULL, NULL, NULL);
-
ofono_modem_set_powered(modem, TRUE);
 }
 
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v4 3/6] udevng: detect ublox TOBY L4

[Jonas Bonn]

ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
 plugins/udevng.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 4473c0a6..f689b756 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1090,11 +1090,17 @@ static gboolean setup_ublox(struct modem_info *modem)
 *  - high throughput profile : 224/1/3
 */
} else if (g_strcmp0(info->interface, "2/2/1") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
-   aux = info->devnode;
-   else if (g_strcmp0(info->number, "00") == 0)
+   if (!g_strcmp0(modem->model, "1010")) {
+   if (g_strcmp0(info->number, "06") == 0)
+   aux = info->devnode;
+   } else {
+   if (g_strcmp0(info->number, "02") == 0)
+   aux = info->devnode;
+   }
+   if (g_strcmp0(info->number, "00") == 0)
mdm = info->devnode;
} else if (g_strcmp0(info->interface, "2/6/0") == 0 ||
+   g_strcmp0(info->interface, "2/13/0") == 0 ||
g_strcmp0(info->interface, "10/0/0") == 0 ||
g_strcmp0(info->interface, "224/1/3") == 0) {
net = info->devnode;
@@ -1691,6 +1697,8 @@ static struct {
{ "quectelqmi", "qcserial", "2c7c", "0121"  },
{ "quectelqmi", "qmi_wwan", "2c7c", "0125"  },
{ "quectelqmi", "qcserial", "2c7c", "0125"  },
+   { "ublox",  "cdc_acm",  "1546", "1010"  },
+   { "ublox",  "cdc_ncm",  "1546", "1010"  },
{ "ublox",  "cdc_acm",  "1546", "1102"  },
{ "ublox",  "rndis_host",   "1546", "1146"  },
{ "ublox",  "cdc_acm",  "1546", "1146"  },
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v4 5/6] ublox: extend LTE driver

[Jonas Bonn]

There are a couple of semi-independent changes here:

* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
 drivers/ubloxmodem/lte.c | 101 ++-
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/ubloxmodem/lte.c b/drivers/ubloxmodem/lte.c
index 34397dfe..eb9062d9 100644
--- a/drivers/ubloxmodem/lte.c
+++ b/drivers/ubloxmodem/lte.c
@@ -39,24 +39,85 @@
 
 #include "ubloxmodem.h"
 
-static const char *ucgdflt_prefix[] = { "+UCGDFLT:", NULL };
+static const char *none_prefix[] = { NULL };
 
 struct lte_driver_data {
GAtChat *chat;
+   const struct ublox_model *model;
+   struct ofono_lte_default_attach_info pending_info;
 };
 
-static void ucgdflt_cb(gboolean ok, GAtResult *result, gpointer user_data)
+static void at_lte_set_auth_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
 {
struct cb_data *cbd = user_data;
ofono_lte_cb_t cb = cbd->cb;
struct ofono_error error;
 
-   DBG("ok %d", ok);
-
decode_at_error(&error, g_at_result_final_response(result));
cb(&error, cbd->data);
 }
 
+static void at_lte_set_default_attach_info_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
+{
+   struct cb_data *cbd = user_data;
+   ofono_lte_cb_t cb = cbd->cb;
+   void *data = cbd->data;
+   struct lte_driver_data *ldd = cbd->user;
+   struct ofono_error error;
+   char buf[32 + OFONO_GPRS_MAX_USERNAME_LENGTH +
+   OFONO_GPRS_MAX_PASSWORD_LENGTH  + 1];
+   enum ofono_gprs_auth_method auth_method;
+   int cid;
+
+   if (!ok) {
+   decode_at_error(&error, g_at_result_final_response(result));
+   cb(&error, data);
+   return;
+   }
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   /* If CGDCONT has already been used to set up cid 4 then
+* the EPS default bearer will be configured from another
+* cid (see documentation for how this is selected).  Avoid
+* doing so as this assumes as much...
+*/
+   cid = 4;
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   cid = 1;
+   } else {
+   ofono_error("Unknown model; "
+   "unable to determine EPS default bearer CID");
+   goto out;
+   }
+
+   auth_method = ldd->pending_info.auth_method;
+
+   /* change the authentication method if the  parameters are invalid */
+   if (!*ldd->pending_info.username || !*ldd->pending_info.password)
+   auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
+
+   /* In contrast to CGAUTH, all four parameters are _required_ here;
+* if auth type is NONE then username and password must be set to
+* empty strings.
+*/
+   sprintf(buf, "AT+UAUTHREQ=%d,%d,\"%s\",\"%s\"",
+   cid,
+   at_util_gprs_auth_method_to_auth_prot(auth_method),
+   ldd->pending_info.username,
+   ldd->pending_info.password);
+
+   cbd = cb_data_ref(cbd);
+   if (g_at_chat_send(ldd->chat, buf, none_prefix,
+   at_lte_set_auth_cb, cbd, cb_data_unref) > 0)
+   return;
+
+out:
+   cb_data_unref(cbd);
+   CALLBACK_WITH_FAILURE(cb, data);
+}
+
 static void ublox_lte_set_default_attach_info(const struct ofono_lte *lte,
const struct ofono_lte_default_attach_info *info,
ofono_lte_cb_t cb, void *data)
@@ -67,17 +128,32 @@ static void ublox_lte_set_default_attach_info(const struct 
ofono_lte *lte,
 
DBG("LTE config with APN: %s", info->apn);
 
-   if (strlen(info->apn) > 0)
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,\"IP\",\"%s\"",
+   cbd->user = ldd;
+   memcpy(&ldd->pending_info, info, sizeof(ldd->pending_info));
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
+   info->apn);
+   else
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+CGDCONT=1,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
info->apn);
-   else
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+   else

[PATCH v4 6/6] ublox: pass model id to LTE plugin

[Jonas Bonn]

---
 plugins/ublox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 10660ff0..1c74fe09 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -408,7 +408,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--ncontexts;
}
 
-   ofono_lte_create(modem, 0, "ubloxmodem", data->aux);
+   ofono_lte_create(modem,
+   ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 }
 
 static void ublox_post_online(struct ofono_modem *modem)
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v4 2/6] ublox: add TOBY L4 models

[Jonas Bonn]

---
 drivers/ubloxmodem/ubloxmodem.c | 23 +++
 drivers/ubloxmodem/ubloxmodem.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 0630fcdf..9e0781f0 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -60,6 +60,23 @@ const struct ublox_model ublox_models[] = {
.name = "TOBY-L280",
.flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
+   /* TOBY L4 series */
+   {
+   .name = "TOBY-L4006",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4106",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4206",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4906",
+   .flags = UBLOX_F_TOBY_L4,
+   },
{ /* sentinel */ },
 };
 
@@ -90,6 +107,12 @@ int ublox_is_toby_l2(const struct ublox_model *model)
return model->flags & UBLOX_F_TOBY_L2;
 }
 
+int ublox_is_toby_l4(const struct ublox_model *model)
+{
+   return model->flags & UBLOX_F_TOBY_L4;
+}
+
+
 static int ubloxmodem_init(void)
 {
ublox_gprs_context_init();
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 1f5b6493..2c5b7433 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -25,6 +25,7 @@
 
 enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
+   UBLOX_F_TOBY_L4 = (1 << 1),
UBLOX_F_HAVE_USBCONF= (1 << 2),
 };
 
@@ -37,6 +38,7 @@ const struct ublox_model *ublox_model_from_name(const char 
*name);
 const struct ublox_model *ublox_model_from_id(int id);
 int ublox_model_to_id(const struct ublox_model *model);
 int ublox_is_toby_l2(const struct ublox_model *model);
+int ublox_is_toby_l4(const struct ublox_model *model);
 
 extern void ublox_gprs_context_init(void);
 extern void ublox_gprs_context_exit(void);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v4 1/6] ublox: add device flags

[Jonas Bonn]

Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one.  This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag.  This is more easily extensible as we
detect other features of the modem.
---
 plugins/ublox.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 1a412def..d99f5c45 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -49,20 +49,17 @@
 static const char *uusbconf_prefix[] = { "+UUSBCONF:", NULL };
 static const char *none_prefix[] = { NULL };
 
-enum supported_models {
-   SARA_G270   = 1102,
-   TOBYL2_COMPATIBLE_MODE  = 1141,
-   TOBYL2_MEDIUM_THROUGHPUT_MODE   = 1143,
-   TOBYL2_HIGH_THROUGHPUT_MODE = 1146,
+enum ublox_device_flags {
+   UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE = (1 << 0),
 };
 
 struct ublox_data {
GAtChat *modem;
GAtChat *aux;
-   int model_id;
enum ofono_vendor vendor_family;
 
const struct ublox_model *model;
+   int flags;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -148,7 +145,7 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
}
 
-   if (data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE)
+   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE)
/* use bridged mode until routed mode support is added */
g_at_chat_send(data->aux, "AT+UBMCONF=2", none_prefix,
NULL, NULL, NULL);
@@ -183,13 +180,12 @@ retry:
switch (profile) {
case 0: /* Fairly back compatible */
case 1: /* Fairly back compatible plus audio */
-   data->model_id =  TOBYL2_COMPATIBLE_MODE;
break;
case 2: /* Low/medium throughput */
-   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
-   break;
+   ofono_error("Medium throughput mode not supported");
+   goto error;
case 3: /* High throughput mode */
-   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   data->flags |= UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE;
break;
default:
ofono_error("Unexpected USB profile: %d", profile);
@@ -390,10 +386,10 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
-   const char *driver = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ?
+   const char *driver = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ?
"ubloxmodem" : "atmodem";
/* Toby L2: Create same number of contexts as supported PDP contexts. */
-   int ncontexts = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ? 8 : 1;
+   int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
 
DBG("%p", modem);
 
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v4 4/6] Separate ATE and AT+CMEE commands

[Jonas Bonn]

The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
 plugins/ublox.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index d99f5c45..10660ff0 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -282,7 +282,9 @@ static int ublox_enable(struct ofono_modem *modem)
/* The modem can take a while to wake up if just powered on. */
g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
 
-   g_at_chat_send(data->aux, "ATE0 +CMEE=1", none_prefix,
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
NULL, NULL, NULL);
 
if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v3 09/10] ublox: extend LTE driver

[Jonas Bonn]

There are a couple of semi-independent changes here:

* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
 drivers/ubloxmodem/lte.c | 101 ++-
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/ubloxmodem/lte.c b/drivers/ubloxmodem/lte.c
index 34397dfe..eb9062d9 100644
--- a/drivers/ubloxmodem/lte.c
+++ b/drivers/ubloxmodem/lte.c
@@ -39,24 +39,85 @@
 
 #include "ubloxmodem.h"
 
-static const char *ucgdflt_prefix[] = { "+UCGDFLT:", NULL };
+static const char *none_prefix[] = { NULL };
 
 struct lte_driver_data {
GAtChat *chat;
+   const struct ublox_model *model;
+   struct ofono_lte_default_attach_info pending_info;
 };
 
-static void ucgdflt_cb(gboolean ok, GAtResult *result, gpointer user_data)
+static void at_lte_set_auth_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
 {
struct cb_data *cbd = user_data;
ofono_lte_cb_t cb = cbd->cb;
struct ofono_error error;
 
-   DBG("ok %d", ok);
-
decode_at_error(&error, g_at_result_final_response(result));
cb(&error, cbd->data);
 }
 
+static void at_lte_set_default_attach_info_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
+{
+   struct cb_data *cbd = user_data;
+   ofono_lte_cb_t cb = cbd->cb;
+   void *data = cbd->data;
+   struct lte_driver_data *ldd = cbd->user;
+   struct ofono_error error;
+   char buf[32 + OFONO_GPRS_MAX_USERNAME_LENGTH +
+   OFONO_GPRS_MAX_PASSWORD_LENGTH  + 1];
+   enum ofono_gprs_auth_method auth_method;
+   int cid;
+
+   if (!ok) {
+   decode_at_error(&error, g_at_result_final_response(result));
+   cb(&error, data);
+   return;
+   }
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   /* If CGDCONT has already been used to set up cid 4 then
+* the EPS default bearer will be configured from another
+* cid (see documentation for how this is selected).  Avoid
+* doing so as this assumes as much...
+*/
+   cid = 4;
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   cid = 1;
+   } else {
+   ofono_error("Unknown model; "
+   "unable to determine EPS default bearer CID");
+   goto out;
+   }
+
+   auth_method = ldd->pending_info.auth_method;
+
+   /* change the authentication method if the  parameters are invalid */
+   if (!*ldd->pending_info.username || !*ldd->pending_info.password)
+   auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
+
+   /* In contrast to CGAUTH, all four parameters are _required_ here;
+* if auth type is NONE then username and password must be set to
+* empty strings.
+*/
+   sprintf(buf, "AT+UAUTHREQ=%d,%d,\"%s\",\"%s\"",
+   cid,
+   at_util_gprs_auth_method_to_auth_prot(auth_method),
+   ldd->pending_info.username,
+   ldd->pending_info.password);
+
+   cbd = cb_data_ref(cbd);
+   if (g_at_chat_send(ldd->chat, buf, none_prefix,
+   at_lte_set_auth_cb, cbd, cb_data_unref) > 0)
+   return;
+
+out:
+   cb_data_unref(cbd);
+   CALLBACK_WITH_FAILURE(cb, data);
+}
+
 static void ublox_lte_set_default_attach_info(const struct ofono_lte *lte,
const struct ofono_lte_default_attach_info *info,
ofono_lte_cb_t cb, void *data)
@@ -67,17 +128,32 @@ static void ublox_lte_set_default_attach_info(const struct 
ofono_lte *lte,
 
DBG("LTE config with APN: %s", info->apn);
 
-   if (strlen(info->apn) > 0)
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,\"IP\",\"%s\"",
+   cbd->user = ldd;
+   memcpy(&ldd->pending_info, info, sizeof(ldd->pending_info));
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
+   info->apn);
+   else
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+CGDCONT=1,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
info->apn);
-   else
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+   else

[PATCH v3 03/10] ublox: query USBCONF for applicable devices

[Jonas Bonn]

The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics.  These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" altogether.  Nonetheless, all we need to
know is which profile is selected in order to set things up correctly
and this can be queried directly.

This patch adds a call to UUSBCONF for applicable modems in order to
query the USB configuration to find out which profile is active.
---
 plugins/ublox.c | 84 +++--
 1 file changed, 61 insertions(+), 23 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 20e20567..2425620f 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -46,6 +46,7 @@
 
 #include 
 
+static const char *uusbconf_prefix[] = { "+UUSBCONF:", NULL };
 static const char *none_prefix[] = { NULL };
 
 enum supported_models {
@@ -155,6 +156,59 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_modem_set_powered(modem, TRUE);
 }
 
+static void query_usbconf_cb(gboolean ok,
+   GAtResult *result, gpointer user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   GAtResultIter iter;
+   int profile;
+
+   if (!ok) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   g_at_result_iter_init(&iter, result);
+
+retry:
+   if (!g_at_result_iter_next(&iter, "+UUSBCONF")) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   if (!g_at_result_iter_next_number(&iter, &profile))
+   goto retry;
+
+   switch (profile) {
+   case 0: /* Fairly back compatible */
+   case 1: /* Fairly back compatible plus audio */
+   data->model_id =  TOBYL2_COMPATIBLE_MODE;
+   break;
+   case 2: /* Low/medium throughput */
+   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
+   break;
+   case 3: /* High throughput mode */
+   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   break;
+   default:
+   ofono_error("Unexpected USB profile: %d", profile);
+   goto error;
+   }
+
+   if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+   cfun_enable, modem, NULL))
+   return;
+
+error:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+
 static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem *modem = user_data;
@@ -162,7 +216,6 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
struct ofono_error error;
const char *model;
const struct ublox_model *m;
-   const char *model_str;
 
decode_at_error(&error, g_at_result_final_response(result));
 
@@ -184,28 +237,13 @@ static void query_model_cb(gboolean ok, GAtResult 
*result, gpointer user_data)
 
DBG("Model: %s", data->model->name);
 
-   if (data->model->flags & UBLOX_F_TOBY_L2) {
-   model_str = ofono_modem_get_string(modem, "Model");
-   if (!model_str)
-   goto fail;
-
-   /*
-* Toby L2 devices are more complex and special than previously
-* supported U-Blox devices. So they need a vendor of their own.
-*/
-   data->model_id = strtoul(model_str, NULL, 10);
-
-   switch (data->model_id) {
-   case TOBYL2_COMPATIBLE_MODE:
-   case TOBYL2_HIGH_THROUGHPUT_MODE:
-   break;
-   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-   DBG("low/medium throughtput profile unsupported");
-   break;
-   default:
-   DBG("unknown ublox model id %d", data->model_id);
-   goto fail;
-   }
+   if (data->model->flags & UBLOX_F_HAVE_USBCONF) {
+   if (g_at_chat_send(data->aux, "AT+UUSBCONF?", uusbconf_prefix,
+   query_usbconf_cb, modem, NULL))
+   return;
+
+   ofono_error("Unable to query USB configuration");
+   goto fail;
} else {
data->vendor_family = OFONO_VENDOR_UBLOX;
}
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 09/10] ublox: extend LTE driver

[Jonas Bonn]

On 13/03/2019 21:23, Jonas Bonn wrote:

There are a couple of semi-independent changes here:

* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
  drivers/ubloxmodem/lte.c | 101 ++-
  1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/ubloxmodem/lte.c b/drivers/ubloxmodem/lte.c
index 34397dfe..e0f419b6 100644
--- a/drivers/ubloxmodem/lte.c
+++ b/drivers/ubloxmodem/lte.c
@@ -39,24 +39,85 @@
  
  #include "ubloxmodem.h"
  
-static const char *ucgdflt_prefix[] = { "+UCGDFLT:", NULL };

+static const char * const none_prefix[] = { NULL };


Same here, the const on the pointer here is no good.

/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 03/10] ublox: query USBCONF for applicable devices

[Jonas Bonn]

On 13/03/2019 21:23, Jonas Bonn wrote:

The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics.  These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" altogether.  Nonetheless, all we need to
know is which profile is selected in order to set things up correctly
and this can be queried directly.

This patch adds a call to UUSBCONF for applicable modems in order to
query the USB configuration to find out which profile is active.
---
  plugins/ublox.c | 86 +++--
  1 file changed, 62 insertions(+), 24 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 20e20567..e6891f21 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -46,7 +46,8 @@
  
  #include 
  
-static const char *none_prefix[] = { NULL };

+static const char * const uusbconf_prefix[] = { "+UUSBCONF:", NULL };
+static const char * const none_prefix[] = { NULL };


Of course, I got conned by checkpatch into making this change... it's 
certainly correct but making the pointer const doesn't play well with 
the rest of ofono so it's not sane to actually change this now.


I'll let you review the rest of the series before resubmitting... if you 
want to get past this, though, just drop the const from the pointer.


Sorry for the noise... my bad.

/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 10/10] ublox: pass model id to LTE plugin

[Jonas Bonn]

---
 plugins/ublox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index ad1b6ec7..7cb12f7f 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -409,7 +409,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--ncontexts;
}
 
-   ofono_lte_create(modem, 0, "ubloxmodem", data->aux);
+   ofono_lte_create(modem,
+   ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 }
 
 static void ublox_post_online(struct ofono_modem *modem)
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 03/10] ublox: query USBCONF for applicable devices

[Jonas Bonn]

The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics.  These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" altogether.  Nonetheless, all we need to
know is which profile is selected in order to set things up correctly
and this can be queried directly.

This patch adds a call to UUSBCONF for applicable modems in order to
query the USB configuration to find out which profile is active.
---
 plugins/ublox.c | 86 +++--
 1 file changed, 62 insertions(+), 24 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 20e20567..e6891f21 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -46,7 +46,8 @@
 
 #include 
 
-static const char *none_prefix[] = { NULL };
+static const char * const uusbconf_prefix[] = { "+UUSBCONF:", NULL };
+static const char * const none_prefix[] = { NULL };
 
 enum supported_models {
SARA_G270   = 1102,
@@ -155,6 +156,59 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_modem_set_powered(modem, TRUE);
 }
 
+static void query_usbconf_cb(gboolean ok,
+   GAtResult *result, gpointer user_data)
+{
+   struct ofono_modem *modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   GAtResultIter iter;
+   int profile;
+
+   if (!ok) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   g_at_result_iter_init(&iter, result);
+
+retry:
+   if (!g_at_result_iter_next(&iter, "+UUSBCONF")) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   if (!g_at_result_iter_next_number(&iter, &profile))
+   goto retry;
+
+   switch (profile) {
+   case 0: /* Fairly back compatible */
+   case 1: /* Fairly back compatible plus audio */
+   data->model_id =  TOBYL2_COMPATIBLE_MODE;
+   break;
+   case 2: /* Low/medium throughput */
+   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
+   break;
+   case 3: /* High throughput mode */
+   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   break;
+   default:
+   ofono_error("Unexpected USB profile: %d", profile);
+   goto error;
+   }
+
+   if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+   cfun_enable, modem, NULL))
+   return;
+
+error:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+
 static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem *modem = user_data;
@@ -162,7 +216,6 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
struct ofono_error error;
const char *model;
const struct ublox_model *m;
-   const char *model_str;
 
decode_at_error(&error, g_at_result_final_response(result));
 
@@ -184,28 +237,13 @@ static void query_model_cb(gboolean ok, GAtResult 
*result, gpointer user_data)
 
DBG("Model: %s", data->model->name);
 
-   if (data->model->flags & UBLOX_F_TOBY_L2) {
-   model_str = ofono_modem_get_string(modem, "Model");
-   if (!model_str)
-   goto fail;
-
-   /*
-* Toby L2 devices are more complex and special than previously
-* supported U-Blox devices. So they need a vendor of their own.
-*/
-   data->model_id = strtoul(model_str, NULL, 10);
-
-   switch (data->model_id) {
-   case TOBYL2_COMPATIBLE_MODE:
-   case TOBYL2_HIGH_THROUGHPUT_MODE:
-   break;
-   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-   DBG("low/medium throughtput profile unsupported");
-   break;
-   default:
-   DBG("unknown ublox model id %d", data->model_id);
-   goto fail;
-   }
+   if (data->model->flags & UBLOX_F_HAVE_USBCONF) {
+   if (g_at_chat_send(data->aux, "AT+UUSBCONF?", uusbconf_prefix,
+   query_usbconf_cb, modem, NULL))
+   return;
+
+   ofono_error("Unable to query USB configuration");
+   goto fail;
} else {
data->vendor_family = OFONO_VENDOR_UBLOX;
}
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 04/10] udevng: ublox: Model string no longer used

[Jonas Bonn]

---
 plugins/udevng.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index ce8cdee1..4473c0a6 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -,7 +,6 @@ static gboolean setup_ublox(struct modem_info *modem)
 
ofono_modem_set_string(modem->modem, "Aux", aux);
ofono_modem_set_string(modem->modem, "Modem", mdm);
-   ofono_modem_set_string(modem->modem, "Model", modem->model);
ofono_modem_set_string(modem->modem, "NetworkInterface", net);
 
return TRUE;
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 08/10] Separate ATE and AT+CMEE commands

[Jonas Bonn]

The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
 plugins/ublox.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 994761f8..ad1b6ec7 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -283,7 +283,9 @@ static int ublox_enable(struct ofono_modem *modem)
/* The modem can take a while to wake up if just powered on. */
g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
 
-   g_at_chat_send(data->aux, "ATE0 +CMEE=1", none_prefix,
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
NULL, NULL, NULL);
 
if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 06/10] ublox: add TOBY L4 models

[Jonas Bonn]

---
 drivers/ubloxmodem/ubloxmodem.c | 23 +++
 drivers/ubloxmodem/ubloxmodem.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 0630fcdf..9e0781f0 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -60,6 +60,23 @@ const struct ublox_model ublox_models[] = {
.name = "TOBY-L280",
.flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
+   /* TOBY L4 series */
+   {
+   .name = "TOBY-L4006",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4106",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4206",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4906",
+   .flags = UBLOX_F_TOBY_L4,
+   },
{ /* sentinel */ },
 };
 
@@ -90,6 +107,12 @@ int ublox_is_toby_l2(const struct ublox_model *model)
return model->flags & UBLOX_F_TOBY_L2;
 }
 
+int ublox_is_toby_l4(const struct ublox_model *model)
+{
+   return model->flags & UBLOX_F_TOBY_L4;
+}
+
+
 static int ubloxmodem_init(void)
 {
ublox_gprs_context_init();
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 1f5b6493..2c5b7433 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -25,6 +25,7 @@
 
 enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
+   UBLOX_F_TOBY_L4 = (1 << 1),
UBLOX_F_HAVE_USBCONF= (1 << 2),
 };
 
@@ -37,6 +38,7 @@ const struct ublox_model *ublox_model_from_name(const char 
*name);
 const struct ublox_model *ublox_model_from_id(int id);
 int ublox_model_to_id(const struct ublox_model *model);
 int ublox_is_toby_l2(const struct ublox_model *model);
+int ublox_is_toby_l4(const struct ublox_model *model);
 
 extern void ublox_gprs_context_init(void);
 extern void ublox_gprs_context_exit(void);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 05/14] ublox: query device model

[Jonas Bonn]

Hi Denis,

Thanks for the review.  I'm a bit baffled by some of the warnings you 
are seeing... DOS line endings?  Where did those come from... I don't 
see them here.


Nonetheless, I'll send a quick resubmission that passes checkpatch.pl 
and we'll take it from there.


Thanks,
Jonas

On 13/03/2019 19:37, Denis Kenzior wrote:

Hi Jonas,

On 03/12/2019 06:09 AM, Jonas Bonn wrote:

This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model.  From this device model string, a
model-specific capabilities structure can be selected.
---
  plugins/ublox.c | 107 ++--
  1 file changed, 77 insertions(+), 30 deletions(-)



Have you tried running checkpatch.pl on these?  There are too many 
coding style violations for me to fix.


Here's a small sample:

ERROR: "foo* bar" should be "foo *bar"
#138: FILE: plugins/ublox.c:64:
+    const struct ublox_model* model;

ERROR: DOS line endings
#147: FILE: plugins/ublox.c:158:
+static void query_model_cb(gboolean ok, GAtResult *result, gpointer 
user_data)^M$


ERROR: DOS line endings
#149: FILE: plugins/ublox.c:160:
+^Istruct ofono_modem* modem = user_data;^M$

ERROR: "foo* bar" should be "foo *bar"
#149: FILE: plugins/ublox.c:160:
+    struct ofono_modem* modem = user_data;




diff --git a/plugins/ublox.c b/plugins/ublox.c
index 32cf1e61..efb0afbc 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -42,9 +42,10 @@
  #include 
  #include 
-#include 
  #include 
+#include 
+
  static const char *none_prefix[] = { NULL };
  enum supported_models {
@@ -59,6 +60,8 @@ struct ublox_data {
  GAtChat *aux;
  int model_id;
  enum ofono_vendor vendor_family;
+
+    const struct ublox_model* model;
  };
  static void ublox_debug(const char *str, void *user_data)
@@ -152,38 +155,79 @@ static void cfun_enable(gboolean ok, GAtResult 
*result, gpointer user_data)

  ofono_modem_set_powered(modem, TRUE);
  }
-static int ublox_enable(struct ofono_modem *modem)
+static void query_model_cb(gboolean ok, GAtResult *result, gpointer 
user_data)

  {
+    struct ofono_modem* modem = user_data;
  struct ublox_data *data = ofono_modem_get_data(modem);
-    const char *model_str = NULL;
+    struct ofono_error error;
+    const char *model;
+    const struct ublox_model* m;
+    const char* model_str;
-    DBG("%p", modem);
+    decode_at_error(&error, g_at_result_final_response(result));
-    model_str = ofono_modem_get_string(modem, "Model");
-    if (model_str == NULL)
-    return -EINVAL;
+    if (!ok)
+    goto fail;
-    /*
- * Toby L2 devices are more complex and special than previously
- * supported U-Blox devices. So they need a vendor of their own.
- */
-    data->model_id = atoi(model_str);
-
-    data->vendor_family = OFONO_VENDOR_UBLOX;
-
-    switch (data->model_id) {
-    case SARA_G270:
-    case TOBYL2_COMPATIBLE_MODE:
-    case TOBYL2_HIGH_THROUGHPUT_MODE:
-    break;
-    case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-    DBG("low/medium throughtput profile unsupported");
-    break;
-    default:
-    DBG("unknown ublox model id %d", data->model_id);
-    return -EINVAL;
+    if (at_util_parse_attr(result, "", &model) == FALSE) {
+    ofono_error("Failed to query modem model");
+    goto fail;
  }
+    m = ublox_model_from_name(model);
+    if (!m->name) {


So you just potentially crashed here


+    ofono_error("Unrecognized model: %s", model);
+    goto fail;
+    }
+
+    data->model = m;
+
+    DBG("Model: %s", data->model->name);
+
+    if (data->model->flags & UBLOX_F_TOBY_L2) {
+    model_str = ofono_modem_get_string(modem, "Model");
+    if (!model_str)
+    goto fail;
+
+    /*
+ * Toby L2 devices are more complex and special than previously
+ * supported U-Blox devices. So they need a vendor of their own.
+ */
+    data->model_id = atoi(model_str);
+


atoi is generally considered harmful.  Use strtoul instead


+    switch (data->model_id) {
+    case TOBYL2_COMPATIBLE_MODE:
+    case TOBYL2_HIGH_THROUGHPUT_MODE:
+    break;
+    case TOBYL2_MEDIUM_THROUGHPUT_MODE:
+    DBG("low/medium throughtput profile unsupported");
+    break;
+    default:
+    DBG("unknown ublox model id %d", data->model_id);
+    goto fail;
+    }
+    } else {
+    data->vendor_family = OFONO_VENDOR_UBLOX;
+    }
+
+    if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+    cfun_enable, modem, NULL))
+    return;
+
+fail:
+    g_at_chat_unref(data->aux);
+    data->aux = NULL;
+    g_at_chat_unref(data->modem);
+    data->modem = NULL;
+ 

[PATCH v2 05/10] ublox: add device flags

[Jonas Bonn]

Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one.  This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag.  This is more easily extensible as we
detect other features of the modem.
---
 plugins/ublox.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index e6891f21..994761f8 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -49,20 +49,17 @@
 static const char * const uusbconf_prefix[] = { "+UUSBCONF:", NULL };
 static const char * const none_prefix[] = { NULL };
 
-enum supported_models {
-   SARA_G270   = 1102,
-   TOBYL2_COMPATIBLE_MODE  = 1141,
-   TOBYL2_MEDIUM_THROUGHPUT_MODE   = 1143,
-   TOBYL2_HIGH_THROUGHPUT_MODE = 1146,
+enum ublox_device_flags {
+   UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE = (1 << 0),
 };
 
 struct ublox_data {
GAtChat *modem;
GAtChat *aux;
-   int model_id;
enum ofono_vendor vendor_family;
 
const struct ublox_model *model;
+   int flags;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -148,7 +145,7 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
}
 
-   if (data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE)
+   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE)
/* use bridged mode until routed mode support is added */
g_at_chat_send(data->aux, "AT+UBMCONF=2", none_prefix,
NULL, NULL, NULL);
@@ -183,13 +180,12 @@ retry:
switch (profile) {
case 0: /* Fairly back compatible */
case 1: /* Fairly back compatible plus audio */
-   data->model_id =  TOBYL2_COMPATIBLE_MODE;
break;
case 2: /* Low/medium throughput */
-   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
-   break;
+   ofono_error("Medium throughput mode not supported");
+   goto error;
case 3: /* High throughput mode */
-   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   data->flags |= UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE;
break;
default:
ofono_error("Unexpected USB profile: %d", profile);
@@ -391,10 +387,10 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
-   const char *driver = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ?
+   const char *driver = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ?
"ubloxmodem" : "atmodem";
/* Toby L2: Create same number of contexts as supported PDP contexts. */
-   int ncontexts = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ? 8 : 1;
+   int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
 
DBG("%p", modem);
 
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 07/10] udevng: detect ublox TOBY L4

[Jonas Bonn]

ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
 plugins/udevng.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 4473c0a6..f689b756 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1090,11 +1090,17 @@ static gboolean setup_ublox(struct modem_info *modem)
 *  - high throughput profile : 224/1/3
 */
} else if (g_strcmp0(info->interface, "2/2/1") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
-   aux = info->devnode;
-   else if (g_strcmp0(info->number, "00") == 0)
+   if (!g_strcmp0(modem->model, "1010")) {
+   if (g_strcmp0(info->number, "06") == 0)
+   aux = info->devnode;
+   } else {
+   if (g_strcmp0(info->number, "02") == 0)
+   aux = info->devnode;
+   }
+   if (g_strcmp0(info->number, "00") == 0)
mdm = info->devnode;
} else if (g_strcmp0(info->interface, "2/6/0") == 0 ||
+   g_strcmp0(info->interface, "2/13/0") == 0 ||
g_strcmp0(info->interface, "10/0/0") == 0 ||
g_strcmp0(info->interface, "224/1/3") == 0) {
net = info->devnode;
@@ -1691,6 +1697,8 @@ static struct {
{ "quectelqmi", "qcserial", "2c7c", "0121"  },
{ "quectelqmi", "qmi_wwan", "2c7c", "0125"  },
{ "quectelqmi", "qcserial", "2c7c", "0125"  },
+   { "ublox",  "cdc_acm",  "1546", "1010"  },
+   { "ublox",  "cdc_ncm",  "1546", "1010"  },
{ "ublox",  "cdc_acm",  "1546", "1102"  },
{ "ublox",  "rndis_host",   "1546", "1146"  },
{ "ublox",  "cdc_acm",  "1546", "1146"  },
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH v2 09/10] ublox: extend LTE driver

[Jonas Bonn]

There are a couple of semi-independent changes here:

* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
 drivers/ubloxmodem/lte.c | 101 ++-
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/ubloxmodem/lte.c b/drivers/ubloxmodem/lte.c
index 34397dfe..e0f419b6 100644
--- a/drivers/ubloxmodem/lte.c
+++ b/drivers/ubloxmodem/lte.c
@@ -39,24 +39,85 @@
 
 #include "ubloxmodem.h"
 
-static const char *ucgdflt_prefix[] = { "+UCGDFLT:", NULL };
+static const char * const none_prefix[] = { NULL };
 
 struct lte_driver_data {
GAtChat *chat;
+   const struct ublox_model *model;
+   struct ofono_lte_default_attach_info pending_info;
 };
 
-static void ucgdflt_cb(gboolean ok, GAtResult *result, gpointer user_data)
+static void at_lte_set_auth_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
 {
struct cb_data *cbd = user_data;
ofono_lte_cb_t cb = cbd->cb;
struct ofono_error error;
 
-   DBG("ok %d", ok);
-
decode_at_error(&error, g_at_result_final_response(result));
cb(&error, cbd->data);
 }
 
+static void at_lte_set_default_attach_info_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
+{
+   struct cb_data *cbd = user_data;
+   ofono_lte_cb_t cb = cbd->cb;
+   void *data = cbd->data;
+   struct lte_driver_data *ldd = cbd->user;
+   struct ofono_error error;
+   char buf[32 + OFONO_GPRS_MAX_USERNAME_LENGTH +
+   OFONO_GPRS_MAX_PASSWORD_LENGTH  + 1];
+   enum ofono_gprs_auth_method auth_method;
+   int cid;
+
+   if (!ok) {
+   decode_at_error(&error, g_at_result_final_response(result));
+   cb(&error, data);
+   return;
+   }
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   /* If CGDCONT has already been used to set up cid 4 then
+* the EPS default bearer will be configured from another
+* cid (see documentation for how this is selected).  Avoid
+* doing so as this assumes as much...
+*/
+   cid = 4;
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   cid = 1;
+   } else {
+   ofono_error("Unknown model; "
+   "unable to determine EPS default bearer CID");
+   goto out;
+   }
+
+   auth_method = ldd->pending_info.auth_method;
+
+   /* change the authentication method if the  parameters are invalid */
+   if (!*ldd->pending_info.username || !*ldd->pending_info.password)
+   auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
+
+   /* In contrast to CGAUTH, all four parameters are _required_ here;
+* if auth type is NONE then username and password must be set to
+* empty strings.
+*/
+   sprintf(buf, "AT+UAUTHREQ=%d,%d,\"%s\",\"%s\"",
+   cid,
+   at_util_gprs_auth_method_to_auth_prot(auth_method),
+   ldd->pending_info.username,
+   ldd->pending_info.password);
+
+   cbd = cb_data_ref(cbd);
+   if (g_at_chat_send(ldd->chat, buf, none_prefix,
+   at_lte_set_auth_cb, cbd, cb_data_unref) > 0)
+   return;
+
+out:
+   cb_data_unref(cbd);
+   CALLBACK_WITH_FAILURE(cb, data);
+}
+
 static void ublox_lte_set_default_attach_info(const struct ofono_lte *lte,
const struct ofono_lte_default_attach_info *info,
ofono_lte_cb_t cb, void *data)
@@ -67,17 +128,32 @@ static void ublox_lte_set_default_attach_info(const struct 
ofono_lte *lte,
 
DBG("LTE config with APN: %s", info->apn);
 
-   if (strlen(info->apn) > 0)
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,\"IP\",\"%s\"",
+   cbd->user = ldd;
+   memcpy(&ldd->pending_info, info, sizeof(ldd->pending_info));
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
+   info->apn);
+   else
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+CGDCONT=1,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
info->apn);
-   else
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+ 

[PATCH v2 01/10] ublox: query device model

[Jonas Bonn]

This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model.  From this device model string, a
model-specific capabilities structure can be selected.
---
 plugins/ublox.c | 107 ++--
 1 file changed, 77 insertions(+), 30 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 32cf1e61..20e20567 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -42,9 +42,10 @@
 #include 
 #include 
 
-#include 
 #include 
 
+#include 
+
 static const char *none_prefix[] = { NULL };
 
 enum supported_models {
@@ -59,6 +60,8 @@ struct ublox_data {
GAtChat *aux;
int model_id;
enum ofono_vendor vendor_family;
+
+   const struct ublox_model *model;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -152,38 +155,79 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_modem_set_powered(modem, TRUE);
 }
 
-static int ublox_enable(struct ofono_modem *modem)
+static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
+   struct ofono_modem *modem = user_data;
struct ublox_data *data = ofono_modem_get_data(modem);
-   const char *model_str = NULL;
+   struct ofono_error error;
+   const char *model;
+   const struct ublox_model *m;
+   const char *model_str;
 
-   DBG("%p", modem);
+   decode_at_error(&error, g_at_result_final_response(result));
 
-   model_str = ofono_modem_get_string(modem, "Model");
-   if (model_str == NULL)
-   return -EINVAL;
+   if (!ok)
+   goto fail;
 
-   /*
-* Toby L2 devices are more complex and special than previously
-* supported U-Blox devices. So they need a vendor of their own.
-*/
-   data->model_id = atoi(model_str);
-
-   data->vendor_family = OFONO_VENDOR_UBLOX;
-
-   switch (data->model_id) {
-   case SARA_G270:
-   case TOBYL2_COMPATIBLE_MODE:
-   case TOBYL2_HIGH_THROUGHPUT_MODE:
-   break;
-   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-   DBG("low/medium throughtput profile unsupported");
-   break;
-   default:
-   DBG("unknown ublox model id %d", data->model_id);
-   return -EINVAL;
+   if (at_util_parse_attr(result, "", &model) == FALSE) {
+   ofono_error("Failed to query modem model");
+   goto fail;
+   }
+
+   m = ublox_model_from_name(model);
+   if (!m) {
+   ofono_error("Unrecognized model: %s", model);
+   goto fail;
+   }
+
+   data->model = m;
+
+   DBG("Model: %s", data->model->name);
+
+   if (data->model->flags & UBLOX_F_TOBY_L2) {
+   model_str = ofono_modem_get_string(modem, "Model");
+   if (!model_str)
+   goto fail;
+
+   /*
+* Toby L2 devices are more complex and special than previously
+* supported U-Blox devices. So they need a vendor of their own.
+*/
+   data->model_id = strtoul(model_str, NULL, 10);
+
+   switch (data->model_id) {
+   case TOBYL2_COMPATIBLE_MODE:
+   case TOBYL2_HIGH_THROUGHPUT_MODE:
+   break;
+   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
+   DBG("low/medium throughtput profile unsupported");
+   break;
+   default:
+   DBG("unknown ublox model id %d", data->model_id);
+   goto fail;
+   }
+   } else {
+   data->vendor_family = OFONO_VENDOR_UBLOX;
}
 
+   if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+   cfun_enable, modem, NULL))
+   return;
+
+fail:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+static int ublox_enable(struct ofono_modem *modem)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
data->aux = open_device(modem, "Aux", "Aux: ");
/* If this is a serial modem then the device may be behind
 * the 'Device' attribute instead...
@@ -199,7 +243,6 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_set_slave(data->modem, data->aux);
g_at_chat_send(data->modem, "ATE0 +CMEE=1", none_prefix,
NULL, NULL, NULL);
-
g_at_chat_send(data->modem, "AT&C0", NULL, NULL, NULL, NULL);
}
 
@@ -209,10 +252,14 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_send(data->aux, "ATE0 +CMEE=1", none_prefix,
NULL, NULL, NULL);
 
-   g_at_chat_send(data-

[PATCH v2 02/10] ublox: add model flag HAVE_USBCONF

[Jonas Bonn]

This flag should be set on devices that support multiple USB profiles
and will be used to determine whether or not querying USB profiles is
appropriate/necessary.
---
 drivers/ubloxmodem/ubloxmodem.c | 10 +-
 drivers/ubloxmodem/ubloxmodem.h |  1 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index c60b6d3f..0630fcdf 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -42,23 +42,23 @@ const struct ublox_model ublox_models[] = {
/* TOBY L2 series */
{
.name = "TOBY-L200",
-   .flags = UBLOX_F_TOBY_L2,
+   .flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
{
.name = "TOBY-L201",
-   .flags = UBLOX_F_TOBY_L2,
+   .flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
{
.name = "TOBY-L210",
-   .flags = UBLOX_F_TOBY_L2,
+   .flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
{
.name = "TOBY-L220",
-   .flags = UBLOX_F_TOBY_L2,
+   .flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
{
.name = "TOBY-L280",
-   .flags = UBLOX_F_TOBY_L2,
+   .flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
{ /* sentinel */ },
 };
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 7c7b159a..1f5b6493 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -25,6 +25,7 @@
 
 enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
+   UBLOX_F_HAVE_USBCONF= (1 << 2),
 };
 
 struct ublox_model {
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH 6/8] gprs-context : Force use of atd99

[Jonas Bonn]

Hi,

Could I get a clarification on the behaviour you see here?

As I understand it, the SARA-R4 doesn't support the CGDATA command. 
That's fine as ofono will detect this and set use_atd99 in order to 
force the use of the ATD command as a fallback.


Why do you need to force this setting in the below patch?  Does the 
CGDATA command not return ERROR?  What does it return?


Thanks,
Jonas

On 15/02/2019 13:11, philippedesw...@gmail.com wrote:

From: Philippe De Swert 

QUIRCK: For some reason I really need to force the use of the atd99 command 
here.
---
  drivers/atmodem/gprs-context.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/atmodem/gprs-context.c b/drivers/atmodem/gprs-context.c
index 93894efd..a0776f2a 100644
--- a/drivers/atmodem/gprs-context.c
+++ b/drivers/atmodem/gprs-context.c
@@ -214,7 +214,7 @@ static void at_cgdcont_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
}
  
-	if (gcd->use_atd99)

+   if (gcd->use_atd99 || gcd->vendor == OFONO_VENDOR_UBLOX)
sprintf(buf, "ATD*99***%u#", gcd->active_context);
else
sprintf(buf, "AT+CGDATA=\"PPP\",%u", gcd->active_context);
@@ -457,6 +457,9 @@ static int at_gprs_context_probe(struct ofono_gprs_context 
*gc,
case OFONO_VENDOR_SIMCOM_SIM900:
gcd->use_atd99 = FALSE;
break;
+   case OFONO_VENDOR_UBLOX:
+   gcd->use_atd99 = TRUE;
+   break;
default:
g_at_chat_send(chat, "AT+CGDATA=?", cgdata_prefix,
at_cgdata_test_cb, gc, NULL);


___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 14/14] ublox: pass model id to LTE plugin

[Jonas Bonn]

---
 plugins/ublox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 7a93adb2..bec0bf83 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -407,7 +407,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--ncontexts;
}
 
-   ofono_lte_create(modem, 0, "ubloxmodem", data->aux);
+   ofono_lte_create(modem,
+   ublox_model_to_id(data->model), "ubloxmodem", data->aux);
 }
 
 static void ublox_post_online(struct ofono_modem *modem)
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 12/14] Separate ATE and AT+CMEE commands

[Jonas Bonn]

The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
 plugins/ublox.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 038b55d5..7a93adb2 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -281,7 +281,9 @@ static int ublox_enable(struct ofono_modem *modem)
/* The modem can take a while to wake up if just powered on. */
g_at_chat_set_wakeup_command(data->aux, "AT\r", 1000, 11000);
 
-   g_at_chat_send(data->aux, "ATE0 +CMEE=1", none_prefix,
+   g_at_chat_send(data->aux, "ATE0", none_prefix,
+   NULL, NULL, NULL);
+   g_at_chat_send(data->aux, "AT+CMEE=1", none_prefix,
NULL, NULL, NULL);
 
if (g_at_chat_send(data->aux, "AT+CGMM", NULL,
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 07/14] ublox: query USBCONF for applicable devices

[Jonas Bonn]

The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics.  These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" altogether.  Nonetheless, all we need to
know is which profile is selected in order to set things up correctly
and this can be queried directly.

This patch adds a call to UUSBCONF for applicable modems in order to
query the USB configuration to find out which profile is active.
---
 plugins/ublox.c | 82 +++--
 1 file changed, 59 insertions(+), 23 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index efb0afbc..f7c2a374 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -46,6 +46,7 @@
 
 #include 
 
+static const char *uusbconf_prefix[] = { "+UUSBCONF:", NULL };
 static const char *none_prefix[] = { NULL };
 
 enum supported_models {
@@ -155,6 +156,57 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_modem_set_powered(modem, TRUE);
 }
 
+static void query_usbconf_cb(gboolean ok, GAtResult *result, gpointer 
user_data){
+   struct ofono_modem* modem = user_data;
+   struct ublox_data *data = ofono_modem_get_data(modem);
+   GAtResultIter iter;
+   int profile;
+
+   if (!ok) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   g_at_result_iter_init(&iter, result);
+
+retry:
+   if (!g_at_result_iter_next(&iter, "+UUSBCONF")) {
+   ofono_error("Unable to query USB configuration");
+   goto error;
+   }
+
+   if (!g_at_result_iter_next_number(&iter, &profile))
+   goto retry;
+
+   switch (profile) {
+   case 0: /* Fairly back compatible */
+   case 1: /* Fairly back compatible plus audio */
+   data->model_id =  TOBYL2_COMPATIBLE_MODE;
+   break;
+   case 2: /* Low/medium throughput */
+   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
+   break;
+   case 3: /* High throughput mode */
+   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   break;
+   default:
+   ofono_error("Unexpected USB profile: %d", profile);
+   goto error;
+   }
+
+   if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+   cfun_enable, modem, NULL))
+   return;
+
+error:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+
 static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
struct ofono_modem* modem = user_data;
@@ -162,7 +214,6 @@ static void query_model_cb(gboolean ok, GAtResult *result, 
gpointer user_data)
struct ofono_error error;
const char *model;
const struct ublox_model* m;
-   const char* model_str;
 
decode_at_error(&error, g_at_result_final_response(result));
 
@@ -184,28 +235,13 @@ static void query_model_cb(gboolean ok, GAtResult 
*result, gpointer user_data)
 
DBG("Model: %s", data->model->name);
 
-   if (data->model->flags & UBLOX_F_TOBY_L2) {
-   model_str = ofono_modem_get_string(modem, "Model");
-   if (!model_str)
-   goto fail;
-
-   /*
-* Toby L2 devices are more complex and special than previously
-* supported U-Blox devices. So they need a vendor of their own.
-*/
-   data->model_id = atoi(model_str);
-
-   switch (data->model_id) {
-   case TOBYL2_COMPATIBLE_MODE:
-   case TOBYL2_HIGH_THROUGHPUT_MODE:
-   break;
-   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-   DBG("low/medium throughtput profile unsupported");
-   break;
-   default:
-   DBG("unknown ublox model id %d", data->model_id);
-   goto fail;
-   }
+   if (data->model->flags & UBLOX_F_HAVE_USBCONF) {
+   if (g_at_chat_send(data->aux, "AT+UUSBCONF?", uusbconf_prefix,
+   query_usbconf_cb, modem, NULL))
+   return;
+
+   ofono_error("Unable to query USB configuration");
+   goto fail;
} else {
data->vendor_family = OFONO_VENDOR_UBLOX;
}
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 10/14] ublox: add TOBY L4 models

[Jonas Bonn]

---
 drivers/ubloxmodem/ubloxmodem.c | 23 +++
 drivers/ubloxmodem/ubloxmodem.h |  2 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 3998f55e..49a824ed 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -58,6 +58,23 @@ const struct ublox_model ublox_models[] = {
.name = "TOBY-L280",
.flags = UBLOX_F_TOBY_L2|UBLOX_F_HAVE_USBCONF,
},
+   /* TOBY L4 series */
+   {
+   .name = "TOBY-L4006",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4106",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4206",
+   .flags = UBLOX_F_TOBY_L4,
+   },
+   {
+   .name = "TOBY-L4906",
+   .flags = UBLOX_F_TOBY_L4,
+   },
{ /* sentinal */ },
 };
 
@@ -88,6 +105,12 @@ int ublox_is_toby_l2(const struct ublox_model* model)
return model->flags & UBLOX_F_TOBY_L2;
 }
 
+int ublox_is_toby_l4(const struct ublox_model* model)
+{
+   return model->flags & UBLOX_F_TOBY_L4;
+}
+
+
 static int ubloxmodem_init(void)
 {
ublox_gprs_context_init();
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index 90749bff..8a499c11 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -25,6 +25,7 @@
 
 enum ublox_flags {
UBLOX_F_TOBY_L2 = (1 << 0),
+   UBLOX_F_TOBY_L4 = (1 << 1),
UBLOX_F_HAVE_USBCONF= (1 << 2),
 };
 
@@ -37,6 +38,7 @@ const struct ublox_model* ublox_model_from_name(const char* 
name);
 const struct ublox_model* ublox_model_from_id(int id);
 int ublox_model_to_id(const struct ublox_model* model);
 int ublox_is_toby_l2(const struct ublox_model* model);
+int ublox_is_toby_l4(const struct ublox_model* model);
 
 extern void ublox_gprs_context_init(void);
 extern void ublox_gprs_context_exit(void);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 13/14] ublox: extend LTE driver

[Jonas Bonn]

There are a couple of semi-independent changes here:

* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
 drivers/ubloxmodem/lte.c | 101 ++-
 1 file changed, 89 insertions(+), 12 deletions(-)

diff --git a/drivers/ubloxmodem/lte.c b/drivers/ubloxmodem/lte.c
index 34397dfe..5b134745 100644
--- a/drivers/ubloxmodem/lte.c
+++ b/drivers/ubloxmodem/lte.c
@@ -39,24 +39,85 @@
 
 #include "ubloxmodem.h"
 
-static const char *ucgdflt_prefix[] = { "+UCGDFLT:", NULL };
+static const char *none_prefix[] = { NULL };
 
 struct lte_driver_data {
GAtChat *chat;
+   const struct ublox_model* model;
+   struct ofono_lte_default_attach_info pending_info;
 };
 
-static void ucgdflt_cb(gboolean ok, GAtResult *result, gpointer user_data)
+static void at_lte_set_auth_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
 {
struct cb_data *cbd = user_data;
ofono_lte_cb_t cb = cbd->cb;
struct ofono_error error;
 
-   DBG("ok %d", ok);
-
decode_at_error(&error, g_at_result_final_response(result));
cb(&error, cbd->data);
 }
 
+static void at_lte_set_default_attach_info_cb(gboolean ok, GAtResult *result,
+   gpointer user_data)
+{
+   struct cb_data *cbd = user_data;
+   ofono_lte_cb_t cb = cbd->cb;
+   void *data = cbd->data;
+   struct lte_driver_data *ldd = cbd->user;
+   struct ofono_error error;
+   char buf[32 + OFONO_GPRS_MAX_USERNAME_LENGTH +
+   OFONO_GPRS_MAX_PASSWORD_LENGTH  + 1];
+   enum ofono_gprs_auth_method auth_method;
+   int cid;
+
+   if (!ok) {
+   decode_at_error(&error, g_at_result_final_response(result));
+   cb(&error, data);
+   return;
+   }
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   /* If CGDCONT has already been used to set up cid 4 then
+* the EPS default bearer will be configured from another
+* cid (see documentation for how this is selected).  Avoid
+* doing so as this assumes as much...
+*/
+   cid = 4;
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   cid = 1;
+   } else {
+   ofono_error("Unknown model; "
+   "unable to determine EPS default bearer CID");
+   goto out;
+   }
+
+   auth_method = ldd->pending_info.auth_method;
+
+   /* change the authentication method if the  parameters are invalid */
+   if (!*ldd->pending_info.username || !*ldd->pending_info.password)
+   auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
+
+   /* In contrast to CGAUTH, all four parameters are _required_ here;
+* if auth type is NONE then username and password must be set to
+* empty strings.
+*/
+   sprintf(buf, "AT+UAUTHREQ=%d,%d,\"%s\",\"%s\"",
+   cid,
+   at_util_gprs_auth_method_to_auth_prot(auth_method),
+   ldd->pending_info.username,
+   ldd->pending_info.password);
+
+   cbd = cb_data_ref(cbd);
+   if (g_at_chat_send(ldd->chat, buf, none_prefix,
+   at_lte_set_auth_cb, cbd, cb_data_unref) > 0)
+   return;
+
+out:
+   cb_data_unref(cbd);
+   CALLBACK_WITH_FAILURE(cb, data);
+}
+
 static void ublox_lte_set_default_attach_info(const struct ofono_lte *lte,
const struct ofono_lte_default_attach_info *info,
ofono_lte_cb_t cb, void *data)
@@ -67,17 +128,32 @@ static void ublox_lte_set_default_attach_info(const struct 
ofono_lte *lte,
 
DBG("LTE config with APN: %s", info->apn);
 
-   if (strlen(info->apn) > 0)
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,\"IP\",\"%s\"",
+   cbd->user = ldd;
+   memcpy(&ldd->pending_info, info, sizeof(ldd->pending_info));
+
+   if (ublox_is_toby_l2(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
+   info->apn);
+   else
+   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+
+   } else if (ublox_is_toby_l4(ldd->model)) {
+   if (strlen(info->apn) > 0)
+   snprintf(buf, sizeof(buf), "AT+CGDCONT=1,%s,\"%s\"",
+   at_util_gprs_proto_to_pdp_type(info->proto),
info->apn);
-   else
-   snprintf(buf, sizeof(buf), "AT+UCGDFLT=0");
+   else

[PATCH 11/14] udevng: detect ublox TOBY L4

[Jonas Bonn]

ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
 plugins/udevng.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 4473c0a6..f689b756 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1090,11 +1090,17 @@ static gboolean setup_ublox(struct modem_info *modem)
 *  - high throughput profile : 224/1/3
 */
} else if (g_strcmp0(info->interface, "2/2/1") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
-   aux = info->devnode;
-   else if (g_strcmp0(info->number, "00") == 0)
+   if (!g_strcmp0(modem->model, "1010")) {
+   if (g_strcmp0(info->number, "06") == 0)
+   aux = info->devnode;
+   } else {
+   if (g_strcmp0(info->number, "02") == 0)
+   aux = info->devnode;
+   }
+   if (g_strcmp0(info->number, "00") == 0)
mdm = info->devnode;
} else if (g_strcmp0(info->interface, "2/6/0") == 0 ||
+   g_strcmp0(info->interface, "2/13/0") == 0 ||
g_strcmp0(info->interface, "10/0/0") == 0 ||
g_strcmp0(info->interface, "224/1/3") == 0) {
net = info->devnode;
@@ -1691,6 +1697,8 @@ static struct {
{ "quectelqmi", "qcserial", "2c7c", "0121"  },
{ "quectelqmi", "qmi_wwan", "2c7c", "0125"  },
{ "quectelqmi", "qcserial", "2c7c", "0125"  },
+   { "ublox",  "cdc_acm",  "1546", "1010"  },
+   { "ublox",  "cdc_ncm",  "1546", "1010"  },
{ "ublox",  "cdc_acm",  "1546", "1102"  },
{ "ublox",  "rndis_host",   "1546", "1146"  },
{ "ublox",  "cdc_acm",  "1546", "1146"  },
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 01/14] Fix whitespace weirdness

[Jonas Bonn]

---
 drivers/atmodem/network-registration.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/atmodem/network-registration.c 
b/drivers/atmodem/network-registration.c
index 2482dfc3..1704f98c 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -1559,12 +1559,12 @@ static void creg_notify(GAtResult *result, gpointer 
user_data)
option_query_tech_cb, tq, g_free) > 0)
return;
break;
-case OFONO_VENDOR_GEMALTO:
-  if (g_at_chat_send(nd->chat, "AT^SMONI",
-  smoni_prefix,
-  gemalto_query_tech_cb, tq, g_free) > 0)
-  return;
-  break;
+   case OFONO_VENDOR_GEMALTO:
+   if (g_at_chat_send(nd->chat, "AT^SMONI",
+ smoni_prefix,
+ gemalto_query_tech_cb, tq, g_free) > 0)
+   return;
+   break;
}
 
g_free(tq);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 05/14] ublox: query device model

[Jonas Bonn]

This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model.  From this device model string, a
model-specific capabilities structure can be selected.
---
 plugins/ublox.c | 107 ++--
 1 file changed, 77 insertions(+), 30 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index 32cf1e61..efb0afbc 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -42,9 +42,10 @@
 #include 
 #include 
 
-#include 
 #include 
 
+#include 
+
 static const char *none_prefix[] = { NULL };
 
 enum supported_models {
@@ -59,6 +60,8 @@ struct ublox_data {
GAtChat *aux;
int model_id;
enum ofono_vendor vendor_family;
+
+   const struct ublox_model* model;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -152,38 +155,79 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
ofono_modem_set_powered(modem, TRUE);
 }
 
-static int ublox_enable(struct ofono_modem *modem)
+static void query_model_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
+   struct ofono_modem* modem = user_data;
struct ublox_data *data = ofono_modem_get_data(modem);
-   const char *model_str = NULL;
+   struct ofono_error error;
+   const char *model;
+   const struct ublox_model* m;
+   const char* model_str;
 
-   DBG("%p", modem);
+   decode_at_error(&error, g_at_result_final_response(result));
 
-   model_str = ofono_modem_get_string(modem, "Model");
-   if (model_str == NULL)
-   return -EINVAL;
+   if (!ok)
+   goto fail;
 
-   /*
-* Toby L2 devices are more complex and special than previously
-* supported U-Blox devices. So they need a vendor of their own.
-*/
-   data->model_id = atoi(model_str);
-
-   data->vendor_family = OFONO_VENDOR_UBLOX;
-
-   switch (data->model_id) {
-   case SARA_G270:
-   case TOBYL2_COMPATIBLE_MODE:
-   case TOBYL2_HIGH_THROUGHPUT_MODE:
-   break;
-   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
-   DBG("low/medium throughtput profile unsupported");
-   break;
-   default:
-   DBG("unknown ublox model id %d", data->model_id);
-   return -EINVAL;
+   if (at_util_parse_attr(result, "", &model) == FALSE) {
+   ofono_error("Failed to query modem model");
+   goto fail;
}
 
+   m = ublox_model_from_name(model);
+   if (!m->name) {
+   ofono_error("Unrecognized model: %s", model);
+   goto fail;
+   }
+
+   data->model = m;
+
+   DBG("Model: %s", data->model->name);
+
+   if (data->model->flags & UBLOX_F_TOBY_L2) {
+   model_str = ofono_modem_get_string(modem, "Model");
+   if (!model_str)
+   goto fail;
+
+   /*
+* Toby L2 devices are more complex and special than previously
+* supported U-Blox devices. So they need a vendor of their own.
+*/
+   data->model_id = atoi(model_str);
+
+   switch (data->model_id) {
+   case TOBYL2_COMPATIBLE_MODE:
+   case TOBYL2_HIGH_THROUGHPUT_MODE:
+   break;
+   case TOBYL2_MEDIUM_THROUGHPUT_MODE:
+   DBG("low/medium throughtput profile unsupported");
+   break;
+   default:
+   DBG("unknown ublox model id %d", data->model_id);
+   goto fail;
+   }
+   } else {
+   data->vendor_family = OFONO_VENDOR_UBLOX;
+   }
+
+   if (g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix,
+   cfun_enable, modem, NULL))
+   return;
+
+fail:
+   g_at_chat_unref(data->aux);
+   data->aux = NULL;
+   g_at_chat_unref(data->modem);
+   data->modem = NULL;
+   ofono_modem_set_powered(modem, FALSE);
+}
+
+static int ublox_enable(struct ofono_modem *modem)
+{
+   struct ublox_data *data = ofono_modem_get_data(modem);
+
+   DBG("%p", modem);
+
data->aux = open_device(modem, "Aux", "Aux: ");
/* If this is a serial modem then the device may be behind
 * the 'Device' attribute instead...
@@ -199,7 +243,6 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_set_slave(data->modem, data->aux);
g_at_chat_send(data->modem, "ATE0 +CMEE=1", none_prefix,
NULL, NULL, NULL);
-
g_at_chat_send(data->modem, "AT&C0", NULL, NULL, NULL, NULL);
}
 
@@ -209,10 +252,14 @@ static int ublox_enable(struct ofono_modem *modem)
g_at_chat_send(data->aux, "ATE0 +CMEE=1", none_prefix,
NULL, NULL, NULL);
 
-   g_at_chat_send(data->aux, "

[PATCH 09/14] ublox: add device flags

[Jonas Bonn]

Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one.  This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag.  This is more easily extensible as we
detect other features of the modem.
---
 plugins/ublox.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/plugins/ublox.c b/plugins/ublox.c
index f7c2a374..038b55d5 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -49,20 +49,17 @@
 static const char *uusbconf_prefix[] = { "+UUSBCONF:", NULL };
 static const char *none_prefix[] = { NULL };
 
-enum supported_models {
-   SARA_G270   = 1102,
-   TOBYL2_COMPATIBLE_MODE  = 1141,
-   TOBYL2_MEDIUM_THROUGHPUT_MODE   = 1143,
-   TOBYL2_HIGH_THROUGHPUT_MODE = 1146,
+enum ublox_device_flags {
+   UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE = (1 << 0),
 };
 
 struct ublox_data {
GAtChat *modem;
GAtChat *aux;
-   int model_id;
enum ofono_vendor vendor_family;
 
const struct ublox_model* model;
+   int flags;
 };
 
 static void ublox_debug(const char *str, void *user_data)
@@ -148,7 +145,7 @@ static void cfun_enable(gboolean ok, GAtResult *result, 
gpointer user_data)
return;
}
 
-   if (data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE)
+   if (data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE)
/* use bridged mode until routed mode support is added */
g_at_chat_send(data->aux, "AT+UBMCONF=2", none_prefix,
NULL, NULL, NULL);
@@ -181,13 +178,12 @@ retry:
switch (profile) {
case 0: /* Fairly back compatible */
case 1: /* Fairly back compatible plus audio */
-   data->model_id =  TOBYL2_COMPATIBLE_MODE;
break;
case 2: /* Low/medium throughput */
-   data->model_id = TOBYL2_MEDIUM_THROUGHPUT_MODE;
-   break;
+   ofono_error("Medium throughput mode not supported");
+   goto error;
case 3: /* High throughput mode */
-   data->model_id = TOBYL2_HIGH_THROUGHPUT_MODE;
+   data->flags |= UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE;
break;
default:
ofono_error("Unexpected USB profile: %d", profile);
@@ -389,10 +385,10 @@ static void ublox_post_sim(struct ofono_modem *modem)
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
GAtChat *chat = data->modem ? data->modem : data->aux;
-   const char *driver = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ?
+   const char *driver = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ?
"ubloxmodem" : "atmodem";
/* Toby L2: Create same number of contexts as supported PDP contexts. */
-   int ncontexts = data->model_id == TOBYL2_HIGH_THROUGHPUT_MODE ? 8 : 1;
+   int ncontexts = data->flags & UBLOX_DEVICE_F_HIGH_THROUGHPUT_MODE ? 8 : 
1;
 
DBG("%p", modem);
 
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 02/14] ublox: drop vendor type for Toby L2 model

[Jonas Bonn]

The 'Toby L2'-specific vendor type is used only to prevent the CMER
command from attempting to set mode '3'.  For all u-blox models, mode
'3' is just an alias for mode '1'.  As such, mode '1' can be used in
place of mode '3', removing the model-specific quirk in favour of a
vendor-specific quirk.

With this change, the L2-specific vendor type is no longer needed.
---
 drivers/atmodem/gprs.c | 1 -
 drivers/atmodem/network-registration.c | 7 +--
 drivers/atmodem/sim.c  | 1 -
 drivers/atmodem/vendor.h   | 1 -
 plugins/ublox.c| 7 +++
 5 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index de7c7864..d3fd893c 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -455,7 +455,6 @@ static void gprs_initialized(gboolean ok, GAtResult 
*result, gpointer user_data)
FALSE, gprs, NULL);
break;
case OFONO_VENDOR_UBLOX:
-   case OFONO_VENDOR_UBLOX_TOBY_L2:
g_at_chat_register(gd->chat, "+UREG:", ublox_ureg_notify,
FALSE, gprs, NULL);
g_at_chat_send(gd->chat, "AT+UREG=1", none_prefix,
diff --git a/drivers/atmodem/network-registration.c 
b/drivers/atmodem/network-registration.c
index 1704f98c..ffd8aa33 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -1655,8 +1655,11 @@ static ofono_bool_t build_cmer_string(char *buf, int 
*cmer_opts,
DBG("");
 
switch (nd->vendor) {
-   case OFONO_VENDOR_UBLOX_TOBY_L2:
-   /* UBX-13002752 R33: TOBY L2 doesn't support mode 2 and 3 */
+   case OFONO_VENDOR_UBLOX:
+   /* For all u-blox models, mode 3 is equivalent to mode 1;
+* since some models do not support setting modes 2 nor 3
+* (see UBX-13002752), we prefer mode 1 for all models.
+*/
mode = "1";
break;
default:
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index 51f84818..5f66a09c 100644
--- a/drivers/atmodem/sim.c
+++ b/drivers/atmodem/sim.c
@@ -1221,7 +1221,6 @@ static void at_pin_retries_query(struct ofono_sim *sim,
return;
break;
case OFONO_VENDOR_UBLOX:
-   case OFONO_VENDOR_UBLOX_TOBY_L2:
if (g_at_chat_send(sd->chat, "AT+UPINCNT", upincnt_prefix,
upincnt_cb, cbd, g_free) > 0)
return;
diff --git a/drivers/atmodem/vendor.h b/drivers/atmodem/vendor.h
index cd70c283..10c04315 100644
--- a/drivers/atmodem/vendor.h
+++ b/drivers/atmodem/vendor.h
@@ -46,7 +46,6 @@ enum ofono_vendor {
OFONO_VENDOR_QUECTEL,
OFONO_VENDOR_QUECTEL_M95,
OFONO_VENDOR_UBLOX,
-   OFONO_VENDOR_UBLOX_TOBY_L2,
OFONO_VENDOR_XMM,
OFONO_VENDOR_GEMALTO,
 };
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 2b3fc5eb..4b9d0410 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -169,13 +169,12 @@ static int ublox_enable(struct ofono_modem *modem)
 */
data->model_id = atoi(model_str);
 
+   data->vendor_family = OFONO_VENDOR_UBLOX;
+
switch (data->model_id) {
case SARA_G270:
-   data->vendor_family = OFONO_VENDOR_UBLOX;
-   break;
case TOBYL2_COMPATIBLE_MODE:
case TOBYL2_HIGH_THROUGHPUT_MODE:
-   data->vendor_family = OFONO_VENDOR_UBLOX_TOBY_L2;
break;
case TOBYL2_MEDIUM_THROUGHPUT_MODE:
DBG("low/medium throughtput profile unsupported");
@@ -189,7 +188,7 @@ static int ublox_enable(struct ofono_modem *modem)
if (data->aux == NULL)
return -EINVAL;
 
-   if (data->vendor_family == OFONO_VENDOR_UBLOX) {
+   if (data->model_id == SARA_G270) {
data->modem = open_device(modem, "Modem", "Modem: ");
if (data->modem == NULL) {
g_at_chat_unref(data->aux);
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH 04/14] ublox: create model data structures

[Jonas Bonn]

This sets up some device model data structures and adds some helpers for
manipulating them.  These data structures are a first step to trying to
support the large number of devices that ublox produces with a common
driver structure.
---
 drivers/ubloxmodem/ubloxmodem.c | 55 +
 drivers/ubloxmodem/ubloxmodem.h | 14 +
 2 files changed, 69 insertions(+)

diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index a325b1f0..682b7cea 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/drivers/ubloxmodem/ubloxmodem.c
@@ -33,6 +33,61 @@
 
 #include "ubloxmodem.h"
 
+const struct ublox_model ublox_models[] = {
+   {
+   .name = "SARA-G270",
+   },
+   /* TOBY L2 series */
+   {
+   .name = "TOBY-L200",
+   .flags = UBLOX_F_TOBY_L2,
+   },
+   {
+   .name = "TOBY-L201",
+   .flags = UBLOX_F_TOBY_L2,
+   },
+   {
+   .name = "TOBY-L210",
+   .flags = UBLOX_F_TOBY_L2,
+   },
+   {
+   .name = "TOBY-L220",
+   .flags = UBLOX_F_TOBY_L2,
+   },
+   {
+   .name = "TOBY-L280",
+   .flags = UBLOX_F_TOBY_L2,
+   },
+   { /* sentinal */ },
+};
+
+const struct ublox_model* ublox_model_from_name(const char* name)
+{
+   const struct ublox_model* m;
+
+   for (m = ublox_models; m->name; m++) {
+   if (!strcmp(name, m->name))
+   return m;
+   }
+
+   return NULL;
+}
+
+const struct ublox_model* ublox_model_from_id(int id)
+{
+   return ublox_models + id;
+}
+
+int ublox_model_to_id(const struct ublox_model* model)
+{
+   return model - ublox_models;
+}
+
+int ublox_is_toby_l2(const struct ublox_model* model)
+{
+   return model->flags & UBLOX_F_TOBY_L2;
+}
+
 static int ubloxmodem_init(void)
 {
ublox_gprs_context_init();
diff --git a/drivers/ubloxmodem/ubloxmodem.h b/drivers/ubloxmodem/ubloxmodem.h
index bfb01064..e8f98b40 100644
--- a/drivers/ubloxmodem/ubloxmodem.h
+++ b/drivers/ubloxmodem/ubloxmodem.h
@@ -23,6 +23,20 @@
 
 #define UBLOXMODEM "ubloxmodem"
 
+enum ublox_flags {
+   UBLOX_F_TOBY_L2 = (1 << 0),
+};
+
+struct ublox_model {
+   char* name;
+   int flags;
+};
+
+const struct ublox_model* ublox_model_from_name(const char* name);
+const struct ublox_model* ublox_model_from_id(int id);
+int ublox_model_to_id(const struct ublox_model* model);
+int ublox_is_toby_l2(const struct ublox_model* model);
+
 extern void ublox_gprs_context_init(void);
 extern void ublox_gprs_context_exit(void);
 
-- 
2.19.1

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono