huawei_disconnect is used to recovery the io and gprs context when
io error happends, see commit 39382730d7
However, io error not only happends at PPP disconnect, in theory it
can happends at any situation. I also observed that it happens when modem
go into offline mode at my Huawei EM770W modem. in this case, gprs should
not be reopened.
Sim state is already known after modem is enabled and there's no need to
query it again. Before this patch, query_sim_state() was called upon
huawei_enable() and huawei_pre_sim(). Both functions might call
notify_sim_state() with a valid state. Hence we could eventually end up
sending AT+CFUN=5 command twice.
If a "^SYSINFO" arrives after the timer for query_sim_locked() has been
set up, it'd would set a new timer, signaling a sim state change more
than once.
When SIM is locked, huawei modem does not send any notification about
SIM state change because it does not differentiate 'invalid' from
'locked'.
In order to be able to unlock the sim, this patch forces a notification
of a valid state after a timeout.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
The recently introduced online support to huawei didn't work with my
Huawei E1552. The problem was that with command AT+CFUN=1;+CFUN=5
the modem didn't initialise the sim state properly.
To fix this I changed the logic so that CFUN=5 is called only after the sim
state has switched to a valid state. Now my Huawei E1552 works with connman
again.
PIN locked SIMs still won't work. The problem is that it takes some time for
the sim state to go to a valid state:
Sep 20 15:01:57 dell-m520 ofonod[12451]: Pcui:< \r\n+CPIN: READY\r\n\r\nOK\r\n
[...]
Sep 20 15:02:00 dell-m520 ofonod[12451]: huawei: invalid sim state in post online (0)
[...]
Sep 20 15:02:01 dell-m520 ofonod[12451]: Pcui:< \r\n^SIMST:1\r\n
I don't know why it takes so long to get a valid state.
There is also another issue, in "cold start" case the phonebook
initialisation fails:
Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:> AT+CPBS=?\r
Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:< \r\n+CME ERROR: SIM busy\r\n
But in "warm start" it seems to work:
Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:> AT+CPBS=?\r
Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:< \r\n+CPBS: ("SM","EN","ON")\r\n\r\nOK\r\n
I consider this as a minor issue and didn't investigate it at all.
On my Huawei E1552 when I plug in the modem (ie. cold start) with PIN locked
SIM, the sim state is 255 (HUAWEI_SIM_STATE_NOT_EXISTENT). As the modem
doesn't send ^SIMST notifications, poll the sim state until it's ready.
In theory it might be possible to do this better, for example follow
^BOOT notifications or something, but it's unknown what parameter we
should check for.
Some newer Huawei modems have support for ^USSDMODE command which seems
to be default to 1. In that mode the text USSD is not working. Switching
it to 0 and text USSD works just fine. Assumption is that with this command
the modem switches between text and PDU mode for USSD. Currently it is
unclear on how the PDU mode is suppose to work all. So default to text mode
if this command is supported.
Huawei EM770W is a 3G WCDMA modem that supports HSPA/UMTS/EDGE/GPRS/GSM
data service and WCDMA/GSM short message services. It also has voice
call capability that supports both 2G and 3G network.
Huawei always closes the tty port after PPP disconnect. Handle this in
huawei plugin, similarly as done with novatel. Now there's no need
to unplug the modem after disconnection.
Tested with Huawei E1552.
Based on a patch by Marcel Holtmann:
commit 0329a6ceaf
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Mon Jun 7 02:36:12 2010 -0700
Reopen the GPRS context channel when the modem closes it after PPP
Instead of using ofono_modem_set_powered(), use ofono_sim_inserted_notify()
which is the proper way to notify about sim state changes.
Now the problem is that voicecall commands fail with my Huawei E1552:
ofonod[12395]: > AT+CRC=1\r
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+CLIP=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+COLP=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+CCWA=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: drivers/atmodem/voicecall.c:at_voicecall_initialized()
voicecall_init: registering to notifications
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: > AT^SYSINFO\r
ofonod[12395]: < \r\n^SYSINFO:0,0,0,0,255,,0\r\n\r\nOK\r\n
ofonod[12395]: > AT+CGMI\r
ofonod[12395]: < \r\nhuawei\r\n\r\nOK\r\n
ofonod[12395]: EventChannel: < \r\n^STIN:0,0,0\r\n
ofonod[12395]: > AT+CLCC\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
But as I can't make voice calls with this modem anyway, I don't worry
about them right now.
With Huawei E1552 I got sim busy errors when I plugged in the modem
and ofono was already running:
May 24 17:02:04 tukki ofonod[7619]: > AT+CRC=1\r
May 24 17:02:04 tukki ofonod[7619]: < \r\n+CME ERROR: SIM busy\r\n
May 24 17:02:04 tukki ofonod[7619]: > AT+CLIP=1\r
May 24 17:02:04 tukki ofonod[7619]: < \r\n+CME ERROR: SIM busy\r\n
Fix this by following sim state changes with ^SIMST notification and
only enable modem after SIM is ready. In case SIM is already ready
and we miss the notification for some reason, also use AT^SYSINFO
to check the state during enable phase.
Also change huawei_enable() to return -EINPROGRESS to make sure that
ofono modem is not powered too early. I believe this was a bug.
Martin Xu
Andras Domokos
Lucas De Marchi
Marcel Holtmann
Denis Kenzior
Kalle Valo
Pekka Pessi
João Paulo Rechi Vita
Zhenhua Zhang