[PATCH 0/3] Huawei E1552 hacks

[PATCH 0/3] Huawei E1552 hacks

[Kalle Valo]

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

Hello,

I did a quick hack to get my Huawei E1552 working with ofono. Here are
three small patches which was needed to get the modem working.

I would like to get Huawei gprs support to ofono, but I understand
that these patches are not acceptable. I would appreciate to get some
feedback how to properly implement Huawei support.

---

Kalle Valo (3):
      huawei: add gprs context
      atmodem: add a huawei hack to check attachment status
      atmodem: add signal strength support for huawei


 drivers/atmodem/gprs.c                 |   51 ++++++++++++++++++++++++++++++++
 drivers/atmodem/network-registration.c |    1 +
 plugins/huawei.c                       |   10 ++++++
 3 files changed, 62 insertions(+), 0 deletions(-)

[PATCH 1/3] atmodem: add signal strength support for huawei

[Kalle Valo]

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

Huawei doesn't support CIND indications, so use CSQ instead. But naturally
the response from modem is not according to standard:

ofonod[6401]: < \r\n^BOOT:38645652,0,0,0,87\r\n
ofonod[6401]: < \r\n^RSSI:23\r\n

Support for this format is not yet implemented.
---

 drivers/atmodem/network-registration.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c
index f7aafbe..1c2b583 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -849,6 +849,7 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data)
 
 	switch (nd->vendor) {
 	case OFONO_VENDOR_PHONESIM:
+	case OFONO_VENDOR_HUAWEI:
 		g_at_chat_register(nd->chat, "+CSQ:",
 					csq_notify, FALSE, netreg, NULL);
 

[PATCH 2/3] atmodem: add a huawei hack to check attachment status

[Kalle Valo]

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

Huawei doesn't seem to send CGREG notifications (or I wasn't able to
properly configure the modem to do it), so add an ugly to hack poll the
state with CGATT.
---

 drivers/atmodem/gprs.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 052417a..41dced2 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -43,13 +43,17 @@
 
 static const char *cgreg_prefix[] = { "+CGREG:", NULL };
 static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL };
+static const char *cgatt_prefix[] = { "+CGATT:", NULL };
 static const char *none_prefix[] = { NULL };
 
 struct gprs_data {
 	GAtChat *chat;
 	unsigned int vendor;
+	guint cgatt_timer;
 };
 
+static void at_poll_cgatt(struct ofono_gprs *grps);
+
 static void at_cgatt_cb(gboolean ok, GAtResult *result, gpointer user_data)
 {
 	struct cb_data *cbd = user_data;
@@ -165,6 +169,50 @@ static void cgev_notify(GAtResult *result, gpointer user_data)
 	}
 }
 
+
+static gboolean at_poll_cgatt_timeout(gpointer user_data)
+{
+	struct ofono_gprs *gprs = user_data;
+
+	at_poll_cgatt(gprs);
+
+	return FALSE;
+}
+
+static void at_poll_cgatt_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+	struct ofono_gprs *gprs = user_data;
+	struct gprs_data *gd = ofono_gprs_get_data(gprs);
+	GAtResultIter iter;
+	int status;
+
+	if (!ok)
+		return;
+
+	g_at_result_iter_init(&iter, result);
+
+	if (!g_at_result_iter_next(&iter, "+CGATT:"))
+		return;
+
+	if (!g_at_result_iter_next_number(&iter, &status))
+		return;
+
+	if (status > 0) {
+		ofono_gprs_status_notify(gprs, status);
+		return;
+	}
+
+	gd->cgatt_timer = g_timeout_add(1000, at_poll_cgatt_timeout, gprs);
+}
+
+static void at_poll_cgatt(struct ofono_gprs *gprs)
+{
+	struct gprs_data *gd = ofono_gprs_get_data(gprs);
+
+	g_at_chat_send(gd->chat, "AT+CGATT?", cgatt_prefix, at_poll_cgatt_cb,
+		       gprs, NULL);
+}
+
 static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data)
 {
 	struct ofono_gprs *gprs = user_data;
@@ -175,6 +223,8 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data)
 				FALSE, gprs, NULL);
 
 	ofono_gprs_register(gprs);
+
+	at_poll_cgatt(gprs);
 }
 
 static void at_cgreg_test_cb(gboolean ok, GAtResult *result,
@@ -310,6 +360,7 @@ static void at_gprs_remove(struct ofono_gprs *gprs)
 {
 	struct gprs_data *gd = ofono_gprs_get_data(gprs);
 
+	g_source_remove(gd->cgatt_timer);
 	ofono_gprs_set_data(gprs, NULL);
 	g_free(gd);
 }

[PATCH 3/3] huawei: add gprs context

[Kalle Valo]

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

Tested with Huawei E1552 HSDPA USB stick using a finnish Saunalahti prepaid
SIM.
---

 plugins/huawei.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/plugins/huawei.c b/plugins/huawei.c
index 90fdcf0..fd1528f 100644
--- a/plugins/huawei.c
+++ b/plugins/huawei.c
@@ -41,6 +41,8 @@
 #include <ofono/gprs.h>
 #include <ofono/voicecall.h>
 #include <ofono/log.h>
+#include <ofono/gprs.h>
+#include <ofono/gprs-context.h>
 
 #include <drivers/atmodem/vendor.h>
 
@@ -178,11 +180,19 @@ static void huawei_pre_sim(struct ofono_modem *modem)
 static void huawei_post_sim(struct ofono_modem *modem)
 {
 	struct huawei_data *data = ofono_modem_get_data(modem);
+	struct ofono_gprs_context *gc;
+	struct ofono_gprs *gprs;
 
 	DBG("%p", modem);
 
 	ofono_netreg_create(modem, OFONO_VENDOR_HUAWEI, "atmodem", data->chat);
 	ofono_sms_create(modem, OFONO_VENDOR_QUALCOMM_MSM, "atmodem", data->chat);
+
+	gprs = ofono_gprs_create(modem, 0, "atmodem", data->chat);
+	gc = ofono_gprs_context_create(modem, 0, "atmodem", data->chat);
+
+	if (gprs && gc)
+		ofono_gprs_add_context(gprs, gc);
 }
 
 static struct ofono_modem_driver huawei_driver = {

Re: [PATCH 1/3] atmodem: add signal strength support for huawei

[Marcel Holtmann]

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

Hi Kalle,

> Huawei doesn't support CIND indications, so use CSQ instead. But naturally
> the response from modem is not according to standard:

is this true for all Huawei modems?

> ofonod[6401]: < \r\n^BOOT:38645652,0,0,0,87\r\n
> ofonod[6401]: < \r\n^RSSI:23\r\n
> 
> Support for this format is not yet implemented.

You see these on the same TTY? Normally they happen on the second TTY.

Regards

Marcel

Re: [PATCH 2/3] atmodem: add a huawei hack to check attachment status

[Marcel Holtmann]

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

Hi Kalle,

> Huawei doesn't seem to send CGREG notifications (or I wasn't able to
> properly configure the modem to do it), so add an ugly to hack poll the
> state with CGATT.

shouldn't be polling AT+CGREG? the better way to do this?

Regards

Marcel

Re: [PATCH 3/3] huawei: add gprs context

[Marcel Holtmann]

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

Hi Kalle,

> Tested with Huawei E1552 HSDPA USB stick using a finnish Saunalahti prepaid
> SIM.
> ---
> 
>  plugins/huawei.c |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/plugins/huawei.c b/plugins/huawei.c
> index 90fdcf0..fd1528f 100644
> --- a/plugins/huawei.c
> +++ b/plugins/huawei.c
> @@ -41,6 +41,8 @@
>  #include <ofono/gprs.h>
>  #include <ofono/voicecall.h>
>  #include <ofono/log.h>
> +#include <ofono/gprs.h>
> +#include <ofono/gprs-context.h>
>  
>  #include <drivers/atmodem/vendor.h>
>  
> @@ -178,11 +180,19 @@ static void huawei_pre_sim(struct ofono_modem *modem)
>  static void huawei_post_sim(struct ofono_modem *modem)
>  {
>  	struct huawei_data *data = ofono_modem_get_data(modem);
> +	struct ofono_gprs_context *gc;
> +	struct ofono_gprs *gprs;
>  
>  	DBG("%p", modem);
>  
>  	ofono_netreg_create(modem, OFONO_VENDOR_HUAWEI, "atmodem", data->chat);
>  	ofono_sms_create(modem, OFONO_VENDOR_QUALCOMM_MSM, "atmodem", data->chat);
> +
> +	gprs = ofono_gprs_create(modem, 0, "atmodem", data->chat);
> +	gc = ofono_gprs_context_create(modem, 0, "atmodem", data->chat);
> +
> +	if (gprs && gc)
> +		ofono_gprs_add_context(gprs, gc);
>  }

this patch is obviously correct if the PPP part and generic GPRS context
support is working correct. I haven't had time to verify that yet. So
far we only used gsmdial for testing.

Regards

Marcel

Re: [PATCH 1/3] atmodem: add signal strength support for huawei

[Kalle Valo]

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

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Kalle,

Hi Marcel,

>> Huawei doesn't support CIND indications, so use CSQ instead. But naturally
>> the response from modem is not according to standard:
>
> is this true for all Huawei modems?

I only have one modem, so I can't tell. I'll do some research and get
back on this.

>> ofonod[6401]: < \r\n^BOOT:38645652,0,0,0,87\r\n
>> ofonod[6401]: < \r\n^RSSI:23\r\n
>> 
>> Support for this format is not yet implemented.
>
> You see these on the same TTY? Normally they happen on the second TTY.

Actually I didn't check that. I'll investigate more.

-- 
Kalle Valo

Re: [PATCH 2/3] atmodem: add a huawei hack to check attachment status

[Kalle Valo]

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

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Kalle,

Hi Marcel,

>> Huawei doesn't seem to send CGREG notifications (or I wasn't able to
>> properly configure the modem to do it), so add an ugly to hack poll the
>> state with CGATT.
>
> shouldn't be polling AT+CGREG? the better way to do this?

Most probably, I'll try with that command and test how it goes.

But is polling acceptable way to do this? And is there anything else I
could do except poll? I'm open to all suggestions.

-- 
Kalle Valo

Re: [PATCH 2/3] atmodem: add a huawei hack to check attachment status

[Denis Kenzior]

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

Hi Kalle,

> Marcel Holtmann <marcel@holtmann.org> writes:
> > Hi Kalle,
> 
> Hi Marcel,
> 
> >> Huawei doesn't seem to send CGREG notifications (or I wasn't able to
> >> properly configure the modem to do it), so add an ugly to hack poll the
> >> state with CGATT.
> >
> > shouldn't be polling AT+CGREG? the better way to do this?
> 
> Most probably, I'll try with that command and test how it goes.
> 
> But is polling acceptable way to do this? And is there anything else I
> could do except poll? I'm open to all suggestions.
> 

These devices are sometimes quite weird, especially if they have multiple 
ports.  Sometimes unsolicited notifications are not sent to a particular port, 
and that port is for control only.  This could be the case here...

Regards,
-Denis

Re: [PATCH 1/3] atmodem: add signal strength support for huawei

[Denis Kenzior]

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

Hi Kalle,

> >> Huawei doesn't support CIND indications, so use CSQ instead. But
> >> naturally the response from modem is not according to standard:
> >
> > is this true for all Huawei modems?
> 

CSQ is not unsolicited, so you'd need to poll it.  Not a good idea.

> >> ofonod[6401]: < \r\n^BOOT:38645652,0,0,0,87\r\n
> >> ofonod[6401]: < \r\n^RSSI:23\r\n

I suggest you simply support this ^RSSI notification, it looks like it has the 
same 0-31 range as CSQ.  Also, sometimes values from vendor-specific commands 
differ from CSQ, so if a query of ^RSSI is supported, use that.

> Actually I didn't check that. I'll investigate more.
> 

ModemManager has done more work integrating ppp devices, poking around there 
can get you some hints.

Regards,
-Denis

Re: [PATCH 2/3] atmodem: add a huawei hack to check attachment status

[Kalle Valo]

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

Denis Kenzior <denkenz@gmail.com> writes:

>> > shouldn't be polling AT+CGREG? the better way to do this?
>> 
>> Most probably, I'll try with that command and test how it goes.
>> 
>> But is polling acceptable way to do this? And is there anything else I
>> could do except poll? I'm open to all suggestions.
>> 
>
> These devices are sometimes quite weird, especially if they have multiple 
> ports.  Sometimes unsolicited notifications are not sent to a particular port, 
> and that port is for control only.  This could be the case here...

Bingo! I did some testing with cgatt and saw this on the third serial
interface:

^BOOT:38645652,0,0,0,87                                                         
                                                                                
^RSSI:18                                                                        
                                                                                
+CGREG: 0,00,0                                                                  
                                                                                
^RSSI:18                                                                        
                                                                                
^RSSI:18                                                                        
                                                                                
^RSSI:18                                                                        
                                                                                
^RSSI:15                                                                        
                                                                                
+CGREG: 1,5AA,5578                                                              
                                                                                
^RSSI:18                                         

I'll cook up something to use this.

-- 
Kalle Valo

Re: [PATCH 1/3] atmodem: add signal strength support for huawei

[Kalle Valo]

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

Denis Kenzior <denkenz@gmail.com> writes:

> Hi Kalle,

Hi Denis,

>> >> Huawei doesn't support CIND indications, so use CSQ instead. But
>> >> naturally the response from modem is not according to standard:
>> >
>> > is this true for all Huawei modems?
>> 
>
> CSQ is not unsolicited, so you'd need to poll it.  Not a good idea.

Agreed.

>> >> ofonod[6401]: < \r\n^BOOT:38645652,0,0,0,87\r\n
>> >> ofonod[6401]: < \r\n^RSSI:23\r\n
>
> I suggest you simply support this ^RSSI notification, it looks like it
> has the same 0-31 range as CSQ. Also, sometimes values from
> vendor-specific commands differ from CSQ, so if a query of ^RSSI is
> supported, use that.

I'll do that.

Thank you for the help.

-- 
Kalle Valo