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 am doing some tests with Ofono.
Currently, I am trying to see if Ofono can handle an automatic data
reconnection in case of signal loss.
I am doing the following test :
- Connect the modem to data connection via atmodem driver (so PPP link)
- Disconnect the antenna to lose signal
- Reconnect the antenna to get signal back
- Try to get data connection back
The atmodem driver is notified that the signal is lost so it disconnects
ppp with "gprs-context.c:ppp_disconnect() Reason: 6".
After re-connecting the antenna and that the network is back, in the
Ofono interfaces, it did not changed, I always have the
ConnectionManager interface. The difference is that the context is not
activated. So, I try to re-activate it but it failed with error :
gprs.c:pri_activate_callback() Activating context failed with error:
Unknown error type
I guess that someone should have test it before me. If it is the case,
is there something I am doing wrong ? I do not know how Ofono should
react in this case. Maybe it should remove some interfaces ? Go in
"offline" mode ?
If nobody tested it before, what should I look for ?
Thank you in advance for any help and Merry Christmas :)
I'm working on adding gtk-doc support to oFono and is available publicly on
github . This job is currently based on my previous patches to clean up
So far the biggest problem is that it's going to add yet another
Makefile.am inside doc/, which breaks no-recursive make rule that is
currently enforced. However, that seems to be an inevitable side effect
when somebody is going to include gtk-doc in his project. I'd like to know
if you has other concerns before going ahead and posting the patches. For
me, oFono has done a great job in implementing core functions and bringing
support to various hardware. It just needs some more refactoring and
polishments to lower the effort to use it, and documentation is one of the
most important tasks on my list. What do you think?
Is there any way to set a timeout on AT commands send?
I'm experiencing some problems because in some situation my modem does not
answer to some AT command and I don't want for that to block my application.
The best solution would be to have a timeout parameter on at command send
to avoid this kind of problems.
I happen to find a strange property "IPv6.Settings" in ConnectionContext.
According to DBus specification , dbus member names can only be
consisted of character set "[A-Z][a-z][0-9]_" and may not begin with a
digit. Any plan to get rid of it? Or is a patch to this welcomed? It will
certainly break compatibility to existing programs.