netdev - Re: qmi_wwan on Huawei E398

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]

Message-ID: <34bc2a91-d03c-4143-8194-5dbe3b55530a@email.android.com>
Date:	Fri, 11 Jan 2013 19:27:53 +0000
From:	Bjørn Mork <bjorn@...k.no>
To:	Cedric Jehasse <cedric.jehasse@...il.com>, netdev@...r.kernel.org
Subject: Re: qmi_wwan on Huawei E398

Cedric Jehasse <cedric.jehasse@...il.com> wrote:

>Hi,
>
>I'm trying to use qmi on an Huawei E398 dongle with ofono on a 3.7.1
>kernel. (this works with a 3.5.0 kernel)
>ofono looks for the class/subclass/protocol of the parent
>usb_interface device for the qmi_wwan and cdc_wdm devices. This must
>match with ff/01/08 and ff/01/09 Cls/Sub/Prot.
>
>Below is a trace of the udev events and usb-device output for a 3.5.0
>and 3.7.1 kernel. The difference is in the parent devices for wwan0
>and cdc-wdm0.
>The parent device for wwan0 is on a 3.7.1 kernel is If3. Is this
>normal?
>
>* 3.5.0:
>KERNEL[201.262240] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usb/cdc-wdm0 (usb)
>KERNEL[201.347292] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.4/net/wwan0 (net)
>
>T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
>D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
>P:  Vendor=12d1 ProdID=150a Rev=00.00
>S:  Manufacturer=Huawei Technologies
>S:  Product=HUAWEI Mobile
>S:  SerialNumber=1234567890ABCDEF
>C:  #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=cdc_wdm
>I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>* 3.7.1:
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>
>T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  6 Spd=480 MxCh= 0
>D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
>P:  Vendor=12d1 ProdID=150a Rev=00.00
>S:  Manufacturer=Huawei Technologies
>S:  Product=HUAWEI Mobile
>S:  SerialNumber=1234567890ABCDEF
>C:  #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=qmi_wwan
>I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>Thanks,
>Cedric

This looks right to me. There is a single function using two USB interfaces. We started out letting the cdc-wdm driver handle the control interface and the qmi_wwan driver the data interface. This is what you see in 3.5. But splitting a function like this was very awkward and made devices like the E398 behave differently from most other QMI devices, which only use a single USB interface. 

So we changed this to let the qmi_wwan driver handle both interfaces. This is what you see in 3.7. The control interface is now the parent of both the cdc_wdm character device and the wwan network device and the data interface is just a data interface.

I realize that this is balancing on the edge of acceptable userspace visible changes, but all this did was making devices like the E398 look similar to single interface devices. Which already had to be supported by the userspace applications.

Now I understand that ofono does a lot stricter matching than I have anticipated, looking at the vendor specific subclass and protocol fields of the wwan parent interface. I don't think we can fix that without updating ofono. Sorry. If it is going to do that then it needs to accept both ff/01/08 and ff/01/09.


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