[sorry for the last mails where I got your last name mixed up...]
On 08/10/2017 07:03 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Could you send me the exact modem description you are using? So that we can write quirk?
> I am using TELIT 910 EUG Modem.
Okay, maybe that is already enough. I saw that in drivers/telit.c there
is already some code to handle variants of the modem. The matching is
done on these strings.
Are there any vid/pid available fot his modem?
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(-)
After the comments on the last patchset, as requested I tried to take
the approach where the serial support is merged into the existing ublox driver.
1. Not sure if filtering on device path is the right approach to identify a serial modem
2. This will not really work unless we fix the CEREG/CREG mess
3. There is still the CHAP NO_AUTH ppp issue also
4. There is an issue with missing support for AT+CGDATA for SARA ublox modems. Did not
find a better way than mandate atd99 for all ublox modems based on vendor. Maybe there
is a cleaner/better way?
Philippe De Swert (4):
ubloxmodem: pre-eliminary support for ublox SARA serial modems
plugins/ublox: Enable serial connection for an ublox modem
udev: Recognize ublox serial modems
atmodem: Use atd99 as ppp command for ublox
drivers/atmodem/gprs-context.c | 11 ++++---
drivers/ubloxmodem/lte.c | 9 ++++++
drivers/ubloxmodem/netmon.c | 2 ++
drivers/ubloxmodem/ubloxmodem.c | 14 +++++++++
drivers/ubloxmodem/ubloxmodem.h | 2 ++
plugins/ublox.c | 55 ++++++++++++++++++++++++++++++++-
plugins/udevng.c | 7 +++++
7 files changed, 95 insertions(+), 5 deletions(-)
When using RCR_REJECT no ppp connection will be established. It used to work before, and
this was a side-effect of commit 6fc119d9eaee5f9cc37a5a7198d1c55ef98fd645
See also this thread: https://lists.ofono.org/pipermail/ofono/2019-January/019067.html
gatchat/ppp_lcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gatchat/ppp_lcp.c b/gatchat/ppp_lcp.c
index 3fe38217..252b3cdc 100644
@@ -281,7 +281,7 @@ static enum rcr_result lcp_rcr(struct pppcp_data *pppcp,
- return RCR_REJECT;