GPRS re-connect problem
by August Mayer
Hello,
When connecting again to GPRS / PPP, after an Internet connection has
been closed previously, the connection seems to fail. It looks like the
ofono_modem serial data channel is completely closed when a PPP
connection is shut down. I'm using a Telit Modem, which provides several
serial ports, and am right now using separate serials for the AT chat
and the data/PPP; for this reason, the AT chat continues working, but
the data channel is dead.
My question is, is it somehow necessary to re-initialise the modem data
serial channel after a PPP connection? Or could there be a conceptual
problem that I have overlooked?
Many thanks & greetings August
--
Scanned by MailScanner.
7 years, 11 months
[PATCH 0/6] mmsd : Add delivery report support
by Ronald Tessier
This set of patches concerns mmsd and implements the first task listed in the
MMS Delivery Report section of TODO.
Ronald Tessier (6):
mmsutil: Add delivery report to send_req struct
doc: Modify SendMessage D-Bus API
service: Retrieve delivery-report parameter
mmsutil: Encode delivery-report in send_req msg
unit: Add delivery_report to send_req testing
test: Support delivery_report in Send-Message script
doc/service-api.txt | 3 ++-
src/mmsutil.c | 9 ++++++++-
src/mmsutil.h | 6 ++++++
src/service.c | 12 +++++++++++-
test/send-message | 19 +++++++++++++------
unit/test-mmsutil.c | 3 ++-
6 files changed, 42 insertions(+), 10 deletions(-)
--
1.7.4.1
7 years, 11 months
[PATCHv2 0/2] mmsd: new tasks definition
by Ronald Tessier
These patches concern mmsd and update documentation to describe new
functionalities to add to mmsd.
Ronald Tessier (2):
doc: Describe delivered group in storage doc
doc: Add new D-Bus methods to service interface
doc/service-api.txt | 20 ++++++++++++++++++++
doc/storage.txt | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
--
1.7.4.1
7 years, 11 months
[PATCH 0/6] phonesim: CBS/USSD improvments
by Philippe Nunes
-CBS message is encoded using the best CBS data coding scheme. In case of
non-GSM characters in the plain text body, the UCS-2 alphabet is used.
-CBS message is splitted automatically in pages if needed. The UI entries
related to the page number and the maximum of pages are removed since this is
handled internally.
-USSD answer and cancellation commands are now supported.
Philippe Nunes (6):
controbase: Remove entries in CBM UI
qcbsmessage: Add bestScheme method in QCBSMessage class
hardwaremanipulator: Use the best scheme for CBS message
hardwaremanipulator: Add multi-page support for CBS message
phonesim: Add support for USSD answer
phonesim: Add support for USSD session cancellation
src/control.cpp | 9 +--
src/controlbase.ui | 184 ++++++++++++++++---------------------------
src/default.xml | 14 ++++
src/hardwaremanipulator.cpp | 70 +++++++++-------
src/hardwaremanipulator.h | 6 +-
src/qcbsmessage.cpp | 10 ++-
src/qcbsmessage.h | 1 +
7 files changed, 137 insertions(+), 157 deletions(-)
--
1.7.9.5
7 years, 11 months
[PATCH] test-ussd: USSD request is optional to monitor SS interface
by Philippe Nunes
---
test/test-ussd | 60 ++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 41 insertions(+), 19 deletions(-)
diff --git a/test/test-ussd b/test/test-ussd
index c21f5e3..c8099b0 100755
--- a/test/test-ussd
+++ b/test/test-ussd
@@ -9,12 +9,28 @@ import dbus.mainloop.glib
state = None
+def clear_screen(numlines=100):
+ import os
+ if os.name == "posix":
+ os.system('clear')
+
+ elif os.name in ("nt", "dos", "ce"):
+ os.system('CLS')
+
+ else:
+ print '\n' * numlines
+
+def print_menu():
+ if state == "user-response":
+ print "Enter response (c for cancel - x for exit):"
+ elif state == "idle":
+ print "Enter USSD request (x for exit):"
+
def ussd_notification_received(content):
print("Network sent a Notification: " + content)
def ussd_request_received(content):
print("Network sent a Request: " + content)
- ss.Cancel()
def ussd_property_changed(name, value):
global state
@@ -23,23 +39,27 @@ def ussd_property_changed(name, value):
print("USSD session state is " + value)
state = str(value)
+ print_menu()
+
def stdin_handler(fd, condition):
- s = os.read(fd.fileno(), 160).rstrip()
- if not s:
- ss.Cancel()
+ s = os.read(fd.fileno(), 182).rstrip()
+
+ if s == 'c':
+ if state == "user-response" or state == 'active':
+ clear_screen
+ ss.Cancel()
+ elif s == 'x':
+ sys.exit(1)
elif state == "user-response":
+ clear_screen()
print ss.Respond(s, timeout = 100)
elif state == "idle":
+ clear_screen()
print ss.Initiate(s, timeout = 100)
- else:
- print "Invalid state", state
+
return True
if __name__ == "__main__":
- if (len(sys.argv) < 2):
- print "Usage: %s [modem] <ussd-string>" % (sys.argv[0])
- sys.exit(1)
-
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
@@ -50,24 +70,26 @@ if __name__ == "__main__":
modems = manager.GetModems()
modem = modems[0][0]
- if (len(sys.argv) == 2):
- ussd = sys.argv[1]
- else:
+ if (len(sys.argv) == 3):
modem = sys.argv[1]
- ussd = sys.argv[2]
ss = dbus.Interface(bus.get_object('org.ofono', modem),
'org.ofono.SupplementaryServices')
- props = ss.GetProperties()
- for p in props:
- ussd_property_changed(p, props[p])
-
ss.connect_to_signal("NotificationReceived", ussd_notification_received)
ss.connect_to_signal("RequestReceived", ussd_request_received)
ss.connect_to_signal("PropertyChanged", ussd_property_changed)
- print ss.Initiate(ussd, timeout=100)
+ if (len(sys.argv) > 1):
+ if (len(sys.argv) == 2):
+ ussd = sys.argv[1]
+ elif (len(sys.argv) == 3):
+ ussd = sys.argv[2]
+ print ss.Initiate(ussd, timeout=100)
+ else:
+ props = ss.GetProperties()
+ for p in props:
+ ussd_property_changed(p, props[p])
gobject.io_add_watch(sys.stdin, gobject.IO_IN, stdin_handler)
--
1.7.9.5
7 years, 11 months
[PATCH] bluetooth: ignore error if driver returns -EALREADY
by Luiz Augusto von Dentz
From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>
---
plugins/bluetooth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index dbf79eb..cb5fe24 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -275,7 +275,7 @@ static void bluetooth_probe(GSList *uuids, const char *path,
continue;
err = driver->probe(path, device, adapter, alias);
- if (err == 0)
+ if (err == 0 || err == -EALREADY)
continue;
ofono_error("%s probe: %s (%d)", driver->name, strerror(-err),
--
1.7.10.2
7 years, 11 months
oFono DUN server issue
by Guillaume Zajac
Hi,
I tested oFono DUN server to be sure it was still working with latest
oFono version, however I have an issue with udev/udevng.
My current "phone like" configuration is:
- laptop with Ubuntu 11.10
- oFono + ConnMan running together (network-manager + modem-manager
stopped)
- Huawei dongle for data connection
I am using a Windows 7 DUN client to connect to the laptop.
Binding with client is fine but when I try to dial to connect to the
server with the DUN client I got this into oFono log:
...
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty add
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty finished
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty move
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty finished
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty move
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty finished
ofonod[20340]: plugins/udevng.c:remove_device()
/sys/devices/virtual/tty/rfcomm0
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty remove
ofonod[20340]: plugins/udev.c:remove_modem() /devices/virtual/tty/rfcomm0
ofonod[20340]: plugins/udev.c:udev_event() subsystem tty finished
ofonod[20340]: plugins/udevng.c:check_modem_list()
...
and the DUN client is getting a timeout error.
Does anybody have any idea about this issue?
Thanks.
Kind regards,
Guillaume
7 years, 11 months
Motorola H.24 does not send its IP address during IPCP negotiation
by Joo
Hi,
I am using Motorola H.24 modem module with the external TCP/IP stack. It seems
like the H.24 modem module never send the network side (remote side) IP address
during the PPP negotiation. The following trace (from bottom to top) is capture
that turn on the IPCP negotiation:
119 : ipcp: down
119 : Could not determine remote IP address
119 : ipcp: up
119 : fsmOut:8-FF03802102050004
119 : ipcp: returning Configure-ACK
119 : input: 01050004
119 : fsmOut: FF0380210304000A030600000000
119 : ipcp: returning Configure-NAK
119 : input: 01040004
119 : fsmOut: FF0380210303000A030600000000
119 : ipcp: returning Configure-NAK
119 : input: 01030004
119 : input: 0203001603060AD3830D81060A0002FE83060A020224
119 : fsmOut: FF0380210302000A030600000000
119 : ipcp: returning Configure-NAK
119 : input: 01020004
119 : fsmOut: FF0380210103001603060AD3830D81060A0002FE83060A020224
119 : local IP address 10.211.131.13
119 : input: 0302001603060AD3830D81060A0002FE83060A020224
119 : fsmOut: FF0380210301000A030600000000
119 : ipcp: returning Configure-NAK
119 : input: 01010004
119 : fsmOut: FF03802101020016030600000000810600000000830600000000
119 : input: 0401000A0206002D0F01
119 : fsmOut:FF0380210300000A030600000000
119 : ipcp: returning Configure-NAK
119 : input: 01000004
116 : fsmOut: FF0380210101001C0306000000000206002D0F01810600000000830600000000
116 : Connect: ppp0 <--> /dev/ser0
116 : synxModuleConnectPSD: Success..
113 : synxModuleConnectPSD..
109 : synxModuleInit: success..
106 : synxModuleInit: ATE1..
101 : synxModuleInit: ATZ..
101 : synxModuleInit..
98 : synxModuleOn: Success..
97 : synxModuleOn..
96 : thttpd/2.20c 21nov01 starting on port 80
96 : Using interface ppp0
7 years, 11 months
oFono upstream test results_20120615
by Nicolas Paccou
Hello all,
Please find the test report of oFono v1.6 commit da80dd7.
During this testing, we ran 464 functional positive cases. 350 cases passed
and 114 are blocked due to missing software/missing hardware/Feature not
supported. The pass rate is 75%.
We found, reopened and verified no issue.
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 11.10 device.
Test Environment
oFono: v1.6 (updated to commit da80dd7)
usb_modeswitch: v1.2.3
modeswitch data: 20120120
Hardware: Laptop
Ubuntu: v11.10
Modem: Huawei E173u-2 - Operator & SIM Card: Orange SIM Card (data only) -
Phone number +33677646185 and other specific SIM Cards
Phonesim: v1.17 (updated to commit 6de7869)
Issue Summary
New bug:
None
Known bug:
None
Closed bug:
None
Test Result
SUMMARY
Total Test Case 464
Passed 350
Failed 0
Blocked 114
TCs completed 100,0%
Run rate 75%
Pass rate total 75%
Blocked rate total 24%
Pass rate of executed 100%
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 51 37 0 17
73% mainly on 3G Dongle (using appropriate SIM Card)
Messaging 26 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 16 13 0 3
81% Phonesim
Call Settings 13 9 0 4
69% 3G Dongle
Supplementary Services 60 53 0 7 88%
mainly on Phonesim
Call Meter 15 9 0 6
60% mainly on Phonesim
Call Barring 48 31 0 17
65% 3G Dongle (using appropriate SIM Cards)
Call Forwarding 5 5 0 0
100% Phonesim
SimToolKit 104 48 0 56
46% Phonesim
Please find details in the attached file
Notes
25% 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 modem to be able to test certain feature or case (e.g.:
network simulator or smartphone device to test PIN/PIN2 cases, Call Barring
etc.)
- Feature not supported by oFono
Best regards,
Nicolas
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
7 years, 11 months
