lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Oct 2012 18:28:05 -0400
From:	"Shawn J. Goff" <shawn.goff@...elecon.com>
To:	Bjørn Mork <bjorn@...k.no>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: qmi-wwan bug


On 10/24/2012 05:19 PM, Bjørn Mork wrote:
>
> "Shawn J. Goff" <shawn.goff@...elecon.com> wrote:
>
>> I've backported qmi-wwan to 2.6.39 (it's here:
>> https://bitbucket.org/accelecon/linux-at91/changesets), and it mostly
>> works, but I've come across a problem. The modem will sometimes stop
>> responding to any qmi data (but the AT commands on the TTY ports keep
>> working). This only happens when there is significant traffic flowing
>> through the device (downloading a large file) while at the same time,
>> AT
>> commands are sent to one of the TTY ports (I first noticed with my own
>> modem query program, but I can reproduce it using microcom to send
>> "ATI\r" in a loop).
> Using the tty ports should be completely independent of any qmi activity from the host perspective. I am tempted to claim this indicates a firmware bug.
>
>> I see this problem with different devices from
>> different manufacturers.
> Which still may use pretty much the same firmware, although a little less likely.
>
>> I've only made it happen on my kernel - I
>> tried
>> on 3.6.2, but it seems to not happen there.
> Good. But I have a feeling that you switched more than just the kernel. Do you see the issue if you run your backport on the same hardware you tested 3.6.2 on?

I just tested my 2.6.39 kernel on the same hardware that had 3.6.2; the 
problem is absent there.

>
>   > I've also tried using a
>> similar modem that uses a different driver (sierra-net) and that
>> doesn't
>> have the same problem.
> Well, that is an entirely different firmware application and driver, even if the hardware is similar or even identical.

Yes - I wanted to eliminate anything lower (such as usb-net? not sure if 
qmi-wwan uses that) from being a suspect contributor to the problem.

>
>> When it is in failure, if I try to ping an address, the system sends
>> out
>> several an ARP requests but gets no response. To get the device to
>> respond again, I have to administratively set the wwan interface down,
>> then up, use libqmi to get the connection going again, then dhcp to get
>>
>> an address.
> Which sounds like the connection died. Does QMI work at this point, or is that dead too?

Looks like qmi works. I can do --nas-get-signal-strength and it gives me 
good numbers. --wds-get-packet-service-status returns "Connection 
status: '2'"
>
>> I also have some USB traces of the failure and recovery process. I'm
>> not
>> familiar with CDC or QMI, so it's not yet clear to me exactly what's
>> happening, but it looks like the modem just stops sending anything on
>> its QMI endpoint for no reason.
>>
>> How might I dive further into the issue? So far, my next step is to
>> look
>> into CDC and QMI and try to decypher the USB traces. If anyone is
>> interested, I can share a tcpdump or a USB trace.
> I think a test of the backport on the same host hardware you run 3.6.2 on would be the best place to start.
>
> Bjørn
Thanks for your help.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists