On Wed, 2010-07-21 at 13:55 -0400, Daenyth Blank wrote: > On Thu, Jul 15, 2010 at 17:16, Dan Williams <[email protected]> wrote: > > And there were /dev/ttyUSBx ports for the device? If you can get it > > into that state again, do this: > > > > 1) mv /usr/sbin/modem-manager / > > 2) killall -TERM modem-manager > > 3) /modem-manager --debug > > > > and see what MM says. When you're done, > > mv /modem-manager /usr/sbin/modem-manager. > > > > Dan > > > > > > Unfortunately if the situation occurs, we can't do that since they're > remotely deployed and the only way to access is by using the modem. It > almost never happens at our office where we can put them on a lan.
That is, well, unfortunate... Sierra firmware is usually top-notch so I'd consider firmware crashes to be less of an issue here than with say Huawei or ZTE devices. But they still could be an issue. If there's any way we can get logs from the devices at all, that would be excellent. But as a workaround, you could use a watchdog that sends a USB reset to the device if it isn't seen in ModemManager for more than 30 seconds. There are some Python examples that list modems here: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/test/list-modems.py and that coupled with echoing some stuff to sysfs might be enough to shoot the modem in the head and get it to re-enumerate. If there's *any* way we can get 'dmesg' or /var/log/messages from the system when this happens that would help a lot. Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
