[RFC] HFP support into oFono and BlueZ
by Gustavo F. Padovan
Hi,
These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
Intefaces API.
The first two patches is for BlueZ and the other for oFono. You can
test it with using enable-modem and test-voicecall scripts into the
test dir of oFono.
Feel free to test it and send me your comments. We have some bugs yet.
The audio part is not working yet. We are going to work on pulseaudio
this week to get this done soon.
Regards,
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
7 years, 11 months
CDMA SMS Handling
by Rajesh.Nagaiah＠elektrobit.com
Hi,
There was a discussion about the CDMA SMS handling and CDMA PDUs in the
IRC channel couple of days before. I would like to highlight the
differences between CDMA and GSM PDU and how we should proceed with this
from my understanding. Let me know your opinion.
Even though oFono supports +CMT and +CMTI, if we feed the incoming CDMA
PDUs to the SMS core it wont get decoded correctly, as there is
substantial differences between the GSM and CDMA SMS PDUs as described
in 3GPP2 specification C.S0015-B Short Message Service (SMS) for
Wideband Spread Spectrum Systems
For eg, the incoming PDU example that was mentioned in the IRC
discussion
+CMT: , 40,
00000210020207028CE95DCC65800601FC08150003168D30010610241830608003061010
04044847
40 - Length of the PDU in bytes
00 - Message Type ( 00 - SMS Point-to-Point)
00 - TeleService Identifier Tag (SMS Parameter Indentifier)
02 - TeleService Identifier Length (SMS Parameter Length)
10 - TeleService Identifier Value - First 8 bits
02 - TeleService Identifier Value - Second 8 bits
TeleService Identifier - 0x1002 - CDMA Messaging Teleservice
(CMT-95)
02 - Originating Address Tag
07 - Originating Address Length
02 - Originating Address 1st 8 Bits
8C - Originating Address 2nd 8 Bits
E9 - Originating Address 3rd 8 Bits
5D - Originating Address 4th 8 Bits
CC - Originating Address 5th 8 Bits
65 - Originating Address 6th 8 Bits
80 - Originating Address 7th 8 Bits
Digit Mode - 1 Bit
Number Mode - 1 Bit
Number Type - 0 or 3 bits
Number Plan - 0 or 4 bits
Number Fields - 8 Bits
Number Field occurrence of CHARi
CHARi - 4 or 8 bits ( 4 - in case of DTMF encoding, 8 - incase
of ASCII encoding)
Reserved - 0-7 bits
Lets take the 1st and 2nd 8 bits
02 - 0000 0010 ( Digit Mode bit - 0, Number Mode bit - 0)
8C - 1000 1100
As Digit mode bit is set to 0, Number Plan and Number Type is void
(0 bits) in this case.
So the remaining 6 bits of 1st 8bits and the first 2 bits of 2nd
8bit is Number fields
Number fields - 00 0010 10 - 0000 1010 - 0x0A (10 digits)
As Digit mode bit is set to 0, each address digit here is
represented as 4bit DTMF digit
0x8C 0xE9 0x5D 0xCC 0x65 0X80
1000 1100 1110 1001 0101 1101 1100 1100 0110 0101 1000 0000
10 0011 0011 1010 0101 0111 0111 0011 0001 1001 0110 0000 00
3 3 0 5 7 7 3 1 9 6 Last 6 bits
are reserved bits
Originating Address - 3305773196
06 - Bearer Reply Option Tag
01 - Bearer Reply Option Length
FC - First 6 bits Reply Sequence number and last 2 bits reserved set to
0
1111 1100 - 111111 REPLY_SEQ
00 Reserved
08 - Bearer Data Tag
15 - Bearer Data Length
00 - Message Indentifier Tag ( Bearer Data Sub parameter )
03 - Message Indentifier Length
16 - Message Type 4 bits Message Id 4 Bits
8D - Message Id 8 Bits
30 - Message Id 4 Bits, UDH Header indicator 1 Bit, Reserved 3 Bits
How Message Identifier value 16 8D 30 was formed ?
Message type ( 4 bits ) - 1( 0001 - Deliver)
Message Identifier ( 16 bits ) - 26835( 0x68D3)
Header Indicator (1 bit) - 0 (UDH not present in User Data
Subparameter)
Reserved ( 3bits) - 0 (000)
01 - User Data Tag ( Bearer Data Sub parameter )
06 - User Data Length
10 - Message Encoding 5 bits ( 0001 0000 ( 00010 = 2 -> 7-bit ASCII )) &
Number Fields 3 bits ( 000)
24 - Number Fields 5 Bits + User char field 1's 3 bits ( 0010 0100 )
18 - User char field 1's remaining 5 bits + User char field 2's 3 bits
(0001 1000)
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
(0011 0000)
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
(0110 0000)
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)
Number Fields: 000 00100 - 04 (4 Character fields)
User Char [1] - 100 00011 - 0x83
User Char [2] - 000 00110 - 0x06
User Char [3] - 000 01100 - 0x0C
User Char [4] - 000 10000 - 0x10
Hex 0x83 0x06 0x0C 0x10
Octets 1000 0011 0000 0110 0000 1100 0001 0000
Septets 1000 001 10000 01 100000 1 1000001
Character A(0x41) A(0x41) A(0x41) A(0x41)
Message content: AAAA
Message Encoding - 2 (00010 - 5 bits)
Number Fields - 4 (0000 0100 - 8 bits)
User characters - 0x83 0x06 0x0C 0x10 ( 8 bits each)
00010 0000 0100 1000 0011 0000 0110 0000 1100 0001 0000
0001 0000 - 0x10
0010 0100 - 0x24
0001 1000 - 0x18
0011 0000 - 0x30
0110 0000 - 0x60
1000 0000 - 0x80 (Last 3 bits set to 0's(reserved bit) to complete
the octets)
03 - Message Center Time Stamp Tag ( Bearer Data Sub parameter )
06 - Message Center Time Stamp Length
all date and time fields contain two 4-bit BCD numbers giving the
decimal value of the field.
10 - Year (2010)
10 - Month (10 - October)
04 - Day
04 - Hour
48 - Minutes
47 - Seconds
Time Stamp 04:48:47 04/10/2010
Decoded Information:
Message Type: Deliver (Incoming Message)
Teleservice: CMT-95
Message Identifier: 26835
Originating Address: 3305773196
Message content: AAAA
Message Center Time Stamp: 04:48:47 04/10/2010
As from the above decoding example we can see there is substantial
differences between the GSM and CDMA SMS specifications and so the SMS
atom needs many additions and needs to be heavily modified to support
also CDMA SMS handling. Currently the oFono sms file unit handles the
common and the GSM technology aspects of the SMS stack along with the
smsutils. The SMS atom has the GSM specific members, segmentation and
queuing logic. The smsutils mainly takes care of encoding/decoding of
the PDUs, which is GSM specific. As the segmentation and queuing logic
and the interface is common for both GSM and CDMA, we could reuse this
common code and add the CDMA handling into it and create a new
cdmasmsutils unit to support the CDMA SMS specifics, much like the
smsutils does already for GSM.
BR,
Rajesh
8 years, 2 months
[PATCH 1/3] add some length verification to avoid reading not owned memory
by jr_extern＠vfnet.de
From: Jens Rehsack <jr_extern(a)vfnet.de>
---
src/push.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/push.c b/src/push.c
index 6a54907..6107352 100644
--- a/src/push.c
+++ b/src/push.c
@@ -351,13 +351,16 @@ gboolean mms_push_notify(unsigned char *pdu, unsigned int len,
/* Consume TID and Type */
nread = 2;
- if (wsp_decode_uintvar(pdu + nread, len,
+ if (wsp_decode_uintvar(pdu + nread, len - nread,
&headerslen, &consumed) == FALSE)
return FALSE;
/* Consume uintvar bytes */
nread += consumed;
+ /* Check if content type could be read */
+ if (headerslen > (len - nread))
+ return FALSE;
/* Try to decode content-type */
if (wsp_decode_content_type(pdu + nread, headerslen, &ct,
&consumed, ¶m_len) == FALSE)
@@ -370,6 +373,9 @@ gboolean mms_push_notify(unsigned char *pdu, unsigned int len,
consumed += param_len;
nread += consumed;
+ /* Check if application_id could be read */
+ if ((headerslen - consumed) > (len - nread))
+ return FALSE;
/* Parse header to decode application_id */
wsp_header_iter_init(&iter, pdu + nread, headerslen - consumed, 0);
--
1.7.9.1
8 years, 4 months
[PATCH] emulator: Fix for PTS test TC_AG_TWC_BV_02_I
by Frédéric Danis
RING event should only be sent when callsetup indicator is set to
Incoming and there is no active call.
If call indicator is set to inactive while callsetup is
already set to Incoming (waiting call has generated +CCWA),
RING event should be sent after all calls' state have been updated.
As state of calls are updated one by one, generating multiple calls
to ofono_emulator_set_indicator(), do not call notify_ring() just
after call indicator went from active/held to inactive (only start
ring timer).
In ring_timer(), in case of a call in waiting state, just exit and
wait for next timeout.
---
src/emulator.c | 21 +++++++++++----------
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/emulator.c b/src/emulator.c
index 262e782..fed699c 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -414,6 +414,13 @@ static gboolean notify_ring(void *user_data)
if (em->type == OFONO_EMULATOR_TYPE_HFP && em->slc == FALSE)
return TRUE;
+ /*
+ * In case of waiting call becoming an incoming call, call status
+ * change may not have been done yet, wait for change has been completed
+ */
+ if (find_call_with_status(em, CALL_STATUS_WAITING))
+ return TRUE;
+
g_at_server_send_unsolicited(em->server, "RING");
if (!em->clip)
@@ -421,13 +428,6 @@ static gboolean notify_ring(void *user_data)
c = find_call_with_status(em, CALL_STATUS_INCOMING);
- /*
- * In case of waiting call becoming an incoming call, call status
- * change may not have been done yet, so try to find waiting call too
- */
- if (c == NULL)
- c = find_call_with_status(em, CALL_STATUS_WAITING);
-
if (c == NULL)
return TRUE;
@@ -1221,10 +1221,10 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em,
/*
* Ring timer should be started when:
* - callsetup indicator is set to Incoming and there is no active call
- * (not a waiting call)
+ * (not a waiting call), in this case, a first RING should be sent
+ * just after the +CIEV
* - or call indicator is set to inactive while callsetup is already
* set to Incoming.
- * In those cases, a first RING should be sent just after the +CIEV
* Ring timer should be stopped for all other values of callsetup
*/
if (waiting)
@@ -1247,8 +1247,9 @@ void ofono_emulator_set_indicator(struct ofono_emulator *em,
return;
}
-start_ring:
notify_ring(em);
+
+start_ring:
em->callsetup_source = g_timeout_add_seconds(RING_TIMEOUT,
notify_ring, em);
}
--
1.7.1
8 years, 5 months
[PATCH 0/2] phonesim: Add timer to set the variable with the delay
by Oleg Zhurakivskyy
Hello,
Please find the changes in order to permit to set variables
with the delay (specify the delay in milliseconds):
<chat>
<set name="AAA" value="BBB" delay="30000"/>
</chat>
This might be useful to simulate SIM PIN unlocking cases, etc.
Regards,
Oleg
Oleg Zhurakivskyy (2):
phonesim: Minor reflow in SimChat::command()
phonesim: Add timer to set the variable with the delay
src/phonesim.cpp | 49 ++++++++++++++++++++++++++++++++++++++-----------
src/phonesim.h | 14 ++++++++++++++
2 files changed, 52 insertions(+), 11 deletions(-)
--
1.7.5.4
8 years, 5 months
[PATCH] phonesim: Fix call scripting capability
by Frédéric Danis
---
doc/scriptable.txt | 6 +++---
src/control.cpp | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/doc/scriptable.txt b/doc/scriptable.txt
index 670bd21..95ae1e1 100644
--- a/doc/scriptable.txt
+++ b/doc/scriptable.txt
@@ -7,8 +7,8 @@ call, you have to do some operations manually within phonesim GUI). Below are
several examples:
1. call.js (stand for incoming call and copy it to /tmp/call/)
-tabRegistration.gbIncomingCall.leCaller.text = "12345";
-tabRegistration.gbIncomingCall.pbIncomingCall.click();
+tabCall.gbIncomingCall.leCaller.text = "12345";
+tabCall.gbIncomingCall.pbIncomingCall.click();
Then set the path of script and run the script with its name:
@@ -50,6 +50,6 @@ Reference" for details.
For example, if you want to know the current incoming number, you may write a
script as below:
// number.js
-tabRegistration.gbIncomingCall.leCaller.text
+tabCall.gbIncomingCall.leCaller.text
After running the script the similar way as above, you may get the number.
diff --git a/src/control.cpp b/src/control.cpp
index 2666b4c..ee1e7d8 100644
--- a/src/control.cpp
+++ b/src/control.cpp
@@ -667,6 +667,9 @@ Script::Script(QObject *obj, Ui_ControlBase *ui) : QDBusAbstractAdaptor(obj)
QScriptValue qsTab8 = engine.newQObject(ui->tab_8);
engine.globalObject().setProperty("tabPosition", qsTab8);
+
+ QScriptValue qsTab9 = engine.newQObject(ui->tab_9);
+ engine.globalObject().setProperty("tabCall", qsTab9);
}
void Script::SetPath(const QString &path, const QDBusMessage &msg)
--
1.7.1
8 years, 5 months
LG VX8360 HFP non-compliance issue
by Mike
I'm getting weird behaviour from an LG VX8360, connected via bluetooth
HFP. When the phone connects, I see a CallAdded signal go out over
dbus, despite there being no call on the phone itself. You can see
the signal below. The LineIdentification held the actual phone number
of the phone, but I replaced it with "xxxxxxxxxx". I also copied in
the initial RFCOMM communication. It looks to me like this phone does
not comply with the HFP spec in that it returns an answer to AT+CLCC
when there is no phone call present (and at that, an index of 0). It
also happens that the status is a 6, which does not appear to be a
valid status in HFPv1.5. This just happens to map to the enum
CALL_STATUS_DISCONNECTED, but I'm guessing this was merely
coincidence. Since the state is broadcast as disconnected, I can
simply ignore it in my GUI application. However, I'm wondering if
this is something that is better handled in the ofono side?
Thanks,
Mike
signal sender=:1.0 -> dest=(null destination) serial=35
path=/hfp/F4FC32DD7E08_0025E5B340D9;
interface=org.ofono.VoiceCallManager; member=CallAdded
object path "/hfp/F4FC32DD7E08_0025E5B340D9/voicecall00"
array [
dict entry(
string "State"
variant string "disconnected"
)
dict entry(
string "LineIdentification"
variant string "xxxxxxxxxx"
)
dict entry(
string "Name"
variant string ""
)
dict entry(
string "Multiparty"
variant boolean false
)
dict entry(
string "RemoteHeld"
variant boolean false
)
dict entry(
string "RemoteMultiparty"
variant boolean false
)
dict entry(
string "Emergency"
variant boolean false
)
]
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 12 fcs 0x7f
0000: 41 54 2b 42 52 53 46 3d 31 31 38 0d AT+BRSF=118.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 0 fcs 0xb9 credits 10
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 14 fcs 0xa5
0000: 0d 0a 2b 42 52 53 46 3a 20 33 35 39 0d 0a ..+BRSF: 359..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f
0000: 41 54 2b 43 49 4e 44 3d 3f 0d AT+CIND=?.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 132 fcs 0xb9 credits 1
0000: 0d 0a 2b 43 49 4e 44 3a 20 28 22 63 61 6c 6c 22 ..+CIND: ("call"
0010: 2c 28 30 2c 31 29 29 2c 28 22 63 61 6c 6c 73 65 ,(0,1)),("callse
0020: 74 75 70 22 2c 28 30 2d 33 29 29 2c 28 22 73 65 tup",(0-3)),("se
0030: 72 76 69 63 65 22 2c 28 30 2c 31 29 29 2c 28 22 rvice",(0,1)),("
0040: 73 69 67 6e 61 6c 22 2c 28 30 2d 35 29 29 2c 28 signal",(0-5)),(
0050: 22 72 6f 61 6d 22 2c 28 30 2c 31 29 29 2c 28 22 "roam",(0,1)),("
0060: 62 61 74 74 63 68 67 22 2c 28 30 2d 35 29 29 2c battchg",(0-5)),
0070: 28 22 63 61 6c 6c 68 65 6c 64 22 2c 28 30 2d 32 ("callheld",(0-2
0080: 29 29 0d 0a ))..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f
0000: 41 54 2b 43 49 4e 44 3f 0d AT+CIND?.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 24 fcs 0xb9 credits 1
0000: 0d 0a 2b 43 49 4e 44 3a 20 30 2c 30 2c 31 2c 33 ..+CIND: 0,0,1,3
0010: 2c 30 2c 35 2c 30 0d 0a ,0,5,0..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 16 fcs 0x7f
0000: 41 54 2b 43 4d 45 52 3d 33 2c 30 2c 30 2c 31 0d AT+CMER=3,0,0,1.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f
0000: 41 54 2b 43 48 4c 44 3d 3f 0d AT+CHLD=?.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 16 fcs 0xb9 credits 1
0000: 0d 0a 2b 43 48 4c 44 3a 20 28 31 2c 32 29 0d 0a ..+CHLD: (1,2)..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 11 fcs 0xa5
0000: 0d 0a 2b 56 47 53 3a 20 37 0d 0a ..+VGS: 7..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f
0000: 41 54 2b 43 4d 45 45 3d 31 0d AT+CMEE=1.
> 0000: 06 00 00 00 10 35 03 19 11 0b 00 f0 35 06 09 00 .....5......5...
0010: 01 09 00 09 00 .....
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f
0000: 41 54 2b 43 4c 49 50 3d 31 0d AT+CLIP=1.
< 0000: 07 00 00 00 1c 00 19 35 17 35 15 09 00 01 35 03 .......5.5....5.
0010: 19 11 0b 09 00 09 35 08 35 06 19 11 0d 09 01 02 ......5.5.......
0020: 00 .
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 10 fcs 0x7f
0000: 41 54 2b 43 43 57 41 3d 31 0d AT+CCWA=1.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f
0000: 41 54 2b 43 49 4e 44 3f 0d AT+CIND?.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 24 fcs 0xb9 credits 1
0000: 0d 0a 2b 43 49 4e 44 3a 20 30 2c 30 2c 31 2c 33 ..+CIND: 0,0,1,3
0010: 2c 30 2c 35 2c 30 0d 0a ,0,5,0..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f
0000: 41 54 2b 56 47 53 3d 37 0d AT+VGS=7.
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 9 fcs 0x7f
0000: 41 54 2b 56 47 4d 3d 37 0d AT+VGM=7.
> 0000: 00 01 ..
< 0000: 02 01 04 08 ....
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 6 fcs 0xb9 credits 1
0000: 0d 0a 4f 4b 0d 0a ..OK..
< RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 8 fcs 0x7f
0000: 41 54 2b 43 4c 43 43 0d AT+CLCC.
> 0000: 10 02 04 ...
< 0000: 12 02 01 00 07 06 00 00 3f ff 02 40 ........?..@
> RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 35 fcs 0xb9 credits 1
0000: 0d 0a 2b 43 4c 43 43 3a 20 30 2c 30 2c 36 2c 30 ..+CLCC: 0,0,6,0
0010: 2c 30 2c 22 36 31 32 38 36 38 35 37 37 36 22 2c ,0,"xxxxxxxxxx",
0020: 30 0d 0a 0..
> RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5
0000: 0d 0a 4f 4b 0d 0a ..OK..
8 years, 5 months
trying to understand context creation
by Jussi Kukkonen
Hi,
I'm looking at how I'm creating and using internet contexts to make
sure I'm not missing any problem cases, and I feel like I don't have
much feedback on what is happening and what possibly scenarios I
should be ready for. Dennis explained the ConnectionManager "life
time" last week which helped a lot (thanks) but I'm still struggling.
I've listed some steps that may happen from user/GUI point of view and
the questions I have (some are connman related but I think this is
still the better list):
* Modem with ConnectionManager appears
A ConnectionContext may have been created automatically or not. Under
what circumstances does this happen? E.g. If the mobile broadband db
contains several plans for a MNC/MCC does ofono try them until one
works or is the selection left to user? Are there checks to make sure
the created context is valid for the network?
* If a ConnectionContext does not appear, UI/user may create one.
using ConnectionManager.AddContext() and
ConnectionContext.SetProperty().
Are there checks at this point to ensure that the created context is
valid and should work? If not, is there anythign I can do to check
context validity?
* Connman exposes a cellular service
What are the conditions for this to happen? If connman exposes a
service, should that "Just work" (with normal caveats about internet
connections) or does it appear for any context that has been created?
* Finally, user can connect the cellular service exposed by connman
If the connection with a cellular service fails, is there anything
else than "Error=connect-failed" to work with? What are the potential
reasons for this -- is it just the normal issues with any network
connection, or can e.g. broken APN settings be a reason for failure at
this point?
In case background helps to understand it, this uncertainty came to be
from two issues (possibly related ones):
1. a tester is telling me nothing happens when he selects his plan
using dawati networks panel (ofono is 1.0 so automatic context
creation does not work), in other words the service isn't appearing in
connman. Now, I know how to start digging to the specific problem in
this case, but I'd like to make sure I'm handling all the relevant
error cases... What are the possible points of failure in this? Is it
just the method calls in ConnectionManager and ConnectionContext plus
Connman Service.Error after trying to connect to the service?
2. I've been testing ofono 1.4 and it seems I can succesfully create a
context with any values of APN/username/password and a connman service
will appear. Is this supposed to happen? (Calling Connect() on this
service will timeout and in the end set "Error=connect-failed", which
is to be expected)
- Jussi
8 years, 5 months
HSO modem, apparent confusion between App and Control ports
by Neil Jerram
I'm using an HSO modem in a GTA04 device, and have a UI that, on session
startup, powers the modem on, and sets it online.
Sometimes - after roughly 50% of reboots - the setting online times out,
and I've established that this is because there's still a preceding
command in chat->command_queue, when hso_set_online() is called. So the
real problem is that the preceding AT command appears to the code not to
have completed.
I've looked at the logs and identified a significant-looking difference
between a good run and a bad one. In a good run, the ofonod log
(following powering on), leading up to the point of divergence, has:
Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT_OERCN?\r
Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n
Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3
Feb 27 22:01:59 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10
Feb 27 22:01:59 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28590\r
Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=176,28589,0,0,4\r
Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n
Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4
Feb 27 22:02:00 gta04 daemon.debug ofonod[983]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4
Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: > AT+CRSM=192,28438\r
Feb 27 22:02:00 gta04 daemon.info ofonod[983]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
But in a bad run, the last line is different:
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT_OERCN?\r
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n_OERCN: 3, 10\r\n\r\nOK\r\n
Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=1, val=3
Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:oercn_cb() retry counter id=9, val=10
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28590\r
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=176,28589,0,0,4\r
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: < \r\n+CRSM: 144,0,"00FFFF02"\r\n\r\nOK\r\n
Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 4
Feb 27 21:52:33 gta04 daemon.debug ofonod[996]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 4
Feb 27 21:52:33 gta04 daemon.info ofonod[996]: Control: > AT+CRSM=192,28438\r
Feb 27 21:52:34 gta04 daemon.info ofonod[996]: App: < \r\n+CRSM: 106,130,""\r\n\r\nOK\r\n\r\n_OSIGQ: 0,0\r\n\r\n+CREG: 0\r\n\r\n+CGREG: 0\r\n\r\n_OSSYSI: 3\r\n
I.e. firstly the AT+CRSM reply appears to be on the wrong channel, and
secondly it seems to have a whole load of further replies or unsolicited
indications tacked on.
If the problem isn't already obvious, from the above, can you advise
what more I can do to debug or fix this? It seems clear that the above
is wrong, but I don't yet understand ofono well enough to have a clue
what the right fix might be.
Thanks,
Neil
8 years, 5 months
