a bug?

[Jean-Pierre.Eckmann at unige.ch]

Thanks. The situation here is that there is only one modem, but of course 
wifi etc...

of course I can use traial and error to find the true number of teh modem

I noted thet when the environment asks for the sim code through at popup 
window it does seem to know the right number. Do they do another mmcli 
call in the background or do they do "trial and error"?

JPE








On Wed, 29 Apr 2015, 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.
->
->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?
->
->-- 
->Aleksander
->https://aleksander.es
->