Page 1 of 1

Quanta (vendor 0408) modem and karmic (2.6.31 kernel)

Posted: 04 Nov 2009, 07:59
by jakartadean
I've been struggling to get this modem (marketed in Indonesia as the Telkomsel Flash SU-8500U) working. I just purchased it, and wanted to get it working with the new kernel / hal model, so haven't tried it under other versions. It does work under windows.

It sets itself up as usb-storage, with vendor_id=0x0408 and product_id=0xf001. It should be able to flip into the same vendor_id with product_id 0xEA02 to EA04.

The modem ships with drivers for mac and windows, and two .deb files for the xandros Eee. In fact, I'm using an EeePC 900, but got rid of xandros the day I first tried it. installing the debs fails quietly, with some problems with home directories. Having poked around them a little, I'm not keen on getting them working anyway, as they change a bunch of files, including the serial.ko module.

What I've tried:
adding a rule to /etc/udev/rules.d to change the product id
adding a rule to /etc/udev/rules.d to send a message, copied from another thread
using usb_modeswitch manually to change product id
using usb_modeswitch manually to send a message copied from another thread
after the above, I've also tried sending a suspend signal using echo, which makes the device disappear from lsusb, but it never reappears.

None of these worked. I'm guessing that I need to get a message that works with this particular modem. I've sniffed the interaction on the windows box, and I'll post that later. Here's the dmesg:
[ 8831.504370] usb 1-3: new high speed USB device using ehci_hcd and address 4
[ 8831.686178] usb 1-3: configuration #1 chosen from 1 choice
[ 8831.692703] scsi3 : SCSI emulation for USB Mass Storage devices
[ 8831.692936] usb-storage: device found at 4
[ 8831.692941] usb-storage: waiting for device to settle before scanning
[ 8836.693413] usb-storage: device scan complete
[ 8836.696391] scsi 3:0:0:0: Direct-Access ConnMgr Storage 2.31 PQ: 0 ANSI: 2
[ 8836.702129] scsi 3:0:0:1: Direct-Access Micro_SD Storage 2.31 PQ: 0 ANSI: 2
[ 8836.702959] sd 3:0:0:0: Attached scsi generic sg3 type 0
[ 8836.703172] sd 3:0:0:1: Attached scsi generic sg4 type 0
[ 8836.718530] sd 3:0:0:0: [sdd] 60928 512-byte logical blocks: (31.1 MB/29.7 MiB)
[ 8836.721586] sd 3:0:0:0: [sdd] Write Protect is off
[ 8836.721596] sd 3:0:0:0: [sdd] Mode Sense: 0f 0e 00 00
[ 8836.721602] sd 3:0:0:0: [sdd] Assuming drive cache: write through
[ 8836.731213] sd 3:0:0:0: [sdd] Assuming drive cache: write through
[ 8836.731228] sdd:
[ 8836.758514] sd 3:0:0:1: [sde] Attached SCSI removable disk
[ 8836.761736] sd 3:0:0:0: [sdd] Assuming drive cache: write through
[ 8836.761749] sd 3:0:0:0: [sdd] Attached SCSI disk

and lsusb:
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 0408:f001 Quanta Computer, Inc.
Bus 001 Device 003: ID 05e3:0505 Genesys Logic, Inc.
Bus 001 Device 002: ID 0951:1606 Kingston Technology
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

and, finally, usb_modeswitch:
sudo usb_modeswitch -v 0x0408 -p 0xf001 -V 0x0408 -P 0xea04
[sudo] password for dean:

* 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 target devices ...
No devices in target mode or class found
Looking for default devices ...
Found default devices (1)
Accessing device 004 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: ConnMgr
Product String: Storage
Revision String: 2.31
-------------------------

Device description data (identification)
-------------------------
Manufacturer:
Product: DataCard Device
Serial No.: 1234567890ABCDEF
-------------------------
Warning: no switching method given.
-> Run lsusb to note any changes. Bye.

SnoopyPro log export (XML format) -- LONG!

Posted: 04 Nov 2009, 13:26
by jakartadean
<?xml version='1.0'?>

<!-- This file was generated by SnoopyPro -->

<snoopyprolog>




(edited by moderator; please don't post sniffing logs here)

Posted: 04 Nov 2009, 15:18
by Josh
I recommend reading the USB_ModeSwitch doc page. First paragraph, to see what the program does.

It's useless if you don't give any switching method or command.

Furthermore, don't post long files/logs here; there is pastebin.com and others.

Regarding the device, the first thing I'd try is to use "eject" on the storage device (/dev/sdb or similar, see "dmesg" output).

If that does not work, sniffing on Windows is the next step.
Sniff on the storage device (the old ID) and focus on the last commands (bulk transfers) that the driver sends to it before it vanishes and the log stops growing.

Posted: 05 Nov 2009, 05:57
by jakartadean
Sorry about the long post. In my defence, I did look for some preferred method, and when I didn't find a sticky I looked at a couple of other threads, and they had some long posts also, so I thought that was the preferred method. I'm new at this (obviously).

I did read the documentation, and I tried all the commands -- I just posted the output of one example. None of them did anything. I'm happy to try one and post the output.

The situation I'm encountering seems to be unusual, as I don't get a CD-ROM mounted automatically, as others seem to get. I can mount the device manually, just as I would with any other flash disk type of device, and examine files. I can eject the device, whether manually mounted or not, with no error message. I understand your suggestion to me to run "eject /dev/sdd" after I plug the modem in, but without mounting it manually. I have tried this, it has no effect -- no error message, but no change to lsusb and no entry in dmesg.

I can look at the last commands of the sniff output, but I seriously doubt my ability to interpret them, and I thought the experienced and competent folks like yourself might find something obvious with a glance, whereas I don't know where to begin. I do believe this device is somewhat different from others I've read about, in other threads here and elsewhere, but I suspect it just needs a different message sent to switch it, as it works in Windows.

Regards,
Dean

Posted: 06 Nov 2009, 10:19
by Josh
You said in the first post the device will have product ID "0xEA02 to EA04" after switching. Is it correct that there will be three different devices after switching? That would be unusual.

For sniffing I recommend SniffUSB (see "Contribute" on the doc page). It outputs plain text, which is easier to read than the result of other tools like SnoopyPro.

If you need hints how to set the sniffer up, here are some:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=695#695

As always, the only interesting part is the end of the log, the last transfers to the device (bulk or control). Following that there is usually a "SURPRISE_REMOVAL".

Posted: 06 Nov 2009, 19:09
by jakartadean
Thanks. I do think this device is unusual. Unfortunately, I'm home for the weekend and away from my windows machine, but I'll try to post the xandros scripts, which do reference three serial ports. As I mentioned earlier, I don't think this was done in a recommended way, and I'm far from an expert, so it's certainly possible I'm wrong. I am certainly not clear about the relationships among tty ports and product ids, for example. I *think* I understand what the standard forms are trying to do, but I can't apply that to this particular case. Possibly because I'm an idiot...

I appreciate your reply, and will post more info as soon as I can.

Regards,
Dean

Posted: 06 Nov 2009, 20:35
by Josh
If the information about the three product IDs is from the Xandros scripts, it may well be that it refers to three different models the scripts are supposed to handle (including other modem variants from the same vendor).

It's not unusual at all to have three serial devices after switching -meaning system devices in the /dev folder. But usually there is only one product ID per device - meaning the physical box in your hand.

We should now focus on the switching; "a solution will present itself in time" ...

Still no joy...

Posted: 11 Nov 2009, 11:29
by jakartadean
I've tried as you suggested, and a little more poking around, but I haven't been able to get it working yet.

I've tried sending the last four commands down that look right to me -- strings beginning with "55 53" to endpoint 0x01 (it uses 0x01 and 0x81 just like the others I've seen on your site). I've even learned more than I ever wanted to know about USB (I liked this document).

There is an interesting exchange at the top of the dialog. The device says it supports two configurations, but I can only see one described, then it sends what looks to me like an invalid string describing the same configuration a second time but with too many bytes. It's highlighted near the top of the log file.

I haven't tried the echo suspend modification this time around, as it just seems to suspend the device, but the device never wakes up.

I've uploaded the top and bottom of the log file if you are interested in snooping around. I'm close to giving up on this thing, but they are selling a lot of them here, so I'm sure others will come across the same problem, and I'd like to help fix it.

Regards,
Dean

Posted: 11 Nov 2009, 19:26
by Josh
What sticks out to me is that there is no "REMOVAL" of the storage device.

How is the thing behaving in Windows? Is the storage (driver) part still visible when the modem part is activated?

Will the log file stop growing after a while?

(Remember to install the logger only for the storage device.)

It will be harder to figure out if the original device is staying active.
In that case, you'd have to install the sniffer on all devices (which are not active at the beginning) to get a combined log. Then you are able to find the moment of activation for the modem devices and look at the storage commands before that moment.

Posted: 12 Nov 2009, 05:17
by jakartadean
It sounds like I haven't been clear. When plugged in, the device appears in the kde USB notification area, but is not automatically mounted (just like any standard USB flash disk). I can mount it and read it, and then eject it. There is no magic "CD-ROM" appearing anywhere. I can't eject it before mounting it.

When I run USB_modeswitch with any of the four messages I highlighted yesterday, the devices disappears from the kde USB devices notification area. No modem or /dev/ttyUSBx appears, and lsusb still indicates the same product id (0xf001).

In windows, it is present as devices G: and H: I cannot read G: -- it tells me to insert a disk. I can read H:, and it's the files stored on the stick's memory.

Posted: 12 Nov 2009, 10:18
by Josh
Now it's me who probably hasn't been clear enough.
If I write about devices present or not I refer to the display of SniffUSB in Windows. It shows in a column if a device with a certain ID is present (plugged in and active) or not. The default setting is to show only devices that have a "yes" in that column. But if you check the option "List Devices Not Present" you see all device IDs ever made available to this machine - including parts of your (physical) device which may have been switched off.

For logging you need to look for the default ID of your stick ("Vid_0408&Pid_f001") and install the filter there before replugging.

For looking at the device IDs present after the switching, it's of course more convenient to list only devices that are present.

Don't bother about drives being visible and disappearing on the desktop. To send a bulk message (the MessageContent), USB_ModeSwitch has to detach the storage driver from the device; consequently it can't be accessed anymore, no matter if the message did anything at all.
And the second drive (your G: ) in Windows is most likely a card reader slot in your stick.

Now you probably want to read my previous post again - and look for this REMOVAL in the log ...

Posted: 13 Nov 2009, 08:09
by jakartadean
Sorry to be late replying, I have been busy at work, and yesterday's experience with this thing was strange...

I went back to my windows machine, but I somehow screwed up the modem badly, as the windows software no longer recognized the modem, just the memory (and card reader, you were right). The only way to fix this was unplug the modem, uninstall the modem's software, then plug it in again and reinstall the software.

In so doing, I discovered a two-page documentation file, which referred to a "quick start mode" Aha, I thought, found that and tried it, and the modem is now recognized in my linux box as a modem (product_id 0xea04). It does build 4 USB ports under /dev, as you suggested. Although I now have a modem, I haven't got the AT commands mastered yet to get it to work, but that shouldn't be hard.

I'm happy to continue to work on the usb_modeswitch side of it if you like, to contribute to the database, but obviously it is a lower priority now. Just let me know.

Thanks for all your help, and the great tool you have developed.

Dean

Posted: 13 Nov 2009, 19:15
by Josh
Yes, please be so kind and complete the sniffing as advised before to help others cope with that modem! And we were indeed very close to a breakthrough ...

Just do that one logging on device "Vid_0408&Pid_f001" in Windows: clear the log file, install the filter (before plugging), start logging, plug the stick, wait a while until the modem is ready. Then please post the log to "pastebin" as you did before.

The "Quick Start Mode" is switched on (or off) by the Windows software, right?
Mind that you'd have to disable it temporarily before sniffing ...

I'd be very grateful if you could squeeze that somewhere into your schedule!