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
| ||
|
Message-ID: <943c3dc1-8bc7-4678-a6fd-adc5051f331c@email.android.com> Date: Wed, 24 Oct 2012 23:19:07 +0200 From: Bjørn Mork <bjorn@...k.no> To: "Shawn J. Goff" <shawn.goff@...elecon.com>, netdev <netdev@...r.kernel.org> Subject: Re: qmi-wwan bug "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'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. >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? >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 -- 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