netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Oct 2012 09:40:26 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	"Shawn J. Goff" <shawn.goff@...elecon.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: qmi-wwan bug

"Shawn J. Goff" <shawn.goff@...elecon.com> writes:
> On 10/24/2012 05:19 PM, Bjørn Mork wrote:
>> "Shawn J. Goff" <shawn.goff@...elecon.com> wrote:
>>
>>> 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.

As I suspected.  Then I believe this issue is more likely related to
your hardware platform and/or its other lower layer drivers, and not to
the backported qmi_wwan driver directly.

Maybe an obscure firmware issue related to timing or other differences?
That is going to be difficult to track down, if it really is the cause.

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

Yes, that is useful.  You are perfectly right that most of the host side
drivers are common. Both sierra_net and qmi_wwan are usbnet minidrivers,
and almost all network device functionality is served by the shared
usbnet framework.  So this test pretty much eliminates the host USB
stack.

Which IMHO points to the firmware implementation as the major
difference.

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

Ah, interesting.  Then we only need to find out where the bulk URBs end
up.

I would have tried to enable what I could of USB and usbnet debugging to
see if there are any hints there.  A usbmon trace may also show the
problem.  I don't know.  But in any case, I believe this is a USB
problem and probably not too interesting for netdev...

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