fix for +CMER parser of AT driver (fixes registration)
by M. Dietrich
Hi All,
i recently noticed that the at driver did not reach the state "registered".
marcel pointer me to the message
+CMER not supported by this modem. If this is an error please submit
patches to support this hardware
and i started digging. problem was parsing of the response
+CMER: (0,3),(0,2),0,(0-1),0
that expresses the allowed options of CMER. neither (a list of) single integer
"(0,3)" (in opposite to range "(0-1)") nor missing brackets "0" were supported
by ofono so i added this (see patch).
i'm not sure if missing brackets are allowed or espress something different,
maybe a AT-guru can tell. for now "(0)" behaves like "0".
i assume that also other response-parsing flows in ofono have that problem
so either a generic aproach should be implemented or other places be reviewed.
marcel already pointer out that a generic aproach may be unnecessarily complex
where i agree if it comes to strings and nested brackets but for plain integer
cases it would be quite useful to get this done in one place for all. if
interested i could implement such stuff into gatchat/gatresult.c which then can
be used for the integer-only cases. what do you think?
regards,
michael
--
M. Dietrich
8 years, 10 months
[PATCH] qmimodem: convert tid in service header to little endian.
by Cedric Jehasse
From: Cedric Jehasse <cedric.jehasse(a)softathome.com>
---
drivers/qmimodem/qmi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/qmimodem/qmi.c b/drivers/qmimodem/qmi.c
index 3389bb1..aaefe9e 100644
--- a/drivers/qmimodem/qmi.c
+++ b/drivers/qmimodem/qmi.c
@@ -1867,6 +1867,7 @@ uint16_t qmi_service_send(struct qmi_service *service,
struct service_send_data *data;
struct qmi_request *req;
struct qmi_service_hdr *hdr;
+ uint16_t tid;
if (!service)
return 0;
@@ -1901,12 +1902,13 @@ uint16_t qmi_service_send(struct qmi_service *service,
if (device->next_service_tid < 256)
device->next_service_tid = 256;
+ tid = device->next_service_tid++;
hdr->type = 0x00;
- hdr->transaction = device->next_service_tid++;
+ hdr->transaction = GUINT16_TO_LE(tid);
__request_submit(device, req, hdr->transaction);
- return hdr->transaction;
+ return tid;
}
bool qmi_service_cancel(struct qmi_service *service, uint16_t id)
--
1.7.9.5
8 years, 10 months
[PATCH] udevng: match vendorId and productId from parent usb_device.
by Cedric Jehasse
From: Cedric Jehasse <cedric.jehasse(a)softathome.com>
cdc_wdm device doesn't have ID_VENDOR_ID and ID_MODEL_ID properties,
read these properties from the parent usb_device.
---
plugins/udevng.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index afb02ca..7d7f4f6 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -1035,8 +1035,10 @@ static void check_usb_device(struct udev_device *device)
}
}
- vid = udev_device_get_property_value(device, "ID_VENDOR_ID");
- pid = udev_device_get_property_value(device, "ID_MODEL_ID");
+ vid = udev_device_get_property_value(usb_device,
+ "ID_VENDOR_ID");
+ pid = udev_device_get_property_value(usb_device,
+ "ID_MODEL_ID");
DBG("%s [%s:%s]", drv, vid, pid);
--
1.7.9.5
8 years, 10 months
[PATCH] Delay AT+CLCC request after setup of an outgoing call
by mail＠timomueller.eu
From: Timo Mueller <timo.mueller(a)bmw-carit.de>
Hi,
this fixes an issue we've been experiencing with the Nokia N9. When
placing an outgoing call from the N9 (AG device) the responded list
does not containt the new outgoing call as the N9 did not update the
list yet.
I tried reqesting the list a second time right after the first request
and the response always contained the call. In conclusion I added a
delay to the first request to give the AG device some time to update
the list before requesting it.
Best regards,
Timo
Timo Mueller (1):
hfpmodem: Delay AT+CLCC request after outgoing callsetup
drivers/hfpmodem/voicecall.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--
1.7.11.7
8 years, 10 months
[PATCH 1/3] build: Do not use deprecated AM_CONFIG_HEADER
by Lucas De Marchi
The long-obsoleted AM_CONFIG_HEADER macro was removed in automake 1.13.
Use AC_CONFIG_HEADERS instead.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 7db4198..a4a350f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ AC_PREREQ(2.60)
AC_INIT(ofono, 1.12)
AM_INIT_AUTOMAKE([foreign subdir-objects color-tests])
-AM_CONFIG_HEADER(config.h)
+AC_CONFIG_HEADERS(config.h)
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
--
1.8.1.1
8 years, 10 months
[PATCH v0 0/6] HFP HF: External Profile
by Claudio Takahasi
This is the first group of the patches which introduces the Handsfree
BlueZ external profile.
The following patches contain only initial files and basic structures
for the HFP HF plugin (since files and plugins names are one of
controversial points).
Remaining HFP HF patches:
git://git.infradead.org/users/cktakahasi/ofono.git HF-20130109
Claudio Takahasi (6):
Makefile: Enable BlueZ 4 and BlueZ 5
bluetooth: Add versioning information to BlueZ plugins
bluetooth: Initial files for BlueZ 5
hfp_hf: Add initial file for external HFP
hfp_hf: Add hfp_driver
hfp_hf: Add BlueZ Profile handler
Claudio Takahasi (6):
Makefile: Enable BlueZ 4 and BlueZ 5
bluetooth: Add versioning information to BlueZ plugins
bluetooth: Initial files for BlueZ 5
hfp_hf: Add initial file for external HFP
hfp_hf: Add hfp_driver
hfp_hf: Add BlueZ Profile handler
Makefile.am | 33 +-
configure.ac | 10 +-
dundee/bluetooth.c | 2 +-
plugins/bluetooth.c | 989 ------------------------------------------------
plugins/bluetooth.h | 84 ----
plugins/bluez4.c | 989 ++++++++++++++++++++++++++++++++++++++++++++++++
plugins/bluez4.h | 84 ++++
plugins/bluez5.c | 145 +++++++
plugins/bluez5.h | 31 ++
plugins/dun_gw.c | 2 +-
plugins/hfp_ag.c | 2 +-
plugins/hfp_hf.c | 552 ---------------------------
plugins/hfp_hf_bluez4.c | 552 +++++++++++++++++++++++++++
plugins/hfp_hf_bluez5.c | 194 ++++++++++
plugins/sap.c | 2 +-
plugins/telit.c | 2 +-
16 files changed, 2030 insertions(+), 1643 deletions(-)
delete mode 100644 plugins/bluetooth.c
delete mode 100644 plugins/bluetooth.h
create mode 100644 plugins/bluez4.c
create mode 100644 plugins/bluez4.h
create mode 100644 plugins/bluez5.c
create mode 100644 plugins/bluez5.h
delete mode 100644 plugins/hfp_hf.c
create mode 100644 plugins/hfp_hf_bluez4.c
create mode 100644 plugins/hfp_hf_bluez5.c
--
1.7.11.7
8 years, 10 months
AT command to modem via ofono from 3rd party
by Cornel Spinu
Hello,
I'm using an cinterion modem, and I wanna send AT commands directly to
the app port from a 3rd party application.
I am considering exposing my own method on dBus. The problem is that
from the dbus layer, I do not have access to the low-level part.
As far as I noticed, the only place I have access to the modem and app
port, is in plugins/ . The fact that I wanna expose a new method
on org.ofono.Modem, which is in src/modem.c , I do not see a way how I
can connect those two. I'm looking for any suggestions if
anyone can help.
Thank you,
Cornel Spinu
8 years, 10 months
[PATCH mmsd 1/3] README: add information about mailing list
by Lucas De Marchi
---
README | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/README b/README
index e33be69..fdfeafb 100644
--- a/README
+++ b/README
@@ -19,3 +19,9 @@ Configure automatically searches for all required components and packages.
To compile and install run:
make && make install
+
+Information
+===========
+
+Mailing list:
+ ofono(a)ofono.org
--
1.8.1
8 years, 10 months
oFono upstream test results_20130110
by Nicolas Paccou
Hello all,
First of all, I would like to wish you a happy new year and my best wishes
to all of you for 2013!
This has been a long time I have not sent an updated test report about oFono
upstream but this last 2 months I was busy on other tasks.
Please find the test report of oFono v1.12 commit 7b97a8a.
During this testing, we ran 462 functional positive cases. 358 cases passed
and 100 are blocked due to missing software/missing hardware/Feature not
supported. The pass rate is 77% (-1%) which is similar to previous test
cycle (v1.11 commit 7b97a8a).
If you have any comment about this report, contact me please.
Test Objective
The aim of this test cycle was to validate the state of oFono upstream by
testing all its features over all material we had (according to what feature
was supported and by priority order: 3G dongle and phonesim). oFono has been
installed and tested on Ubuntu 12.04 device.
Test Environment
oFono: v1.12 (updated to commit 7b97a8a)
usb_modeswitch: v1.2.3
modeswitch data: 20120120
Hardware: Laptop
Ubuntu: v12.04
Modem: Huawei E173u-2 - Operator & SIM Card: several french and UK SIM Cards
according to features
Phonesim: v1.19 (updated to commit d7f1f1a)
Issue Summary
New bug: 1
Bug 25952 - oFono crashes when doing a SIM refresh (Reset, Initialization
and or File change) with Phonesim
Known bug: 0
None
Closed bug: 0
None
Test Result
SUMMARY
Total Test Case 462
Passed 358
Failed 0
Blocked 100
TCs completed 100,0%
Run rate 78%
Pass rate total 77% (-1%)
Blocked rate total 22%
Pass rate of executed 99% (-1%)
FEATURES TOTAL PASS FAIL BLOCKED
PASS % MODEM USED
Modem 16 16 0 0
100% 3G Dongle
SIM 20 20 0 0
100% 3G Dongle
Phonebook 1 1 0 0
100% 3G Dongle
Network 18 18 0 0
100% 3G Dongle
Radio 22 17 0 5
77% 3G Dongle
Connectivity 28 28 0 0
100% 3G Dongle
Voice Calls 50 40 0 10
80% mainly on 3G Dongle (using appropriate SIM Card)
Messaging 24 22 0 2
92% 3G Dongle (using appropriate SIM Card)
Smart Messaging 15 15 0 0
100% Phonesim
Message Waiting 8 8 0 0
100% Phonesim
Cell Broadcast 15 12 0 3
80% Phonesim
Call Settings 13 9 0 4
69% 3G Dongle
Supplementary Services 59 56 0 3
95% mainly on 3G Dongle (using appropriate SIM Card)
Call Meter 15 5 0 10
33% Phonesim
Call Barring 49 33 0 16
67% 3G Dongle (using appropriate SIM Cards)
Call Forwarding 5 5 0 0
100% Phonesim
SimToolKit 104 53 4 47
51% Phonesim
Please find details in the attached file.
Notes
1% of cases are failed due to:
Bug <https://bugs.meego.com/show_bug.cgi?id=25952> 25952 - I have observed
one regression in STK and it is possible the guilty is Phonesim which has
not been updated whereas lots of changes have been submitted in oFono due to
recent GCF pre-certification work. In order to clarify the origin of this
issue, I have first entered the bug for oFono (Please see details in Issue
Summary section)
22% of cases are blocked due to:
Missing software (e.g.: Missing feature in Phonesim or missing a visual
application for some blocked feature as Setup Idle ModeText, Select Item,
Send SMS, etc.)
Missing hardware (e.g.: Missing other SIM (having appropriate service
activated) or oFono integrated in an end user device (e.g. smartphone) in
order to be able to test certain feature or case with the network simulator
(e.g.: PIN/PIN2 cases, Call Barring for specific scenarios etc.).
Feature not supported by oFono
Best regards,
Nicolas
8 years, 10 months
