libqmi-glib

Fri Apr 27 02:00:58 PDT 2012

On Friday 27 April 2012, Bjørn Mork wrote:
> Thomas Schäfer <tschaefer at t-online.de> writes:
> > at zte-k3565z
> > 
> > [24 Apr 2012, 18:14:47] [Debug] Checking version info...
> > [24 Apr 2012, 18:14:47] [Debug] [/dev/cdc-wdm0] QMI Device supports 4
> > services: [24 Apr 2012, 18:14:47] [Debug] [/dev/cdc-wdm0]    ctl (1.2)
> > [24 Apr 2012, 18:14:47] [Debug] [/dev/cdc-wdm0]    wds (1.3)
> > [24 Apr 2012, 18:14:47] [Debug] [/dev/cdc-wdm0]    dms (1.2)
> > [24 Apr 2012, 18:14:47] [Debug] [/dev/cdc-wdm0]    nas (1.0)
> > [24 Apr 2012, 18:14:47] [Debug] Asynchronously getting IDs...
> > 
> > [/dev/cdc-wdm0] Device IDs retrieved:
> >          ESN: 'not available'
> >         
> >         IMEI: '357867027052282'
> >         MEID: 'not available'
> > 
> > [24 Apr 2012, 18:14:47] [Debug] Client CID released
> 
> And this device works as expected with the qmi_wwan driver?
> 
> The reason I ask is that it looks very similar to the ZTE MF60 "Global
> Mobile Hotspot", which reports:
Hi Bjørn,
	The K3565-Z is a standard 3G modem rather than any sort of hotspot 
device, but does offer a pseudo Ethernet mode. Unlike some devices it has no AT 
commands for bringing up the connection in this mode, so I expect qmi to be 
the way to do this. I'm hoping to get this mode working at some point, so if 
there are any procedures you have that would make the device try to establish 
a connection via qmi, I'd be happy to try them out on all the devices I have.

Andrew

> 
> bjorn at nemi:/usr/local/src/git/libqmi-glib$ cli/qmicli
> --device=/dev/cdc-wdm2 --ctl-get-version-info [/dev/cdc-wdm2] Supported
> services:
>         ctl (1.3)
>         wds (1.5)
>         dms (1.2)
>         nas (1.0)
> bjorn at nemi:/usr/local/src/git/libqmi-glib$ cli/qmicli
> --device=/dev/cdc-wdm2 --dms-get-ids [/dev/cdc-wdm2] Device IDs retrieved:
>          ESN: 'not available'
>         IMEI: '355572041200667'
>         MEID: 'not available'
> 
> 
> but any attempt to actually *use* WDS on this device will trigger a USB
> modeswitch, after which all usable USB interfaces are gone as far as I
> can see.  I haven't found any other reset method than removing all power
> sources (which includes a battery).
> 
> Presumably this device has some very special firmware to enable the WiFi
> hotspot functionality, and that's the reason why it reacts weird to
> QMI_WDS even if it appears to be a normal USB QMI/wwan device.  I am of
> course not going to add the device ID to qmi_wwan, but I just wanted to
> make a note of this in case any other devices like this shows up.
> 
> USB descriptors:
> 
> Hotspot powered off (does not react to eject in this state):
> 
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=19d2 ProdID=2004 Rev= 0.00
> S:  Manufacturer=ZTE,Incorporated
> S:  Product=ZTE WCDMA Technologies MSM
> S:  SerialNumber=P680A1ZTED010000
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> 
> 
> Hotspot on, before initial modeswitch:
> 
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=19d2 ProdID=2000 Rev= 0.00
> S:  Manufacturer=ZTE,Incorporated
> S:  Product=ZTE WCDMA Technologies MSM
> S:  SerialNumber=P680A1ZTED010000
> C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> 
> 
> After modeswitch ("eject /dev/srX"):
> 
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=19d2 ProdID=1402 Rev= 0.00
> S:  Manufacturer=ZTE,Incorporated
> S:  Product=ZTE WCDMA Technologies MSM
> S:  SerialNumber=P680A1ZTED010000
> C:* #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
> E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
> I:* If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> 
> 
> After sending a request for a QMI_WDS client ID (which fails with
> QMI_ERR_MALFORMED_MSG):
> 
> T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  9 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=19d2 ProdID=1402 Rev= 0.00
> S:  Manufacturer=ZTE,  Incorporated
> S:  Product=ZTE CDMA Technologies MSM
> S:  SerialNumber=P680A1ZTED010000
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
> E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
> 
> 
> The device does not respond to AT commands on this interface, and it
> cannot do QMI embedded in CDC without an interrupt endpoint.  I haven't
> tested if it does usb-storage.  Doesn't seem very likely with a ff
> class, as I don't think that will work on Windows either?
> 
> 
> Anyway, the clue here is that we cannot necessarily trust the list of
> supported services.  Vendors are not very good at matching such service
> descriptions with the actual supported services. This device lists WDS
> support but we cannot use it.
> 
> 
> Bjørn
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel