2017-03-07 18:22 GMT+02:00 Dan Williams <d...@redhat.com>:

> On Tue, 2017-03-07 at 16:28 +0200, matti kaasinen wrote:
> > Hi!
> >
> > I would appreciate advices how to cope bad gsm connections with NM. I
> > do
> > have auto set-up for gsm configuration.
> > Modem gets huawei_cdc_ncm and NM brings up WWAN0 interface. What I
> > can see
> > from systemd journal is that NM tries to keep connection by
> > unplugging and
> > plugging kernel driver (or somthing like that as "USB Mass Storage
> > device
> > detected", gets enumerated and drivers registered...).
>
> That's the modem firmware crashing and restarting.  It then reappears
> to the kernel and gets re-enumerated, and usb_modeswitch does its thing
> and then eventually it comes back as a modem.  Which could be due to
> any number of issues.
>
But the first thing to check is whether the modem has enough power.
> Laptops and embedded devices are sometimes unable to supply enough
> power to the USB ports while the modem is connected.

Ok, so it is not NM just trying to restart connection. I tried to emulate
bad field by putting modem in metal box on my desk. Connection phase had 8
phases and usually it proceeded up to phase 7 and then timed out. Kernel
driver got re-loaded shortly after this. Board operating on the field could
drop immediately after connecting - after two seconds or so. On the other
hand I did not see usb driver crash logs than I did experience when I tried
switching usb power directly instead of sysfs services.

In fact both of these cases could be power issues. Doesn't these modems
increase power in bad field condition? That could lead to power problem.
But, still I did not see kernel crash log. Actually yesterday I did. I
thought that card was broken and other card did not give kernel crash logs.
Also we do have several devices in that neighborhood and they all have
experienced bad connection history. They are based on older HW and using
ppp protocol, though. I can't get logs from those devices, but really power
problem could also explain their behavior as booting usually recovers the
connection.

USB modems are
> even sometimes shipped with Y cables that draw power from two USB ports
> to give to the modem.  If your device is a PCIe minicard, obviously you
> can't use a Y cable, but the problem could be the same.  If you can try
> the device in a different machine that has sufficient power, this can
> isolate the problem.
>
I could try on my desctop machine, but problem is that it has different usb
drivers for this particular device (huawei 3131). I could try tracking
power line with oscilloscope on that device on my desk.

>
> It could also be a command sequence that ModemMangaer sends to the
> modem, which it doesn't like and crashes.  Could also be driver issues.
>
> > Somehow this does not always work well enough, and connection does
> > not
> > recover before this embedded Linux card boots up.
> > I do also have connection monitor that tries to ping external server
> > and it
> > power sequences modem if PING does not succeed and eventually, if
> > this
> > lasts long enough also boots the card. Somehow, this sounds as
> > overkill to
> > have two processes executing virtually the same process. I tried to
> > probe
> > if NM did also power sequencing, but I could not detect that.
> > However, I
> > did find
> > https://mail.gnome.org/archives/networkmanager-list/2016-March/msg000
> > 67.html
> > that discusses the very thing. I checked my kernel configuration and
> > it
> > turned out that rfkill was not enabled.
> >
> > Is NM executing "wwan off" at the moments it unplugs kernel driver
> > (or what
> > looks me to unplugging it) so that I could drop that feature from
> > connection monitor - provided that rfkill really touches usb power?
> > Kernel
> > do already have some services for usb power hanling in sysfs that my
> > connection monitor uses for this power sequencing.
>
> rfkill may or may not touch USB power depending on the hardware.
> Sometimes its wired into the machine's BIOS or embedded controller,
> other times it's just a signal to the device to do something but
> doesn't actually shut power off to the device itself.
>
As you told that above behavior (reloading kernel driver) is none of NM
initiated, I suppose there is no need for rfkill either.

>
> If a ping doesn't succeed, I'd be very curious if terminating the
> connection, setting the modem to low-power mode (via mmcli or 'nmcli r
> wwan off') works instead of power cycling the modem.
>

I'm not sure now what works. Booting seems working more reliably than other
methods, but it is far too crude operation if anything else works. That
connection monitor try using power cycling only (and booting as last trial)
and there is no other plans for anything else as it came clear above that
NM is not reloading kernel drivers for restarting connection

Thank you for your excellent answers.
I'll try to concentrate on (potential) powering issues.

-Matti
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to