Re: [PATCH v2] sim: validate IMS private identity

2021-01-15 Thread Sergey Matyukevich
Hi Denis,

> > > > Make sure that IMS private identity is a valid UTF8 string before
> > > > setting sim->impi field. Otherwise ofono may crash on dbus assert
> > > > when SIM properties are reported via org.ofono.SimManager interface.
> > > > ---
> > > >src/sim.c | 3 ++-
> > > >1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/sim.c b/src/sim.c
> > > > index 33e1245f..2a663e2d 100644
> > > > --- a/src/sim.c
> > > > +++ b/src/sim.c
> > > > @@ -1664,7 +1664,8 @@ static void impi_read_cb(int ok, int 
> > > > total_length, int record,
> > > > return;
> > > > }
> > > > -   sim->impi = g_strndup((const char *)data + 2, data[1]);
> > > > +   if (g_utf8_validate((const char *)data + 2, data[1], NULL))
> > > > +   sim->impi = g_strndup((const char *)data + 2, data[1]);
> > > 
> > > I assume this code path was tested with a file containing embedded NULs as
> > > that is the only way it would have worked.
> 
> Ignore the last part of the above sentence.  What I'm trying to say is that:
> 
> We in theory have two possibilities:
> 
> 1. file with a string 'foo', no null:
> 0x80 0x03 'f' 'o' 'o'
> 
> 2. file with  a string 'foo' and null:
> 0x80 0x04 'f' 'o' 'o'
> 
> I suspect the spec really wants 1, but maybe it can be interpreted that 2 is
> also a possibility?
> 
> The present logic should work for either of the above, but not what you have, 
> i.e.:
> 
> 0x80 0x03 0xff 0xff 0xff
> 
> > > 
> > > glib docs [1] say:
> > > "Note that g_utf8_validate() returns FALSE if max_len is positive and any 
> > > of
> > > the max_len bytes are nul."
> > > 
> > > So I think the above logic would flag such a file as invalid, no?
> > 
> 
> ...but g_utf8_validate as invoked in this patch would flag possibility 2 as
> invalid...

True. Thanks for detailed clarification. Indeed, both cases needs to be
supported. Let me double-check and come back with v3.

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


Re: [PATCH v2] sim: validate IMS private identity

2021-01-15 Thread Denis Kenzior

Hi Sergey,

On 1/15/21 2:34 PM, Sergey Matyukevich wrote:

Make sure that IMS private identity is a valid UTF8 string before
setting sim->impi field. Otherwise ofono may crash on dbus assert
when SIM properties are reported via org.ofono.SimManager interface.
---
   src/sim.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/sim.c b/src/sim.c
index 33e1245f..2a663e2d 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1664,7 +1664,8 @@ static void impi_read_cb(int ok, int total_length, int 
record,
return;
}
-   sim->impi = g_strndup((const char *)data + 2, data[1]);
+   if (g_utf8_validate((const char *)data + 2, data[1], NULL))
+   sim->impi = g_strndup((const char *)data + 2, data[1]);


I assume this code path was tested with a file containing embedded NULs as
that is the only way it would have worked.


Ignore the last part of the above sentence.  What I'm trying to say is that:

We in theory have two possibilities:

1. file with a string 'foo', no null:
0x80 0x03 'f' 'o' 'o'

2. file with  a string 'foo' and null:
0x80 0x04 'f' 'o' 'o'

I suspect the spec really wants 1, but maybe it can be interpreted that 2 is 
also a possibility?


The present logic should work for either of the above, but not what you have, 
i.e.:

0x80 0x03 0xff 0xff 0xff



glib docs [1] say:
"Note that g_utf8_validate() returns FALSE if max_len is positive and any of
the max_len bytes are nul."

So I think the above logic would flag such a file as invalid, no?




...but g_utf8_validate as invoked in this patch would flag possibility 2 as 
invalid...



No, I tested using modem with attached SIM/eSIM. TLV data object appears
to be well-formed, but the contents is all padding 0xff bytes. Could you
please clarify your concern ? I assume we can not rely on the content
being properly null terminated string.


Yeah, for the case you have this logic works just fine.

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


Re: [PATCH v2] sim: validate IMS private identity

2021-01-15 Thread Sergey Matyukevich
> > Make sure that IMS private identity is a valid UTF8 string before
> > setting sim->impi field. Otherwise ofono may crash on dbus assert
> > when SIM properties are reported via org.ofono.SimManager interface.
> > ---
> >   src/sim.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/sim.c b/src/sim.c
> > index 33e1245f..2a663e2d 100644
> > --- a/src/sim.c
> > +++ b/src/sim.c
> > @@ -1664,7 +1664,8 @@ static void impi_read_cb(int ok, int total_length, 
> > int record,
> > return;
> > }
> > -   sim->impi = g_strndup((const char *)data + 2, data[1]);
> > +   if (g_utf8_validate((const char *)data + 2, data[1], NULL))
> > +   sim->impi = g_strndup((const char *)data + 2, data[1]);
> 
> I assume this code path was tested with a file containing embedded NULs as
> that is the only way it would have worked.
> 
> glib docs [1] say:
> "Note that g_utf8_validate() returns FALSE if max_len is positive and any of
> the max_len bytes are nul."
> 
> So I think the above logic would flag such a file as invalid, no?

No, I tested using modem with attached SIM/eSIM. TLV data object appears
to be well-formed, but the contents is all padding 0xff bytes. Could you
please clarify your concern ? I assume we can not rely on the content
being properly null terminated string.

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


Re: [PATCH v2] sim: validate IMS private identity

2021-01-15 Thread Denis Kenzior

Hi Sergey,

On 1/15/21 1:56 PM, Sergey Matyukevich wrote:

Make sure that IMS private identity is a valid UTF8 string before
setting sim->impi field. Otherwise ofono may crash on dbus assert
when SIM properties are reported via org.ofono.SimManager interface.
---
  src/sim.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/sim.c b/src/sim.c
index 33e1245f..2a663e2d 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1664,7 +1664,8 @@ static void impi_read_cb(int ok, int total_length, int 
record,
return;
}
  
-	sim->impi = g_strndup((const char *)data + 2, data[1]);

+   if (g_utf8_validate((const char *)data + 2, data[1], NULL))
+   sim->impi = g_strndup((const char *)data + 2, data[1]);


I assume this code path was tested with a file containing embedded NULs as that 
is the only way it would have worked.


glib docs [1] say:
"Note that g_utf8_validate() returns FALSE if max_len is positive and any of the 
max_len bytes are nul."


So I think the above logic would flag such a file as invalid, no?


  }
  
  static void discover_apps_cb(const struct ofono_error *error,

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



Regards,
-Denis

[1] 
https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-validate

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


[PATCH v2] sim: validate IMS private identity

2021-01-15 Thread Sergey Matyukevich
Make sure that IMS private identity is a valid UTF8 string before
setting sim->impi field. Otherwise ofono may crash on dbus assert
when SIM properties are reported via org.ofono.SimManager interface.
---
 src/sim.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/sim.c b/src/sim.c
index 33e1245f..2a663e2d 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1664,7 +1664,8 @@ static void impi_read_cb(int ok, int total_length, int 
record,
return;
}
 
-   sim->impi = g_strndup((const char *)data + 2, data[1]);
+   if (g_utf8_validate((const char *)data + 2, data[1], NULL))
+   sim->impi = g_strndup((const char *)data + 2, data[1]);
 }
 
 static void discover_apps_cb(const struct ofono_error *error,
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


Re: [PATCH] sim: validate IMS private identity

2021-01-15 Thread Denis Kenzior

Hi Sergey,


This field may not be defined for ISIM in use. In this case the
field still can be read from ISIM, though it will not contain
a valid UTF8 string. For instance, it may contain 255 0xFF bytes.


Ugh, seems like the SIM vendor can't follow RFC's either?  31.103 Section
4.2.2 says:

"For contents and syntax of NAI TLV data object values see IETF RFC 2486
[24]. The NAI shall be encoded to an octet string according to UTF-8
encoding rules as specified in IETF RFC 3629 [27]. The tag value of the NAI
TLV data object shall be '80'. "


This crash occured during my experiments with eSIM. As I mentioned, the
content of that TLV data object was 0xff bytes. IIUC it looks like vendor
could just skip initialization of that particular TLV data object during
bootstrap. Though I am not yet familiar with eSIM init procedure...



I figured.  The likely reason for this is that SIM strings are generally encoded 
in another format.  If you're interested, see src/util.c sim_string_to_utf8(). 
0xff is used as padding in such cases and thus a field with only 0xffs is 
treated as empty.


However, the  above would seem not to apply to EFimpi and a few others that 3GPP 
wants encoded as a utf-8 string.  So, likely, a bug on the SIM, but we should 
have sanitized the contents better.


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


Re: [PATCH] sim: validate IMS private identity

2021-01-15 Thread Sergey Matyukevich
Hi Denis,

> > Make sure that IMPI is a valid UTF8 string before attempting
> > to report it via DBus. Otherwise ofono may crash on dbus assert.
> > This field may not be defined for ISIM in use. In this case the
> > field still can be read from ISIM, though it will not contain
> > a valid UTF8 string. For instance, it may contain 255 0xFF bytes.
> 
> Ugh, seems like the SIM vendor can't follow RFC's either?  31.103 Section
> 4.2.2 says:
> 
> "For contents and syntax of NAI TLV data object values see IETF RFC 2486
> [24]. The NAI shall be encoded to an octet string according to UTF-8
> encoding rules as specified in IETF RFC 3629 [27]. The tag value of the NAI
> TLV data object shall be '80'. "

This crash occured during my experiments with eSIM. As I mentioned, the
content of that TLV data object was 0xff bytes. IIUC it looks like vendor
could just skip initialization of that particular TLV data object during
bootstrap. Though I am not yet familiar with eSIM init procedure...

> > ---
> >   src/sim.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/sim.c b/src/sim.c
> > index 33e1245f..f60f5d1b 100644
> > --- a/src/sim.c
> > +++ b/src/sim.c
> > @@ -423,7 +423,7 @@ static DBusMessage *sim_get_properties(DBusConnection 
> > *conn,
> > ofono_dbus_dict_append(, "ServiceProviderName",
> > DBUS_TYPE_STRING, >spn);
> > -   if (sim->impi)
> > +   if (sim->impi && g_utf8_validate(sim->impi, 255, NULL))
> 
> Hmm, this would imply that we're setting sim->impi incorrectly..  Also,
> since we have __ofono_sim_get_impi() API, the better fix would be to make
> sure sim->impi is set correctly in impi_read_cb()

Ok. I will set sim->impi in impi_read_cb only if it is a valid UTF8 string.

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


Re: [PATCH v2 3/3] gemalto: netmon measurements scaling

2021-01-15 Thread Sergey Matyukevich
Hello Denis,

> > Gemalto modem reports raw measurements in dBm. Reported values may
> > include negative numbers. Meanwhile oFono follows ETSI TS 27.007,
> > so negative numbers do not really exist at the API level.
> > 
> > Modify gemalto netmon driver to report measurements according to
> > 27.007. For this purpose re-scale from what Gemalto firmware
> > reports into something that 27.007 recommends.
> > ---
> >   drivers/gemaltomodem/netmon.c | 52 ---
> >   1 file changed, 48 insertions(+), 4 deletions(-)
> > 
> 
> I went ahead and applied all three patches after making minor tweaks in this 
> one:

Thanks!

> > +static int gemalto_rscp_scale(int value)
> > +{
> > +   if (value < -120)
> > +   return 0;
> > +
> > +   if (value > -24)
> > +   return 96;
> > +
> > +   return (value + 120);
> 
> The ()s weren't needed here..

Well, I did check coding style document for arithmetic expressions,
but I did not find anything other than spaces around operators. 
So I made a wrong guess...

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


Re: [PATCH] sim: validate IMS private identity

2021-01-15 Thread Denis Kenzior

Hi Sergey,

On 1/15/21 10:38 AM, Sergey Matyukevich wrote:

Make sure that IMPI is a valid UTF8 string before attempting
to report it via DBus. Otherwise ofono may crash on dbus assert.
This field may not be defined for ISIM in use. In this case the
field still can be read from ISIM, though it will not contain
a valid UTF8 string. For instance, it may contain 255 0xFF bytes.


Ugh, seems like the SIM vendor can't follow RFC's either?  31.103 Section 4.2.2 
says:


"For contents and syntax of NAI TLV data object values see IETF RFC 2486 [24]. 
The NAI shall be encoded to an octet string according to UTF-8 encoding rules as 
specified in IETF RFC 3629 [27]. The tag value of the NAI TLV data object shall 
be '80'. "



---
  src/sim.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sim.c b/src/sim.c
index 33e1245f..f60f5d1b 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -423,7 +423,7 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
ofono_dbus_dict_append(, "ServiceProviderName",
DBUS_TYPE_STRING, >spn);
  
-	if (sim->impi)

+   if (sim->impi && g_utf8_validate(sim->impi, 255, NULL))


Hmm, this would imply that we're setting sim->impi incorrectly..  Also, since we 
have __ofono_sim_get_impi() API, the better fix would be to make sure sim->impi 
is set correctly in impi_read_cb()



ofono_dbus_dict_append(, "ImsPrivateIdentity",
DBUS_TYPE_STRING, >impi);
  
___

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



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


Re: [PATCH v2 3/3] gemalto: netmon measurements scaling

2021-01-15 Thread Denis Kenzior

Hi Sergey,

On 1/15/21 10:25 AM, Sergey Matyukevich wrote:

Gemalto modem reports raw measurements in dBm. Reported values may
include negative numbers. Meanwhile oFono follows ETSI TS 27.007,
so negative numbers do not really exist at the API level.

Modify gemalto netmon driver to report measurements according to
27.007. For this purpose re-scale from what Gemalto firmware
reports into something that 27.007 recommends.
---
  drivers/gemaltomodem/netmon.c | 52 ---
  1 file changed, 48 insertions(+), 4 deletions(-)



I went ahead and applied all three patches after making minor tweaks in this 
one:


+static int gemalto_rscp_scale(int value)
+{
+   if (value < -120)
+   return 0;
+
+   if (value > -24)
+   return 96;
+
+   return (value + 120);


The ()s weren't needed here..


+}
+
+static int gemalto_rsrp_scale(int value)
+{
+   if (value < -140)
+   return 0;
+
+   if (value > -43)
+   return 97;
+
+   return (value + 140);


here and ...


+}
+
+static int gemalto_rsrq_scale(int value)
+{
+   if (2 * value < -39)
+   return 0;
+
+   if (2 * value > -5)
+   return 34;
+
+   return (2 * value + 39);


here


+}
+
  static int gemalto_parse_smoni_gsm(GAtResultIter *iter,
struct req_cb_data *cbd)
  {
@@ -273,13 +317,13 @@ static int gemalto_parse_smoni_umts(GAtResultIter *iter,
case SMONI_UMTS_ECN0:
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%f", ) == 1)
-   cbd->t.umts.ecno = (int)fnumber;
+   cbd->t.umts.ecno = 
gemalto_ecno_scale((int)fnumber);


Also added a line break to better wrap to 80 char columns here...


}
break;
case SMONI_UMTS_RSCP:
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%d", ) == 1)
-   cbd->t.umts.rscp = number;
+   cbd->t.umts.rscp = 
gemalto_rscp_scale(number);


and here


}
break;
case SMONI_UMTS_MCC:


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


[PATCH] sim: validate IMS private identity

2021-01-15 Thread Sergey Matyukevich
Make sure that IMPI is a valid UTF8 string before attempting
to report it via DBus. Otherwise ofono may crash on dbus assert.
This field may not be defined for ISIM in use. In this case the
field still can be read from ISIM, though it will not contain
a valid UTF8 string. For instance, it may contain 255 0xFF bytes.
---
 src/sim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sim.c b/src/sim.c
index 33e1245f..f60f5d1b 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -423,7 +423,7 @@ static DBusMessage *sim_get_properties(DBusConnection *conn,
ofono_dbus_dict_append(, "ServiceProviderName",
DBUS_TYPE_STRING, >spn);
 
-   if (sim->impi)
+   if (sim->impi && g_utf8_validate(sim->impi, 255, NULL))
ofono_dbus_dict_append(, "ImsPrivateIdentity",
DBUS_TYPE_STRING, >impi);
 
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


[PATCH v2 3/3] gemalto: netmon measurements scaling

2021-01-15 Thread Sergey Matyukevich
Gemalto modem reports raw measurements in dBm. Reported values may
include negative numbers. Meanwhile oFono follows ETSI TS 27.007,
so negative numbers do not really exist at the API level.

Modify gemalto netmon driver to report measurements according to
27.007. For this purpose re-scale from what Gemalto firmware
reports into something that 27.007 recommends.
---
 drivers/gemaltomodem/netmon.c | 52 ---
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/drivers/gemaltomodem/netmon.c b/drivers/gemaltomodem/netmon.c
index ddaebf1a..c3a0498d 100644
--- a/drivers/gemaltomodem/netmon.c
+++ b/drivers/gemaltomodem/netmon.c
@@ -128,6 +128,50 @@ static gboolean gemalto_delayed_register(gpointer 
user_data)
return FALSE;
 }
 
+static int gemalto_ecno_scale(int value)
+{
+   if (value < -24)
+   return 0;
+
+   if (value > 0)
+   return 49;
+
+   return 49 * (value + 24) / 24;
+}
+
+static int gemalto_rscp_scale(int value)
+{
+   if (value < -120)
+   return 0;
+
+   if (value > -24)
+   return 96;
+
+   return (value + 120);
+}
+
+static int gemalto_rsrp_scale(int value)
+{
+   if (value < -140)
+   return 0;
+
+   if (value > -43)
+   return 97;
+
+   return (value + 140);
+}
+
+static int gemalto_rsrq_scale(int value)
+{
+   if (2 * value < -39)
+   return 0;
+
+   if (2 * value > -5)
+   return 34;
+
+   return (2 * value + 39);
+}
+
 static int gemalto_parse_smoni_gsm(GAtResultIter *iter,
struct req_cb_data *cbd)
 {
@@ -273,13 +317,13 @@ static int gemalto_parse_smoni_umts(GAtResultIter *iter,
case SMONI_UMTS_ECN0:
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%f", ) == 1)
-   cbd->t.umts.ecno = (int)fnumber;
+   cbd->t.umts.ecno = 
gemalto_ecno_scale((int)fnumber);
}
break;
case SMONI_UMTS_RSCP:
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%d", ) == 1)
-   cbd->t.umts.rscp = number;
+   cbd->t.umts.rscp = 
gemalto_rscp_scale(number);
}
break;
case SMONI_UMTS_MCC:
@@ -368,12 +412,12 @@ static int gemalto_parse_smoni_lte(GAtResultIter *iter,
 
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%d", ) == 1)
-   cbd->t.lte.rsrp = number;
+   cbd->t.lte.rsrp = gemalto_rsrp_scale(number);
}
 
if (g_at_result_iter_next_unquoted_string(iter, )) {
if (sscanf(str, "%d", ) == 1)
-   cbd->t.lte.rsrq = number;
+   cbd->t.lte.rsrq = gemalto_rsrq_scale(number);
}
 
DBG(" %-15s %s", "LTE.MCC", cbd->op.mcc);
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


[PATCH v2 2/3] plugin: gemalto: enable netmon

2021-01-15 Thread Sergey Matyukevich
Enable netmon functionality for Gemalto ELS81x modems.
---
 plugins/gemalto.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/plugins/gemalto.c b/plugins/gemalto.c
index 28ee3aff..135e2d26 100644
--- a/plugins/gemalto.c
+++ b/plugins/gemalto.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -622,6 +623,7 @@ static void gemalto_post_sim(struct ofono_modem *modem)
 static void gemalto_post_online(struct ofono_modem *modem)
 {
struct gemalto_data *data = ofono_modem_get_data(modem);
+   const char *model = ofono_modem_get_string(modem, "Model");
 
DBG("%p", modem);
 
@@ -634,6 +636,10 @@ static void gemalto_post_online(struct ofono_modem *modem)
ofono_call_settings_create(modem, 0, "atmodem", data->app);
ofono_call_meter_create(modem, 0, "atmodem", data->app);
ofono_call_barring_create(modem, 0, "atmodem", data->app);
+
+   if (!g_strcmp0(model, GEMALTO_MODEL_ELS81x))
+   ofono_netmon_create(modem, OFONO_VENDOR_GEMALTO,
+   "gemaltomodem", data->app);
 }
 
 static struct ofono_modem_driver gemalto_driver = {
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org


[PATCH v2 1/3] gemalto: add netmon driver

2021-01-15 Thread Sergey Matyukevich
Implement network monitoring driver for gemalto modems that
are able to provide serving cell information and basic
measurements using AT+CQS and AT^SMONI commands.
---
 Makefile.am |   3 +-
 drivers/gemaltomodem/gemaltomodem.c |   2 +
 drivers/gemaltomodem/gemaltomodem.h |   3 +
 drivers/gemaltomodem/netmon.c   | 605 
 4 files changed, 612 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gemaltomodem/netmon.c

diff --git a/Makefile.am b/Makefile.am
index c0631081..5e7614c1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -483,7 +483,8 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/gemaltomodem/gemaltomodem.c \
drivers/gemaltomodem/location-reporting.c \
drivers/gemaltomodem/voicecall.c \
-   drivers/gemaltomodem/gprs-context.c
+   drivers/gemaltomodem/gprs-context.c \
+   drivers/gemaltomodem/netmon.c
 
 builtin_modules += xmm7modem
 builtin_sources += drivers/atmodem/atutil.h \
diff --git a/drivers/gemaltomodem/gemaltomodem.c 
b/drivers/gemaltomodem/gemaltomodem.c
index 4b20dd1b..f7e4ff3e 100644
--- a/drivers/gemaltomodem/gemaltomodem.c
+++ b/drivers/gemaltomodem/gemaltomodem.c
@@ -38,6 +38,7 @@ static int gemaltomodem_init(void)
gemalto_location_reporting_init();
gemalto_gprs_context_init();
gemalto_voicecall_init();
+   gemalto_netmon_init();
 
return 0;
 }
@@ -47,6 +48,7 @@ static void gemaltomodem_exit(void)
gemalto_location_reporting_exit();
gemalto_gprs_context_exit();
gemalto_voicecall_exit();
+   gemalto_netmon_exit();
 }
 
 OFONO_PLUGIN_DEFINE(gemaltomodem, "Gemalto modem driver", VERSION,
diff --git a/drivers/gemaltomodem/gemaltomodem.h 
b/drivers/gemaltomodem/gemaltomodem.h
index dc0d346b..ae8f2141 100644
--- a/drivers/gemaltomodem/gemaltomodem.h
+++ b/drivers/gemaltomodem/gemaltomodem.h
@@ -30,3 +30,6 @@ extern void gemalto_voicecall_exit();
 
 extern void gemalto_gprs_context_init();
 extern void gemalto_gprs_context_exit();
+
+extern void gemalto_netmon_init(void);
+extern void gemalto_netmon_exit(void);
diff --git a/drivers/gemaltomodem/netmon.c b/drivers/gemaltomodem/netmon.c
new file mode 100644
index ..ddaebf1a
--- /dev/null
+++ b/drivers/gemaltomodem/netmon.c
@@ -0,0 +1,605 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  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 
+#include 
+#include 
+
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include "common.h"
+#include "gemaltomodem.h"
+#include "drivers/atmodem/vendor.h"
+
+static const char *smoni_prefix[] = { "^SMONI:", NULL };
+static const char *csq_prefix[] = { "+CSQ:", NULL };
+
+struct netmon_driver_data {
+   GAtChat *chat;
+};
+
+struct req_cb_data {
+   gint ref_count; /* Ref count */
+
+   struct ofono_netmon *netmon;
+   ofono_netmon_cb_t cb;
+   void *data;
+
+   struct ofono_network_operator op;
+
+   int rssi;   /* CSQ: received signal strength indicator (RSSI) */
+
+   union {
+   struct {
+   int arfcn;  /* SMONI: Absolute Radio Frequency 
Channel Number */
+   int bcch;   /* SMONI: Receiving level of the BCCH 
carrier in dBm */
+   int lac;/* SMONI: Location Area Code */
+   int ci; /* SMONI: Cell ID */
+   } gsm;
+   struct {
+   int uarfcn; /* SMONI: UTRAN Absolute Radio 
Frequency Channel Number */
+   int psc;/* SMONI: Primary Scrambling Code */
+   int ecno;   /* SMONI: Carrier to noise ratio in dB 
*/
+   int rscp;   /* SMONI: Received Signal Code Power in 
dBm */
+   int lac;/* SMONI: Location Area Code */
+   int ci; /* SMONI: Cell ID */
+   } umts;
+   struct {
+   int euarfcn;/* SMONI: E-UTRA Absolute Radio 
Frequency Channel Number */
+   int rsrp;   /* SMONI: Reference Signal 

[PATCH v2 0/3] gemalto: netmon driver

2021-01-15 Thread Sergey Matyukevich
Hello Denis and all,

This patch series implements netmon driver for gemalto modems that are
able to provide basic measurements using AT+CQS and AT^SMONI commands.
For now netmon driver is enabled for ELS81x modems.

Regards,
Sergey

v1 -> v2

- use g_new0 instead of g_try_new0
- remove rssi scaling: keep using 27.007 range
- scale modem measurement reports to ranges recommended by 27.007

Sergey Matyukevich (3):
  gemalto: add netmon driver
  plugin: gemalto: enable netmon
  gemalto: netmon measurements scaling

 Makefile.am |   3 +-
 drivers/gemaltomodem/gemaltomodem.c |   2 +
 drivers/gemaltomodem/gemaltomodem.h |   3 +
 drivers/gemaltomodem/netmon.c   | 649 
 plugins/gemalto.c   |   6 +
 5 files changed, 662 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gemaltomodem/netmon.c
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org