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, 13 Dec 2011 10:02:13 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	netdev@...r.kernel.org
Cc:	linux-usb@...r.kernel.org
Subject: Re: [PATCH 0/3] Adding a new driver for Huawei E392 WWAN modem

Bjorn Mork <bjorn@...k.no> writes:

> patch 3 adds the new driver.  Most of it is QMI protocol handling.
> The network device is a minimalistic usbnet minidriver.

In case anyone wonders what this really does, here's an excerpt of a
connection being initiated by simply doing "dhclient wwan1". 
"ip link set dev wwan1 up" would achieve the same, except for address
configuration of course.


I'm explaining inline:


Dec 13 04:15:38 nemi kernel: [23893.115819] qmi_wwan 2-2:1.3: wwan1: register 'qmi_wwan' at usb-0000:00:1d.7-2, QMI speaking CDC ECM like wwan device, 76:bb:09:ca:8e:84
Dec 13 04:15:38 nemi kernel: [23893.116732] usbcore: registered new interface driver qmi_wwan
Dec 13 04:15:40 nemi kernel: [23894.842205] usb 2-2: QMI_CTL request: msg 0x0022 (len 15) from "control point" with cid=0x00 and TLVs:
Dec 13 04:15:40 nemi kernel: [23894.842214] usb 2-2: [0x01] (1) 01                                               .

requesting a client ID for subsystem QMI_WDS.  We need this for starting
the network connection.

Dec 13 04:15:40 nemi kernel: [23894.944602] usb 2-2: QMI_CTL response: msg 0x0022 (len 23) from "service" with cid=0x00 and TLVs:
Dec 13 04:15:40 nemi kernel: [23894.944614] usb 2-2: [0x02] (4) SUCCESS (0x0000)
Dec 13 04:15:40 nemi kernel: [23894.944622] usb 2-2: [0x01] (2) 01 03                                            ..

received QMI_WDS client ID = 3

Dec 13 04:15:40 nemi kernel: [23894.945827] usb 2-2: QMI_CTL request: msg 0x0022 (len 15) from "control point" with cid=0x00 and TLVs:
Dec 13 04:15:40 nemi kernel: [23894.945837] usb 2-2: [0x01] (1) 02                                               .

requesting a client ID for subsystem QMI_DMS.  We need this for
verifying SIM PIN state (well, we don't really need to do that, but it
enables us to understand why the connection fails if a PIN code is
required).


Dec 13 04:15:40 nemi kernel: [23895.048729] usb 2-2: QMI_CTL response: msg 0x0022 (len 23) from "service" with cid=0x00 and TLVs:
Dec 13 04:15:40 nemi kernel: [23895.048738] usb 2-2: [0x02] (4) SUCCESS (0x0000)
Dec 13 04:15:40 nemi kernel: [23895.048743] usb 2-2: [0x01] (2) 02 03                                            ..

received QMI_DMS client ID = 3


Dec 13 04:15:40 nemi kernel: [23895.050066] usb 2-2: QMI_DMS request: msg 0x002b (len 12) from "control point" with cid=0x03 and TLVs:

requesting PIN code state

Dec 13 04:15:40 nemi kernel: [23895.152746] usb 2-2: QMI_DMS response: msg 0x002b (len 31) from "service" with cid=0x03 and TLVs:
Dec 13 04:15:40 nemi kernel: [23895.152758] usb 2-2: [0x02] (4) SUCCESS (0x0000)
Dec 13 04:15:40 nemi kernel: [23895.152767] usb 2-2: [0x12] (3) PIN2 status=1, 3 verify retries left, 10 unblock retries left
Dec 13 04:15:40 nemi kernel: [23895.152777] usb 2-2: [0x11] (3) PIN1 status=2, 3 verify retries left, 10 unblock retries left

PIN1 is enabled but already verified, so we're ready to go.


Dec 13 04:15:40 nemi kernel: [23895.153987] usb 2-2: QMI_WDS request: msg 0x0022 (len 12) from "control point" with cid=0x03 and TLVs:

requesting connection state

Dec 13 04:15:41 nemi kernel: [23895.256746] usb 2-2: QMI_WDS response: msg 0x0022 (len 23) from "service" with cid=0x03 and TLVs:
Dec 13 04:15:41 nemi kernel: [23895.256757] usb 2-2: [0x02] (4) SUCCESS (0x0000)
Dec 13 04:15:41 nemi kernel: [23895.256765] usb 2-2: [0x01] (1) 01                                               .

state is disconnected

Dec 13 04:15:41 nemi kernel: [23895.257967] usb 2-2: QMI_WDS request: msg 0x0020 (len 12) from "control point" with cid=0x03 and TLVs:

starting a new connection

Dec 13 04:15:41 nemi kernel: [23895.360622] usb 2-2: QMI_WDS response: msg 0x0020 (len 26) from "service" with cid=0x03 and TLVs:
Dec 13 04:15:41 nemi kernel: [23895.360634] usb 2-2: [0x02] (4) SUCCESS (0x0000)
Dec 13 04:15:41 nemi kernel: [23895.360641] usb 2-2: [0x01] (4) e8 90 15 02                                      ....


successfully connected.  Got a 32bit handle (needed for disconnect).
The connection is now fully usable, and DHCP will now succeed (not
shown).


Dec 13 04:15:41 nemi kernel: [23895.361114] usb 2-2: QMI_WDS indication: msg 0x0022 (len 21) from "service" with cid=0xff (broadcast) and TLVs:
Dec 13 04:15:41 nemi kernel: [23895.361124] usb 2-2: [0x01] (2) 02 00                                            ..
Dec 13 04:15:41 nemi kernel: [23895.361131] usb 2-2: [0x12] (1) 04                                               .


received an unsolicited QMI_WDS status message (sent to all clients)
with the new IPv4 connected state

Dec 13 04:15:41 nemi kernel: [23895.362343] usb 2-2: QMI_WDS request: msg 0x0001 (len 20) from "control point" with cid=0x03 and TLVs:
Dec 13 04:15:41 nemi kernel: [23895.362352] usb 2-2: [0x10] (1) 01                                               .
Dec 13 04:15:41 nemi kernel: [23895.362360] usb 2-2: [0x15] (1) 01                                               .

request speed and system change updates.  Nice to know, but not strictly
required.

Dec 13 04:15:41 nemi kernel: [23895.464623] usb 2-2: QMI_WDS response: msg 0x0001 (len 19) from "service" with cid=0x03 and TLVs:
Dec 13 04:15:41 nemi kernel: [23895.464635] usb 2-2: [0x02] (4) SUCCESS (0x0000)

received ack to the last request.  That's the last we'll see until
something changes.



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

Powered by Openwall GNU/*/Linux Powered by OpenVZ