Skip site navigation (1)Skip section navigation (2) 
Date:      Sat, 07 Dec 2013 22:10:48 +1100
From:      Edwin Groothuis - FreeBSD <edwin@freebsd.org>
To:        Hans Petter Selasky <hps@bitfrost.no>, freebsd-usb@freebsd.org
Subject:   Re: Huawei K4606 issues
Message-ID:  <52A30238.1000308@freebsd.org>
In-Reply-To: <529EE734.3030206@bitfrost.no>
References:  <529DB241.7030203@freebsd.org> <529DBB97.7020304@bitfrost.no>	<529EE6A5.9080709@freebsd.org> <529EE734.3030206@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help 
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--LLJv5ov5ADjhOdKtvjUnkQxR4Tp6DW1Ek
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Hans,

On 4/12/13 19:26 , Hans Petter Selasky wrote:
> On 12/04/13 09:24, Edwin Groothuis - FreeBSD wrote:
>>
>> I found out that the device doesn't act as a serial port but an ethern=
et
>> card:
>>
>> bInterfaceClass is 2 (UICLASS_CDC)
>> bInterfaceSubClass is 14 (undefined in usb.h)
>>
>> Reading up on various other forums, they talk about using it as an
>> Ethernet device:
>> "and shows up as a USB ethernet device after modeswitching"
>>
>> According to the spec from Vodafone, this is a HiSilicon Balong 520
>> chipset.
>>
>> I think I'm stuck here...
>> Unless somebody has a good idea where to go next?
>> I'm open to experiment for the next 25 days :-)
>=20
> Have a look at if_cdce.c
>=20
> Should support your device, probably the NCM protocol.

Thank you, that did the trick: It got recognized by the probe!
Now the attach is the problem:

Dec  7 21:54:26 t43 sudo:    edwin : TTY=3Dpts/7 ;
PWD=3D/usr/home/edwin/9.2.0/sys/mod
ules/usb/cdce ; USER=3Droot ; COMMAND=3D/sbin/kldload ./if_cdce.ko
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1
Dec  7 21:54:26 t43 kernel: cdce0: <VodafoneHuawei K4606, class 0/0, rev
2.00/1.02, addr 2> on usbus4
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1a
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:0
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4b: error:12
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:1
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:3
Dec  7 21:54:26 t43 kernel: cdce0: No valid alternate setting found
Dec  7 21:54:26 t43 kernel: device_attach: cdce0 attach returned 6
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1
Dec  7 21:54:26 t43 kernel: cdce0: <VodafoneHuawei K4606, class 0/0, rev
2.00/1.02, addr 2> on usbus4
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1a
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:0
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 21:54:26 t43 root: Unknown USB device: vendor 0x12d1 product
0x1f19 bus uhub4
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4b: error:12
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:1
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4b: error:0
Dec  7 21:54:26 t43 kernel: cdce0: faking MAC address
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1
Dec  7 21:54:26 t43 kernel: cdce1: <VodafoneHuawei K4606, class 0/0, rev
2.00/1.02, addr 2> on usbus4
Dec  7 21:54:26 t43 kernel: >cdce_attach - 1a
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:0
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 21:54:26 t43 kernel: ue0: <USB Ethernet> on cdce0
Dec  7 21:54:26 t43 kernel: ue0: Ethernet address: 2a:d5:fd:08:00:00
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4b: error:12
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4:1
Dec  7 21:54:26 t43 kernel: >cdce_attach - 4a: error:3
Dec  7 21:54:26 t43 kernel: cdce1: No valid alternate setting found
Dec  7 21:54:26 t43 kernel: device_attach: cdce1 attach returned 6


The patches were as follows for the cdce_host_devs:
+	{USB_VPI(USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_K4606_INIT,
CDCE_FLAG_NO_UNION)},

And for the debugging:
@@ -506,6 +512,8 @@
 	uint8_t data_iface_no;
 	char eaddr_str[5 * ETHER_ADDR_LEN];	/* approx */

+	printf(">cdce_attach - 1\n");
+
 	sc->sc_flags =3D USB_GET_DRIVER_INFO(uaa);
 	sc->sc_ue.ue_udev =3D uaa->device;

@@ -519,6 +527,7 @@

 	if ((ud =3D=3D NULL) || (ud->bLength < sizeof(*ud)) ||
 	    (sc->sc_flags & CDCE_FLAG_NO_UNION)) {
+		printf(">cdce_attach - 1a\n");
 		DPRINTFN(1, "No union descriptor!\n");
 		sc->sc_ifaces_index[0] =3D uaa->info.bIfaceIndex;
 		sc->sc_ifaces_index[1] =3D uaa->info.bIfaceIndex;
@@ -526,6 +535,7 @@
 	}
 	data_iface_no =3D ud->bSlaveInterface[0];

+	printf(">cdce_attach - 2\n");
 	for (i =3D 0;; i++) {

 		iface =3D usbd_get_iface(uaa->device, i);
@@ -545,6 +555,7 @@
 			goto detach;
 		}
 	}
+	printf(">cdce_attach - 3\n");

 	/*
 	 * <quote>
@@ -575,8 +586,10 @@

 	for (i =3D 0; i !=3D 32; i++) {

+		printf(">cdce_attach - 4:%d\n", i);
 		error =3D usbd_set_alt_interface_index(uaa->device,
 		    sc->sc_ifaces_index[0], i);
+		printf(">cdce_attach - 4a: error:%d\n", error);
 		if (error)
 			break;
 #if CDCE_HAVE_NCM
@@ -587,6 +600,7 @@
 		    sc->sc_ifaces_index, sc->sc_xfer,
 		    pcfg, CDCE_N_TRANSFER, sc, &sc->sc_mtx);

+		printf(">cdce_attach - 4b: error:%d\n", error);
 		if (error =3D=3D 0)
 			break;
 	}

I tried with both with CDCE_FLAG_ZAURUS in there, no differences.
I tried it without CDCE_FLAG_NO_UNION and then I got this:

Dec  7 22:01:03 t43 root: Unknown USB device: vendor 0x0483 product
0x2016 bus uhub2
Dec  7 22:01:03 t43 kernel: >cdce_attach - 1
Dec  7 22:01:03 t43 kernel: cdce0: <VodafoneHuawei K4606, class 0/0, rev
2.00/1.02, addr 2> on usbus4
Dec  7 22:01:03 t43 kernel: >cdce_attach - 2
Dec  7 22:01:03 t43 kernel: >cdce_attach - 3
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4:0
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4b: error:12
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4:1
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4a: error:0
Dec  7 22:01:03 t43 kernel: >cdce_attach - 4b: error:0
Dec  7 22:01:03 t43 kernel: cdce0: faking MAC address
Dec  7 22:01:03 t43 kernel: ue0: <USB Ethernet> on cdce0
Dec  7 22:01:03 t43 kernel: ue0: Ethernet address: 2a:7d:0b:0f:00:00


Is that better? I don't know yet...
At least ue0 gets created, but the link light doesn't go on the modem...

I will take some traces on Monday on a Windows machine to see what needs
to be happening after the attachment of the interface.

Edwin



--LLJv5ov5ADjhOdKtvjUnkQxR4Tp6DW1Ek
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSowI6AAoJEBHEgofFk7N6JrwH/0+h2MipRyo5FlpUpXId88jd
F4Fmz2iyBypXz1ojit0VLU1rG9eub8ZKkWjxjVlLzcrsBAIGOOShuRWuxI/K0Vdz
im9BCb+g8F5pBgS3HLBc7IoOehd/a1trEmSCDvQsKnn8HRVA7Vp6HQRHD4pELD7X
mby9mCEKDlNbJuUm/Czqj8kOjeZ6uC7iJBNEWBhShQMOH1n19bMHjpOMHPBsHXtG
xx7iM7tUIBPguMj9HnpnAjiqX0OaEdeGA42d1j0rEdCV/XGUh7C8sy5g8MkWvswy
rTzr6K1wlVFp4dEMOWC3iWDUuvilxNruI6DVc+9p7+igr9J8X5gXZlxj6KfqAWc=
=wL9h
-----END PGP SIGNATURE-----

--LLJv5ov5ADjhOdKtvjUnkQxR4Tp6DW1Ek--

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52A30238.1000308>