Re: SAT support in oFono
Hi Lasse, 2011/1/24 Lasse Kunnasluoto lasse.kunnaslu...@tieto.com: Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. I think enabling these types of modems would require the stk driver API be able to give a bit of context to a proactive command. For example, indicating that a send SMS proactive command is for information purposes only, and that the SMS has been sent by the modem. Also some sort of feature negotiation between core and the stk drivers might be needed for instance for indicating whether the modem takes care of call control or not. The ISI modems are another variation on this topic, as there you need to use a specific request type to create calls with SIM toolkit turned off (= no call control). With the default request type and implementation, the call service would actually send the call control requests back towards the stk driver. This would likely cause the voicecall driver to be different, say, between the isiusb and n900 plugins. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/6] gprs-provision: add driver API header
Hi Jukka, 2011/1/24 Jukka Saunamaki jukka.saunam...@nokia.com: Then how about something like this: Lets make provisioning API synchronous (so that plugins do not need to care about SIM or other safety). In stead, if in gprs atom ofono_gprs_register() we notice the need for provisioning, ofono_sim_read(SPN) is called there. All issues would be localised there. Provisioning modules would be called with MCC,MNC,SPN as parameters. I think this is a better approach. It would reduce the role of the provisioning plugins to database abstraction only, which is essentially what they are. I think the provisioning atom/plugins also should not be modem specific, but just created once for all modems to use. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/6] gprs-provision: add driver API header
Hi Denis, 2011/1/21 Denis Kenzior denk...@gmail.com: How exactly are you guaranteeing that 'nothing bad should happen'? There is no cancellation mechanism that I see. Not to mention that the current ofono_sim_read API is not even safe either. For exactly the same reasons. This is a problem with all users of ofono_sim_read() at the moment. I suppose if the atoms get removed at different times, it may happen that after the gprs atom is gone, the SIM atom is still calling its read callback. Seems like we need some sort of cancellation API to ofono_sim_read(), or use Jukka's approach of a request object, perhaps with a GDestroyNotify parameter, or simply change the way atoms are created and removed so that this could be handled inside the SIM atom. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Lasse, I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list. Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111): - Call control by USIM - MO SMS Control by USIM Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. show us modem hardware where this is needed. At some point we just had to be realistic here in what can be tested with real hardware. And thus is really required to be supported and what makes sense in a smartphone environment. - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. I think the important phrase is wish list. So far nobody could really showed me the exact use case for BIP. I am actually really interested in understanding what the operators wanna use it for. I prefer to have hard facts here and not just wish list and probably. If this is not a requirement for certification and the operator is not actually using such a feature at all, then why bother. Feel free to convince me otherwise here. While we can certainly look into supporting BIP at some point, but from where I am standing it is pretty clear; first get all mandatory STK features sorted out, before trying to work on optional ones. - Extend support in PROVIDE LOCAL INFO What support are you looking for? Most of the information that is asked by provide local info is implemented in the modem firmware. We have only included support for items which are not covered by the firmware. If aiming GCF approval support should contain: IMEI, location info, network measurementsBCCH channel list, timing advance, access technology, IMEISV, Inter-frequency UTRAN measurements. As you said these are often handled by modem, but isn't possible that modem can be configured in a way it leaves the full control of SAT to the host? Although certain AT command based modems would require proprietary commands to fetch all the needed information. So in that sense it is more logical for modem to handle these commands what requires low level interfaces. What we have seen so far is that all of these are handled by the modem. If the modem has all information available, then why bother waking up the host CPU for this. It does make a lot of sense to keep the host CPU asleep if possible. I am pretty pragmatic here; if we have to support a modem that does not handle these, then we have to do it. So if you have more information about other modem types, please let us know. And patches are always welcome. - EVENT DOWNLOAD / SET UP EVENT LIST Again, which ones are you looking for? oFono explicitly ignores the following two events as these make no sense in the smartphone context: - Idle Screen Available - User Activity It looks like Idle Screen Available and User Activity User Activity are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability table. Rest of the sub-features are listed there. Don't they depend on the STK profile that you are using? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Aki, Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. I think enabling these types of modems would require the stk driver API be able to give a bit of context to a proactive command. For example, indicating that a send SMS proactive command is for information purposes only, and that the SMS has been sent by the modem. we have this kind of information coming from most modems. Question is just what to do with it. If the modem already send the SMS for example, then why bother the host CPU with that kind of information. You can check ofono_stk_proactive_command_handled_notify() for example which does this right now. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: ppp problem
Hi, I have got a problem about 3G connectrion from ofono, does anyone have idea to resolve it? The modem is huawei EM560. Here is the log: ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property Path ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property Registered ofonod[940]: plugins/udev.c:add_modem() /devices/pci:00/:00:00.7/usb1/1-1/1-1.2/1-1.2:2.1/tty/ttyACM0 (huawei) ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property ModemRegistered ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property PcuiRegistered ofonod[940]: plugins/udev.c:add_huawei() add_huaweiingg by hyq ofonod[940]: plugins/udev.c:add_huawei() name =OFONO_HUAWEI_TYPE by hyq ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property Modem ofonod[940]: src/modem.c:set_modem_property() m odem 0x8d49058 property ModemRegistered ofonod[940]: plugins/udev.c:add_huawei() after ofono_modem_register by hyq ppp=1 pcui=0 ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property Path ofonod[940]: plugins/udev.c:add_modem() /devices/pci:00/:00:00.7/usb1/1-1/1-1.2/1-1.2:2.3/tty/ttyACM1 (huawei) ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property ModemRegistered ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property PcuiRegistered ofonod[940]: plugins/udev.c:add_huawei() add_huaweiingg by hyq ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property HasVoice ofonod[940]: plugins/udev.c:add_huawei() after ofono_modem_register by hyq ppp=1 pcui=0 ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property Path ofonod[940]: plugins/udev.c:add_modem() /devices/pci:00/:00:00.7/usb1/1-1/1-1.2/1-1.2:2.7/tty/ttyACM2 (huawei) ofonod[940]: src/modem.c:g et_modem_property() modem 0x8d49058 property ModemRegistered ofonod[940]: src/modem.c:get_modem_property() modem 0x8d49058 property PcuiRegistered ofonod[940]: plugins/udev.c:add_huawei() name =OFONO_HUAWEI_TYPE by hyq ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property Pcui ofonod[940]: src/modem.c:set_modem_property() modem 0x8d49058 property PcuiRegistered [root@localhost test]# ./activate-context Entering new phase: 1 Entering new phase: 3 Entering new phase: 4 ofonod[815]: drivers/atmodem/gprs-context.c:ppp_connect() ofonod[815]: IP: 0.0.0.0 ofonod[815]: DNS: 0.0.0.0, 0.0.0.0 ofonod[815]: src/gprs.c:pri_activate_callback() 0xa063660 ppp0 no idea what goes wrong here, but the network or your modem firmware basically tells you that the IP address is not set. Run with OFONO_PPP_DEBUG=1 and see if it gives you more details. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] Expose voice call direction synchronously (fix MeeGo #12717)
Currently, the call direction can only be inferred from the signals. This adds a property to keep it visible also from GetCalls(). --- src/voicecall.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/voicecall.c b/src/voicecall.c index 7e2b3f0..d454d9d 100644 --- a/src/voicecall.c +++ b/src/voicecall.c @@ -352,7 +352,7 @@ static void append_voicecall_properties(struct voicecall *v, const char *callerid; const char *timestr; const char *name; - ofono_bool_t mpty; + ofono_bool_t mpty, originated; dbus_bool_t emergency_call; status = call_status_to_string(call-status); @@ -391,6 +391,10 @@ static void append_voicecall_properties(struct voicecall *v, timestr); } + originated = call-direction == CALL_DIRECTION_MOBILE_ORIGINATED; + ofono_dbus_dict_append(dict, Originated, DBUS_TYPE_BOOLEAN, + originated); + if (g_slist_find_custom(v-vc-multiparty_list, GINT_TO_POINTER(call-id), call_compare_by_id)) mpty = TRUE; -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] Document voicecall direction
--- doc/voicecall-api.txt |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt index 047b8cb..2feb215 100644 --- a/doc/voicecall-api.txt +++ b/doc/voicecall-api.txt @@ -102,6 +102,11 @@ Properties string LineIdentification [readonly] Contains the Name Identification information returned by the network, if present. + boolean Originated [readonly] + + Indicates whether the call was mobile-originated + (true) or mobile-terminated (false). + boolean Multiparty [readonly] Contains the indication if the voice call is part -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hello - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. I think the important phrase is wish list. So far nobody could really showed me the exact use case for BIP. I am actually really interested in understanding what the operators wanna use it for. I prefer to have hard facts here and not just wish list and probably. If this is not a requirement for certification and the operator is not actually using such a feature at all, then why bother. Feel free to convince me otherwise here. Sorry, still quite anecdotal, but I heard about a case related to RFC payment system, where operator wants to use BIP for loading payment application into SIM (I guess SMS-PP-data-download was not good enough for that). Also, at least some NFC plans use Smart Card Web Server (SCWS), that needs at least part of BIP. --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/3] Use pkglibdir where applicable
--- Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9933e32..f941a19 100644 --- a/Makefile.am +++ b/Makefile.am @@ -366,7 +366,7 @@ BUILT_SOURCES = $(local_headers) CLEANFILES = src/builtin.h $(BUILT_SOURCES) $(rules_DATA) -plugindir = $(libdir)/ofono/plugins +plugindir = $(pkglibdir)/plugins if MAINTAINER_MODE build_plugindir = $(abs_top_srcdir)/plugins/.libs -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 2/3] Use dist_ prefix as applicable
--- Makefile.am | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/Makefile.am b/Makefile.am index f941a19..1f09c11 100644 --- a/Makefile.am +++ b/Makefile.am @@ -25,17 +25,17 @@ local_headers = $(foreach file,$(pkginclude_HEADERS) \ if DATAFILES dbusconfdir = @DBUS_CONFDIR@ -dbusconf_DATA = src/ofono.conf +dist_dbusconf_DATA = src/ofono.conf if SYSTEMD systemdunitdir = @SYSTEMD_UNITDIR@ -systemdunit_DATA = src/ofono.service +dist_systemdunit_DATA = src/ofono.service endif confdir = $(sysconfdir)/ofono -conf_DATA = +dist_conf_DATA = statedir = $(localstatedir)/lib/ofono @@ -244,7 +244,7 @@ builtin_modules += phonesim builtin_sources += plugins/phonesim.c if DATAFILES -conf_DATA += plugins/phonesim.conf +dist_conf_DATA += plugins/phonesim.conf endif endif @@ -477,9 +477,7 @@ testdir = $(pkglibdir)/test test_SCRIPTS = $(test_scripts) endif -conf_files = src/ofono.conf plugins/phonesim.conf - -EXTRA_DIST = src/genbuiltin $(conf_files) $(udev_files) \ +EXTRA_DIST = src/genbuiltin $(udev_files) \ $(doc_files) $(test_scripts) dist_man_MANS = doc/ofonod.8 -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 3/3] Support for pkg-config
---
.gitignore |1 +
Makefile.am | 10 --
ofono.pc.in | 10 ++
3 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644 ofono.pc.in
diff --git a/.gitignore b/.gitignore
index 7cfb1d9..59308be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,6 +20,7 @@ install-sh
libtool
ltmain.sh
missing
+ofono.pc
stamp-h1
autom4te.cache
diff --git a/Makefile.am b/Makefile.am
index 1f09c11..e8570f8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,9 @@ local_headers = $(foreach file,$(pkginclude_HEADERS) \
$(nodist_pkginclude_HEADERS), \
include/ofono/$(notdir $(file)))
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = ofono.pc
+
if DATAFILES
dbusconfdir = @DBUS_CONFDIR@
@@ -364,7 +367,7 @@ src_ofonod_LDFLAGS = -Wl,--export-dynamic \
BUILT_SOURCES = $(local_headers)
-CLEANFILES = src/builtin.h $(BUILT_SOURCES) $(rules_DATA)
+CLEANFILES = src/builtin.h ofono.pc $(BUILT_SOURCES) $(rules_DATA)
plugindir = $(pkglibdir)/plugins
@@ -477,7 +480,7 @@ testdir = $(pkglibdir)/test
test_SCRIPTS = $(test_scripts)
endif
-EXTRA_DIST = src/genbuiltin $(udev_files) \
+EXTRA_DIST = src/genbuiltin ofono.pc.in $(udev_files) \
$(doc_files) $(test_scripts)
dist_man_MANS = doc/ofonod.8
@@ -572,5 +575,8 @@ include/ofono/%.h: include/%.h
$(AM_V_at)$(MKDIR_P) include/ofono
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$ $@
+%.pc: %.pc.in $(builddir)/config.status
+ $(AM_V_GEN)$(SHELL) ./config.status --file=$@ /dev/null
+
clean-local:
@$(RM) -rf include/ofono
diff --git a/ofono.pc.in b/ofono.pc.in
new file mode 100644
index 000..19f12e6
--- /dev/null
+++ b/ofono.pc.in
@@ -0,0 +1,10 @@
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+plugindir=${libdir}/@PACKAGE@/plugins
+includedir=@includedir@
+
+Name: oFono
+Description: oFono - Open Source Telephony
+Version: @VERSION@
+Cflags: -I${includedir}
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
SMS agent interface
Hello, If you aren't too busy, could you please check and comment on SMS agent interface? (the patches were sent on December 29th, maybe they were just missed somehow). Thanks! Regards, Oleg ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] Use pkglibdir where applicable
Hi Remi, Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Marcel, On Mon, 2011-01-24 at 12:49 +0200, Marcel Holtmann wrote: Hi Lasse, I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list. Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111): - Call control by USIM - MO SMS Control by USIM Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. show us modem hardware where this is needed. At some point we just had to be realistic here in what can be tested with real hardware. And thus is really required to be supported and what makes sense in a smartphone environment. Understand. Sorry, cannot give an example of such HW. But if we would follow the 31.111 literally the alpha id should be displayed to user. - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. I think the important phrase is wish list. So far nobody could really showed me the exact use case for BIP. I am actually really interested in understanding what the operators wanna use it for. I prefer to have hard facts here and not just wish list and probably. If this is not a requirement for certification and the operator is not actually using such a feature at all, then why bother. Feel free to convince me otherwise here. Main use case is that operator can update the SAT applet on the SIM remotely. Operators cannot really advertise or productize usage of BIP before enough terminals support it. SCWS introduces new ways of using SAT, you could build better UIs using a web browser to access SIM applets. This is the use case Jukka Saunamaki mentioned. While we can certainly look into supporting BIP at some point, but from where I am standing it is pretty clear; first get all mandatory STK features sorted out, before trying to work on optional ones. What is the 3GPP release you are aiming in STK support? Release 99, 4, 5 6,7? As it defines what is mandatory to support and to be tested in GCF. - Extend support in PROVIDE LOCAL INFO What support are you looking for? Most of the information that is asked by provide local info is implemented in the modem firmware. We have only included support for items which are not covered by the firmware. If aiming GCF approval support should contain: IMEI, location info, network measurementsBCCH channel list, timing advance, access technology, IMEISV, Inter-frequency UTRAN measurements. As you said these are often handled by modem, but isn't possible that modem can be configured in a way it leaves the full control of SAT to the host? Although certain AT command based modems would require proprietary commands to fetch all the needed information. So in that sense it is more logical for modem to handle these commands what requires low level interfaces. What we have seen so far is that all of these are handled by the modem. If the modem has all information available, then why bother waking up the host CPU for this. It does make a lot of sense to keep the host CPU asleep if possible. I am pretty pragmatic here; if we have to support a modem that does not handle these, then we have to do it. So if you have more information about other modem types, please let us know. And patches are always welcome. - EVENT DOWNLOAD / SET UP EVENT LIST Again, which ones are you looking for? oFono explicitly ignores the following two events as these make no sense in the smartphone context: - Idle Screen Available - User Activity It looks like Idle Screen Available and User Activity User Activity are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability table. Rest of the sub-features are listed there. Don't they depend on the STK profile that you are using? No. If a terminal claims to support USAT and be compliant with 3GPP e.g. Rel-7 or any other, certain features become mandatory, depending
Re: Problem configuring Longsung U6300
21.01.2011 18:26, Вячеслав Крот пишет: Hello, all. I have a little question - which driver should I use for modem Longsung U6300 based on Qualcomm MSM6290? I know that Huawei uses qualcomm chips, so I tried to add udev rule like for huawei modem, but it did not work. list-modes shows modem (online=0, powered=0, lockdown=0), but enable-modem fails with timeout exception. vendorId - 1c9e, productId - 9603. Could you help me, please? ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono On irc channel ZTE driver was proposed and it works quite good. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: SAT support in oFono
Hi Lasse, I am checking what is the level of SAT/STK support in ofono and have a couple of questions. The current implementation contains support for basic STK commands, like menus, inputs, calls, sms and so on. In TODO, there is only REFRESH command on the list. Is there plans or ideas to extend the support in oFono Core with more complex STK features like (3GPP TS 31.111): - Call control by USIM - MO SMS Control by USIM Let us set aside the the merits of the use cases for these features for the moment ;) Implementing Call control by USIM is fairly straightforward to do in the core. However, no modem manufacturer currently allows us to have full control over this feature. It is implemented in the firmware and every vendor does this differently. So for now support of this feature is in the realm of the modem driver. okay, so assuming this is how it is going stay. Even modem handles these, ofono should deliver possible AlphaId SIM may give in a response to call control envelope. I did not see if this is implemented. Or is it dropped since it is not tested in GCF.. show us modem hardware where this is needed. At some point we just had to be realistic here in what can be tested with real hardware. And thus is really required to be supported and what makes sense in a smartphone environment. Understand. Sorry, cannot give an example of such HW. But if we would follow the 31.111 literally the alpha id should be displayed to user. I have not tested this by myself, but judging from the code we do inform the STK agent even about commands handled by the modem. You checked up on the agent callback DisplayActionInformation, do you? - BIP (Bearer independent protocol), including commands like OPEN CHANNEL, CLOSE CHANNEL, SEND/RECEIVE DATA BIP is on many operators' wish list of supported SAT features. Even it is optional in 3GPP, some market areas will probably require BIP. I don't have an example to give right now. I think the important phrase is wish list. So far nobody could really showed me the exact use case for BIP. I am actually really interested in understanding what the operators wanna use it for. I prefer to have hard facts here and not just wish list and probably. If this is not a requirement for certification and the operator is not actually using such a feature at all, then why bother. Feel free to convince me otherwise here. Main use case is that operator can update the SAT applet on the SIM remotely. Operators cannot really advertise or productize usage of BIP before enough terminals support it. SCWS introduces new ways of using SAT, you could build better UIs using a web browser to access SIM applets. This is the use case Jukka Saunamaki mentioned. As mentioned SMS-PP-data-download is not good enough for what reason? While we can certainly look into supporting BIP at some point, but from where I am standing it is pretty clear; first get all mandatory STK features sorted out, before trying to work on optional ones. What is the 3GPP release you are aiming in STK support? Release 99, 4, 5 6,7? As it defines what is mandatory to support and to be tested in GCF. I think it will be 7 or later, but it does depend a little bit on what hardware we will test it. - EVENT DOWNLOAD / SET UP EVENT LIST Again, which ones are you looking for? oFono explicitly ignores the following two events as these make no sense in the smartphone context: - Idle Screen Available - User Activity It looks like Idle Screen Available and User Activity User Activity are mandatory features in 3GPP TS 31.124, chapter 3.4 Applicability table. Rest of the sub-features are listed there. Don't they depend on the STK profile that you are using? No. If a terminal claims to support USAT and be compliant with 3GPP e.g. Rel-7 or any other, certain features become mandatory, depending on certain conditions, like the HW capability, e.g. do you have a display, keypad etc. To check what is mandatory and what not in various 3GPP releases, you can check 3GPP TS 31.124, Table B.1. Conditions are in Table A.1. 31.124 is for 3G. Equivalent for 2G is 51.010-4 I let the people that are currently working GCF pre-certification worry about the details here. Feel free to provide any feedback that you might have on this topic. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Problem configuring Longsung U6300
Hi, I have a little question - which driver should I use for modem Longsung U6300 based on Qualcomm MSM6290? I know that Huawei uses qualcomm chips, so I tried to add udev rule like for huawei modem, but it did not work. list-modes shows modem (online=0, powered=0, lockdown=0), but enable-modem fails with timeout exception. vendorId - 1c9e, productId - 9603. Could you help me, please? On irc channel ZTE driver was proposed and it works quite good. we can either re-use ZTE driver or write a new one for these. However until I have access to these devices it becomes pretty hard. I tried to buy some of these while being in Japan last time, but they always try to tie you into contracts. We do have a proper collection for North America and European specific models, but I do like to get a set of Asian examples. So if anybody wants to donate some of these, please let us know. Adding support for these dongles is pretty simple once you figured out their quirks since all Qualcomm ones are broken one way or another. They all use outdated firmware. At least that is my experience. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v5] ifx: Adding modem selftest for Infineon modem
Infineon modem selftest, during ifx_enable().
Two steps trigger, with timeout. In case one
fails, modem will not power up.
---
plugins/ifx.c | 128
1 files changed, 109 insertions(+), 19 deletions(-)
diff --git a/plugins/ifx.c b/plugins/ifx.c
index 0d31167..efbf6b6 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -72,6 +72,8 @@
#define GPRS3_DLC 4
#define AUX_DLC 5
+#define IFX_SETUP_TIMEOUT 10
+
static char *dlc_prefixes[NUM_DLC] = { Voice: , Net: , GPRS1: ,
GPRS2: , GPRS3: , Aux: };
@@ -89,7 +91,7 @@ struct ifx_data {
guint dlc_poll_count;
guint dlc_poll_source;
guint dlc_init_source;
- guint mux_init_timeout;
+ guint cmd_setup_timeout;
guint frame_size;
int mux_ldisc;
int saved_ldisc;
@@ -100,6 +102,9 @@ struct ifx_data {
int audio_loopback;
struct ofono_sim *sim;
gboolean have_sim;
+ gboolean rtc_gti_selftest_timeout;
+ gboolean dev_ver_selftest_timeout;
+ gboolean mux_setup_timeout;
};
static void ifx_debug(const char *str, void *user_data)
@@ -434,10 +439,17 @@ error:
static void setup_internal_mux(struct ofono_modem *modem)
{
struct ifx_data *data = ofono_modem_get_data(modem);
+ GIOFlags flags;
int i;
DBG();
+ flags = g_io_channel_get_flags(data-device) | G_IO_FLAG_NONBLOCK;
+ g_io_channel_set_flags(data-device, flags, NULL);
+
+ g_io_channel_set_encoding(data-device, NULL, NULL);
+ g_io_channel_set_buffered(data-device, FALSE);
+
data-mux = g_at_mux_new_gsm0710_basic(data-device, data-frame_size);
if (data-mux == NULL)
goto error;
@@ -474,14 +486,17 @@ static void mux_setup_cb(gboolean ok, GAtResult *result,
gpointer user_data)
int fd;
DBG();
+ data-mux_setup_timeout = FALSE;
- if (data-mux_init_timeout 0) {
- g_source_remove(data-mux_init_timeout);
- data-mux_init_timeout = 0;
+ if (data-cmd_setup_timeout 0) {
+ g_source_remove(data-cmd_setup_timeout);
+ data-cmd_setup_timeout = 0;
}
- g_at_chat_unref(data-dlcs[AUX_DLC]);
- data-dlcs[AUX_DLC] = NULL;
+ if (data-dlcs[AUX_DLC]) {
+ g_at_chat_unref(data-dlcs[AUX_DLC]);
+ data-dlcs[AUX_DLC] = NULL;
+ }
if (!ok)
goto error;
@@ -519,26 +534,89 @@ error:
ofono_modem_set_powered(modem, FALSE);
}
-static gboolean mux_timeout_cb(gpointer user_data)
+static gboolean cmd_setup_timeout_cb(gpointer user_data)
{
struct ofono_modem *modem = user_data;
struct ifx_data *data = ofono_modem_get_data(modem);
- ofono_error(Timeout with multiplexer setup);
+ if (data-rtc_gti_selftest_timeout)
+ ofono_error(ERROR:IFX Selftest
+ at@rtc:rtc_gti_test_verify_32khz()-TIMEOUT);
+ else if (data-dev_ver_selftest_timeout)
+ ofono_error(ERROR:IFX Selftest
+ at@vers:device_version_id()-TIMEOUT);
+ else if (data-mux_setup_timeout)
+ ofono_error(ERROR:IFX Mux setup-TIMEOUT);
- data-mux_init_timeout = 0;
+ data-cmd_setup_timeout = 0;
- g_at_chat_unref(data-dlcs[AUX_DLC]);
- data-dlcs[AUX_DLC] = NULL;
+ if (data-dlcs[AUX_DLC]) {
+ g_at_chat_unref(data-dlcs[AUX_DLC]);
+ data-dlcs[AUX_DLC] = NULL;
+ }
- g_io_channel_unref(data-device);
- data-device = NULL;
+ if (data-device) {
+ g_io_channel_unref(data-device);
+ data-device = NULL;
+ }
ofono_modem_set_powered(modem, FALSE);
return FALSE;
}
+static void dev_ver_selftest_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ data-dev_ver_selftest_timeout = FALSE;
+
+ if (!ok) {
+ ofono_error(ERROR:IFX Selftest at@vers:device_version_id()
+ -FAILED);
+
+ if (data-dlcs[AUX_DLC]) {
+ g_at_chat_unref(data-dlcs[AUX_DLC]);
+ data-dlcs[AUX_DLC] = NULL;
+ }
+
+ if (data-device) {
+ g_io_channel_unref(data-device);
+ data-device = NULL;
+ }
+
+ ofono_modem_set_powered(modem, FALSE);
+ }
+}
+
+static void rtc_gti_selftest_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ data-rtc_gti_selftest_timeout = FALSE;
+
+ if (!ok) {
+
Re: [PATCH v5] ifx: Adding modem selftest for Infineon modem
Hi Robertino, Infineon modem selftest, during ifx_enable(). Two steps trigger, with timeout. In case one fails, modem will not power up. snip + flags = g_io_channel_get_flags(data-device) | G_IO_FLAG_NONBLOCK; + g_io_channel_set_flags(data-device, flags, NULL); + + g_io_channel_set_encoding(data-device, NULL, NULL); + g_io_channel_set_buffered(data-device, FALSE); + have you actually tested this patch. Your re-base of the patch is wrong again. It will not work like this. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/7] src: Introduced enum called_number_type
Hi George,
+/* 24.008 Section 10.5.4.7 Called party BCD number */
+enum called_number_type {
+ CALLED_NUMBER_TYPE_UNKNOWN = 0,
+ CALLED_NUMBER_TYPE_INTERNATIONAL = 1,
+ CALLED_NUMBER_TYPE_NATIONAL = 2,
+ CALLED_NUMBER_TYPE_NETWORK_SPECIFIC = 3,
+ CALLED_NUMBER_TYPE_DEDICATED_ACCESS = 4,
+ CALLED_NUMBER_TYPE_RESERVED = 7
+};
+
This isn't going to work. Your patches basically break all voice call
drivers that we have. I refer you to stemodem ecav_notify function or
the calypsomodem cpi parser. The number type is not handled properly there.
27.007 uses three main ton/npi combinations:
unknown / unknown (128)
unknown / isdn (129)
international / isdn (145)
If you want to be pedantic, then define an enum something like this:
enum number_type {
NUMBER_TYPE_UNKNOWN,
NUMBER_TYPE_UNKNOWN_ISDN,
NUMBER_TYPE_INTERNATIONAL_ISDN,
};
And just handle these three appropriately.
Alternatively decompose the value into the appropriate bit-fields and
compare the bit-field values. E.g. bits 1..4 - npi. Bits 5..7 - ton
and define enums for them appropriately. This will still be a messier
solution than assigning the values 128/129 (in fact 27.007 recommends
assigning these values anyway).
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] stk: change timeout from 10 to 3mintues
Hi Jeevaka, On 01/21/2011 12:04 PM, Jeevaka Badrappan wrote: --- src/stk.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Patch has been applied, thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] sim: check if lock is locked after code input attempt
Hi Jussi,
On 01/17/2011 05:34 AM, Jussi Kangas wrote:
Hi again,
This is third attempt to fix the problem where PUK required information
is not shown correctly after user tries to change pin code too many
times with wrong passwords. Basically solution is pretty much as in
original made by Marit Henriksen except it does not do the sim interface
initialization anymore and it goes to PRE_SIM state if PUK is required
except in case of PIN2. Fix is also extended to pin locking and pin
unlocking.
Br,
-Jussi
---
src/sim.c | 47 +++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index d627647..00f0463 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -622,6 +622,45 @@ static void sim_locked_cb(struct ofono_sim *sim,
gboolean locked)
sim_pin_retries_check(sim);
}
+static void fail_reason_check_cb(const struct ofono_error *error,
+ enum ofono_sim_password_type pin_type,
+ void *data)
+{
+ struct ofono_sim *sim = data;
+ DBusConnection *conn = ofono_dbus_get_connection();
+ const char *path = __ofono_atom_get_path(sim-atom);
+ struct ofono_modem *modem = __ofono_atom_get_modem(sim-atom);
+ const char *pin_name;
+
+ if (sim-pin_type != pin_type) {
+ sim-pin_type = pin_type;
+ pin_name = sim_passwd_name(pin_type);
+
+ if (pin_type != OFONO_SIM_PASSWORD_NONE
+ password_is_pin(pin_type) == FALSE)
+ pin_type = puk2pin(pin_type);
+
+ if (pin_type != OFONO_SIM_PASSWORD_INVALID)
+ sim-locked_pins[pin_type] = TRUE;
+
+ ofono_dbus_signal_property_changed(conn, path,
+ OFONO_SIM_MANAGER_INTERFACE,
+ PinRequired, DBUS_TYPE_STRING,
+ pin_name);
+
+ if ((sim-state != OFONO_SIM_STATE_READY) ||
+((sim-locked_pins[pin_type] == TRUE) (
Please don't mix tabs and spaces for indentation
+ pin_type == OFONO_SIM_PASSWORD_SIM_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHSIM_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHFSIM_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHNET_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHNETSUB_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHSP_PIN ||
+ pin_type == OFONO_SIM_PASSWORD_PHCORP_PIN)))
+ ofono_modem_reset(modem);
So I'm mostly happy with this approach except that ofono_modem_reset is
too big of a hammer to use here. We need something that drops us back
to pre-sim state without having to re-power on the device (which is what
reset does).
Can you try using sim_inserted / sim_removed or maybe even be smarter
and do 90% of what sim removal does but without affecting information
which is already read. So things like EFiccid, EFpl/EFlp, EFecc, etc.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] Use dist_ prefix as applicable
Hi Remi, Makefile.am | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/Makefile.am b/Makefile.am index f941a19..1f09c11 100644 --- a/Makefile.am +++ b/Makefile.am @@ -25,17 +25,17 @@ local_headers = $(foreach file,$(pkginclude_HEADERS) \ if DATAFILES dbusconfdir = @DBUS_CONFDIR@ -dbusconf_DATA = src/ofono.conf +dist_dbusconf_DATA = src/ofono.conf there was a reason why I did not do this. I need to figure out what it was or if it is something that doesn't apply to ofono.git tree. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/3] Support for pkg-config
Hi Remi, .gitignore |1 + Makefile.am | 10 -- ofono.pc.in | 10 ++ 3 files changed, 19 insertions(+), 2 deletions(-) create mode 100644 ofono.pc.in diff --git a/.gitignore b/.gitignore index 7cfb1d9..59308be 100644 --- a/.gitignore +++ b/.gitignore @@ -20,6 +20,7 @@ install-sh libtool ltmain.sh missing +ofono.pc stamp-h1 autom4te.cache diff --git a/Makefile.am b/Makefile.am index 1f09c11..e8570f8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -21,6 +21,9 @@ local_headers = $(foreach file,$(pkginclude_HEADERS) \ $(nodist_pkginclude_HEADERS), \ include/ofono/$(notdir $(file))) +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = ofono.pc + if DATAFILES dbusconfdir = @DBUS_CONFDIR@ @@ -364,7 +367,7 @@ src_ofonod_LDFLAGS = -Wl,--export-dynamic \ BUILT_SOURCES = $(local_headers) -CLEANFILES = src/builtin.h $(BUILT_SOURCES) $(rules_DATA) +CLEANFILES = src/builtin.h ofono.pc $(BUILT_SOURCES) $(rules_DATA) plugindir = $(pkglibdir)/plugins @@ -477,7 +480,7 @@ testdir = $(pkglibdir)/test test_SCRIPTS = $(test_scripts) endif -EXTRA_DIST = src/genbuiltin $(udev_files) \ +EXTRA_DIST = src/genbuiltin ofono.pc.in $(udev_files) \ $(doc_files) $(test_scripts) dist_man_MANS = doc/ofonod.8 @@ -572,5 +575,8 @@ include/ofono/%.h: include/%.h $(AM_V_at)$(MKDIR_P) include/ofono $(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$ $@ +%.pc: %.pc.in $(builddir)/config.status + $(AM_V_GEN)$(SHELL) ./config.status --file=$@ /dev/null + I do wanna keep this in sync with ConnMan actually. In ConnMan we create this one via configure.ac script. So I think we should do the same here as well. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
