[PATCH resend] test/list-modems : print Strength as an integer

[Benoît Monin]

org.ofono.NetworkRegistration property Strength is an integer,
so print it as such.
---
 test/list-modems |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/test/list-modems b/test/list-modems
index 557efd5..8c075ac 100755
--- a/test/list-modems
+++ b/test/list-modems
@@ -51,7 +51,8 @@ for path, properties in modems:
elif key in ["MobileNetworkCodeLength",
"VoicemailMessageCount",
"MicrophoneVolume",
-   "SpeakerVolume"]:
+   "SpeakerVolume",
+   "Strength"]:
val = int(properties[key])
elif key in ["MainMenu"]:
val = ", ".join([ text + " (" + str(int(icon)) +
-- 
1.7.1

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH] test/list-modems : print Strength as an integer

[Benoît Monin]

Hi Denis,

Le vendredi 17 décembre 2010 01:56:48 Denis Kenzior, vous avez écrit :
[snip]
> Can you make sure to configure your MTA agent correctly?
> 
Duh, my dog ate my patch, again.
Sorry about that, resending now.

--
Cheers,
Benoît.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] test/list-modems : print Strength as an integer

[Benoît Monin]

org.ofono.NetworkRegistration property Strength is an integer,
so print it as such.
---
 test/list-modems     3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/test/list-modems b/test/list-modems
index 557efd5..8c075ac 100755
--- a/test/list-modems
+++ b/test/list-modems
@@ -51,7 +51,8 @@ for path, properties in modems:
 elif key in ["MobileNetworkCodeLength",
 "VoicemailMessageCount",
 "MicrophoneVolume",
- "SpeakerVolume"]:
+ "SpeakerVolume",
+ "Strength"]:
 val = int(properties[key])
 elif key in ["MainMenu"]:
 val = ", ".join([ text + " (" + str(int(icon)) +
-- 
1.7.0.3

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

What should happen after losing and retrieving gsm signal ?

[Benoît Monin]

Hi,

I'm trying to re-establish a 3G connection after a gsm signal loss and
I'm getting some pretty strange results.

So first, some short and general questions : What should happen after
going off gsm coverage and back again ?
In particular, is ofono taking care of the network registration or
does it need a manual call org.ofono.NetworkRegistration.Register ?
Also, is ofono reactivating a previously activated context or does it
needs a manual call ?

I'm running my tests on the following platform :
    - Atom Z520 based.
    - 2 ethernet
    - 2 gsm modem: Option GTM382, usb ID 0af0:7601, firmware 2.9.4.0Hd
    - 1 wlan ath9k (unused for the tests)

Software side:
    - linux 2.6.35.9
    - connman 0.64
    - ofono 0.36
    - dbus 1.2.20

I'm using only one modem and I have a variable antenna attenuator to
simulate gsm signal loss/retrieval. The device is not moving and the
signal strength is around 60% without attenuation. The sim card used
is configured with a dedicated password authenticated APN connected
to our internal network through vpn. The context is created before
the first test. Then the sequence of my test is as follow:
    - power-up device
    - call activate_context (no antenna attenuation)
    - Set attenuator to the max (-60dB)
    - Set attenuator back to 0
    - call activate_context again

I'm getting some mixed results:
 * connman crash (sig11) when stopping attenuation
 or reactivating context:
    This is obviously a connman bug (will post backtrace to connman
    ml), but after connman is restarted, the modem service does not
    appear and I have to restart both connman and ofono. Is there a
    startup dependency between connman and ofono ?

 * Network Registration stays in registered state with
 strength = 0 :
    This happens with attenuation set to -60dB. I haven't been able
    to catch some debug traces with AT_DEBUG on. I've waited one hour
    and nothing else happened.

 * Network Registration stays in searching state with
 strength != 0 :
    This happens after setting attenuator back to 0dB. I also don't
    have debug traces for this case. After waiting 15 minutes, I
    called the method org.ofono.NetworkRegistration.Register and
    things went back to normal.

 * Calling activate_context exits with timeout :
    This is the most common case, debug trace below shows that the
    modem never sends the _OWANCALL callback. After waiting more than
    an hour, I restarted ofono and called activate_context, it worked.

(actual apn, username and password have been replaced)
2010-12-06_16:44:15.28570 user.notice: test: reactivate context
2010-12-06_16:44:15.36944 daemon.info: ofonod[1109]: Control: > 
AT$QCPDPP=1,1,"password","username"\r
2010-12-06_16:44:15.44620 daemon.info: ofonod[1109]: Control: < \r\nOK\r\n
2010-12-06_16:44:15.44636 daemon.info: ofonod[1109]: Control: > 
AT+CGDCONT=1,"IP","apn"\r
2010-12-06_16:44:15.45019 daemon.info: ofonod[1109]: App: < \r\n_OSIGQ: 14,0\r\n
2010-12-06_16:44:15.47923 daemon.info: ofonod[1109]: Control: < \r\nOK\r\n
2010-12-06_16:44:15.47938 daemon.info: ofonod[1109]: Control: > 
AT_OWANCALL=1,1,1\r
2010-12-06_16:44:15.48118 daemon.info: ofonod[1109]: Control: < \r\nOK\r\n
2010-12-06_16:44:24.42033 daemon.info: ofonod[1109]: App: < \r\n_OSIGQ: 16,0\r\n
2010-12-06_16:44:27.42032 daemon.info: ofonod[1109]: App: < \r\n_OSIGQ: 17,0\r\n
2010-12-06_16:44:33.42032 daemon.info: ofonod[1109]: App: < \r\n_OSIGQ: 16,0\r\n
2010-12-06_16:44:42.41933 daemon.info: ofonod[1109]: App: < \r\n_OSIGQ: 17,0\r\n
...

I can run some other tests and provide full logs if needed, Do you
think there is something wrong with the test I'm running ?
Might the modem be at fault ?

--
Thanks for reading so far,
Benoît.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH] hso: Set modem name based on udev network interface name

[Benoît Monin]

Hi Marcel,
[Sorry for the delay]

Le lundi 25 octobre 2010 14:15:55 Marcel Holtmann, vous avez écrit :
> actually do you get the serial number from the USB descriptors?
> 
No, the serial number comes from an AT command, I guess.

> oFono does not have the concept of physical devices actually. We moved
> away from dealing with specific modem hardware for a reason. oFono is
> based around a SIM card.
> 
> However we did allow the object path of the modem to be unique, but for
> that, the udev plugin needs to know it. And in your case the modem needs
> to have proper USB descriptors for that.
> 
I checked with udevadm info, ID_SERIAL_SHORT is not set and ID_SERIAL
is "Option_N.V._Globetrotter_HSUPA_Modem" for both modem. So I simply set
ID_SERIAL_SHORT to what I wanted with an udev rule. 

Thank you for pointing me to udev and please discard my patch.

--
Cordially,
Benoît.


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH] hso: Set modem name based on udev network interface name

[Benoît Monin]

Hi Marcel,

> De : Marcel Holtmann
> 
> Hi Benoit,
> 
> the friendly modem name is for devices that do have a friendly name,
> like Bluetooth headsets. Why do you wanna misuse the interface name
> here. I am a bit against this, because it leads to speculation and
> assumptions in userspace programs.
> 
Maybe I should give some details of what I'm trying to achieve. The
device we're building has 2 identical modems with fixed position on
USB. We also have the possibility to drive their power supply
independently and to swap the sim cards.

I need a way to know which one is modem A and which one is modem B
and I have no easy way of knowing the modem serial number or the
sim subscriber id beforehand. With an udev rule, I can easily set
a fixed name for the network interface of each modem. But under
ofono, I can't tell which modem is which. That's why I added this
"not-so-friendly" name.

Is there a way of knowing which physical modem ofono is refering to ?
I recognize that our case may not be the most common and I understand
that you don't want to abuse the Name property. Maybe exposing the
NetworkInterface as a modem property would be ok ? or exposing
a PhysicalName ?

--
Benoît.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH] hso: Set modem name based on udev network interface name

[Benoît Monin]

Hi Denis,

> De : Denis Kenzior
> 
> Hi Benoît,
> 
> I prefer you do this in plugins/hso and not in udev.
> 
Is the patch below correct ? I moved the call to set_name
to hso_probe.

Benoît
--
Subject: [PATCH] hso: Set modem name based on udev network interface name

Useful if you have multiple identical modems and you need a way
to know which modem you're talking to.
---
 plugins/hso.c |    6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/plugins/hso.c b/plugins/hso.c
index 055c63b..a9fb1ba 100644
--- a/plugins/hso.c
+++ b/plugins/hso.c
@@ -59,6 +59,7 @@ struct hso_data {
 static int hso_probe(struct ofono_modem *modem)
 {
        struct hso_data *data;
+       const char *interface;

        DBG("%p", modem);

@@ -68,6 +69,11 @@ static int hso_probe(struct ofono_modem *modem)

        ofono_modem_set_data(modem, data);

+       /* Set name based on network interface name */
+       interface = ofono_modem_get_string(modem, "NetworkInterface");
+       if (interface)
+               ofono_modem_set_name(modem, interface);
+
        return 0;
 }

--
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Re: [PATCH] common : bring back some details about technology

[Benoît Monin]

Hi Aki,

> De : Aki Niemi
> 
> Hi,
> 
> 2010/10/21 "Benoît Monin" :
> > diff --git a/src/common.c b/src/common.c
> > index b5b9a6f..d571d81 100644
> > --- a/src/common.c
> > +++ b/src/common.c
> > @@ -655,15 +655,15 @@ const char *registration_tech_to_string(int tech)
> >         case ACCESS_TECHNOLOGY_GSM:
> >                 return "gsm";
> >         case ACCESS_TECHNOLOGY_GSM_COMPACT:
> > -               return "gsm";
> > +               return "gprs";
> >         case ACCESS_TECHNOLOGY_UTRAN:
> >                 return "umts";
> >         case ACCESS_TECHNOLOGY_GSM_EGPRS:
> >                 return "edge";
> >         case ACCESS_TECHNOLOGY_UTRAN_HSDPA:
> > -               return "hspa";
> > +               return "hsdpa";
> >         case ACCESS_TECHNOLOGY_UTRAN_HSUPA:
> > -               return "hspa";
> > +               return "hsupa";
> >         case ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
> >                 return "hspa";
> >         case ACCESS_TECHNOLOGY_EUTRAN:
> 
> Do you need to know if the cell supports high speed uplink, downlink
> or both; or in fact, when uplink or downlink is active (i.e., channel
> allocated)? Currently the API is telling you the former, and
> supporting the latter would require changes not only in the D-Bus API,
> but also in the driver API.
> 
The API is fine as-is, we just need a bit more details about the
technology in use. It will be purely informative in our application
anyway.

> As a side note, I think I was originally proposing using the
> generation tags, but either way works for me. That is, I consider it
> 3.5G when at least HSDPA is available.
> 
I was just thinking out loud about a "generation" field, I don't have
any need for it. And it can be obtained from the technology (correct
me if I'm wrong) :

gsm -> 2G
gprs, edge -> 2.5G
umts -> 3G
hsdpa, hsupa, hspa -> 3.5G
lte -> 4G

--
Benoît.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] common : bring back some details about technology

[Benoît Monin]

Our application require some more details about network technology
in use. This patch might be a bit controversial because commit
1e783b3 actively simplified the technology field.

Maybe adding a 'Generation' field ('2G', '2.5G', '3G'...) would
be  more end-user friendly ?
---
 src/common.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/common.c b/src/common.c
index b5b9a6f..d571d81 100644
--- a/src/common.c
+++ b/src/common.c
@@ -655,15 +655,15 @@ const char *registration_tech_to_string(int tech)
        case ACCESS_TECHNOLOGY_GSM:
                return "gsm";
        case ACCESS_TECHNOLOGY_GSM_COMPACT:
-               return "gsm";
+               return "gprs";
        case ACCESS_TECHNOLOGY_UTRAN:
                return "umts";
        case ACCESS_TECHNOLOGY_GSM_EGPRS:
                return "edge";
        case ACCESS_TECHNOLOGY_UTRAN_HSDPA:
-               return "hspa";
+               return "hsdpa";
        case ACCESS_TECHNOLOGY_UTRAN_HSUPA:
-               return "hspa";
+               return "hsupa";
        case ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
                return "hspa";
        case ACCESS_TECHNOLOGY_EUTRAN:
--
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

[PATCH] hso: Set modem name based on udev network interface name

[Benoît Monin]

Useful if you have multiple identical modems and you need a way
to know which modem you're talking to.
---
 plugins/udev.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/plugins/udev.c b/plugins/udev.c
index 737a637..e687c01 100644
--- a/plugins/udev.c
+++ b/plugins/udev.c
@@ -191,6 +191,7 @@ static void add_hso(struct ofono_modem *modem,
        } else if (g_str_equal(subsystem, "net") == TRUE) {
                devnode = get_property(udev_device, "INTERFACE");
                ofono_modem_set_string(modem, NETWORK_INTERFACE, devnode);
+               ofono_modem_set_name(modem, devnode);
        } else {
                return;
        }
--
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono