Re: Huawei 3131 with idVendor=12d1, idProduct=14fe
by matti kaasinen
Denis,
I noticed from the logs that 'net' should have been probed by
huawei_cdc_ncm module instead of plain cdc_ncm. I managed getting sysfs
lines after "net finished" line in ofonod log after changing cdc_ncm to
huawei_cdc_ncm (below):
..plugins/udev.c:udev_event() subsystem net finished
..plugins/udevng.c:check_usb_device() huawei_cdc_ncm [12d1:1506]
..plugins/udevng.c:add_device()
/sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1
..plugins/udevng.c:add_device()
/sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.1/net/wwan0
..plugins/udevng.c:add_device() wwan0 (huawei) 255/2/22 ==> (null) (null)
I also got net record from setup_huawei() printout:
..plugins/udevng.c:setup_huawei() mdm=/dev/ttyUSB0 pcui=/dev/ttyUSB2
diag=/dev/ttyUSB1 qmi=(null) net=wwan0
Now this process proceeded further providing printout from
provision_get_settings():
..plugins/provision.c:provision_get_settings() Provisioning for MCC 244,
MNC 05, SPN 'elisa'
..plugins/provision.c:provision_get_settings() Found 1 APs
..plugins/provision.c:provision_get_settings() Name: '(null)'
..plugins/provision.c:provision_get_settings() APN: 'internet'
..plugins/provision.c:provision_get_settings() Type:
OFONO_GPRS_CONTEXT_TYPE_INTERNET
..plugins/provision.c:provision_get_settings() Username: '(null)'
..plugins/provision.c:provision_get_settings() Password: '(null)'
After that came some errors:
..src/sim.c:ofono_sim_remove_spn_watch() 0x11cf60
ofonod: PCUI: > AT+CPBS=?\r
ofonod: PCUI: < \r\n+CME ERROR: 14\r\n
ofonod: PCUI: > AT+CPBS=?\r
ofonod: PCUI: < \r\n+CME ERROR: 14\r\n
ofonod: PCUI: > AT+CPBS=?\r
ofonod: PCUI: < \r\n+CPBS: ("SM","EN","ON")\r\n\r\nOK\r\n
I did not see any progress on connman side.
Modifications in plugins/udevng.c
vendor_list[]:
{ "huawei", "huawei_cdc_ncm", "12d1" },
setup_huawei():
g_strcmp0(info->interface, "255/2/22") == 0 ||
g_strcmp0(info->interface, "255/1/56") == 0) {
net = info->devnode;
Where should I look next?
I could provide full log, but I am not sure if attachments/messages with
attachments pass through.
Thanks,
Matti
2016-01-08 17:36 GMT+02:00 matti kaasinen <matti.kaasinen(a)gmail.com>:
> Denis,
> It was not that easy as adding that "255/2/22" -line ( without '(' ) for
> net detection.
> It still returns null for net. Ofono.log attached.
>
> -Matti
>
> 2016-01-08 15:59 GMT+02:00 matti kaasinen <matti.kaasinen(a)gmail.com>:
>
>> Denis,
>>
>> I studied both my desktop operation (ModemManager & NetworkManager) and
>> Cortex A8 board operation with ofono & connaman. I took logs from both of
>> them (attached). I also took lsusb listing and verified sysfs with my
>> desktop logs.
>> From ModemManager logs it seems that ModemManager does not suppoer
>> cdc-wdm interface. It finds three interfaces:
>> tty/ttyUSB2 at (primary)
>> net/wwan0 data (primary)
>> tty/ttyUSB0 data (secondary)
>>
>> Cortex A8 board sysfs seems have following nodes:
>>
>> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.0/ttyUSB0
>>
>> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.1/net/wwan0
>>
>> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.2/ttyUSB1
>>
>> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb2/2-1/2-1:1.3/ttyUSB2
>>
>> Thereafter it seems using ttuUSB2 for communication (AT commands anyway).
>> Compared to sysfs/lsusb and ofono.log
>> ttyUSB2 and ttyUSB0 match (bDeviceSubClass/bDeviceProtocol). Both use
>> ttyUSB2. However ofono does not get setup_huawei()/net, so it does not have
>> net/wwan0=net. As you noted, most likely setup_huawei() logic requires
>> following modification:
>> } else if (g_strcmp0(info->interface, "255/1/8") == 0 ||
>> (g_strcmp0(info->interface, "255/2/22") == 0 ||
>> g_strcmp0(info->interface, "255/1/56") == 0) {
>> net = info->devnode;
>>
>> I'll try that and see how it works.
>> -Matti
>>
>> 2016-01-07 18:39 GMT+02:00 Denis Kenzior <denkenz(a)gmail.com>:
>>
>>> Matti,
>>>
>>> On 01/07/2016 03:54 AM, matti kaasinen wrote:
>>>
>>>> Denis,
>>>>
>>>> I inserted that line to vendor_list[]. Unfortunately it did not make any
>>>> difference.
>>>> I need to execute /usr/lib/ofono/
>>>> enable-modem
>>>> online-modem
>>>>
>>>> After that cellular_...._context1 becomes powered on
>>>> connmanctl monitor reports these events. It also reports Strength
>>>> changes.
>>>>
>>>
>>> Sounds like the modem is being detected
>>>
>>>
>>>> When I try to execute:
>>>> connmanctl connect cellular_244052161781216_context1
>>>>
>>>> I get:
>>>> Error /net/connman/service/cellular_244052161781216_context1:
>>>> Input/output error
>>>>
>>>>
>>> It is hard to say anything without detailed oFono logs. Can you enable
>>> AT command logging and debug information using:
>>>
>>> as root:
>>> export OFONO_AT_DEBUG=1
>>> src/ofonod -n -d
>>>
>>> When I try to execute:
>>>> connmanctl config cellular_244052161781216_context1 --autoconnect yes
>>>>
>>>> I get:
>>>> Error cellular_244052161781216_context1: Invalid service
>>>>
>>>> This is just like it used to be before change.
>>>>
>>>> Supposing that I can somehow get this modem connected,
>>>> is it so that I need to create some agent as followes:
>>>> 1) Monitoring modem presence, e.g using
>>>> /usr/lib/ofono/test/list-contexts command.
>>>> 2) When above command returns proper context execute enable-modem and
>>>> online-modem.
>>>>
>>>> After that there should be a new service available for connaman.
>>>> Should I also write an agent monitoring/excuting connect from that event
>>>> or is there some more advanced way of doing that. Or should it work as
>>>> smoothly as it works with older version of this modem using cdc_ether
>>>> when some (hopefully minor problem gets solved) - just plug modem in and
>>>> it gets connected?
>>>>
>>>>
>>> It should work the same as older devices.
>>>
>>> I think the issue is that the NetworkInterface associated with the
>>> context is not being detected properly. E.g. rules in plugins/udevng.c
>>> need to be updated. Check out setup_huawei() function and make sure that
>>> the logic that assigns "net" is correct for your device.
>>>
>>> Regards,
>>> -Denis
>>>
>>>
>>
>
4 years, 3 months
Re: [PATCH] sim: Add ServiceProviderName property to SimManager
by Denis Kenzior
Hi Slava,
On 01/26/2016 09:08 AM, Slava Monich wrote:
> Contains the service provider name fetched from the SIM card, if available.
> ---
> doc/sim-api.txt | 5 +++++
> src/sim.c | 13 +++++++++++++
> 2 files changed, 18 insertions(+)
I broke this up into two commits (see our patch submission guidelines in
HACKING) and pushed this patch upstream.
Thanks,
-Denis
4 years, 4 months
[PATCH] rilmodem: Fix GPRS feature inavailable issue
by caiwen.zhang＠intel.com
From: Caiwen Zhang <caiwen.zhang(a)intel.com>
When query max cid if rild radio status isn't RADIO_STATUS_ON, it may
fail, gprs atom will be removed, gprs feature will always be inavailable.
---
drivers/rilmodem/gprs.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/rilmodem/gprs.c b/drivers/rilmodem/gprs.c
index 0ec9d5f..f3bdc86 100644
--- a/drivers/rilmodem/gprs.c
+++ b/drivers/rilmodem/gprs.c
@@ -54,8 +54,11 @@ struct ril_gprs_data {
gboolean ofono_attached;
int rild_status;
int pending_deact_req;
+ gboolean registered;
};
+static void query_max_cids(struct ofono_gprs *gprs);
+
/*
* This module is the ofono_gprs_driver implementation for rilmodem.
*
@@ -300,6 +303,34 @@ static void ril_gprs_registration_status(struct ofono_gprs *gprs,
}
}
+static void ril_radio_state_changed(struct ril_msg *message,
+ gpointer user_data)
+{
+ struct ofono_gprs *gprs = user_data;
+ struct ril_gprs_data *gd = ofono_gprs_get_data(gprs);
+ struct parcel rilp;
+ int radio_state;
+
+ if (gd->registered)
+ return;
+
+ g_ril_init_parcel(message, &rilp);
+ radio_state = parcel_r_int32(&rilp);
+
+ if (rilp.malformed) {
+ ofono_error("%s: malformed parcel received", __func__);
+ return;
+ }
+
+ g_ril_append_print_buf(gd->ril, "(state: %s)",
+ ril_radio_state_to_string(radio_state));
+ g_ril_print_unsol(gd->ril, message);
+
+ if (radio_state == RADIO_STATE_ON) {
+ query_max_cids(gprs);
+ }
+}
+
static void query_max_cids_cb(struct ril_msg *message, gpointer user_data)
{
struct ofono_gprs *gprs = user_data;
@@ -315,7 +346,14 @@ static void query_max_cids_cb(struct ril_msg *message, gpointer user_data)
ofono_error("%s: DATA_REGISTRATION_STATE reply failure: %s",
__func__,
ril_error_to_string(message->error));
- goto error;
+
+ if (message->error != RIL_E_RADIO_NOT_AVAILABLE)
+ goto error;
+ else {
+ g_ril_register(gd->ril, RIL_UNSOL_RESPONSE_RADIO_STATE_CHANGED,
+ ril_radio_state_changed, gprs);
+ return;
+ }
}
g_ril_init_parcel(message, &rilp);
@@ -341,6 +379,7 @@ reg_atom:
g_strfreev(strv);
ofono_gprs_set_cid_range(gprs, 1, max_calls);
ofono_gprs_register(gprs);
+ gd->registered = TRUE;
return;
error_free:
@@ -380,6 +419,7 @@ static void query_max_cids(struct ofono_gprs *gprs)
if (g_ril_vendor(gd->ril) == OFONO_RIL_VENDOR_MTK) {
ofono_gprs_set_cid_range(gprs, 1, 3);
ofono_gprs_register(gprs);
+ gd->registered = TRUE;
return;
}
@@ -495,6 +535,7 @@ static int ril_gprs_probe(struct ofono_gprs *gprs, unsigned int vendor,
gd->ril = g_ril_clone(ril);
gd->ofono_attached = FALSE;
gd->rild_status = -1;
+ gd->registered = FALSE;
ofono_gprs_set_data(gprs, gd);
--
1.9.1
4 years, 4 months
[PATCH] plugins/ril.c: avoid create a gril each time enable ril modem
by caiwen.zhang＠intel.com
From: Caiwen Zhang <caiwen.zhang(a)intel.com>
---
plugins/ril.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/plugins/ril.c b/plugins/ril.c
index ea50d76..688a5bf 100644
--- a/plugins/ril.c
+++ b/plugins/ril.c
@@ -400,9 +400,13 @@ static gboolean connect_rild(gpointer user_data)
int ril_enable(struct ofono_modem *modem)
{
int ret;
+ struct ril_data *rd = ofono_modem_get_data(modem);
DBG("");
+ if (rd->ril)
+ return 0;
+
ret = create_gril(modem);
if (ret < 0)
g_timeout_add_seconds(RILD_CONNECT_RETRY_TIME_S,
--
1.9.1
4 years, 4 months
[PATCH v2] hfpmodem: Handle repeated held call indicator
by Kuba Pawlak
An issue with iPhone 5C iOS 9.2 triggers desynchronization in call
states. When an active call is put on hold and another call arrives,
it is in WAITING state. It should be possible to answer it by issuing
AT+CHLD=2 but the phone changes its state to INCOMING so ATA should be
used. This change is advertised by sending callheld:2 event, but it is
not handled. This event can be used to trigger CLCC poll to synchronize
call states.
+CIEV: 3,1 <- first call arrives
AT+CLCC
+CLCC: 1,1,4,0,0,"01234567890",129
OK
RING
+CLIP: "01234567890",129
ATA
OK
+CIEV: 2,1
+CIEV: 3,0.
AT+CHLD=2.$ <- first call is put on hold
OK
+CIEV: 7,2 <- notification confirming that call #1 is on hold
+CCWA: "09876543210",129,1 <- second call arrives
+CIEV: 7,2
+CIEV: 3,1
AT+CLCC
+CLCC: 1,1,1,0,0,"01234567890",129
+CLCC: 2,1,5,0,0,"09876543210",129 <- new call is still in WAITING state
OK
+CIEV: 7,2 <- phone iternally promotes WAITING call to INCOMING
AT+CHLD=2 <- there is no WAITING call anymore, ATA should be used
+CME ERROR:3
---
drivers/hfpmodem/voicecall.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index d0e9353796c335a1fc876779345eedeb6556345d..782fae867ebe0280eaf7b039e60e901bd8812669 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -1110,7 +1110,19 @@ static void ciev_callheld_notify(struct ofono_voicecall *vc,
*/
vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
poll_clcc, vc);
+ } else {
+ if (vd->clcc_source)
+ g_source_remove(vd->clcc_source);
+
+ /*
+ * We got a notification that there is a held call
+ * and no active call but we already are in such state.
+ * Let's schedule a poll to see what happened.
+ */
+ vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
+ poll_clcc, vc);
}
+
}
vd->cind_val[HFP_INDICATOR_CALLHELD] = value;
--
1.9.3
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
4 years, 4 months
[PATCH] hfpmodem: Handle repeated held call indicator
by Kuba Pawlak
An issue with iPhone 5C iOS 9.2 triggers desynchronization in call
states. When an active call is put on hold and another call arrives,
it is in WAITING state. It should be possible to answer it by issuing
AT+CHLD=2 but the phone changes its state to INCOMING so ATA should be
used. This change is advertised by sending callheld:2 event, but it is
not handled. This event can be used to trigger CLCC poll to synchronize
call states.
+CIEV: 3,1 <- first call arrives
AT+CLCC
+CLCC: 1,1,4,0,0,"01234567890",129
OK
RING
+CLIP: "01234567890",129
ATA
OK
+CIEV: 2,1
+CIEV: 3,0.
AT+CHLD=2.$ <- first call is put on hold
OK
+CIEV: 7,2 <- notification confirming that call #1 is on hold
+CCWA: "09876543210",129,1 <- second call arrives
+CIEV: 7,2
+CIEV: 3,1
AT+CLCC
+CLCC: 1,1,1,0,0,"01234567890",129
+CLCC: 2,1,5,0,0,"09876543210",129 <- new call is still in WAITING state
OK
+CIEV: 7,2 <- phone iternally promotes WAITING call to INCOMING
AT+CHLD=2 <- there is no WAITING call anymore, ATA should be used
+CME ERROR:3
---
drivers/hfpmodem/voicecall.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index d0e9353796c335a1fc876779345eedeb6556345d..2b7524e9cccbbdb9d8ce1e47a91d2e32ccfbb6a8 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -1111,6 +1111,18 @@ static void ciev_callheld_notify(struct ofono_voicecall *vc,
vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
poll_clcc, vc);
}
+ else {
+ if (vd->clcc_source)
+ g_source_remove(vd->clcc_source);
+
+ /* We got a notification that there is a held call
+ * and no active call but we already are in such state.
+ * Let's schedule a poll to see what happened.
+ */
+ vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
+ poll_clcc, vc);
+ }
+
}
vd->cind_val[HFP_INDICATOR_CALLHELD] = value;
--
1.9.3
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
4 years, 4 months
Re: [PATCH] gdbus: Drop message replies if the sender requested no reply
by Denis Kenzior
Hi Philip,
On 01/08/2016 05:57 PM, Philip Withnall wrote:
> If the sender flags a D-Bus message as not expecting a reply, it is
> against system bus policy to send a reply — sending one will result in
> errors being sent to us by dbus-daemon.
>
> Magically drop all replies to messages which request no reply.
>
> This is not a complete fix. In an ideal world, the existing check for
> G_DBUS_METHOD_FLAG_NOREPLY would be dropped, as the server should be
> prepared to return a reply to every method, if the client requests and
> expects one — otherwise the client will time out. However, that’s a
> much bigger change with a much bigger risk of breaking things, so I’ll
> stick with this for now.
> ---
> gdbus/object.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Patch is still corrupt.
Applying: gdbus: Drop message replies if the sender requested no reply
fatal: corrupt patch at line 10
Patch failed at 0001 gdbus: Drop message replies if the sender requested
no reply
Are you using git send-email?
Regards,
-Denis
4 years, 4 months
ERROR:Reject SCO: Agent not registered.
by Abhishek Dharmapurikar
Hi,
I was trying to setup HFP uing ofono. I have the following setup
Rasperry Pi B+ ( ARM1176JZF-S)
Bluez 5.32
Pulseaudio 6.0
ofono 1.16
Used the following steps
http://padovan.org/blog/2010/02/handsfree-profile-into-bluez-and-ofono/
start pulseaudio, bluetoothd and ofonod
Connect to phone using bluetoothctl
./enable-modem
./dial-number
loopback
I was able to pair my nexus 4 device and use the script ./dial-number which
actually sets a call up. But the audio of the call doesn't route to the
default sink. I see the following error in ofonod
*Reject SCO: Agent not registered*
Which could be the reason for the audio problem.
Things that I have already tried.
Patched http://cgit.freedesktop.org/~jprvita/pulseaudio/ file
bluetooth-headsets-media-api.
Recompiled the raspbian kernel with
*CONFIG_BT_SCOCONFIG_BT_HCIUSB_SCO*
enabled
Added
*Enable = Source,Sink,Headset,Gateway,Control,MediaDisable = Socket*
to /etc/bluetooth/audio.conf.
Things that could be wrong
When I do a pactl list cards, i see the bluetooth card at #0 with two
profiles.
* Profiles: a2dp_source: High Fidelity Capture (A2DP
Source) (sinks: 0, sources: 1, priority: 10, available: yes)
headset_audio_gateway: Headset Audio Gateway (HSP/HFP) (sinks: 1, sources:
1, priority: 20, available: no) off: Off (sinks: 0, sources:
0, priority: 0, available: yes) Active Profile: a2dp_source*
But when I try making the headset_audio_gateway the default profile. I get
*$ sudo pactl set-card-profile 0 headset_audio_gatewayFailure: Input/Output
error*
Also read this in the pulseaudio notes
http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/6.0/
"When building PulseAudio, it's possible to choose between "native" and
"ofono" BlueZ 5 headset backends."
How do I specify that I wish to use the ofono headset backend? Is that the
problem?
4 years, 4 months
[PATCH v2] network: Fix use-after-free caused by Scan() in poor reception.
by John Ernberg
From: John Ernberg <john.ernberg(a)actia.se>
The area where I could test this behavior has gotten better reception now so I
cannot test this patch as thoroughly as I'd like but it seems to work.
Please be extra strict during the review to minimize the risk of something
being by this.
John Ernberg (1):
network: Fix use-after-free caused by Scan() in poor reception.
src/network.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
1.9.1
4 years, 4 months
[PATCH] gdbus: Drop message replies if the sender requested no reply
by Philip Withnall
If the sender flags a D-Bus message as not expecting a reply, it is
against system bus policy to send a reply — sending one will result in
errors being sent to us by dbus-daemon.
Magically drop all replies to messages which request no reply.
This is not a complete fix. In an ideal world, the existing check for
G_DBUS_METHOD_FLAG_NOREPLY would be dropped, as the server should be
prepared to return a reply to every method, if the client requests and
expects one — otherwise the client will time out. However, that’s a
much
bigger change with a much bigger risk of breaking things, so I’ll stick
with this for now.
Signed-off-by: Philip Withnall <philip.withnall(a)collabora.co.uk>
Reviewed-by: Simon McVittie <simon.mcvittie(a)collabora.co.uk>
---
gdbus/object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gdbus/object.c b/gdbus/object.c
index 96db516..146a255 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -258,7 +258,8 @@ static DBusHandlerResult
process_message(DBusConnection *connection,
reply = method->function(connection, message,
iface_user_data);
- if (method->flags & G_DBUS_METHOD_FLAG_NOREPLY) {
+ if (method->flags & G_DBUS_METHOD_FLAG_NOREPLY ||
+ dbus_message_get_no_reply(message)) {
if (reply != NULL)
dbus_message_unref(reply);
return DBUS_HANDLER_RESULT_HANDLED;
--
2.5.0
4 years, 4 months
