Ofono with Sagem Hilo GPRS

[Bouteille Yoann]

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

[Denis Kenzior]

Hi Yoann,

<snip>

Post by Bouteille Yoann
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

[andrzej zaborowski]

Hi,

Post by Denis Kenzior
Hi Yoann,
<snip>

Post by Bouteille Yoann
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,

[Denis Kenzior]

Hi Andrew,

Post by andrzej zaborowski
Hi,

Post by Denis Kenzior
Hi Yoann,
<snip>

Post by Bouteille Yoann
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

[andrzej zaborowski]

Hi,

Post by Denis Kenzior

Post by Bouteille Yoann
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
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

[Denis Kenzior]

Hi Andrew,

Post by andrzej zaborowski

Post by Denis Kenzior
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.

Post by andrzej zaborowski
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

[andrzej zaborowski]

Hi Denis,

Post by Denis Kenzior

Post by andrzej zaborowski
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

[andrzej zaborowski]

 All in all I agree the polling should stay, atleast until it's
done correctly.

Sorry, I wanted to say "stay disabled".

Regards