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:	Tue, 10 Feb 2015 09:51:31 +0100
From:	Aleksander Morgado <aleksander@...ksander.es>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	David Miller <davem@...hat.com>,
	Kristian Evensen <kristian.evensen@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: qmi_wwan: MC73xx interface 10 is not QMI

On Tue, Feb 10, 2015 at 9:43 AM, Aleksander Morgado
<aleksander@...ksander.es> wrote:
> On Tue, Feb 10, 2015 at 8:49 AM, Bjørn Mork <bjorn@...k.no> wrote:
>>>> On Mon, Feb 9, 2015 at 2:33 PM, Bjørn Mork <bjorn@...k.no> wrote:
>>>>> That is pretty old relative to this hardware. First commercial release?
>>>>> I don't really want to push you to do an upgrade, but it would sure be
>>>>> nice to have this test repeated on a recent firmware version.  Not that
>>>>> I can spot anything particularily promising in the release notes.
>>>>
>>>> I updated firmware now, but still see the same behavior.
>>>>
>>>>> I did find our previous discussions about these two RMNET1 and RMNET2
>>>>> functions, e.g:
>>>>> http://lists.freedesktop.org/archives/libqmi-devel/2014-July/000875.html
>>>>> and it seems to indicate that both work as long as you configure them
>>>>> for 802.3 framing. But that could just be an information feedback
>>>>> loop...
>>>>
>>>> That is correct. In order for this device to accept network traffic
>>>> (or driver to accept packets from device), I have to set the transfer
>>>> mode to 802.3.
>>>
>>> So what are we going to do with this patch?
>>
>> I am hoping to get a second opinion from Aleksander.
>
> I have a MC7304 and a MC7354 and both work with interfaces #8 and #10,
> the only difference being that #10 ends up being raw-ip by default
> instead of 802.3. I previously had old firmware in both, from early
> last year IIRC, but last week I upgraded both to the latest firmware
> available.
>
> The only case in which I've seen such a modem (a MC7304) with 1 single
> valid QMI interface (actually being #8) is when the modem is put in
> "single-qmi" interface mode, which you can do forcing it to get the
> MC7710 PID, e.g. AT!UDPID=68A2. But otherwise, if the modem was
> exposed as 0x68c0, if#10 always worked for me...


BTW, regarding the patch... if interface #10 ends up being usable only
in some 73xx models, I would still leave it available anyway in the
kernel driver. Userspace can always figure out whether the interface
is usable or not (e.g. MM does some QMI probing on the interface
before flagging it as usable).

A similar issue we had with if#11 IIRC, which the sierra driver marked
it as being QMI but we never made it work once, so we ended up
removing it from qmi_wwan (see commit fc0d6e9cd0a). Now I wonder if we
should have done that only by testing it once with my hw.

-- 
Aleksander
https://aleksander.es
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ