Royaltek Q110

kent_chang · Post by **kent_chang** » 03 May 2010, 12:03

I want to know the MessageContent of Royaltek Q110.
Please help me, thanks.

DefaultVendor = 0x0408
DefaultProduct= 0xf000
TargetVendor = 0x0408
TargetProduct = 0xea03

MessageEndpoint=0x01
MessageContent="????"

Post by **Josh** » 03 May 2010, 19:29

To find that MessageContent you need access to the device and a Windows system where you can start progs with admin rights. Do you have it?

If so, read the short sniffing hint on the main doc page, paragraph "Contribute"; there is a link to the Windows sniffer and annother to the report of a good case example.

kent_chang · Post by **kent_chang** » 04 May 2010, 05:53

Thanks Josh.
I got USBSnoop.log with sniffUSB and try to find MessageContent in the log.

(1) find MessageContent
PipeHandle = 88b477dc [endpoint 0x00000001]
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 0000001f
TransferBuffer = 8822e688
TransferBufferMDL = 00000000
00000000: 55 53 42 43 00 4e 9e 89 fc 00 00 00 80 01 0a 23
00000010: 00 00 00 00 00 00 00 fc 00 00 00 00 00 00 00

(2) use command to switch
usb_modeswitch -v 0x0408 -p 0xf000 -V 0x0408 -P 0xea03 -m 0x01 -M 5553424308d0bf88fc00000080010a2300000000000000fc00000000000000

However, it still can't work to change.
Is the MessageContent wrong?
how to find the correct MessageContent in the log?
Thank you very much

Post by **Josh** » 04 May 2010, 08:42

It should not be too hard for your device because it changes the device ID.

It's important that you install the sniffing filter only on 0408:f000; in Windows it translates to "Vid_0408_Pid_f000" or similar.

This ID (in fact the whole first device) goes away after switching which means the log stops growing. At the end of the log you should find some messages in capitals containing SURPRISE_REMOVAL.

The switching command must be one of the bulk transfers (or control messages) occurring close to the end; best to work up your way backwards.

Sometimes the relevant command is repeated several times until the device reacts.

The transfers starting with "55 53 42 43" are storage commands and among the first suspects. They have the same length as the one you posted.
If they have a 06 in them they are most likely SCSI commands. A typical switching sequence would be "06 1b" which represents the EJECT command.

Testing in Linux is the only way to confirm your findings ... good luck!

kent_chang · Post by **kent_chang** » 05 May 2010, 10:42

Thank you Josh.
I have try to find "06 1b" in the UsbSnoop.log but I can't find it.

This is my UsbSnoop.log file
http://fileupper.com/WG1WL2Q0U668/UsbSnoop.log.html

Post by **Josh** » 05 May 2010, 11:31

Doesn't have to be "06 1b".

From what I see in the log I'd try the message from URB 1103:

55534243123456780000000000010600000000000000000000000000000000

Note that byte 4-7 is a random tag. I set it to 12345678.

rrbert · Post by **rrbert** » 14 Jun 2010, 23:03

I think I have the same device so I created a file modeled on your format and called 0408:f000
########################################################
# Quanta Q110 (aka "RoyalTek")

DefaultVendor= 0x0408
DefaultProduct=0xf000

MessageContent="55534243123456780000000000010600000000000000000000000000000000"

root@darkstar:/home/rl# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 04b8:084d Seiko Epson Corp.
Bus 003 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 001 Device 006: ID 0408:f000 Quanta Computer, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@darkstar:/home/rl# usb_modeswitch -c /home/rl/usbwifi/0408:f000

Looking for default devices ...
Found devices in default mode or class (1)
Accessing device 006 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: ConnMgr
Model String: Storage
Revision String: 2.31
-------------------------

USB description data (for identification)
-------------------------
Manufacturer:
Product: DataCard Device
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
-> Run lsusb to note any changes. Bye.

root@darkstar:/home/rl# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 04b8:084d Seiko Epson Corp.
Bus 003 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 001 Device 006: ID 0408:f000 Quanta Computer, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@darkstar:/home/rl#

lsusb seems to be the same, however there were some devices created in /dev
(bsg, sda, sdb, sg0, sg1) when I first plugged it in, that were removed after running the program.
rrbert

Post by **Josh** » 17 Jun 2010, 08:15

Hmm, I don't think that command changed anything. The disappearing devices are a consequence of removing the storage driver.

Unfortunately, I did not save the sniffing log from kent_chang and now it's not online anymore. Do you have a copy by any chance?

rrbert · Post by **rrbert** » 18 Jun 2010, 23:21

No, I don't have a copy and don't have windows either.
It appears that you may have already helped someone solve this particular problem.
http://www.draisberghof.de/usb_modeswit ... .php?t=249
Unfortunately, he didn't document his solution after getting his modem working. Hopefully this time we will.
On the usb in disk mode are drivers for windows, mac, EeePC, and AspireOne
So I downloaded linpus lite (the OS for AspireOne) which is like a cross between slax and redhat
and boot my computer, hoping to monitor the usb. However it is a partially crippled linux system and doesn't
have some basic commands like lsusb.
So I'm trying another tack, examining the driver code for the EeePC, and am finding some useful info
the modified option module
root@odin:/home/mm/quanta/usbwifi# modinfo option.ko | grep 0408
alias: usb:v0408pEA02d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0408pEA03d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0408pEA04d*dc*dsc*dp*ic*isc*ip*

udev rules especially 10-GXXdatacarddisk.rules
root@odin:/home/mm/quanta/usbwifi# cat 10-GXXdatacarddisk.rules
#This udev rule enables Gkx Data card to be detected as Gkxdatacarddisk while connected
#This rule invokes the /usr/bin/GkxSockClient application to wake up GkxMonitor
KERNEL=="sr[0-9]",SYSFS{idVendor}=="0408",SYSFS{idProduct}=="f00[0-1]",RUN+="/usr/bin/eject -s %k"
KERNEL=="sr[0-9]",SYSFS{idVendor}=="0408",SYSFS{idProduct}=="f00[0-1]",RUN+="/usr/bin/GkxSockClient"
#DRIVER="usb",SYSFS{idVendor}=="0408",SYSFS{idProduct}=="f00[0-1]",SYMLINK="GKxdatacarddisk",RUN+="/usr/bin/GkxSockClient"
#modify by sean, 20090226
KERNEL=="sd[a-z]",SYSFS{size}=="60928",SYMLINK="GKxdatacarddisk",RUN+="/usr/bin/GkxSockClient"

and a partial disassembly of GkxMonitor which I think switches the mode
here seems to be the relevant function
08048c76 <SwitchToModem>:
8048c76: 55 push %ebp
8048c77: 89 e5 mov %esp,%ebp
8048c79: 81 ec 98 00 00 00 sub $0x98,%esp
8048c7f: c7 45 e4 00 00 00 00 movl $0x0,-0x1c(%ebp)
8048c86: c7 45 e8 00 00 00 00 movl $0x0,-0x18(%ebp)
8048c8d: c7 45 ec 00 00 00 00 movl $0x0,-0x14(%ebp)
8048c94: c7 45 f0 00 00 00 00 movl $0x0,-0x10(%ebp)
8048c9b: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%ebp)
8048ca2: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp)
8048ca9: a1 08 af 04 08 mov 0x804af08,%eax
<-- snip -->
where I see your 'magic prefix' 55 at the top. It may take me some time to interpret
the other numbers as I've forgotten most of my assembly language knowledge.
this is from the file GkxMonitorobjdump-S which was created by
objdump -S GkxMonitor > GkxMonitorobjdump-S

All of these files can be viewed at

http://xyztw.com/usbwifi/index.php

rrbert

Post by **Josh** » 21 Jun 2010, 17:47

I think the thing is switched "eject" and the remaining tools are used to handle/monitor the resulting serial port. Note the difference between "sr" and "sd" in the rules. Apart from that the second rule seems to be a bit confusing.

Stand by for a few hours, I will release a new package with a test version for these devices.

rrbert · Post by **rrbert** » 28 Aug 2010, 19:16

success

Method
1. plug the device into the usb port
2. mount it (i used dolphin from kde)
3. issue the command
touch /media/CONNMGR/wcdma.cfg
4. wait a few seconds, then issue the command (as root)
pppd call the-name-of-your-pppd-connection-script

Note: some people prefer to use wvdial for step 4
Anyhow the main point is step 3, which does the switching in this case.
I didn't invent this method myself, but stumbled across it on a message board.
The credit should go to Ethan Hsiao, who says he spent 5 months trying to figure it out.
He actually reported the method for a D-Link DWM-156 vendor=0x07d1 product=0x3e02
and just mentioned that it would also work for a Quanta Q110.

To make it clearer what is happening here is some more info

root@darkstar:/home/rl# uname -a
Linux darkstar 2.6.33.4-smp #1 SMP Wed May 12 21:39:37 CDT 2010 i686 Intel(R) Celeron(R) M CPU 440 @ 1.86GHz GenuineIntel GNU/Linux

1. plug the device into the usb port

root@darkstar:/home/rl# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0408:f000 Quanta Computer, Inc.
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
Bus 003 Device 002: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

2. mount it (i used dolphin from kde)
root@darkstar:/home/rl# mount
/dev/sda8 on / type ext4 (rw,relatime,barrier=1,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sdb on /media/CONNMGR type vfat (rw,nosuid,nodev,uhelper=hal,uid=1000,utf8,shortname=mixed,flush)
root@darkstar:/home/rl# ls /media/CONNMGR
AUTORUN.INF AspireOne EeePC Mac QSG.pdf VID0408PIDEA03.cfg icon.ico setup setup.exe
root@darkstar:/home/rl# lsmod | grep ption
root@darkstar:/home/rl# ls /dev/ttyUSB*
ls: cannot access /dev/ttyUSB*: No such file or directory

3. issue the command
root@darkstar:/home/rl# touch /media/CONNMGR/wcdma.cfg
root@darkstar:/home/rl# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0408:ea03 Quanta Computer, Inc.
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
Bus 003 Device 002: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@darkstar:/home/rl# ls /dev/ttyUSB*
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3
root@darkstar:/home/rl# lsmod | grep ption
option 14564 0
usbserial 27618 1 option
root@darkstar:/home/rl# mount
/dev/sda8 on / type ext4 (rw,relatime,barrier=1,data=ordered)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)

Note that after step 3, the device switches and the option module is loaded automatically
and the ttyUSB devices are created

I think it may be the case that this is an undocumented :) method that could provide insight
into the behaviour of certain devices, but also a 2nd, more traditional method
(maybe using 2 messages separated by 500 mS or so) exists.
Just before I found this method, I had access to a windows machine and got a UsbSnoop.log
file, which I have pasted up along with my earlier files.

http://xyztw.com/usbwifi/index.php

The UsbSnoop.log file seems to have these delays.

I'm quite happy to use my semi-manual method, but I guess the next thing to do is write some
udev rules and integrate it with usb_modeswitch so that people can just plug it in
and have it work.

rrbert

Post by **Josh** » 28 Aug 2010, 22:12

The question is if you have to access that specific file (wcdma.cfg) or if it would work by accessing any of the existing files. The "touch" command will try to update the last-modified date of the target file. This will not work on a real CDROM obviously; maybe the directory write access does something to the device.

I had annother look on the log (thanks for providing!) and I did not find anything suspicious - apart from one storage command which is undocumented.

The repeating sequence (once a second) that you spotted is a "test unit ready" command - this shows the driver waiting for the device to vanish.

The suspicious command is sent right after the device is fully discovered by the system and shortly before it is mounted (the reading of the directory follows); see [363 ms], urb 66.
From there it takes almost six seconds until the device is gone and the log ends.

So maybe you try that one command. The other working method is kind of awkward to implement in a way that it runs on every system; I would be relieved if there was a simpler way ...

Code: Select all

MessageContent="55534243123456781800000000000615100000180000000000000000000000"

rrbert · Post by **rrbert** » 02 Sep 2010, 20:48

No, the new message didn't seem to work either.
Just to be sure, I installed your latest version (1.1.4) and tried with the new message,
"55534243123456781800000000000615100000180000000000000000000000"
then also tried again with the 1st message,
"55534243123456780000000000010600000000000000000000000000000000"

However an interesting thing is that the file wcdma.cfg does not exist until created by the
touch command. It also needs to be recreated each time to switch. Would it be possible
to wrap this command in a scsi command?
Alternatively we might be able to do it in the udev rules.

There is also a thread about the D-Link DWM-156 which seems to use the same method.

rrbert