Alcatel One Touch X220L (1bbb:f000)
As the OT-X220L HSPA USB modem seems to be currently unsupported, I have followed the instructions by Mark Ziesemer and have sniffed the corresponding commands, but am not sure which MessageContent to use for the device. The device IDs are 1bbb:f000 (unswitched) and 1bbb:0017 (switched), and the USBSnoop.log is provided here. I would greatly appreciate any help getting the device working on Ubuntu (9.10).
O.K., the log seems to be correct.
There are two "MessageContents" to try. The first is known to work with other Alcatel devices, the second is a suspect from your log.
Please put this into a test config file (like "test.conf"):Call it (as root or with sudo):
"usb_modeswitch -c test.conf"
If the first message doesn't help, change the "test.conf" file, comment it out and uncomment the second message. Repeat the run.
"dmesg" and "lsusb" can show you if there were any changes.
There are two "MessageContents" to try. The first is known to work with other Alcatel devices, the second is a suspect from your log.
Please put this into a test config file (like "test.conf"):
Code: Select all
DefaultVendor= 0x1bbb
DefaultProduct= 0xf000
TargetVendor= 0x1bbb
TargetProduct= 0x0017
MessageContent="55534243123456788000000080000606f50402527000000000000000000000"
#MessageContent="55534243123456780000000000000600000000000000000000000000000000""usb_modeswitch -c test.conf"
If the first message doesn't help, change the "test.conf" file, comment it out and uncomment the second message. Repeat the run.
"dmesg" and "lsusb" can show you if there were any changes.
Thank you, Josh!
However, none of the suggested "MessageContent" lines didn't work so I collected all the potential messages from the log-file, placing each on a separate line in a text file. After ordering the lines I discovered a message quite similar to the first one you suggested. The following "MessageContent" switched the modem successfully, and now I write this through the 3G connection:
Cheers! 
However, none of the suggested "MessageContent" lines didn't work so I collected all the potential messages from the log-file, placing each on a separate line in a text file. After ordering the lines I discovered a message quite similar to the first one you suggested. The following "MessageContent" switched the modem successfully, and now I write this through the 3G connection:
Code: Select all
5553424348680a88c000000080010606f50402527000000000000000000000
Very good news!
The strange thing is that I can't find that command in the log you posted.
Anyway, since the USB IDs of your device are identical to annother device with a slightly different switching command, I badly need some information about your's ...
Be so kind and post a "lsusb -v -d 1bbb:" of the unswitched device. Also, I'd like to see the output of a nonswitching run of usb_modeswitch:
"usb_modeswitch -v 1bbb -p f000"
If you have the lastest version (1.1.2) of usb_modeswitch, may I ask you to test a combination of both known commands in your "test.conf"?
Like this:
...
MessageContent="55534243123456788000000080000606f50402527000000000000000000000"
MessageContent2="5553424387654321c000000080010606f50402527000000000000000000000"
Don't worry about differences to your command, the "12345678" is a random tag which doesn't do anything except giving a unique ID to the bulk transfer.
The strange thing is that I can't find that command in the log you posted.
Anyway, since the USB IDs of your device are identical to annother device with a slightly different switching command, I badly need some information about your's ...
Be so kind and post a "lsusb -v -d 1bbb:" of the unswitched device. Also, I'd like to see the output of a nonswitching run of usb_modeswitch:
"usb_modeswitch -v 1bbb -p f000"
If you have the lastest version (1.1.2) of usb_modeswitch, may I ask you to test a combination of both known commands in your "test.conf"?
Like this:
...
MessageContent="55534243123456788000000080000606f50402527000000000000000000000"
MessageContent2="5553424387654321c000000080010606f50402527000000000000000000000"
Don't worry about differences to your command, the "12345678" is a random tag which doesn't do anything except giving a unique ID to the bulk transfer.
Well, it might be that I have used an older log-file (as I have produced a few) to collect the working "MesageContent" I posted.
Anyway, here is the output of the commands as requested:
Anyway, here is the output of the commands as requested:
Code: Select all
lsusb -v -d 1bbb:
Bus 001 Device 023: ID 1bbb:f000 T & A Mobile Phones
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1bbb T & A Mobile Phones
idProduct 0xf000
bcdDevice 0.00
iManufacturer 3
iProduct 2
iSerial 4
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 1
bmAttributes 0xa0
(Bus 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
can't get device qualifier: Operation not permitted
can't get debug descriptor: Operation not permitted
cannot read device status, Operation not permitted (1)
Code: Select all
sudo usb_modeswitch -v 1bbb -p f000
* usb_modeswitch: tool for controlling "flip flop" mode USB devices
* Version 1.0.2 (C) Josua Dietze 2009
* Works with libusb 0.1.12 and probably other versions
Looking for default devices ...
Found default devices (1)
Accessing device 025 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
Received inquiry data (detailed identification)
-------------------------
Vendor String: ALCATEL
Product String: Mass Storage
Revision String: 2.31
-------------------------
Device description data (identification)
-------------------------
Manufacturer: USBModem
Product: HSPA Data Card
Serial No.: 1234567890ABCDEF
-------------------------
Warning: no switching method given.
-> Run lsusb to note any changes. Bye.
I forgot to add that I use the packaged usb-modeswitch (1.0.2-1) so I cannot test the combination right now, but as I will update to the latest Ubuntu soon, I will build usb_modeswitch (1.1.2) and will provide feedback on this.If you have the lastest version (1.1.2) of usb_modeswitch, may I ask you to test a combination of both known commands in your "test.conf"?
I have build the latest usb_modeswitch and using the above combination I get:...
If you have the lastest version (1.1.2) of usb_modeswitch, may I ask you to test a combination of both known commands in your "test.conf"?
Like this:
...
MessageContent="55534243123456788000000080000606f50402527000000000000000000000"
MessageContent2="5553424387654321c000000080010606f50402527000000000000000000000"
Don't worry about differences to your command, the "12345678" is a random tag which doesn't do anything except giving a unique ID to the bulk transfer.
Code: Select all
sudo ~/bin/usb_modeswitch -c test.conf
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
Found devices in default mode or class (1)
Accessing device 035 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: ALCATEL
Model String: Mass Storage
Revision String: 2.31
-------------------------
USB description data (for identification)
-------------------------
Manufacturer: USBModem
Product: HSPA Data Card
Serial No.: 1234567890ABCDEF
-------------------------
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Trying to send message 2 to endpoint 0x01 ...
Device seems to have vanished right after sending. Good.
Device is gone, skipping any further commands
-> Run lsusb to note any changes. Bye.
Yes, it does. And that is a very good thing, because it means that there is no need to set up an extra configuration for that device.john256 wrote:Thereafter I can dial and establish a connection. Does this mean that the first "MessageContent" actually works?
Maybe the newer program version did the trick, 1.0.2 is really outdated.
If you have the data package too (it's now separate) then there is only a little correction necessary to get the full support for your modem.
There should be a small file called "1bbb:f000" among many in "/etc/usb_modeswitch.d". Edit this (with admin rights) and change the line
Code: Select all
TargetProduct= 0x0000Code: Select all
TargetProductList="0000,0017"Last night I tested the modem with both "MessageContent" strings alternating and have found that when using the first one, the modem light turns green from time to time, that means, according to the user manual, it "registers to HSPA or UMTS network". When using the second "MessageContent" the modem remained all the time registered into the GPRS or EDGE network (i.e. the light was constantly red). Could this observation be a good reason to use only the second "MessageContent" for this modem?
I rather assume the contrary:
usually these modems are constantly trying to get the fastest connection method available, which means that they sometimes change protocols and try to "upgrade".
This is transparent from the user's side and should not be noticed except when the speed of transfer does improve.
Staying in EDGE mode means that you have a fixed low bit rate which is probably not what you want.
usually these modems are constantly trying to get the fastest connection method available, which means that they sometimes change protocols and try to "upgrade".
This is transparent from the user's side and should not be noticed except when the speed of transfer does improve.
Staying in EDGE mode means that you have a fixed low bit rate which is probably not what you want.
Yes, this is definitely not what I wantStaying in EDGE mode means that you have a fixed low bit rate which is probably not what you want.
, but I couldn't confirm with the ISP that the connection is limited to EDGE/GPRS only (as revealed during the continuous use of the device under win32 with it's native software & driver), so the light-indicated shift appeared rather strange to me and therefore I assumed that there was something wrong with the first "MessageContent" used for switching the device.Thank you for the help so far, Josh!
I have found this thread very interesting and tried using the information to solve a problem I have but without any success
I have a device that first showed with lsusb as 1bbb:f000. The device was automatically mounted as a mass storage device. I unmounted the device and the information under lsusb changed to 1bbb:0017. This meant that I was unable to use usb_modeswitch because it was looking for 1bbb:f000.
I created a test file as suggested:
I alternated the MessageContent and got the same output each time:
Here is the output of lsusb -v -d 1bbb:
I have also tried editing the /etc/usb_modeswitch.d/1bbb:f000 file as suggested but get the same message.
Any help would be appreciated as it appears that this device should work but it is a little beyond me to finish off the job!
BTW since umounting the device I have never seen 1bbb:f000 again. I cannot switch it back to that state.
I have a device that first showed with lsusb as 1bbb:f000. The device was automatically mounted as a mass storage device. I unmounted the device and the information under lsusb changed to 1bbb:0017. This meant that I was unable to use usb_modeswitch because it was looking for 1bbb:f000.
I created a test file as suggested:
Code: Select all
DefaultVendor= 0x1bbb
DefaultProduct= 0xf000
TargetVendor= 0x1bbb
TargetProduct= 0x0017
#MessageContent="55534243123456788000000080000606f50402527000000000000000000000"
#MessageContent="55534243123456780000000000000600000000000000000000000000000000"
MessageContent="5553424348680a88c000000080010606f50402527000000000000000000000"Code: Select all
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.Code: Select all
Bus 001 Device 004: ID 1bbb:0017 T & A Mobile Phones
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1bbb T & A Mobile Phones
idProduct 0x0017
bcdDevice 0.00
iManufacturer 3 USBModem
iProduct 2 HSPA Data Card
iSerial 4 1234567890ABCDEF
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 154
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 1 USBModem Configuration
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
Any help would be appreciated as it appears that this device should work but it is a little beyond me to finish off the job!
BTW since umounting the device I have never seen 1bbb:f000 again. I cannot switch it back to that state.
O.K.; first, you should not have to uninstall the mass storage if everything works. Also, usb_modeswitch does its job automatically, so in an ideal case you won't even notice it.
Second, with your edit of the config file, you likely made everything work
I just realized that the "0017" entry is still missing in the config file. I should have added it to the official data package. Sorry about that. All it needs really is that little change pointed out here.
My view of your situation is (just a guess):
usb_modeswitch was already working when you saw the drive on the desktop (many modems expose their driver partition again after switching. Unmounting did not change anything I suspect. But there was no driver loaded because of the missing target entry in the config file.
Then you edited the config file, so even the driver should work now.
If you don't see the 1bbb:f000 anymore, this means everything is fine. Check if you get a symbolic link file in the "/dev" folder named "gsmmodem" after plugging (only for usb_modeswitch packages >= 1.1.2). This will point to your connection port (ttyUSBx).
If you have reason to believe that something is not right with the device, switch on logging as described on the main doc page, paragraph "Troubleshooting".
Second, with your edit of the config file, you likely made everything work
I just realized that the "0017" entry is still missing in the config file. I should have added it to the official data package. Sorry about that. All it needs really is that little change pointed out here.
My view of your situation is (just a guess):
usb_modeswitch was already working when you saw the drive on the desktop (many modems expose their driver partition again after switching. Unmounting did not change anything I suspect. But there was no driver loaded because of the missing target entry in the config file.
Then you edited the config file, so even the driver should work now.
If you don't see the 1bbb:f000 anymore, this means everything is fine. Check if you get a symbolic link file in the "/dev" folder named "gsmmodem" after plugging (only for usb_modeswitch packages >= 1.1.2). This will point to your connection port (ttyUSBx).
If you have reason to believe that something is not right with the device, switch on logging as described on the main doc page, paragraph "Troubleshooting".
Thanks Josh, you were right 
I am now struggling with actually making a connection. I have run wvdialconf and a /etc/wvdial.conf file has been created. I just get a 'no carrier' message over and over again and the dongle just continues to flash red.
Using the Network Manager is another option but I am not sure what to enter where?
If anyone has an opinion on the best way to go on this it would be useful. I am using Linux Mint Isadora KDE.
BTW is it still possible to access the mass storage device on the dongle?
Thanks
Alan
I am now struggling with actually making a connection. I have run wvdialconf and a /etc/wvdial.conf file has been created. I just get a 'no carrier' message over and over again and the dongle just continues to flash red.
Using the Network Manager is another option but I am not sure what to enter where?
If anyone has an opinion on the best way to go on this it would be useful. I am using Linux Mint Isadora KDE.
BTW is it still possible to access the mass storage device on the dongle?
Thanks
Alan