[thomasschaefer]

I tried to read what is going on in windows xp.

Maybe somebody can read the logfile.

It is about the question why windows switches to 1403 and linux doesn't.

[Josh]

I did extensive sniffing on Windows 8.1 and on Windows XP.

As I said, nothing unusual going on, all transfers are normal UFI/SCSI commands. Even with the stick software installed, I can't find any EJECT command before the mode switch.

What I didn't do yet is sniffing in Linux.

[LOM]

If we go back a bit in time then the first occurence of 19d2:1225 was here:

http://forums.whirlpool.net.au/forum-re ... &p=14#r263

Note that it is not supported in usb_modeswitch at this time so the ROOTer log shows
an erronous switched id.
Of interest is that the ROOTer firmware was able to to find cdc_rndis interfaces, a very
clear indication that the dongle had auto mode switched into 19d2:1403
Also worth to mention is that the ROOTer firmware did not have a usb_storage driver.

The next time we find 19d2:1225 is here:

http://forums.whirlpool.net.au/forum-re ... 135188&p=6

Dairyman has now added modeswitch support for 19d2:1225, there is still no
usb_storage driver present and the dongle switches into 19d2:1403.

We continue on to:

http://www.draisberghof.de/usb_modeswit ... f=3&t=1645

where the dongle switches to 19d2:1403 if using a scsi cmd 0x85 message but
switches to 19d2:1408 if using standard eject message.
The single use of the scsi cmd 0x85 is very interesting and there is more about it here:

http://www.draisberghof.de/usb_modeswit ... .php?t=924

I can still not find the underlying logic for the auto switching, maybe different
firmware have different default behaviour?
We have the following:

1. No storage driver, auto switches or switches by eject msg into 19d2:1403.

2. With storage driver it switches into 19d2:1405 or 19d2:1408 by an eject msg

3. Josh gets it to switch into 19d2:1403 with a std eject msg under linux, this is
what Thomas also wants but he can only get it to 19d2:1405.


Auto switching might be controlled by a timer/counter in the dongles firmware.
A read in the virtual cd-roms filesystem will reset the counter making it possible to
load driver and connection manager without the cd-rom getting switched away.
The counter starts to increment first when there are no more filesystem reads.
Windows starts to read early (autorun) so it resets the counter before it has reached
its limit and the windows auto switch will happen after connection manager is installed
but is not initiated by the connection manager, this would also explain why there is
no unusual traffic to be seen before switching happen.

It could also be that the counter is locked by the prevent media remove cmd and gets
unlocked as soon as the dongle receives the allow media removal cmd.
That cmd is used in the latest usb_modeswitch package (20140129) but previous versions and
Dairymans Rooter firmware did only use the start/stop unit (eject) cmd.

[thomasschaefer]

http://www.draisberghof.de/usb_modeswit ... .php?t=924

Seems to be one solution.

I continued there.

So I tried:

Code: Select all

modprobe usb_storage
echo 1000 > /sys/module/usb_storage/parameters/delay_use


usb_modeswitch -v 0x19d2 -p 0x1225 -W -m 0x01 -M 55534243123456782000000080000c85010101180101010101000000000000 
Taking all parameters from the command line


 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.2.5 (C) Josua Dietze 2012
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x19d2
DefaultProduct= 0x1225
TargetVendor=   not set
TargetProduct=  not set
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint=0x01
MessageContent="55534243123456782000000080000c85010101180101010101000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice enabled (default)
Success check disabled
System integration mode disabled

Looking for default devices ...
  searching devices, found USB ID 19d2:1225
   found matching vendor ID
   found matching product ID
   adding device
  searching devices, found USB ID 05c8:021a
  searching devices, found USB ID 1d6b:0002
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 1d6b:0001
 Found device in default mode, class or configuration (1)
Accessing device 009 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...

Looking for active driver ...
 OK, driver found; name unknown, limitation of libusb1
 OK, driver "unkown" detached

SCSI inquiry data (for identification)
-------------------------
  Vendor String: CWID    
   Model String: USB SCSI CD-ROM 
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: ZTE,Incorporated
     Product: ZTE WCDMA Technologies MSM
  Serial No.: MF8230ZTED010000CP261718U46EM0SHF3BW707_8C65&&&&&&&&&&&&&&&&&&&0
-------------------------
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
 Device is gone, skipping any further commands
-> Run lsusb to note any changes. Bye.

[ 2102.831205] usb 1-2: new high-speed USB device number 9 using ehci-pci
[ 2102.972830] usb 1-2: New USB device found, idVendor=19d2, idProduct=1225
[ 2102.972848] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2102.972861] usb 1-2: Product: ZTE WCDMA Technologies MSM
[ 2102.972866] usb 1-2: Manufacturer: ZTE,Incorporated
[ 2102.972872] usb 1-2: SerialNumber: MF8230ZTED010000CP261718U46EM0SHF3BW707_8C65&&&&&&&&&&&&&&&&&&&0
[ 2102.999396] usb-storage 1-2:1.0: USB Mass Storage device detected
[ 2102.999981] scsi10 : usb-storage 1-2:1.0
[ 2115.509583] usb 1-2: usbfs: process 3843 (usb_modeswitch) did not claim interface 0 before use
[ 2120.529992] usb 1-2: USB disconnect, device number 9
[ 2120.919260] usb 1-2: new high-speed USB device number 10 using ehci-pci
[ 2121.057319] usb 1-2: New USB device found, idVendor=19d2, idProduct=1403
[ 2121.057336] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2121.057347] usb 1-2: Product: ZTE WCDMA Technologies MSM
[ 2121.057356] usb 1-2: Manufacturer: ZTE,Incorporated
[ 2121.057365] usb 1-2: SerialNumber: MF8230ZTED010000CP261718U46EM0SHF3BW707_8C65&&&&&&&&&&&&&&&&&&&0
[ 2121.081239] usb-storage 1-2:1.2: USB Mass Storage device detected
[ 2121.081575] scsi11 : usb-storage 1-2:1.2
[ 2121.120621] rndis_host 1-2:1.0 usb0: register 'rndis_host' at usb-0000:00:1d.7-2, RNDIS device, 36:4b:50:b7:ef:2d
[ 2121.120765] usbcore: registered new interface driver rndis_host
[ 2121.124605] usbcore: registered new interface driver rndis_wlan




T:  Bus=01 Lev=01 Prnt=01 Port=01 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=19d2 ProdID=1403 Rev=f0.f1
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE WCDMA Technologies MSM
S:  SerialNumber=MF8230ZTED010000CP261718U46EM0SHF3BW707_8C65&&&&&&&&&&&&&&&&&&&0
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=03
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Now the device works as before, only with different ID and different driver. I have no clue which driver better is. Of course we can prefer the mode windows uses. But there is a problem - the kernel built in switch of usb_storage.


Regards,
Thomas Schäfer

[LOM]

http://www.draisberghof.de/usb_modeswit ... .php?t=924

Seems to be one solution.

Food for thoughts for Josh.

Now the device works as before, only with different ID and different driver. I have no clue which driver better is. Of course we can prefer the mode windows uses. But there is a problem - the kernel built in switch of usb_storage.

There is no kernel built in switch of usb_storage, it is a switch built into your dongles firmware and it
is activated by the os behaviour, most likely related to how the dongles virtual cd-rom is treated.

Both rndis and cdc_ether has their shortcomings so I see it as a draw. Windows ndis driver is proprietary code and the linux driver is an incompletely hack of it. cdc_ether needs to be rewritten so it can be used together with cdc_wdm as cmd channel device, I suppose that is easier to do than fixing the ndis driver.
It might happen now that all mbim dongles seems to have cdc_ether as alternative mode.

[thomasschaefer]

There is no kernel built in switch of usb_storage, it is a switch built into your dongles firmware and it
is activated by the os behaviour, most likely related to how the dongles virtual cd-rom is treated.

And what does this:

parm: option_zero_cd:ZeroCD mode (1=Force Modem (default), 2=Allow CD-Rom (uint)
parm: swi_tru_install:TRU-Install mode (1=Full Logic (def), 2=Force CD-Rom, 3=Force Modem) (uint)
parm: delay_use:seconds to delay before using a new device (uint)
parm: quirks:supplemental list of device IDs and their quirks (string)


mean?

/sys/module/usb_storage/parameters

delay_use option_zero_cd quirks swi_tru_install

It has an influence. I have had no usb-modeswitch-entry (because of an outdatet data-file) and the modem switched.
Only "delay_use" did stop that.

I will try again, what comes first.
Of course 19d2:1225 is used for more than one device.

[Josh]

The two mode-switching routines in usb-storage have been there since the time when usb_modeswitch was not around yet.

They are targetting only a very limited list of devices and have not been extended. They have stayed only because of compatibility considerations.

I once contributed a patch to the "Option" routine to avoid the handling of unrelated devices with the notorious "05c6:1000" ID.

There is one other - non-overridable - switching function included, called "e220_init" or similar. It targets a small range of Huawei devices; a patch with a broad extension to handle newer models was accepted by mistake and later extracted again.

Nothing about ZTE devices though. The Linux mode-switch is based on the system behaviour, in combination with a sort of timer. I agree with LOM.

I didn't continue my experiments because I found that I could freely choose the mode in Linux. Once I have some more time, I try to find out which conditions will trigger the "autoswitch".