On Fri, Jun 30, 2017 at 1:00 AM, Aleksander Morgado
<aleksan...@aleksander.es> wrote:
> On 29/06/17 19:20, Eric Caruso wrote:
>> Thanks for taking a look at this!
>>
>> On Thu, Jun 29, 2017 at 3:22 AM, Carlo Lobrano <c.lobr...@gmail.com> wrote:
>>> Hi,
>>>
>>>> If I'm not mistaken, whenever a sim insert/removal event is detected, we
>>>> should just call
>>>> mm_broadband_modem_update_sim_hot_swap_detected(), which will trigger a
>>>> full modem re-probe.
>>
>> I had imagined that a full re-probe on SIM removal was overkill, and
>> the discussion in thread
>> https://lists.freedesktop.org/archives/modemmanager-devel/2014-February/000914.html
>> seemed to land on moving the modem into the failed state rather than
>> disabling it. I suppose the re-probe will re-initialize it and it will
>> get to the failed state because it doesn't have a SIM inserted, so I
>> can change this if that's what we want.
>>
>
> A full reprobe is a bit overkill, yes, but right now that's the only way to
> not only force the modem in Failed state but also make sure all feature
> interfaces get un-exported from DBus. A modem in failed state should only
> allow very few of the feature interfaces exposed, mainly those which would
> allow to get away from a failed state, like e.g. the Firmware interface.
>
> I'd suggest we keep the full reprobe for now, but also investigate the
> possibility of getting in the Failed state with the limited interfaces, as
> that would be much quicker.
Thanks, I'll do that for now and look into moving it into the failed
state in the future.
>
>>>
>>> yes, I confirm this. mm_broadband_modem_update_sim_hot_swap_detected will
>>> trigger full re-probe and disable current modem.
>>>
>>> Here is the code in telit plugin
>>>
>>>
>>> 133 if ((prev_qss_status == QSS_STATUS_SIM_REMOVED && cur_qss_status !=
>>> QSS_STATUS_SIM_REMOVED) ||
>>> 134 (prev_qss_status > QSS_STATUS_SIM_REMOVED && cur_qss_status ==
>>> QSS_STATUS_SIM_REMOVED)) {
>>> 135 mm_info ("QSS: SIM swap detected");
>>> 136 mm_broadband_modem_update_sim_hot_swap_detected
>>> (MM_BROADBAND_MODEM (self));
>>> 137 }
>>> The if condition is a bit complex here because we can have 4 different QSS
>>> states, but if we are tracing just 2 or them (SIM IN vs SIM OUT), and if I'm
>>> not wrong here, whenever last_ready_state and ready_state differ,
>>> mm_broadband_modem_update_sim_hot_swap_detected should be called
>>>
>>> if self->priv->last_ready_state != ready_state:
>>> mm_broadband_modem_update_sim_hot_swap_detected (...)
>>>
>>
>> If I'm not mistaken, the
>> basic_connect_notification_subscriber_ready_status callback will
>> trigger on any change in the subscriber ready state, so this would
>> catch other state changes such as unlocking the SIM.
>>
>
> I sure hope we're not reprobing completely on SIM unlock notifications...
> Carlo, could you confirm that?
It doesn't look like the telit QSS code does this since it looks for
specific QSS_STATUS_* states, and prior to this patch the only thing
basic_connect_notification_subscriber_ready_status would do is get the
own numbers off the SIM, so I'm not sure where it would be
reprobing...
>
>>>
>>> On 29 June 2017 at 11:08, Aleksander Morgado <aleksan...@aleksander.es>
>>> wrote:
>>>>
>>>> On 29/06/17 10:51, Aleksander Morgado wrote:
>>>>>> + if (self->priv->last_ready_state !=
>>>>>> MBIM_SUBSCRIBER_READY_STATE_SIM_NOT_INSERTED &&
>>>>>> + ready_state == MBIM_SUBSCRIBER_READY_STATE_SIM_NOT_INSERTED) {
>>>>>> + /* SIM has been removed */
>>>>>> + mm_iface_modem_update_failed_state (MM_IFACE_MODEM (self),
>>>>>> +
>>>>>> MM_MODEM_STATE_FAILED_REASON_SIM_MISSING);
>>>>>> + } else if (self->priv->last_ready_state ==
>>>>>> MBIM_SUBSCRIBER_READY_STATE_SIM_NOT_INSERTED &&
>>>>>> + ready_state !=
>>>>>> MBIM_SUBSCRIBER_READY_STATE_SIM_NOT_INSERTED) {
>>>>>> + /* SIM has been reinserted */
>>>>>> + mm_broadband_modem_update_sim_hot_swap_detected
>>>>>> (MM_BROADBAND_MODEM (self));
>>>>>> + }
>>>>>>
>>>>> If I'm not mistaken, whenever a sim insert/removal event is detected, we
>>>>> should just call mm_broadband_modem_update_sim_hot_swap_detected(), which
>>>>> will trigger a full modem re-probe. In this case the method is only being
>>>>> called for the case where the SIM is inserted, not for when the SIM is
>>>>> removed.
>>>>>
>>>>
>>>> Also, could you provide MM debug logs showing the SIM card hot insertion
>>>> and the SIM card hot removal?
>>
>> Removal puts this in the logs:
>>
>> 2017-06-29T09:52:09.749860-07:00 INFO ModemManager[7755]: <debug>
>> Received notification (service 'basic-connect', command
>> 'subscriber-ready-status')
>> 2017-06-29T09:52:09.749918-07:00 INFO ModemManager[7755]: <info> Modem
>> /org/freedesktop/ModemManager1/Modem/0: state changed (connected ->
>> failed)
>> 2017-06-29T09:52:09.759901-07:00 INFO ModemManager[7755]: <debug>
>> Disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0'
>> 2017-06-29T09:52:09.760052-07:00 INFO ModemManager[7755]: <info> Modem
>> /org/freedesktop/ModemManager1/Modem/0: state changed (failed ->
>> disconnecting)
>> 2017-06-29T09:52:09.760772-07:00 INFO ModemManager[7755]: <debug> Not
>> enabling periodic signal checks: unsupported
>> 2017-06-29T09:52:09.760832-07:00 INFO ModemManager[7755]: <debug>
>> Launching disconnection on data port (net/wwan0)
>>
>> and reinsertion puts this in the logs:
>>
>> 2017-06-29T09:54:02.475438-07:00 INFO ModemManager[7755]: <debug>
>> Received notification (service 'basic-connect', command
>> 'subscriber-ready-status')
>> 2017-06-29T09:54:02.475481-07:00 INFO ModemManager[7755]: <debug>
>> Releasing SIM hot swap ports context
>> 2017-06-29T09:54:02.475544-07:00 INFO ModemManager[7755]: <debug>
>> (ttyACM0) device open count is 1 (close)
>> 2017-06-29T09:54:02.475586-07:00 INFO ModemManager[7755]: <debug>
>> (ttyACM2) device open count is 1 (close)
>> 2017-06-29T09:54:02.475743-07:00 INFO ModemManager[7755]: <info> Modem
>> /org/freedesktop/ModemManager1/Modem/0: state changed (registered ->
>> disabling)
>> 2017-06-29T09:54:02.476583-07:00 INFO ModemManager[7755]: <debug>
>> Modem has time capabilities, disabling the Time interface...
>> 2017-06-29T09:54:02.476704-07:00 INFO ModemManager[7755]: <debug>
>> Modem has messaging capabilities, disabling the Messaging interface...
>> ...
>> 2017-06-29T09:54:02.506030-07:00 INFO ModemManager[7755]: <info> Modem
>> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
>> changed (idle -> unknown)
>> 2017-06-29T09:54:02.506323-07:00 INFO ModemManager[7755]: <debug>
>> Bearer not allowed to connect, not registered in 3GPP network
>> ...
>> 2017-06-29T09:54:02.515322-07:00 INFO ModemManager[7755]: <info> Modem
>> /org/freedesktop/ModemManager1/Modem/0: state changed (disabling ->
>> disabled)
>> 2017-06-29T09:54:02.516099-07:00 INFO ModemManager[7755]: <debug>
>> Removing from DBus bearer at '/org/freedesktop/ModemManager1/Bearer/0'
>> 2017-06-29T09:54:02.516145-07:00 INFO ModemManager[7755]: <debug>
>> [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1] unexported
>> modem from path '/org/freedesktop/ModemManager1/Modem/0'
>> ...
>> 2017-06-29T09:54:02.518943-07:00 DEBUG ModemManager[7755]: opening device...
>> ...
>> 2017-06-29T09:54:02.587822-07:00 INFO ModemManager[7755]: <debug>
>> loaded modem capabilities: gsm-umts, lte
>> 2017-06-29T09:54:02.587842-07:00 INFO ModemManager[7755]: <debug>
>> Setting EPS network as supported
>> 2017-06-29T09:54:02.588054-07:00 INFO ModemManager[7755]: <debug>
>> Modem allows up to 1 bearers
>> 2017-06-29T09:54:02.588074-07:00 INFO ModemManager[7755]: <debug>
>> Creating bearer list (max: 1, max active: 1)
>>
>> which looks like disabling and reprobing. Most of the elided stuff is
>> either raw MBIM messages or AT commands. Let me know if you want to
>> see anything else.
>>
>
> Ok, thanks.
>
> --
> Aleksander
> https://aleksander.es
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
