This patch reads and writes the call forwarding unconditional status
from and to the SIM depending on the SIM file availability.
New property needs to be added due to the fact that number won't be
available from the cphs-cff file.
Incase of SIM, EFcphs-cff file holds call forwarding status and it
is represented as a flag. In case of USIM(EFcfis), we have the status
flag and also number.So, adding new property for status and using the
existing VoiceUnconditional with number will work for both SIM and USIM cases.
Other option is to have 2 properties, "VoiceUnconditional" and "Number".
"VoiceUnconditional" will have the status of the call forwarding( "enabled",
"disabled") whereas the "Number" property will have the call forwared number.
offline-online state transitions results in caching the call forwaring status
every time. To avoid this, call forwarding atom is moved to the post sim and
its moved also due to the fact that call forwarding status doesn't change in
Jeevaka Badrappan (7):
call-forwarding: Read/Write cfis/cphs-cff
ifx: Move call forwarding to post sim
isigen: Move call forwarding to post sim
plugins/n900: Move call forwarding to post sim
phonesim: Move call forwarding to post sim
doc: Add new property to call forwarding
TODO: Marking the Read/Write EFcfis task as done
TODO | 9 --
doc/call-forwarding-api.txt | 5 +
doc/features.txt | 5 +
plugins/ifx.c | 2 +-
plugins/isigen.c | 2 +-
plugins/n900.c | 2 +-
plugins/phonesim.c | 3 +-
src/call-forwarding.c | 242 ++++++++++++++++++++++++++++++++++++++++++-
8 files changed, 256 insertions(+), 14 deletions(-)
I need your help in using a Telit HE910 with ofono (and eventually connman).
(I am using ofono 1.16 with HE910 firmware version 12.00.006; connman
version is 1.29).
My problem is the following ...
on startup everything works fine and the ppp0 connection is established,
but problems occur in the following case:
connmanctl> disconnect cellular_*_context15
connmanctl> connect cellular_*_context15
Error /net/connman/service/cellular_*_context15: Input/output error
ofonod: gprs-context.c(244):at_gprs_activate_primary() cid 1
ofonod: gprs.c(889):pri_activate_callback() 0x1a18c50
ofonod: gprs.c(893):pri_activate_callback() Activating context
failed with error: Unknown error type
connmand: Failed to change property: /he910_0/context15
org.ofono.ConnectionContext.Active: org.ofono.Error.Failed Operation failed
The same error happens if I am manually sending connect/disconnect via
Only a hard ofono restart can establish the connection again.
This behavior happens all the time once a ppp0 disconnect happened
(e.g. by removing the SIM; manual disconnect via dbus or connmanctl).
A subquestion regarding connman:
Can connmand be configured in such a way that on every connection
loss, ofono is triggered to reconnect to the Internet?
Thank you very muchin advance,
On 18.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Wed, 17 Jun 2015 23:07:53 -0500
> From: Denis Kenzior
> <denkenz(a)gmail.com> To: ofono(a)ofono.org Cc: tommi.kenakkala(a)tieto.com
> Subject: Re: [PATCH 1/2] [sim] Emit LockedPins after pin_type is queried
> Message-ID: <55824419.5080703(a)gmail.com> Content-Type: text/plain;
> charset=ISO-8859-1; format=flowed
> There is a subtlety here. OFONO_SIM_PASSWORD_NONE is never considered
> when emitting LockedPins. However, in this proposal you can trigger a
> LockedPins emission even if there's no PIN set.
> To me it seems like emitting LockedPins with an empty value seems
> unnecessary. Thoughts?
I agree. Initially there was a though but now I don't see any extra
value on emitting it. Updated patch submitted.
I am having issue in connecting 3G modem on my arm platform.
I am using connman(1.29) as my network manager and ofonod(1.14) and modem
is not been detected.
I have checked the logs
huawei_probe function is been called and hung there.
Any body can help on this one.
Events after inserting a card are as follows. Problem is
async steps 2 and 3+4 complete independently so client can't
rely on Present, CardIdentifier or other properties to know
when PinRequired and LockedPins are updated.
1. ofono_sim_inserted_notify > emit "Present" ==> sim_initialize
2. sim_iccid_read_cb > emit "CardIdentifier"
3. sim_efpl_read_cb > __ofono_sim_recheck_pin
==> "PinRequired" emitted at startup but not on pin-enabled hotswaps
==> "LockedPins" never emitted
These patches improve the situation.
Tommi Kenakkala (2):
[sim] Emit LockedPins after pin_type is queried
[sim] Reset pin_type on card remove
src/sim.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
On 16.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Tue, 16 Jun 2015 11:53:33 -0500 From: Denis Kenzior
> <denkenz(a)gmail.com> To: ofono(a)ofono.org Subject: Re: ofono Digest, Vol
> Today LockedPins is emitted only as a result of locking or unlocking the
> PIN. We can certainly look into emitting it when PinRequired is
> emitted. Do you already have a patch for this handy?
Sure, coming up.
> Yes, this sounds like a bug. We should always emit PinRequired on
> pin-enabled hotswaps.
>> >OFONO_SIM_PASSWORD_INVALID was used because at startup it's the initial
> Actually, it isn't. OFONO_SIM_PASSWORD_NONE is the initial value.
True. I incorrectly recalled value would be "0" which is what the struct
is initialised to.
>> >Logs about use-case: remove & insert a pin-required usim card.
>> >There's an additional __ofono_sim_recheck_pin call seen here after
>> >ofono_sim_inserted_notify from driver to core trigger a password query.
>> >Now when I look at it I'm not sure if it's still needed, but
>> >nevertheless even if it's removed monitor-ofono does not show
>> >"LockedPins" or "PinRequired" being emitted
>> >(logs and code analysis confirm that).
> ??? This seems wrong. Are you running upstream? We should not be
> querying the PIN until after we read EFpl
Like I wrote the logs show an additional __ofono_sim_recheck_pin call
but that's besides the point, the property signalling problem is still
valid in upstream even when the extra __ofono_sim_recheck_pin is removed.
Just FYI, it is there because upstream EFpl reading triggers password
query, but sometimes at that time modem returns still an old value. As a
workaround the driver needs to poke "core" ofono to re-query when it's
updated. But let's not focus to that, we're not upstreaming that :)
Let's continue the discussion in the patch thread,