Re: Implement signal strength polling in plugin/driver
by Audric Schiltknecht
Denis,
>> I found by looking in include/netreg.h that it should be up to the
>> plugin to
>> implement CSQ polling, however I can't find how it is supposed to be
>> done.
>> Indeed, the plugin has no access to the netreg atom nor structure,
>> so
>> how is it
>> supposed to update one of these properties ?
>
> Drivers do not modify DBus properties directly. Instead you should
> be signaling the change to the core the regular way, via
> ofono_netreg_strength_notify.
>
> If you want to implement periodic signal strength reporting, then use
> g_idle_add_seconds to periodically send the +CSQ query. Please note
> that doing it this way you'd have to keep track of other states. For
> example, you might want to stop polling when the registration is
> lost,
> etc.
Oh, I see. Indeed, I noticed that signal strength reporting
is stopped when modem is not registered. I'll keep that in mind.
Thank you for the lead on this matter.
>
> Ideally you should be asking your vendor why the signal strength
> isn't reported properly.
Sure, it would be great to not have to do all these hacks to get it
working right !
Regards,
Audric
8 years, 5 months
[PATCH] TODO: Remove infeasible SIM task
by Guillaume Zajac
---
TODO | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/TODO b/TODO
index 1fef651..3ddf363 100644
--- a/TODO
+++ b/TODO
@@ -66,23 +66,6 @@ SIM / SIM File system
Priority: Low
Complexity: C2
-- Add support for SIM 'ready' notifications from the driver to the core. Most
- modem manufacturers initialize the SIM (e.g. cache SIM file system, STK
- initialization, etc) internally before allowing the telephony stack to
- access these portions. When the PIN is locked, this can lead to oFono being
- too fast for the modem and asking it for things before the firmware is ready.
-
- The proposal is to introduce a new sim function:
- void ofono_sim_ready_notify(struct ofono_sim *sim);
-
- When oFono determines the SIM PIN is READY, it checks whether
- ofono_sim_ready_notify has been called. If it hasn't, then it stalls the
- initialization procedure (and calling post_sim) until
- ofono_sim_ready_notify is called.
-
- Priority: High
- Complexity: C2
-
- Support SIM authentication: SIM and AKA suites.
Priority: Medium
--
1.7.5.4
8 years, 5 months
Implement signal strength polling in plugin/driver
by Audric Schiltknecht
Hi guys,
It seems my first post was lost, so here is a new try.
I am currently developing an ofono-based GSM control interface, using a
Sagem
Hilo modem (I wrote the appropriate plugin) with the atmodem driver.
I am having trouble with signal strength reporting. The terminal does
not report
signal strength by event. Hence, it is not possible to get the value
from Ofono,
since Ofono expects it to be updated on a +CIEV event. I implemented a
new DBus method in the NetworkRegistration interface to force AT+CSQ
command and
update the property value, but this is clearly not a valid solution.
I found by looking in include/netreg.h that it should be up to the
plugin to
implement CSQ polling, however I can't find how it is supposed to be
done.
Indeed, the plugin has no access to the netreg atom nor structure, so
how is it
supposed to update one of these properties ?
Thank you for your help.
Regards,
Audric Schiltknecht
8 years, 5 months
[PATCH 0/3] mmsd: (resending) new tasks definition
by Ronald Tessier
These patches concern mmsd and update TODO and documentation to describe new
functionalities to add to mmsd.
Ronald Tessier (3):
TODO: Add new tasks
doc: Describe delivered group in storage doc
doc: Add new D-Bus methods to service interface
TODO | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++
doc/service-api.txt | 20 +++++++++++++++
doc/storage.txt | 30 ++++++++++++++++++++++
3 files changed, 117 insertions(+), 0 deletions(-)
--
1.7.4.1
8 years, 5 months
[PATCHv5 0/5] Call forwarding state handling change
by Oleg Zhurakivskyy
Hello,
Please find the changes in order to correct call forwarding states.
Changes from v4:
- Check the CFU in order to find whether querying is needed.
- End querying once CFU is active.
- Cache TYPE_ALL queries on supplementary services path.
Regards,
Oleg
Oleg Zhurakivskyy (5):
call-forwarding: Streamline number assignment
call-forwarding: Don't query cfs if CFU is active
call-forwarding: End querying once CFU is active
call-forwarding: Cache ss TYPE_ALL queries
TODO: Remove completed call forwarding state task
TODO | 17 -----------------
src/call-forwarding.c | 14 ++++++++------
2 files changed, 8 insertions(+), 23 deletions(-)
--
1.7.5.4
8 years, 5 months
[PATCH v0 0/4] Add Serial and Type property to dundee
by Daniel Wagner
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Hi,
The first patch is fixes an obvious typo in the introspection.
The next three patches punch a whole through the DUN device
abstraction. If a Bluetooth device supports PAN and DUN at the same
time, there is no real good reason to offer both services to
user. ConnMan needs to figure out if a device supports both profile
(and then picking PAN). For this we need to provide an device
identifier. This API estension is modeled after the modem API, where
we have to do the same thing for HFP.
cheers,
daniel
Daniel Wagner (4):
dundee: Fix signal name
dundee: Add Serial and Type documantation
dundee: Add Serial property
dundee: Add Type property
doc/dundee-api.txt | 12 ++++++++++++
dundee/bluetooth.c | 11 +++++++++++
dundee/device.c | 27 +++++++++++++++++++++++++++
dundee/dundee.h | 9 +++++++++
dundee/manager.c | 2 +-
5 files changed, 60 insertions(+), 1 deletion(-)
--
1.7.10.130.g36e6c
8 years, 6 months
[PATCH] atmodem: check the Packet Domain service state before attaching
by Philippe Nunes
---
drivers/atmodem/gprs.c | 66 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 65a8b7b..3be0a9d 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -44,6 +44,7 @@
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 {
@@ -62,17 +63,74 @@ static void at_cgatt_cb(gboolean ok, GAtResult *result, gpointer user_data)
cb(&error, cbd->data);
}
+static void at_cgatt_query_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct cb_data *cbd = user_data;
+ ofono_gprs_cb_t cb = cbd->cb;
+ struct gprs_data *gd = cbd->user;
+ struct ofono_error error;
+ GAtResultIter iter;
+ int state;
+
+ decode_at_error(&error, g_at_result_final_response(result));
+
+ if (!ok) {
+ cb(&error, cbd->data);
+ g_free(cbd);
+ return;
+ }
+
+ g_at_result_iter_init(&iter, result);
+
+ if (!g_at_result_iter_next(&iter, "+CGATT:")) {
+ CALLBACK_WITH_FAILURE(cb, cbd->data);
+ g_free(cbd);
+ return;
+ }
+
+ g_at_result_iter_next_number(&iter, &state);
+
+ switch (state) {
+ case 0:
+ if (g_at_chat_send(gd->chat, "AT+CGATT=1", none_prefix,
+ at_cgatt_cb, cbd, g_free) > 0)
+ return;
+
+ CALLBACK_WITH_FAILURE(cb, cbd->data);
+ break;
+ case 1:
+ CALLBACK_WITH_SUCCESS(cb, cbd->data);
+ break;
+ }
+
+ g_free(cbd);
+}
+
static void at_gprs_set_attached(struct ofono_gprs *gprs, int attached,
ofono_gprs_cb_t cb, void *data)
{
struct gprs_data *gd = ofono_gprs_get_data(gprs);
struct cb_data *cbd = cb_data_new(cb, data);
- char buf[64];
- snprintf(buf, sizeof(buf), "AT+CGATT=%i", attached ? 1 : 0);
+ cbd->user = gd;
- if (g_at_chat_send(gd->chat, buf, none_prefix,
- at_cgatt_cb, cbd, g_free) > 0)
+ /*
+ * Before attaching, check the current state.
+ * If we are already attached to the packet domain service, it means
+ * that the attachment is done automatically at power on.
+ * If we send again the command +CGATT, this command should be ignored
+ * by the modem but some of them are initiating a complete new
+ * attachment procedure resulting in a preliminary IMSI/P-TMSI detach.
+ * To prevent such bad behavior, the command +CGATT is not sent if the
+ * modem is already in the requested state.
+ */
+ if (attached == TRUE) {
+ if (g_at_chat_send(gd->chat, "AT+CGATT?", cgatt_prefix,
+ at_cgatt_query_cb, cbd, NULL) > 0)
+ return;
+ } else if (g_at_chat_send(gd->chat, "AT+CGATT=0", none_prefix,
+ at_cgatt_cb, cbd, g_free) > 0)
return;
g_free(cbd);
--
1.7.9.5
8 years, 6 months
[PATCH v0 0/3] Prefer PAN over DUN
by Daniel Wagner
From: Daniel Wagner <daniel.wagner(a)bmw-carit.de>
Hi,
So here is the first oFono version for the "prefer pan over dun"
feature. Since this is a policy thing, it makes sense to place this
inside dundee and not inside ConnMan or BlueZ.
I am not really happy to pass in the UUIDs but I found it a lot nicer
than adding a 'filter' callback to struct bluetooth_profile.
Another idea how to implement it I had was, adding a blacklist when
registering the profile.
Let's start with the simplest possible solution.
cheers,
daniel
Daniel Wagner (3):
bluetooth: Add list of UUIDs to probe function
bluetooth: Add PAN UUID
dundee: Ignore DUN device if PAN is present
dundee/bluetooth.c | 11 ++++++++++-
plugins/bluetooth.c | 8 +++++---
plugins/bluetooth.h | 3 ++-
plugins/hfp_hf.c | 2 +-
plugins/sap.c | 2 +-
5 files changed, 19 insertions(+), 7 deletions(-)
--
1.7.10.130.g36e6c
8 years, 6 months
[RFC 0/3] Fix crash when network is lost
by Guillaume Zajac
Hi,
Problem description:
Some Huawei modems are trying to keep PPP session with the network alive even if the network is lost.
Thus oFono PPP session with the modem is never ended. Currently when network is lost, oFono will release the active contexts into the core however the context is still active at driver level. If the connection with the network is established again and we try to enable a data call, we have a crash.
This issue is very tricky there might be multiple solutions, here is one I discussed with Denis yesterday.
A new driver entry is added to release context into the driver in shutting down the PPP session between oFono and the modem.
Then ofono_context_deactivated() is called to signal the context is inactive at driver level.
In the case we lost the network and we are reattaching to the network but the PPP session had no time to be released, there is a mechanism to wait for the previous context to be released and then signal modem is reattached to the network. ConnMan can do again a data call.
Guillaume Zajac (3):
gprs-context: Add new driver entry
gprs-context: Add new driver entry definition
gprs: Release context in driver and core when network is lost
drivers/atmodem/gprs-context.c | 11 +++++
include/gprs-context.h | 2 +
src/gprs.c | 84 ++++++++++++++++++++++++++++++----------
3 files changed, 76 insertions(+), 21 deletions(-)
--
1.7.5.4
8 years, 6 months
