12:46 a.m.
Hi,
I'am trying to work with the Ofono stack in our development around Sagem Hilo GPRS
hardware (SAGEM HiC,A.005.00).
So I git the sources, make and install it, configure to use the atgen plugin and the
atmodem driver.
Then I try to execute some tests' scripts :
enable-modem
enter-pin
list-modems
At this time I get :
[ /generic ]
Powered = 1
Interfaces = org.ofono.VoiceCallManager org.ofono.SimManager
Online = 0
Model = HILO GPRS
Manufacturer = SAGEM
Serial = 352218039849049
Revision = SAGEM HiC,A.005.00
[ org.ofono.VoiceCallManager ]
EmergencyNumbers = 119 118 999 110 08 000 911 112
MultipartyCalls =
Calls =
[ org.ofono.SimManager ]
SubscriberNumbers =
PreferredLanguages = fr
CardIdentifier = 89330118214678482630
LockedPins = pin
PinRequired = none
Present = 1
=> and enter in infinite loop :
ofonod[3221]: src/modem.c:get_modem_property() modem 0x8142058 property
status-poll-interval
ofonod[3221]: > AT+CSIM=8,A0F200C0\r
ofonod[3221]: < AT+CSIM=8,A0F200C0\r\r\n+CME ERROR: 3\r\n
Then if i disable and enable the modem again I get all the Interfaces for a short time :
[ /generic ]
Powered = 1
Interfaces = org.ofono.NetworkRegistration org.ofono.Phonebook
org.ofono.CallMeter org.ofono.SupplementaryServices
org.ofono.CallBarring org.ofono.CallSettings org.ofono.CallForwarding
org.ofono.MessageWaiting org.ofono.VoiceCallManager org.ofono.SimManager
Online = 1
Model = HILO GPRS
Manufacturer = SAGEM
Serial = 352218039849049
Revision = SAGEM HiC,A.005.00
[ org.ofono.NetworkRegistration ]
Status = registered
Strength = 75
Name = Orange F
Operators = /generic/operator/20801
LocationAreaCode = 12818
Mode = auto
CellId = 7965
[ org.ofono.Phonebook ]
[ org.ofono.CallMeter ]
[ org.ofono.SupplementaryServices ]
State = idle
[ org.ofono.CallBarring ]
[ org.ofono.CallSettings ]
[ org.ofono.CallForwarding ]
[ org.ofono.MessageWaiting ]
[ org.ofono.VoiceCallManager ]
EmergencyNumbers = 119 118 999 110 08 000 911 112
MultipartyCalls =
Calls =
[ org.ofono.SimManager ]
Present = 0
but after a while I get Online=0 and only the 2 Interfaces SimManager (Present=0 ???) and
VoiceCallManager (Emergency call) :
[ /generic ]
Powered = 1
Interfaces = org.ofono.VoiceCallManager org.ofono.SimManager
Online = 0
Model = HILO GPRS
Manufacturer = SAGEM
Serial = 352218039849049
Revision = SAGEM HiC,A.005.00
[ org.ofono.VoiceCallManager ]
EmergencyNumbers = 119 118 999 110 08 000 911 112
MultipartyCalls =
Calls =
[ org.ofono.SimManager ]
Present = 0
I put the debug log in attached file and the sequence scripts.
Is there the right way to manage ofono working with my Sagem Modem ?
Regards,
Yoann
5:11 a.m.
Hi Yoann,
<snip>
ofonod[3221]: src/modem.c:get_modem_property() modem 0x8142058
property
status-poll-interval ofonod[3221]: > AT+CSIM=8,A0F200C0\r
ofonod[3221]: < AT+CSIM=8,A0F200C0\r\r\n+CME ERROR: 3\r\n
The culprit was sim polling which performs CSIM pdus to detect a dead SIM.
Your modem doesn't seem to support CSIM command, so returns an error and oFono
foolishly thinks the SIM has been removed. For now I disabled this in the
atgen plugin, but the proper solution is for you to write a Sagem Hilo driver.
If you still have problems, let us know.
Regards,
-Denis
6:34 a.m.
Hi,
On 1 June 2010 21:11, Denis Kenzior <denkenz(a)gmail.com> wrote:
Hi Yoann,
<snip>
> ofonod[3221]: src/modem.c:get_modem_property() modem 0x8142058 property
> status-poll-interval ofonod[3221]: > AT+CSIM=8,A0F200C0\r
> ofonod[3221]: < AT+CSIM=8,A0F200C0\r\r\n+CME ERROR: 3\r\n
>
The culprit was sim polling which performs CSIM pdus to detect a dead SIM.
Your modem doesn't seem to support CSIM command, so returns an error and oFono
foolishly thinks the SIM has been removed.
Not if the +CME ERROR is sent withing 5 seconds. Only if there is a 5
second or longer lag between the AT+CSIM=... and the response (success
or error), it decides the card is dead.
Regards,
7:17 a.m.
Hi Andrew,
Hi,
On 1 June 2010 21:11, Denis Kenzior <denkenz(a)gmail.com> wrote:
> Hi Yoann,
>
> <snip>
>
>> ofonod[3221]: src/modem.c:get_modem_property() modem 0x8142058 property
>> status-poll-interval ofonod[3221]: > AT+CSIM=8,A0F200C0\r
>> ofonod[3221]: < AT+CSIM=8,A0F200C0\r\r\n+CME ERROR: 3\r\n
>
> The culprit was sim polling which performs CSIM pdus to detect a dead
> SIM. Your modem doesn't seem to support CSIM command, so returns an error
> and oFono foolishly thinks the SIM has been removed.
Not if the +CME ERROR is sent withing 5 seconds. Only if there is a 5
second or longer lag between the AT+CSIM=... and the response (success
or error), it decides the card is dead.
Thanks for the correction. I was hitting a slightly different issue with HSO
modem and atgen that was also resulting in sim removal.
Looking at the logs again, it seems that this response causes the poll to
signal sim removal:
ofonod[3253]: > AT+CRSM=192,28618\r
ofonod[3253]: < A
ofonod[3253]: < T+CRSM=192,28618\r
ofonod[3253]: < \000
ofonod[3253]: src/message-waiting.c:mw_remove() atom: 0x9ac6c00
ofonod[3253]: src/phonebook.c:phonebook_remove() atom: 0x9ac6a98
ofonod[3253]: src/sms.c:sms_remove() atom: 0x9ac69c0
ofonod[3253]: src/ssn.c:ssn_remove() atom: 0x9ac68f0
ofonod[3253]: src/call-barring.c:call_barring_remove() atom: 0x9ac6880
ofonod[3253]: src/call-meter.c:call_meter_remove() atom: 0x9ac6780
ofonod[3253]: src/network.c:netreg_remove() atom: 0x9ac62e8
ofonod[3253]: src/call-settings.c:call_settings_remove() atom: 0x9ac64f8
ofonod[3253]: src/call-forwarding.c:call_forwarding_remove() atom: 0x9ac6418
ofonod[3253]: src/ussd.c:ussd_remove() atom: 0x9ac4e70
ofonod[3253]: src/modem.c:set_modem_property() modem 0x9ac4058 property
status-poll-interval
ofonod[3253]: src/modem.c:unregister_property() property 0x9ac49d8
Seems we try to read EFmwis and get back a '\0' as a response. This probably
stalls the gatchat queue and causes the sim poll timeout to fire. Or is there
something else going on I'm not seeing?
There is another issue:
When we send the CPIN to unlock the PIN, the modem actually takes some time to
initialize the SIM and our CIMI request fails. This means that we don't
proceed with the initialization procedure. Disabling / Enabling the modem
skips the PIN entry and we initialize properly.
This modem's firmware is wonderful :)
Regards,
-Denis
7:46 a.m.
Hi,
On 1 June 2010 23:17, Denis Kenzior <denkenz(a)gmail.com> wrote:
> >> ofonod[3221]: src/modem.c:get_modem_property() modem
0x8142058 property
> >> status-poll-interval ofonod[3221]: > AT+CSIM=8,A0F200C0\r
> >> ofonod[3221]: < AT+CSIM=8,A0F200C0\r\r\n+CME ERROR: 3\r\n
> >
> > The culprit was sim polling which performs CSIM pdus to detect a dead
> > SIM. Your modem doesn't seem to support CSIM command, so returns an error
> > and oFono foolishly thinks the SIM has been removed.
>
> Not if the +CME ERROR is sent withing 5 seconds. Only if there is a 5
> second or longer lag between the AT+CSIM=... and the response (success
> or error), it decides the card is dead.
Thanks for the correction. I was hitting a slightly different issue with HSO
modem and atgen that was also resulting in sim removal.
Looking at the logs again, it seems that this response causes the poll to
signal sim removal:
ofonod[3253]: > AT+CRSM=192,28618\r
ofonod[3253]: < A
ofonod[3253]: < T+CRSM=192,28618\r
ofonod[3253]: < \000
ofonod[3253]: src/message-waiting.c:mw_remove() atom: 0x9ac6c00
ofonod[3253]: src/phonebook.c:phonebook_remove() atom: 0x9ac6a98
ofonod[3253]: src/sms.c:sms_remove() atom: 0x9ac69c0
ofonod[3253]: src/ssn.c:ssn_remove() atom: 0x9ac68f0
ofonod[3253]: src/call-barring.c:call_barring_remove() atom: 0x9ac6880
ofonod[3253]: src/call-meter.c:call_meter_remove() atom: 0x9ac6780
ofonod[3253]: src/network.c:netreg_remove() atom: 0x9ac62e8
ofonod[3253]: src/call-settings.c:call_settings_remove() atom: 0x9ac64f8
ofonod[3253]: src/call-forwarding.c:call_forwarding_remove() atom: 0x9ac6418
ofonod[3253]: src/ussd.c:ussd_remove() atom: 0x9ac4e70
ofonod[3253]: src/modem.c:set_modem_property() modem 0x9ac4058 property
status-poll-interval
ofonod[3253]: src/modem.c:unregister_property() property 0x9ac49d8
Seems we try to read EFmwis and get back a '\0' as a response. This probably
stalls the gatchat queue and causes the sim poll timeout to fire. Or is there
something else going on I'm not seeing?
Yes, it seems there's not much we can do when the queue gets stuck so
for each of these modems we need a custom driver. The sim polling
code thinks the card is dead because it counts the timeout from the
moment it submits the STATUS poll to the queue, not the moment the
command is executed. We need to either disable the polling or start
timer when the command is sent to modem.
If the device doesn't have a removable card, and there's a
vendor-specific PROACTIVE COMMAND notification then there's no point
polling. If the card is removable and modem doesn't support AT+CSIM,
we can send the status through AT+CRSM instead, maybe
atmodem/sim-poll.c should have a quirk for that.
Regards,
Andrew
8:13 a.m.
Hi Andrew,
> Seems we try to read EFmwis and get back a '\0' as a
response. This
> probably stalls the gatchat queue and causes the sim poll timeout to
> fire. Or is there something else going on I'm not seeing?
Yes, it seems there's not much we can do when the queue gets stuck so
for each of these modems we need a custom driver. The sim polling
code thinks the card is dead because it counts the timeout from the
moment it submits the STATUS poll to the queue, not the moment the
command is executed. We need to either disable the polling or start
timer when the command is sent to modem.
I'm still of the opinion this is not really relevant with today's hardware.
The modem will be doing its own polling and it makes no sense for the main
processor to do so as well (power consumption goes through the roof.)
However, it could be some vendor is actually crazy enough to require it.
If the device doesn't have a removable card, and there's a
vendor-specific PROACTIVE COMMAND notification then there's no point
polling. If the card is removable and modem doesn't support AT+CSIM,
we can send the status through AT+CRSM instead, maybe
atmodem/sim-poll.c should have a quirk for that.
I think we should assume that vendor specific STK notifications and non-
removable cards are the default, not the other way around.
We should keep sim polling out of atgen. Even initializing the stk atom in
atgen plugin is wrong due to how wildly different the modem implementations
are. People use atgen as the first driver to get started with oFono, so lets
keep its feature set conservative, or at least add more intelligence into the
atmodem stk driver. E.g. if CSIM is not supported / allowed, don't bother
doing anything.
However, this is now getting off-topic from the original discussion.
Regards,
-Denis
8:23 a.m.
Hi Denis,
On 2 June 2010 00:13, Denis Kenzior <denkenz(a)gmail.com> wrote:
> If the device doesn't have a removable card, and there's
a
> vendor-specific PROACTIVE COMMAND notification then there's no point
> polling. If the card is removable and modem doesn't support AT+CSIM,
> we can send the status through AT+CRSM instead, maybe
> atmodem/sim-poll.c should have a quirk for that.
I think we should assume that vendor specific STK notifications and non-
removable cards are the default, not the other way around.
The problem with the vendor specific notifications is we don't know
what they are (in atgen). Whereas it costs nothing to talk to the
card directly. This assumes that the modem will not read the
proactive commands out of the card before us, if we don't tell it to.
We probably would also need to do the profile download for this to
work. All in all I agree the polling should stay, atleast until it's
done correctly.
Cheers
4492
days inactive
4492
days old
7 comments
3 participants
participants (3)
-
andrzej zaborowski -
Bouteille Yoann -
Denis Kenzior