Re: bad gsm connections

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:

I would appreciate advices how to cope bad gsm connections with
have auto set-up for gsm configuration.
Modem gets huawei_cdc_ncm and NM brings up WWAN0 interface. What
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
detected", gets enumerated and drivers registered...).
That's the modem firmware crashing and restarting.  It then
to the kernel and gets re-enumerated, and usb_modeswitch does its
and then eventually it comes back as a modem.  Which could be due
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
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.
driver got re-loaded shortly after this. Board operating on the field
drop immediately after connecting - after two seconds or so. On the
hand I did not see usb driver crash logs than I did experience when I
switching usb power directly instead of sysfs services.

In fact both of these cases could be power issues. Doesn't these
increase power in bad field condition? That could lead to power
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

For example, a cable like this:

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

But, still I did not see kernel crash log. Actually yesterday I did.
thought that card was broken and other card did not give kernel crash
Also we do have several devices in that neighborhood and they all
experienced bad connection history. They are based on older HW and
ppp protocol, though. I can't get logs from those devices, but really
problem could also explain their behavior as booting usually recovers

USB modems are
even sometimes shipped with Y cables that draw power from two USB
to give to the modem.  If your device is a PCIe minicard, obviously
can't use a Y cable, but the problem could be the same.  If you can
the device in a different machine that has sufficient power, this
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
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.


It could also be a command sequence that ModemMangaer sends to the
modem, which it doesn't like and crashes.  Could also be driver

Somehow this does not always work well enough, and connection
recover before this embedded Linux card boots up.
I do also have connection monitor that tries to ping external
and it
power sequences modem if PING does not succeed and eventually, if
lasts long enough also boots the card. Somehow, this sounds as
overkill to
have two processes executing virtually the same process. I tried
if NM did also power sequencing, but I could not detect that.
However, I
did find
that discusses the very thing. I checked my kernel configuration
turned out that rfkill was not enabled.

Is NM executing "wwan off" at the moments it unplugs kernel
(or what
looks me to unplugging it) so that I could drop that feature from
connection monitor - provided that rfkill really touches usb
do already have some services for usb power hanling in sysfs that
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
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
methods, but it is far too crude operation if anything else works.
connection monitor try using power cycling only (and booting as last
and there is no other plans for anything else as it came clear above
NM is not reloading kernel drivers for restarting connection

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

networkmanager-list mailing list
networkmanager-list gnome org

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]