[tekra]

I recently purchased a USB wireless stick from Virgin Mobile that doesn't switch. Probably my lack of understanding of what's required. When plugged into a Lenovo laptop running Slackware 12.2 / KDE it is opened by Konqueror, displays as a normal directory, is visible as the same in MC, and lists with 'lsusb' as follows:
root@lenovo:~# lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.

I then compiled and installed usb_modeswitch as per instructions. All OK, no error messages. Commandline invocation works fine. The filelist in /etc/usb_modeswitch.d/ contains the entry 12d1:1446 with contents:

########################################################
# Huawei, newer modems

DefaultVendor= 0x12d1
DefaultProduct=0x1446

TargetVendor= 0x12d1
TargetProductList="1001,1406,140b,140c,141b,14ac"

CheckSuccess=20

MessageContent="55534243123456780000000000000011060000000000000000000000000000"

Note the entry in the line TargetProductList of '140c'. Using this as the config file:

root@lenovo:~# usb_modeswitch -v 12d1 -p 1446 -V 12d1 -P 140c

Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
No devices in default mode or class found. Nothing to do. Bye.

root@lenovo:~# usb_modeswitch -c /etc/usb_modeswitch.d/12d1:1446
Warning: TargetProductList overrides TargetProduct!

Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
No devices in default mode or class found. Nothing to do. Bye.

Any assistance or suggestions much appreciated.
Tekra.

[Josh]

root@lenovo:~# lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.

This shows that the modem was switched all right. Did you issue that lsub command after installation of usb_modeswitch ?

In that case see if you have a symbolic link file in the /dev folder named "gsmmodem".

[tekra]

Did you issue that lsub command after installation of usb_modeswitch ?

No, before. This is what puzzles me. Here is the sequence after pluggin in the modem:

root@lenovo:~# mount
/dev/sr1 on /media/Virgin Mobile type iso9660 (ro,nosuid,nodev,noatime,uhelper=hal,uid=0,utf8)

root@lenovo:~# lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.

root@lenovo:~# usb_modeswitch -c /etc/usb_modeswitch.d/12d1:1446
Warning: TargetProductList overrides TargetProduct!

Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
No devices in default mode or class found. Nothing to do. Bye.

root@lenovo:~# lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.

root@lenovo:~# mount
/dev/sr1 on /media/Virgin Mobile type iso9660 (ro,nosuid,nodev,noatime,uhelper=hal,uid=0,utf8)

In that case see if you have a symbolic link file in the /dev folder named "gsmmodem".

There's no /dev folder or softlink named "gsmmodem".

It looks to me like there's a duplicate device ID involved. Note the following output from usb_modeswitch:

Warning: TargetProductList overrides TargetProduct!

If this is so, it could be nasty to sort out. My background is in hardware engineering, and I'm reasonably proficient with Linux, so if you'd like me to assist in figuring it out, I'd be happy to follow your instructions.

FYI, I'm in Australia where Virgin Mobile is a fourth-tier player in the wireless broadband market. The modem's brand new and may not be in your database.

Over to you
Tekra

[Josh]

I don't think it's hard to figure out. If usb_modeswitch doesn't do the switching then something else does. I guess you will find an existing rule for 12d1:1446 somewhere in your udev rules folders (/lib/udev and /etc/udev).

That in itself would not be a problem, but usb_modeswitch takes care of the driver loading as well which the "other" known methods don't do. So it might be preferable to disable the existing rules and leave the whole thing to usb_modeswitch.

[tekra]

I guess you will find an existing rule for 12d1:1446 somewhere in your udev rules folders (/lib/udev and /etc/udev).

root@lenovo:/lib/udev/rules.d# grep 1446 *
40-usb_modeswitch.rules:ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"
root@lenovo:/lib/udev/rules.d# lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.
root@lenovo:/lib/udev# grep 140c *
root@lenovo:/lib/udev# grep 140C *
root@lenovo:/lib/udev#

Yep, as above.

That in itself would not be a problem, but usb_modeswitch takes care of the driver loading as well which the "other" known methods don't do. So it might be preferable to disable the existing rules and leave the whole thing to usb_modeswitch.

Commented out the line (# at beginning):
root@lenovo:/lib/udev/rules.d# cat 40-usb_modeswitch.rules |grep 1446
#ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1446", RUN+="usb_modeswitch '%b/%k'"

Unmounted the device, reinserted it - identified by KDE as an "Unmounted CD writer". Reran 'usb_modeswitch -c /etc/usb_modeswtitch.d/12d1:1446' with the same result including the warning:
Warning: TargetProductList overrides TargetProduct!

I don't think it's hard to figure out. If usb_modeswitch doesn't do the switching then something else does.

Question: IF it has been switched, should I still see the USB storage device? I've NEVER seen 12d1:1446 only 12d1:140c and this is storage - at least, I can read the files in it. If it has been switched, how do I identify it as a modem? A blue LED on the device blinks at about three-second intervals - looks like a modem searching for a connection, but KDE doesn't detect it as such.

[tekra]

Here's a possible solution. Some months ago, I purchased a Western Digital 'My Book - Essentials' 1TB external USB HDD. It came configured in such a way that it registered as TWO separate devices every time it was plugged in, one the HDD, the second a 'fake CD'. The CD contained M$ firmware for doing backups etc. Fortunately, WD provided a (Windows only) utility that disabled the 'fake CD', and it now behaves as an ordinary 1TB USB HDD.

If the ID 12d1:140c refers to a modem, as it obviously seems to, then the device may NOT need switching. It appears to have a 'dual personality' like the WD HDD - a 'fake CD' and a modem. I know that PCI devices can have two or more subdevices, and it appears that USB devices can do the same. If this is the case, then the modem may always be visible, and may just need the setup string passed to it.

Does this sound reasonable?

[Josh]

I think you might have had usb_modeswitch installed before doing the "lsusb". Did you check again with the rule disabled/outcommented? What USB ID are you seeing then? I assume it will be "12d1:1446" ...

The "Override Warning" is really pointless; in fact it is a tiny bug (or quirk), a leftover from a change in the source for version 1.1.4. Note that the message itself is the error; it should not be displayed. Otherwise this does not affect operation at all.

For newer devices it's not uncommon to expose the install storage after switching. The difference is that they usually do not register themselves as CD but as a plain stick.

[tekra]

I think you might have had usb_modeswitch installed before doing the "lsusb".

lsusb was installed - version 0.1.12 whereas I installed 1.0.8.
modeswitch wasn't installed prior to my installing it. I checked this and I'm sure: also it's not in the package list and a grep of the package logs looking for 'modeswitch' fails.

Did you check again with the rule disabled/outcommented? What USB ID are you seeing then? I assume it will be "12d1:1446"

No. I've just plugged the modem into an older machine running PCLinuxOS 2009.1. It has no usb_modeswitch, '/lib/udev/rules.d/40-usb_modeswitch.rules' or anything else, and it lists the device straight away as 12d1:140c

I then used the PCLOS Hardware Detection utility and found the device listed twice, in both cases under ID 12d1
1. As a USB storage device with the module 'usb_storage' used and class 'Mass Storage|SCSI|Bulk (Zip)'.
2. As a CDROM with module 'usb_storage (usb_storage)' and class 'cdrom (Mass Storage|SCSI|Bulk (Zip))'.

For newer devices it's not uncommon to expose the install storage after switching. The difference is that they usually do not register themselves as CD but as a plain stick.

OK, then we have a device that:
1. Registers as a single device with ID 12d1:140c on plugging in, and is detected as both USB storage and a CDROM.
2. Implements a CD storage device with an ISO9660 filesystem that is mountable and readable.
3. Presumably contains a modem that is not detected by the h'ware detection utility.

What's next?

[tekra]

Copied 12d1:1446 to 12d1:140c in /etc/usb_modeswitch.d/ then did the following:

[~># lsusb
Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.

[~># usb_modeswitch -c /etc/usb_modeswitch.d/12d1:140c
Warning: TargetProductList overrides TargetProduct!

Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
Found devices in default mode or class (1)
Accessing device 004 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
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: HUAWEI
Model String: Mass Storage
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: HUAWEI Technology
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
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

Checking for mode switch (max. 20 times, once per second) ...
Waiting for original device to vanish ...
Original device can't be accessed anymore. Good.
Searching for target devices ...
Searching for target devices ...
^C

This suggests that the modem may have been activated.

Question again: how do I check that a modem is present?

Went to KPPP and asked it to query modem - not found. Went to /dev/bus/usb/001/ and found that entry 005 was timestamped with the same moment that I invoked usb_modeswitch. This suggests that it is the modem, but the list in KPPP does not have this entry. Can't find how to expand list in ~/.kde/share/apps/ or ../config/

[Josh]

To check for the modem state, you need the output of "lsusb -v -d 12d1:140c", issued before and after your manual switching.

Please post both outputs here, I should like to see them.

[tekra]

OK, here goes. I apologize for the length of this post. If it's a nuisance, I can delete it and put the text file up on my website with a link to it.

[~># lsusb -v -d 12d1:140c

Bus 001 Device 003: ID 12d1:140c Huawei Technologies Co., Ltd.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x140c
bcdDevice 0.00
iManufacturer 3 HUAWEI Technology
iProduct 2 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 1 Qualcomm Configuration
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
...
[Edited for brevity, Josh]

[~># usb_modeswitch -c /etc/usb_modeswitch.d/12d1:140c
Warning: TargetProductList overrides TargetProduct!

Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
Found devices in default mode or class (1)
Accessing device 003 on bus 001 ...
Using endpoints 0x01 (out) and 0x81 (in)
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: HUAWEI
Model String: Mass Storage
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer: HUAWEI Technology
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
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
Error resetting endpoint: -71

Checking for mode switch (max. 20 times, once per second) ...
Waiting for original device to vanish ...
Original device can't be accessed anymore. Good.
Searching for target devices ...
^C

[~># lsusb -v -d 12d1:140c

Bus 001 Device 004: ID 12d1:140c Huawei Technologies Co., Ltd.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x140c
bcdDevice 0.00
iManufacturer 3 HUAWEI Technology
iProduct 2 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 161
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 1 Qualcomm Configuration
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
...
[Edited for brevity, Josh]

[Josh]

I apologize for the length of this post

I knew what the length would be

No problem, I'll save this completely and then I'll edit your post to remove everything non-essential.

About your device, it really does not change IDs. If you are sure that the original ID had been 12d1:1446, then you somehow managed to reach a third mode ...

Never mind, to recognize the mode in that case we will use the TargetClass parameter. Remove the target IDs in your copy of the config file and add "TargetClass=0xff".
In your "lsusb" output you can see that the device has indeed changed internally. Interface 0 has class 8 initially, after switching it has class 255. That's what we are checking instead of the ID.

[tekra]

About your device, it really does not change IDs. If you are sure that the original ID had been 12d1:1446, then you somehow managed to reach a third mode ...

Forgot to mention back earlier that when I copied the config file I altered the DefaultProduct line to '0x140c' (natch).

Never mind, to recognize the mode in that case we will use the TargetClass parameter. Remove the target IDs in your copy of the config file and add "TargetClass=0xff".

Have put a # at the beginning of the TargetProductList line (assume that'target IDs' refers to this) and inserted your TargetClass line below it.

In your "lsusb" output you can see that the device has indeed changed internally. Interface 0 has class 8 initially, after switching it has class 255. That's what we are checking instead of the ID.

OK, thanks. Am beginning to understand the process. I've been redirecting output into files, and have just done a diff of the two outputs. Using the changes above, the output of the second lsusb in each case was the same, but here's the difference with usb_modewitch:

2d1
< Warning: TargetProductList overrides TargetProduct!
5c4
< Found devices in target mode or class (1)
---
> No devices in target mode or class found
35d33
< Error resetting endpoint: -71
40,41c38,42
< Searching for target devices ...
< ^C
---
> (For a better success check provide target IDs or class)
> Original device vanished after switching
>
> Mode switch most likely succeeded. Bye.

Does this mean that the modem should now work? Reason I ask is I haven't yet enabled the account; it's got a one-month timeout so if it's not working I'll be losing access time.

One other concern. Once the device is mounted, it is named 'Virgin Mobile' and has a subdirectory within it with the same name:

[Virgin Mobile># ls
AUTORUN.INF DataCard_Setup.exe ResetDevice.exe SysConfig.dat
AutoRun.exe DataCard_Setup64.exe Startup.ico Virgin Mobile
[Virgin Mobile># cd Virgin\ Mobile/
[Virgin Mobile># ls
data.bin setup.exe

I've a feeling that the 'setup.exe' in this subdir will need to be run in order to access the account, and given what we've discussed, other devices may not have this requirement. Can you recommend a procedure from here? The first thing I need to verify is that the modem is active and hunting for a connection. Then perhaps activate the account and see if it logs in successfully. If not, I'll need to come back to you for further assistance.

With thanks for all your help so far.

Tekra.

[Josh]

Please just delete all "Target" lines except the "TargetClass". I was being unprecise: "target ID" denotes vendor and product ID after switching.
There are other examples of the TargetClass usage in some config files (see the "0af0" configurations).

If your config file is complete, you need to add a line to the udev rule file (40-usb_modeswitch.rules):

Code: Select all

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="140c", RUN+="usb_modeswitch '%b/%k'"

Best to insert this close to the other Huawei lines, but the exact position does not matter as long as you put it above the end label.

From that point on, you shouldn't have to do anything but to plug your stick in to make it usable.

If you did not activate your SIM card yet, I'd recommend to use the Windows software for that. Afterwards, it should work happily with Linux. But don't ask me about your provider data or special procedures; you should find lots of hints in the Net.

[boran]

Hi,

If I may join in... I have a USB stick modem from Swisscom with E180v written on it.
Lsusb identifies it as 12d1:140c.

The OS is ubuntu 8.04, which is a bit old, 2.6.24.

Now I've read though all of the above.. and tried unsuccessfully.. ...
I'm not sure that the device needs to switch into a modem mode, but I don't see a modem device anywhere (like /dev/ttyU*).

Can usb_modeswitch compensate for an older kernel?

I previously had an older stick on this kernel and iot recognized and created /dev/ttyUSB0

Some output:
/usr/sbin/usb_modeswitch -c /etc/usb_modeswitch.d/12d1:140c
Looking for target devices ...
Found devices in target mode or class (1)
Looking for default devices ...
No devices in default mode or class found. Nothing to do. Bye.

cat /etc/usb_modeswitch.d/12d1:140c
########################################################
# Huawei, newer modems
DefaultVendor= 0x12d1
DefaultProduct=0x140c
#TargetVendor= 0x12d1
#TargetProductList="1001,1406,140b,140c,1412,141b,14ac"
TargetClass=0xff
CheckSuccess=20
MessageContent="55534243123456780000000000000011060000000000000000000000000000"

Thanks in advance,

Sean