a bug?

Aleksander Morgado aleksander at aleksander.es
Wed Apr 29 14:52:06 PDT 2015

On Wed, Apr 29, 2015 at 11:19 PM, Dan Williams <dcbw at redhat.com> wrote:
>> On Ubuntu 14.04
>> mmcli -L says 8after many sleeps)
>> /org/freedesktop/ModemManager1/Modem/57 [Generic] MBIM [1199:A001]
>> but
>> tcsh>mmcli --pin=1213 --sim=57
>> error: couldn't find sim at '/org/freedesktop/ModemManager1/SIM/57'
>> where actually
>> mmcli --pin=1213 --sim=53
>> successfully sent PIN code to the SIM
>> what is wrong here?

Well, it may be nothing wrong here. The index of the modem doesn't
have to be exactly equal to the sim index. You can list the modem
indexes available when doing mmcli -L; then for each of the modems you
can do e.g. mmcli -m 0 and you'll see listed among other things the
sim object index. These indexes are usualy equal, though, if there is
a single modem in the system always and if the modem always has a SIM.

A mismatch of the indexes may happen if you end up e.g. connecting at
the same time a modem with sim and a modem without sim. This happens a
lot to me as I don't really never use the modem built-in my laptop and
that always gets a modem index but never a sim index.

Does any of this make any sense to your use case? If you only used
always a modem and that modem always had a valid sim card, then we'd
need to see why they ended up getting mismatched, which is what Dan
was already discussing below.

> I think ModemManager is not compiled with suspend/resume support, and
> that the version of MM in 14.04 is probably too old to have that support
> in the code.
> What's going on is that when the machine goes to sleep, ModemManager has
> no idea about this, and because of that it holds the control port open
> over the suspend/resume.  But since the modem's other ports are not held
> open by MM, they can disappear when power is cut to the modem and it
> disconnects from the USB bus.

But even if MM holds the ports open and is not removed/recreated by
the kernel, we would get a HUP right away from the kernel in that
case, right? MM treats HUPs in the ports as port removes; if the
control port gets a HUP the modem gets flagged as invalid right away.

> Then when a resume happens, the modem comes back and the control port is
> brought back up again, but the other ports are re-created by the kernel
> and MM goes through the normal probing cycle, which creates a new modem
> object (57) in addition to the old one, but since this new one doesn't
> have control port it's useless.

I don't think the problem here is having 2 modems with different
indexes. There is just one modem (modem index #57) which has a sim
card (sim index #53).

> It looks like the suspend/resume support is only present on git master;
> I think we should probably backport it to MM 1.4 too.  Aleksander, does
> that sound reasonable?

I'd definitely prefer to go forward and start thinking in a new 1.6
stable series... maybe in the next few months?


More information about the ModemManager-devel mailing list