On Tue, Nov 27, 2012 at 9:46 AM, Dan Williams <dcbw redhat com> wrote: > On Mon, 2012-11-26 at 18:59 -0800, Kelsey Sigurdur wrote: >> On Mon, Nov 26, 2012 at 10:26 AM, Dan Williams <dcbw redhat com> wrote: >> > On Fri, 2012-11-23 at 17:33 -0800, Kelsey Sigurdur wrote: >> >> Hi folks, >> >> >> >> Newb here. As the subject says, GetSignalQuality() is failing with >> >> the error "Could not parse the +CIND response" when connected to the >> >> network. When disconnected but enabled GetSignalQuality() properly >> >> returns a value. >> >> >> >> I'm just looking to find out if this is a issue with the hardware or >> >> perhaps a bug in ModemManager. >> >> >> >> I've scoured the archives as far back as January 2011 and the closest >> >> problem to mine that I've found so far is the following thread, which >> >> wasn't followed up on: >> >> >> >> "Re: how to get signal strength of EVDO modem" >> >> https://mail.gnome.org/archives/networkmanager-list/2011-January/msg00073.html >> > >> > So here's what's going on. >> > >> > 1) you don't appear to have the sierra_net driver on your system, or if >> > you do, it's not bound to the USB 306. The USB 306 should expose a >> > network port as well as a few serial TTYs, and ModemManager should pick >> > that network port up. The logs you posted indicate that the kernel >> > isn't binding sierra_net to the USB 306, so this appears to be a kernel >> > or modeswitch issue. >> > >> > 2) Because there's no network port, you only get one full-featured AT >> > command port, which is used for PPP while connected. The other >> > AT-capable ports have limited AT command parsers which do not allow the >> > AT+CIND command, which is why you get that error. However, there's a >> > bug in ModemManager where it should just report the signal quality >> > obtained by +CSQ instead of returning an error. >> > >> > So, I'd suggest finding out why sierra_net isn't getting used, but I'll >> > also fix the MM bug too. >> > >> > Dan >> > >> >> Thanks Dan. >> >> I do have the sierra_net driver on my system but you are correct that >> it's not getting bound to the device. >> >> For now I'm guessing it's a kernel issue. Google, and my rudimentary >> understanding of C, suggests that the USB 306 is blacklisted in >> sierra.c but would work with a firmware version >= M3.0. >> Unfortunately, the Sierra Wireless site offers only M2_0_11_10AP as >> the latest firmware for this device. > > Ah, you're right. My USB306 has firmware version 3, and I have no idea > where I got that firmware version, or even what firmware version it had > when I got it from Sierra. I did a bunch of searching around to find > out if there was a firmware upgrade for the 306, but couldn't find one > beyond the version you have. > >> See http://lwn.net/Articles/385096/ if you're interested in where I >> came across the blacklist info. >> >> I'm off to investigate modeswitching. Thanks for the tips, I appreciate it. > > So in light of this, I'll assume that the USB306 allows PPP on the > secondary APP ports. This makes the APP1 port with the limited AT > parser the PPP/data port, so that we can continue to issue normal > commands on the main port, instead of the main port being used for PPP > and APP port rejecting most of what we want to do. > > To test that out, do this: > > mv /usr/sbin/modem-manager / > killall -TERM modem-manager > MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug > > and then reconnect and see if the signal strength turns out OK. I can't > recall if I tested PPP on the APP1 port with the USB306, but the above > commands will force that to occur. If it works, I'll add a quirk for > the 306. > > Dan > That worked beautifully! I've attached the debug output. Could you briefly explain why moving the modem-manager binary was necessary? Thank-you very much for your help. :) Now to try and score more recent firmware.
Attachment:
ModemManager.log
Description: Binary data