Re: [RFC] New probing-related status in ModemManager

[Aleksander Morgado <aleksander lanedo com>]

Hey Dan,

>> One of the things that annoys me when using ModemManager is that 
>> whenever I plug in a modem, I need to wait for the modem to get all 
>> ports probed before I can see the NM applet updated with the new 
>> broadband-related menu elements. In the worst case, where the modem just 
>> returns errors to probing, I may end up waiting forever unless I check 
>> syslog.
>>
>> This long time to wait is mainly related to the fact that we probe all 
>> ports of the modem trying to send several AT commands, or even trying to 
>> see if the port is QCDM and such.
> 
> One reason here is that we don't know whether or not the modem will have
> more than one usable port.  If, for example, one port responds very
> quickly which triggers creation of the modem object in D-Bus, which is
> then noticed by a connection manager which then attempts to start a WWAN
> connection, we may be still probing other ports when the connection
> request starts.  It made the code a lot simpler to ensure that we had
> fully found the modem before exposing it.
> 
> It might be simple enough to just ensure that we have at least two
> ports: the Data port and the Command port (whether AT, QMI, WMC, or
> QCDM/DIAG), and then expose the modem, and let the other ports finish
> probing after we have what we need.
> 

It should be very simple to export the modem in DBus as soon as the
initialization sequence is finished; but only allowing to get it enabled
once all the ports have been probed. That should be quite a safe fix to
have. I will hack this in the 06-api branch if no one opposes.

> I'm not opposed to tagging certain ports via udev rules if we know they
> are going to be QMI or WMC or whatever too; I'm just against using that
> as the primary mechanism because it can and does change, especially for
> vendors that use the same USB IDs for multiple deivces, which happens
> often with phones and ZTE dongles.  Tagging here can speed up probing
> too since we could skip a useless AT probe on a QCDM port.
> 
> As long as we have logic in place to walk the parent/child relationships
> and always match up ports with their parent modem (so that we never get
> two USB interfaces of the same physical device exposed as two modems
> over D-Bus) then it doesn't really matter when the modem is exposed as
> long as we have a full understanding of it's capabilities.
> 
> One other note; we may not be able to detect that a device supports EVDO
> until we can query it with QCDM/DIAG since sometimes the AT+GCAP won't
> report that.  So capabilities need to be able to change too, but that
> was the whole point of the 06-api so that shouldn't be an issue there.

Capabilities as defined in the 06-api don't differentiate between CDMA1x
and EVDO; do you mean that no CDMA-related capability is given in
AT+GCAP? anyway, for that specific case we may just run the
initialization sequence once the first AT port is grabbed *and* also
once the last port (either AT or QCDM) is grabbed, so that in this
second run we get the proper capabilities via QCDM and the CDMA
interface enabled. Shouldn't be very difficult to handle that case.

> 
>> For example:
>>   * I plugin a Huawei modem which exposes lots of ports.
>>   * Probing is started in all of them in parallel
>>   * The good AT ports reply instantly and probing ends quite fast for them.
>>   * Non-AT ports go on with the probing, timing out in each AT command.
>>   * Once all non-AT ports get timed out in the last command from the 
>> probing sequence, we successfully initialize and export the modem, as we 
>> got valid AT ports previously.
> 
> We can initialize whenever the modem is valid, which at least means we
> have 1 data port and 1 command port.  But since those can be the same
> port (and they are until additional ports are found) we need to be
> careful here or we may export a modem that only knows one port and have
> a connection manager start a connection using only that one port.
> Allowing export in this situation would imply that we are able to open
> and use secondary ports *while the connection is potentially active*,
> which isn't the case now and could be somewhat complicated in the code.
> 

If we forbid modem enabling as long as there are ports being probed, it
should be safe to export the DBus object which was just initialized
(checked capabilities, checked locks and loaded basic info). Such an
exported modem would allow PIN unlock during the remaining port probings.

>>   * If for whatever reason the probing completely fails, we don't really 
>> notify it to the user in any way.
>>
>> This whole sequence may take up to 10-20s to complete.
>>
>> The new 06-api branch tries to minimize this by early trying to probe 
>> just for AT support; and more improvements can even be done (like, if we 
>> got an AT port already, just allow max one AT command timeout in the 
>> other ports, just an idea). But, in order to minimize the effect of 
>> probing ports which will end up timing out and not being used, I think 
>> we could try to show to the user some status that the device was 
>> detected and probing is ongoing. Even if the whole probing of the modem 
>> takes 10s, the user could see an in-progress icon, or even a 
>> notification that a modem was detected and support is being checked.
>>
>> So, a probing-specific ModemManager status could be of help here:
>>   MM_PROBING_STATUS_IDLE,
>>   MM_PROBING_STATUS_LAUNCHED,
>>   MM_PROBING_STATUS_ONGOING, (device specific)
>>   MM_PROBING_STATUS_FAILED, (device specific)
>>   MM_PROBING_STATUS_COMPLETED (device specific)
> 
> This would be per-modem specific status I assume?
> 
>> Whenever a new modem is connected and probing launched, or when a 
>> re-scan of modems is started, we would go to the LAUNCHED state.
> 
> This makes it sound like it's an MM global state?
> 

The idea was to have a MM global state (IDLE or PROBING), but then also
device-specific events like COMPLETED (well, possibly not needed if you
just wait for object-added signals in the DBus ObjectManager) and
specially FAILED.

>> As soon as we create the Modem object once the first valid port is 
>> probed, we would go to the ONGOING state. In this ONGOING state we 
> 
> The point of probing is to provide enough info to connection managers to
> do something useful with the modem, so if the manager still has to wait
> for the device's capabilities to be fully detected then exposing the
> modem before it's actually usable doesn't really speed things up.  But I
> don't have a problem with exposing the modem earlier but not allowing it
> to be Enabled or something like that until we have complete information.
> 

With the suggestion above the modem would get exported after
initialization, so after capability checks have been run. This fix would
possibly be enough to get it exported as soon as possible, but we still
lack the information of failures, i.e. Modem was detected, probed, but
failed during initialization (missing SIM for example).

-- 
Aleksander