netdev - qmi-wwan bug

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-next>] [day] [month] [year] [list]

Date:	Wed, 24 Oct 2012 14:50:04 -0400
From:	"Shawn J. Goff" <shawn.goff@...elecon.com>
To:	netdev <netdev@...r.kernel.org>
Subject: qmi-wwan bug

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). I see this problem with different devices from 
different manufacturers. I've only made it happen on my kernel - I tried 
on 3.6.2, but it seems to not happen there. I've also tried using a 
similar modem that uses a different driver (sierra-net) and that doesn't 
have the same 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.

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.

-- 
Shawn J. Goff | Accelerated Concepts | Embedded Systems Engineer | 1-813-983-7501

--
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