On Tue, 2017-03-07 at 19:18 +0200, matti kaasinen wrote: > 2017-03-07 18:22 GMT+02:00 Dan Williams <[email protected]>: > > > 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 [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
