Activation Codes and Methods, Hardware Details, Sniffing
Post Reply
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 11 Jun 2010, 09:33

about the response byte, I got some thing.
If I swich modem with repeat config, or send some error message,after this,it will recevie 0 byte .
So I re-plug the modem, and repeat test your package again.
Now it receive 13 bytes. but modem still remain the original ID.

here are log.
* usb-modeswitch: handle USB devices with multiple modes
* Version 1.1.3 (C) Josua Dietze 2010
* Based on libusb0 (0.1.12 and above)

! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor= 0x1a8d
DefaultProduct= 0x1000
Targeusb 1-1: usbfs: process 8968 (usb_modeswitch) did not claim interface 0 before use
tVendor= 0x1a8d
TargetProduct= 0x1009
TargetClass= not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
GCTMode=0
MessageEndpoint= not set
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
NeedResponse=1
ResponseEndpoint= not set
Interface=0x00

InquireDevice enabled (default)
Success check enabled, max. wait time 20 seconds
System integration mode disabled

usb_os_init: Found USB VFS at /proc/bus/usb
usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_busses: Skipping non bus directory devices
usb_os_find_devices: Found 001 on 002
usb_os_find_devices: Found 016 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device

Looking for target devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
searching devices, found USB ID 0000:0000
No devices in target mode or class found
Looking for default devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 0000:0000
Found devices in default mode or class (1)
Accessing device 016 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached

SCSI inquiry data (for identification)
-------------------------
Vendor String: BandRich
Model String: CDROM
Revision String: 2.01
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: BandRich, Inc.
Product: BandLuxe 3.5G HSPA Adapter
Serial No.: 358094021837456
-------------------------
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 1 ...
OK, response successfully read (13 bytes).
Delaying next message transfer for 1000 ms
Trying to send message 2 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 2 ...
OK, response successfully read (13 bytes).

Checking for mode switch (max. 20 times, once per second) ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Original device still present after the timeout

Mode switch most likely failed. Bye.
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 11 Jun 2010, 11:37

Hmm, that looks OK.

You can try more of these things:
- disable the MessageDelay again
- adding your third command (with "06 00") as MessageContent3

Please do a re-plug before each time you try.

Also, add the -I parameter to disable the SCSI inquiry.

Top
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 11 Jun 2010, 12:42

mm, I have follow your step to try, but the MessageContent3's response is 0 byte.
Reading the response to message 3 ...
OK, response successfully read (0 bytes).
Also, I have tried the different combination,

As result, if send MessageContent1 first, then MessageContent2, later whatever MessageContent send, it only receive 0 byte.

but if I send MessageContent2, then MessageContent1 , later,
it still can recive 13 bytes even send MessageContent3.
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 11 Jun 2010, 19:31

There is one more thing I took from your logs. There is an endpoint reset for the response endpoint close to the end in both logs.

I added that. Please load the beta package again with the same link, it is changed now. Try with the included config first.
Top
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 14 Jun 2010, 05:04

sorry for late reply.

It is pity that still fail, also try enable message delay.
here is log.
* usb-modeswitch: handle USB devices with multiple modes
* Version 1.1.3 (C) Josua Dietze 2010
* Based on libusb0 (0.1.12 and above)

! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor= 0x1a8d
DefaultProduct= 0x1000
TargetVendor= 0x1a8d
TargetProduct= 0x1009
TargetClass= not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
GCTMode=0
MessageEndpoint= not set
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
NeedResponse=1
ResponseEndpoint= not set
Interface=0x00

InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode disabled

usb_os_init: Found USB VFS at /proc/bus/usb
usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_busses: Skipping non bus directory devices
usb_os_find_devices: Found 001 on 002
usb_os_find_devices: Found 003 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device

Looking for target devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
searching devices, found USB ID 0000:0000
No devices in target mode or class found
Looking for default devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 0000:0000
Found devices in default mode or class (1)
Accessing device 003 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: BandRich, Inc.
Product: BandLuxe 3.5G HSPA Adapter
Serial No.: 358094021837456
-------------------------
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to the message (CSW) ...
OK, response successfully read (13 bytes).
Delaying next message transfer for 1000 ms
Trying to send message 2 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 2 ...
OK, response successfully read (13 bytes).
Resetting response endpoint 0x81
Resetting message endpoint 0x01

Checking for mode switch (max. 20 times, once per second) ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Waiting for original device to vanish ...
Original device still present after the timeout

Mode switch most likely failed. Bye.
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 14 Jun 2010, 08:19

What happens if you add your third command again? And no delay?
Top
CCTU
Posts: 14
Joined: 02 Jun 2010, 14:23

Post by CCTU » 14 Jun 2010, 08:31

It works!!! And it do not need MessageDelay.
When I type "sudo usb_modeswitch -c 1a8d\:1000\:uPr\=5G ."
Usb mode is switched correctly.
This is the log file.
http://dl.dropbox.com/u/2495108/usb_mod ... ta_success
But I could not find the symbolic link "/dev/gsmmodem."


Then, I test it in auto modeswitch process, but it failed.
I follow the steps to test it.
step1. sudo cp 1a8d:1000:uPr=5G /etc/usb_modeswitch.d/

setp2. modify /etc/usb_modeswitch.conf and set
DisableSwitching=0

step3. replug-n C170 device.

step4. "lsusb" and device id is not changed.
This is the log file.
http://dl.dropbox.com/u/2495108/usb_mod ... _beta_0614
Josh wrote:O.K., folks, there is a new beta package ready.

Please try first with the included config file (1a8d:1000:uPr=5G) with the -c parameter, as usual. If it still doesn't work try to enable the "MessageDelay" parameter which is commented out initially.

I mainly changed two things to come closer to what your sniffing logs are showing.
Top
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 14 Jun 2010, 08:51

the 3rd message still receive 0 byte,

here skip some message for saving space.
MessageEndpoint= not set
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
MessageContent3="55534243123456700000000000000600000000000000000000000000000000"
NeedResponse=1
ResponseEndpoint= not set
Interface=0x00

InquireDevice enabled (default)
Success check enabled, max. wait time 20 seconds
System integration mode disabled

usb_os_init: Found USB VFS at /proc/bus/usb
usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_busses: Skipping non bus directory devices
usb_os_find_devices: Found 001 on 002
usb_os_find_devices: Found 009 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device

Looking for target devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
searching devices, found USB ID 0000:0000
No devices in target mode or class found
Looking for default devices ...
searching devices, found USB ID 0000:0000
searching devices, found USB ID 1a8d:1000
found matching vendor ID
found matching product ID
adding device
searching devices, found USB ID 0000:0000
Found devices in default mode or class (1)
Accessing device 009 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached

SCSI inquiry data (for identification)
-------------------------
Vendor String: BandRich
Model String: CDROM
Revision String: 2.01
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: BandRich, Inc.
Product: BandLuxe 3.5G HSPA Adapter
Serial No.: 358094021837456
-------------------------
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to the message (CSW) ...
OK, response successfully read (13 bytes).
Delaying next message transfer for 500 ms
Trying to send message 2 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 2 ...
OK, response successfully read (13 bytes).
Delaying next message transfer for 500 ms
Trying to send message 3 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 3 ...
OK, response successfully read (0 bytes).
Resetting response endpoint 0x81
Resetting message endpoint 0x01

Checking for mode switch (max. 20 times, once per second) ...
Waiting for original device to vanish ...

Waiting for original device to vanish ...
Original device still present after the timeout

Mode switch most likely failed. Bye.
.
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 14 Jun 2010, 11:53

There is one very last thing to try ... Add a -R to the command line; this will send a reset command to the device after all others.

That is my last idea so far. I will see if I can get my hands on a modem of that family.
Top
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 14 Jun 2010, 13:11

-R parameter also fail.

This kind of modem is really trouble, I will spare a little time to try, if having progress, I will let you know.

Anyway thanks for your help~~
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 14 Jun 2010, 20:19

I just ordered a C170 which will be sent from Taiwan. Let's see if I can figure out something a few days from now.
Top
aaa37
Posts: 23
Joined: 08 Oct 2009, 07:59

Post by aaa37 » 15 Jun 2010, 05:01

"CCTU" reported that using new package to switch c170 seems ok.
But the modem I used is c270, maybe c270 is a little different than c170?
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 15 Jun 2010, 08:09

Oops, I missed that success report ...

CCTU, somehow an older wrapper version slipped into the beta package. I corrected that, and if you load it again, you should have a match and everything should work automatically.

You will never get a "gsmmodem" link if you run usb_modeswitch manually. This is created by the wrapper in cooperation with udev.

aaa37, I doubt there is a big difference in the firmware between the two models. I suspect that your problems are connected with your system.
Once I have the modem here, I have four machines and seven different distributions to test on. If it is a system-dependent problem, I am likely to run into it on one of the installations.

Top
CCTU
Posts: 14
Joined: 02 Jun 2010, 14:23

Post by CCTU » 20 Jun 2010, 16:21

Yes!!I re-download and re-install the package you given in previous post(Posted: Thu Jun 10, 2010 5:25 pm).

The auto switch feature works after I plug-in C170 device.
And I could see the "/dev/gsmmodem" link to my device /dev/ttyUSBx.
Thank you!! It really a hug help~

But could I consult you one more question?
Each time if I want to dial up to network, I type command "sudo wvdial Modem=/dev/gsmmodem."
How could I make it an auto task in my mode switch process?
An idea auto process is:
1. plug-in C170
2. auto mode-switch
3. auto send command "sudo wvdial Modem=/dev/gsmmodem"

If step3 could be work, mode-switch will be a perfect solution. ^_^
hrhr...Although usb-ModeSwitch is really a good solution for now.

Josh wrote:Oops, I missed that success report ...

CCTU, somehow an older wrapper version slipped into the beta package. I corrected that, and if you load it again, you should have a match and everything should work automatically.

You will never get a "gsmmodem" link if you run usb_modeswitch manually. This is created by the wrapper in cooperation with udev.

aaa37, I doubt there is a big difference in the firmware between the two models. I suspect that your problems are connected with your system.
Once I have the modem here, I have four machines and seven different distributions to test on. If it is a system-dependent problem, I am likely to run into it on one of the installations.
Top
Josh
Site Admin
Posts: 6570
Joined: 03 Nov 2007, 00:30

Post by Josh » 21 Jun 2010, 11:07

The easiest way is to edit the wrapper script:
/lib/udev/usb_modeswitch

Before line 618 which reads "return $symlinkName", you can insert an "exec" command to launch any external program.

Example:
exec /usr/local/startdial.sh $symlinkName &

Start that script with a "sleep 1" line to give udev time to complete the symlink action. Then run wvdial with "Modem=/dev/$1".

No need for "sudo", the wrapper runs with admin rights.

Top
Post Reply

Return to “Device Information”