RE: ofono Digest, Vol 20, Issue 28

From: ofono-request(a)ofono.org Subject: ofono Digest, Vol 20, Issue 28 To: ofono(a)ofono.org Date: Wed, 8 Dec 2010 02:55:29 -0800 Send ofono mailing list submissions to ofono(a)ofono.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ofono.org/listinfo/ofono or, via email, send a message with subject or body 'help' to ofono-request(a)ofono.org You can reach the person managing the list at ofono-owner(a)ofono.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ofono digest..." Today's Topics: 1. [PATCH 4/4] scripts: Added init.rc script (Jessica Nilsson) 2. RE: [PATCH] stkutil: fix crash issue cause by null length of text string (Lucas, GuillaumeX) 3. Re: [PATCH 1/3] plugins: Implementation of Network Time plugin (Marcel Holtmann) 4. Re: [PATCH 0/5] Call Counters (2nd) (Marcel Holtmann) 5. Re: [PATCH 1/3] plugins: Implementation of Network Time plugin (Aki Niemi) 6. Re: [PATCH 3/4] isimodem2.5: Changes to add isimodem2.5 (Marcel Holtmann) 7. Re: [PATCH 1/4] gisi: Changes to prepare for isimodem2.5 (Marcel Holtmann) 8. Re: [PATCH 0/5] Call Counters (2nd) (Aki Niemi) 9. Re: [RFC PATCH 2/4] modem: add EmergencyMode property (Denis Kenzior) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Dec 2010 09:35:29 +0100 From: Jessica Nilsson <jessica.j.nilsson(a)stericsson.com&gt; To: ofono(a)ofono.org Cc: Jessica Nilsson <jessica.j.nilsson(a)stericsson.com&gt; Subject: [PATCH 4/4] scripts: Added init.rc script Message-ID: <1291797329-20592-1-git-send-email-jessica.j.nilsson(a)stericsson.com&gt; Updates in Makefile.am and the adding of an init file. Regards, Jessica Nilsson --- Makefile.am | 10 +++++++ scripts/ofonod | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 89 insertions(+), 0 deletions(-) create mode 100755 scripts/ofonod diff --git a/Makefile.am b/Makefile.am index a5c89f2..0e6b761 100644 --- a/Makefile.am +++ b/Makefile.am @@ -82,6 +82,10 @@ gatchat_sources = gatchat/gatchat.h gatchat/gatchat.c \ udev_files = plugins/ofono.rules +if ISIMODEM25 +init_files = scripts/ofonod +endif + if UDEV builtin_modules += udev builtin_sources += plugins/udev.c @@ -562,3 +566,9 @@ include/ofono/%.h: include/%.h clean-local: @$(RM) -rf include/ofono + +if ISIMODEM25 +init-scripts: + $(AM_V_at)$(MKDIR_P) $(sysconfdir)/rc.d/init.d + @install -m 755 $(init_files) $(sysconfdir)/rc.d/init.d/ofonod +endif diff --git a/scripts/ofonod b/scripts/ofonod new file mode 100755 index 0000000..6f568e8 --- /dev/null +++ b/scripts/ofonod @@ -0,0 +1,79 @@ +#!/bin/sh + +# Init file for ofono daemon + +### BEGIN INIT INFO +# Provides: ofonod +# Required-Start: $local_fs cops msa +# Required-Stop: +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +# chkconfig: 2345 99 01 +# Short-Description: start and stop ofono +# Description: ofono +# Modem middleware for accessing the modem +# through phonet sockets. +### END INIT INFO + +progname=ofonod +execname=/usr/sbin/$progname +lockfile=/var/lock/subsys/$progname +options="" + +# Sanity check +[ -x $execname ] || exit 5 + +# Source function library. +. /etc/init.d/functions + +RETVAL=0 + +start() { + + echo -n "Starting $progname: " + /sbin/ifconfig shrm0 up + daemon $execname $options + RETVAL=$? + [ $RETVAL -eq 0 ] && touch $lockfile + echo + return $RETVAL +} + +stop() { + echo -n "Stopping $progname: " + killproc $progname + RETVAL=$? + echo + [ $RETVAL -eq 0 ] && rm -f $lockfile + return $RETVAL +} + +case "$1" in + start) + start + ;; + stop) + stop + ;; + reload) + ;; + restart|force-reload) + stop + start + ;; + status) + status $progname + RETVAL=$? + ;; + try-restart) + if [ -f $lockfile ]; then + stop + start + fi + ;; + *) + echo $"Usage: $0 {start|stop|restart|try-restart|reload|force-reload|status}" + RETVAL=$? +esac + +exit $RETVAL -- 1.7.3.2 ------------------------------ Message: 2 Date: Wed, 8 Dec 2010 08:37:19 +0000 From: "Lucas, GuillaumeX" <guillaumex.lucas(a)intel.com&gt; To: &quot;ofono(a)ofono.org&quot; <ofono(a)ofono.org&gt; Subject: RE: [PATCH] stkutil: fix crash issue cause by null length of text string Message-ID: <9F3EABD6E3419B4C81F34EAABB4D40188136D95D4B(a)irsmsx501.ger.corp.intel.com&gt; Content-Type: text/plain; charset="utf-8" Hi > > On 7 December 2010 22:55, <Jeevaka.Badrappan(a)elektrobit.com&gt; wrote: > > Hi Guillaume, > > > >> > >> According to 3GPP TS 31.124 a null length for the text string > >> should be allowed. An empty string must be returned to the > >> user in this case. > >> --- > >> ?src/stkutil.c | ? ?6 ++++-- > >> ?1 files changed, 4 insertions(+), 2 deletions(-) > >> > > > > Agree. As per the 3GPP TS 31.124 null text string will be indicated > with > > length 0. > > So, in first place if (text == NULL) check in > handle_command_get_input, > > handle_command_get_inkey has to be removed. Removing this check will > > result > > in crash due to the fact that we are not handling this case properly > > neither > > in parse_dataobj_text nor in corresponding stkagent functions. > > > > There are 2ways to solve this issue: > > > > First option - Fix provided in the function parse_dataobj_text( e.g. > > *text = "") > > Second option - In all the stk_agent_ function which has this text > > string we > > ? ? ? ? ? ? ? ?need to check for NULL and assign it to empty string > if > > it is NULL. > > > > First option seems to be right and also better one. > Agree. It's why I've did this one :) I'll be more explicit in the description for my future patches. Especially for crash issue. Regards, Guillaume --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------------------------------ Message: 3 Date: Wed, 08 Dec 2010 09:44:12 +0100 From: Marcel Holtmann <marcel(a)holtmann.org&gt; To: ofono(a)ofono.org Subject: Re: [PATCH 1/3] plugins: Implementation of Network Time plugin Message-ID: <1291797852.4795.137.camel@aeonflux> Content-Type: text/plain; charset="UTF-8" Hi Aki, > > > where is this timed running? I prefer the plugin just send a D-Bus > > > message to the timed directly instead of a Get/Changed API kind of > > > thing. > > > > AFAIK, timed is in system bus. However, I fail to see how you can make > > this any simpler. In the end, one of the two entities has to implement > > a service that the other one uses. There also needs to be some > > synchronization for when the entities start up. A getter/signal API is > > also what timed uses in Harmattan, but of course if you have a better > > idea, I'm all ears. > > is timed actually open source and I can have a look at it? so what about this? Where is the timed respository? I really wanna have a look at it and see what it is doing. Regards Marcel ------------------------------ Message: 4 Date: Wed, 08 Dec 2010 10:03:04 +0100 From: Marcel Holtmann <marcel(a)holtmann.org&gt; To: ofono(a)ofono.org Subject: Re: [PATCH 0/5] Call Counters (2nd) Message-ID: <1291798984.4795.146.camel@aeonflux> Content-Type: text/plain; charset="UTF-8" Hi Aki, > > Here a proposal for call counters implementation for keeping track > > of the total incoming and outgoing call duration counters. Each > > established call instance is contributing to either of the call > > duration counters. The 2 counters are updated periodically when > > there is an established call and the information is stored in > > a file. The bookkeeping of the call duration counters are per IMSI > > number. > > The implementation makes use of the history framework which had to be > > expanded with a function for marking the beginning of a voice call. > > There is a D-Bus interface to call counters for reading and clearing > > the counters. > > This set looks good to me, and I believe you fixed the issues from > previous review comments. Denis, are you ok with this? so Denis and I talked about this a little bit and I am not fine with this at all. Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API. My main concerns are here that we are waking up ofonod every 10 seconds and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API. What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here. In addition to that, what is the problem with just updating the stats after the call has ended? Are you really expecting realtime updates of call time stats for some hidden UI stats menu? This would be a really expensive change for just doing that. Has anybody looked at how we are doing realtime stats inside ConnMan? Regards Marcel ------------------------------ Message: 5 Date: Wed, 8 Dec 2010 11:19:48 +0200 From: Aki Niemi <aki(a)protocolpolice.com&gt; To: ofono(a)ofono.org Subject: Re: [PATCH 1/3] plugins: Implementation of Network Time plugin Message-ID: <AANLkTin6KXd0UMq8acZojmScyBPMssSWhH2+bNezgx8T(a)mail.gmail.com&gt; Content-Type: text/plain; charset=UTF-8 Hi Marcel, 2010/12/8 Marcel Holtmann <marcel(a)holtmann.org&gt;: >> is timed actually open source and I can have a look at it? > > so what about this? Where is the timed respository? I really wanna have > a look at it and see what it is doing. Knock yourself out: http://meego.gitorious.org/meego-middleware/timed Cheers, Aki ------------------------------ Message: 6 Date: Wed, 08 Dec 2010 10:30:04 +0100 From: Marcel Holtmann <marcel(a)holtmann.org&gt; To: ofono(a)ofono.org Cc: Jessica Nilsson <jessica.j.nilsson(a)stericsson.com&gt; Subject: Re: [PATCH 3/4] isimodem2.5: Changes to add isimodem2.5 Message-ID: <1291800604.4795.151.camel@aeonflux> Content-Type: text/plain; charset="UTF-8" Hi Jessica, > Updates in Makefile.am - adding of isimodem2.5 > Adding of drivers/isimodem2.5/ files to fully listed functionality. > > Regards, > Jessica Nilsson > > --- > Makefile.am | 36 +- > drivers/isimodem2.5/call-barring.c | 503 ++ > drivers/isimodem2.5/call-forwarding.c | 613 +++ > drivers/isimodem2.5/call-settings.c | 1093 +++++ > drivers/isimodem2.5/call.h | 237 + > drivers/isimodem2.5/cbs.c | 433 ++ > drivers/isimodem2.5/checkpatch.pl | 2789 ++++++++++++ > drivers/isimodem2.5/debug.c | 694 +++ > drivers/isimodem2.5/debug.h | 66 + > drivers/isimodem2.5/devinfo.c | 246 + > drivers/isimodem2.5/gpds-context.c | 788 ++++ > drivers/isimodem2.5/gpds.c | 395 ++ > drivers/isimodem2.5/gpds.h | 295 ++ > drivers/isimodem2.5/gss.h | 84 + > drivers/isimodem2.5/info.h | 53 + > drivers/isimodem2.5/isimodem.c | 534 +++ > drivers/isimodem2.5/isimodem.h | 69 + > drivers/isimodem2.5/isiutil.h | 64 + > drivers/isimodem2.5/mce.h | 65 + > drivers/isimodem2.5/network-registration.c | 1158 +++++ > drivers/isimodem2.5/network.h | 257 ++ > drivers/isimodem2.5/phonebook.c | 1320 ++++++ > drivers/isimodem2.5/radio-settings.c | 313 ++ > drivers/isimodem2.5/simu_resps.h | 6800 ++++++++++++++++++++++++++++ > drivers/isimodem2.5/sms.c | 869 ++++ > drivers/isimodem2.5/sms.h | 188 + > drivers/isimodem2.5/ss.h | 174 + > drivers/isimodem2.5/ssn.c | 456 ++ > drivers/isimodem2.5/timeout.h | 33 + > drivers/isimodem2.5/uicc.c | 3316 ++++++++++++++ > drivers/isimodem2.5/uicc.h | 253 ++ > drivers/isimodem2.5/uicc_interface.h | 40 + > drivers/isimodem2.5/ussd.c | 341 ++ > drivers/isimodem2.5/voicecall.c | 1555 +++++++ > 34 files changed, 26128 insertions(+), 2 deletions(-) > create mode 100644 drivers/isimodem2.5/call-barring.c > create mode 100644 drivers/isimodem2.5/call-forwarding.c > create mode 100644 drivers/isimodem2.5/call-settings.c > create mode 100644 drivers/isimodem2.5/call.h > create mode 100644 drivers/isimodem2.5/cbs.c > create mode 100755 drivers/isimodem2.5/checkpatch.pl > create mode 100644 drivers/isimodem2.5/debug.c > create mode 100644 drivers/isimodem2.5/debug.h > create mode 100644 drivers/isimodem2.5/devinfo.c > create mode 100644 drivers/isimodem2.5/gpds-context.c > create mode 100644 drivers/isimodem2.5/gpds.c > create mode 100644 drivers/isimodem2.5/gpds.h > create mode 100644 drivers/isimodem2.5/gss.h > create mode 100644 drivers/isimodem2.5/info.h > create mode 100644 drivers/isimodem2.5/isimodem.c > create mode 100644 drivers/isimodem2.5/isimodem.h > create mode 100644 drivers/isimodem2.5/isiutil.h > create mode 100644 drivers/isimodem2.5/mce.h > create mode 100644 drivers/isimodem2.5/network-registration.c > create mode 100644 drivers/isimodem2.5/network.h > create mode 100644 drivers/isimodem2.5/phonebook.c > create mode 100644 drivers/isimodem2.5/radio-settings.c > create mode 100644 drivers/isimodem2.5/simu_resps.h > create mode 100644 drivers/isimodem2.5/sms.c > create mode 100644 drivers/isimodem2.5/sms.h > create mode 100644 drivers/isimodem2.5/ss.h > create mode 100644 drivers/isimodem2.5/ssn.c > create mode 100644 drivers/isimodem2.5/timeout.h > create mode 100644 drivers/isimodem2.5/uicc.c > create mode 100644 drivers/isimodem2.5/uicc.h > create mode 100644 drivers/isimodem2.5/uicc_interface.h > create mode 100644 drivers/isimodem2.5/ussd.c > create mode 100644 drivers/isimodem2.5/voicecall.c this is not gonna work this way. No one can review such a massive patch. Actually Evolution even refused to format this for me. So please split this into one patch per atom driver. In addition, I don't a point in a filename. So isimodem25 or isimodem2 or something like that please. I am open for proposals. Regards Marcel ------------------------------ Message: 7 Date: Wed, 08 Dec 2010 10:31:35 +0100 From: Marcel Holtmann <marcel(a)holtmann.org&gt; To: ofono(a)ofono.org Cc: Jessica Nilsson <jessica.j.nilsson(a)stericsson.com&gt; Subject: Re: [PATCH 1/4] gisi: Changes to prepare for isimodem2.5 Message-ID: <1291800695.4795.153.camel@aeonflux> Content-Type: text/plain; charset="UTF-8" Hi Jessica, > This set of patches introduces the isimodem2.5. > > WG2.5 (isimodem2.5) Supported features list: > > General: > Online / Offline mode (RF on/off) > > Voice call: > MO/MT call > Multiparty call (max 7 calls) > Transfer call > Swap calls > Hold calls > Hang up all > Hang up specific call > Disconnect reason (Network/local/remote) > Send DTMF tones > > PS data: > Primary PDP context (IPv4 only) > APN: User name and password supported > Attach mode: Manual (Automatic works as well, but not activated) > Data flow control not activated (Not supported by Kernel) > > SMS: > Send and receieve SMS > Concatenated messages supported (up to 255 messages) > Class 0 > Delivery reports > Read / Write SMSC to SIM card > Bearer settings supported (CS or PS) > > Supplementary Services: > Call Barring > VoiceOutgoing > VoiceIncoming > Call Settings > CalledLineRestriction > HideCallerId > CallingLinePresentation > CalledLinePresentation > VoiceCallWaiting > CallingLineRestriction > Call Forwarding > Voice Not Reachable > Voice Busy > Voice No Reply > Voice Unconditional > USSD > MO USSD > MT USSD NOT SUPPORTED > SSN > > CS Network: > Network registration > Scanning available networks > Selecting automatically and manually the target network > Changing RAT between GSM/UMTS/ANY > Registration status: Cell ID, LAC, MNC, Current Technology (GSM, UMTS, > EDGE, HSDPA, HSUPA, HSDPA&HSUPA) > Deregister > RSSI (%) > > SIM: > Read IMSI > MSISDN (Subscriber numbers) > SDN (Service Dialing Numbers) > PIN/PIN2/PUK/PUK2 supported (reset/change/lock) > Read file info from SIM > Read FIle (Transparent, Linear & Cyclic) * Some functionalities flagged > out as ofono core is not using these > Write File (Transparent, Linear & Cyclic) * Some functionalities flagged > out as ofono core is not using these > MCC & MNC > CardIdentifier > PreferredLanguages > > Export contacts(SIM phonebook): > SIM and USIM cards supported > Name > Number (extension record supported) > Additional number > Email > No limitiation in amount of records read from SIM > > CBS: > CBS reception in GSM > Subscribe Topics in range or specific value > > Phone Info: > Revision of the modem SW > IMEI > > This specific patch contains updates in Makefile.am, configure.ac and gisi to prepare the addition of isimodem2.5 > Added 2 new files to gisi pipe_wg25.c and pipe_wg25.h, isimodem2.5 pipe implementation due to pipe handler not on modem side. this needs to be split into separate patches and the commit message needs to be a bit cleaner. Also is this in sync with the GISI re-write Aki is doing? Regards Marcel ------------------------------ Message: 8 Date: Wed, 8 Dec 2010 11:34:40 +0200 From: Aki Niemi <aki(a)protocolpolice.com&gt; To: ofono(a)ofono.org Subject: Re: [PATCH 0/5] Call Counters (2nd) Message-ID: <AANLkTinYryk1jdhdVRXh1RXn5CvwrD_A8y2GPBcP0ZsK(a)mail.gmail.com&gt; Content-Type: text/plain; charset=UTF-8 Hi Marcel, 2010/12/8 Marcel Holtmann <marcel(a)holtmann.org&gt;: > so Denis and I talked about this a little bit and I am not fine with > this at all. Next time, can you invite me to join your little talk? > Lets take this one step and please explain to me what your requirements > and objectives are. I also wanna see a top to bottom from UI down to the > modem usage of this API. We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable. > and consuming heavy IO with writing this information to disk. In > addition to that there is no clear UI usage for the getter API. What do you mean? Do you mean your iPhone has no such UI? The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide. > What are the granularity there. What is the expected user experience > with this API. I don't see any clear usage model here. > > In addition to that, what is the problem with just updating the stats > after the call has ended? Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear. Andras has some data on what reasonable reliability here means. Cheers, Aki ------------------------------ Message: 9 Date: Wed, 08 Dec 2010 04:55:21 -0600 From: Denis Kenzior <denkenz(a)gmail.com&gt; To: ofono(a)ofono.org Subject: Re: [RFC PATCH 2/4] modem: add EmergencyMode property Message-ID: <4CFF6419.3090402(a)gmail.com&gt; Content-Type: text/plain; charset=ISO-8859-1 Hi Pekka, >> So my only major concern left is here actually. If we activate an >> emergency call and a set_property(Online, blah) is active, we get into >> some funny race conditions. I mentioned these to Pekka on IRC. But >> basically the worst one is if we have an Online=False operation pending. >> In this case your call proceeds, but then gets terminated shortly >> thereafter by the offline procedure ;) > > That is a tricky problem. I'd say the most straightforward way is to > return an error if there is a pending operation and push these > problems up the stack. In any case dialer has to retry ecall if user > tries to make the emergency call just after or before moving device to > offline / removing SIM card / etc. However, I'm not sure if we can > propagate the error in all cases where ofono_modem_inc_emergency() > gets called. There's really no way for the voicecall atom to know that a modem is undergoing an online / offline transition.. > > In order to manage the worst case in best possible manner, I'd check > for set_online in progress here. Return FALSE from > ofono_modem_get_online() immediately after the set_online(FALSE) call > is made. Also, check the emergency state again in after set_online > callback response. The online/offline watches should be called before > the set_online() call. (I have no idea what we will do should > set_online(FALSE) fail)? > So my thinking was essentially along the same lines. We can check whether an Online change operation is in progress by peeking at the pending D-Bus message. If we're going online, then not triggering another set_online call and waiting for the online_cb should be sufficient. If we're going offline, then returning FALSE from ofono_modem_get_online and re-checking the emergency counter in the offline_cb seems like the way to go. I'd like to take care of this completely inside oFono and not bother the dialer with these details. Thoughts? Regards, -Denis ------------------------------ _______________________________________________ ofono mailing list ofono(a)ofono.org http://lists.ofono.org/listinfo/ofono End of ofono Digest, Vol 20, Issue 28 *************************************