Re: bad gsm connections

[Alex Ferm <aferm petropower com>]

I've seen similar issues using SierraWireless modems on a mPCIe USB 
adapter. I was trying to run one of our newer 4G modems on a carrier 
board scavenged from a 3G modem. The 4G modems will run on the old 
carrier board, but will occasionally draw more power than the adapter 
can deal with. I believe the important difference between the two boards 
is the size of capacitors used.


On 03/07/2017 12:11 PM, Dan Williams wrote:
> On Tue, 2017-03-07 at 19:18 +0200, matti kaasinen wrote:
> > 2017-03-07 18:22 GMT+02:00 Dan Williams <dcbw 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.
> They do, in bad signal situations they increase transmit power to
> compensate.  But that in turn increases the power draw of the modem
> itself from the host computer, and the host computer may not be able to
> supply enough power through its USB port or PCIe pins.  That causes the
> modem to crash like how clocks in your home reset during a power
> brownout.
>
> For example, a cable like this:
>
> http://www.nevacell.com/nevacell/images/UTStarcom/Cable/YC150B/USB_Y_Cable.JPG
>
> is used to pull power from two separate USB ports to supply to modems
> that require more power than a single port can provide.
>
> You could also try with a good-quality powered USB hub.  These can
> typically supply more power to a port than a laptop/embedded machine
> can.
>
> > 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.
> That would be very interesting.  It might be able to conclusively blame
> power delivery or not.
>
> Again, this may not be the actual problem.  But it's often a culprit.
>
> Dan
>
> > > 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/ms
> > > > g000
> > > > 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

--
Alex Ferm
PetroPower, LLC.
3003 E. 37th Street N.
Suite 100
Wichita, KS 67219