a bug?

Dan Williams dcbw at redhat.com
Wed Apr 29 19:34:32 PDT 2015

On Wed, 2015-04-29 at 23:52 +0200, Aleksander Morgado wrote:
> 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.

Argh!  I didn't read carefully enough and ignored the --sim part :)  So
ignore this completely.  You are 100% correct.


> 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