Re: Re-scanning for available devices/connections after failure
- From: Dan Williams <dcbw redhat com>
- To: Daenyth Blank <daenyth gmail com>
- Cc: networkmanager-list gnome org
- Subject: Re: Re-scanning for available devices/connections after failure
- Date: Thu, 22 Jul 2010 16:20:02 -0700
On Wed, 2010-07-21 at 13:55 -0400, Daenyth Blank wrote:
> On Thu, Jul 15, 2010 at 17:16, Dan Williams <dcbw redhat com> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]