netdev - Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET

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

Date:   Fri, 21 Apr 2017 15:02:47 +0200
From:   Bjørn Mork <bjorn@...k.no>
To:     Daniele Palmas <dnlplm@...il.com>
Cc:     netdev@...r.kernel.org, linux-usb <linux-usb@...r.kernel.org>,
        Aleksander Morgado <aleksander@...ksander.es>
Subject: Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

Daniele Palmas <dnlplm@...il.com> writes:

> So, I applied your debug patch and this is what is happening:

Thanks

> [ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data
> [ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
>
> Here qmicli is stuck. Then I disconnect the cable:

I guess this modem dislikes the unsolicted IN control request so much
that it ignores the OUT control request. I have a feeling that this is
violating the USB spec, since a STALL on the control pipe is supposed to
be cleared by the next setup.

But either way, we have to just accept whatever the device does.

> This is instead the output with the commit reverted:
..
> [ 9885.295723] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
> [ 9885.296210] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_NETWORK_CONNECTION disconnected from network
> [ 9885.328208] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_RESPONSE_AVAILABLE received: index 2 len 0
> [ 9885.328216] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0

I note that you get a NETWORK_CONNECTION notification here, which you
also did not receive in the failing case.  That's interesting.  Another
indication that the device is completely stuck as a result of the IN
control request.

Thanks for this.  It shows that we can forget about any such automatic
queue flushing for QMI devices. Any reimplementation of this feature
must be limited to CDC MBIM. The "queue-out-of-sync" issue is mostly
affecting Intel MBIM devices anyway.

Bjørn