On Wed, 2015-04-29 at 23:52 +0200, Aleksander Morgado wrote: > On Wed, Apr 29, 2015 at 11:19 PM, Dan Williams <[email protected]> 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. Dan > 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? > _______________________________________________ ModemManager-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
