| Author |
Message |
< Device Information ~ MD400 (Sonyericsson HSUPA USB modem) I need some help! |
| The Solutor |
 Posted: Mon Dec 29, 2008 11:59 am |
 |
|
|
Joined: 29 Dec 2008
Posts: 29
|
I got yesterday this modem, it works perfectly (about 6Mbps of average download speed  ) but , as you imagine, there are some trubles using it in linux.
The modem works well if I reboot the PC from a a windows session, without power down or detach the device.
I solved the problem of turning ON the radio with the command
AT+CFUN=1 (radio enabled)
or
AT+CFUN=6 (radio enabled for UMTS/HSPA only)
I also found a way to use the modem via lan and not via the old dialup way:
first I patched the kernel with this:
http://lkml.indiana.edu/hypermail/linux/net/0810.3/0014.html
And then I activate the internal lan with the command
AT+ENAP=1,1 (the first digit enables the lan interface, the second recalls the first profile, the one created in windows by the SE dashboard).
But if I detach and reattach the modem the only discovered devices are the modem internal flash disk and the M2/microSD card.
So I discovered this nice program usb_modeswitch but I'm still not able to use the modem.
I grabbed two USB logs in windows
http://www.megaupload.com/it/?d=IH8ZHW0R
one with the SE drivers installed, and one with the standard windows drivers (in the latter case windows can see only the two flash disks as linux does).
I'm not so skilled in those low level things, but seems that the correct "magic number" is
55534243207ebd862400000080000612000000240000000000000000000000
which is sent to the endpoint 0x03
Now I tried this in linux but the problem is that sending anything to the EP 0x03 is refused, only the EP 0x01 accepts the message, but then nothing happens.
Can someone take a look to the attached logs (they are in snoopy format), or gimme any useful ideas ?
Thanks in advance, and Happy New Year to all the forum users. |
|
|
| Back to top |
 
|
| Josh |
| Posted: Tue Dec 30, 2008 12:16 am |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
Can't read the logs. What format are they?
I recommend using sniffusb which outputs plain text. |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 12:50 am |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
It's the format of snoopy pro http://sourceforge.net/project/showfiles.php?group_id=34567.
Try it, is nice, tiny, open source, and when the logs are loaded in the program, is a lot of easier to read than the plain text output.
I tried sniffusb but for some weird reason the program won't start to monitor when the SE drivers are loaded, so I have just the "flash drive mode" output in plain text format.
I'll try with another installation/os to see if I can get the missing log, in the meantime if you want to take a look to snoopy pro, I think is not only useful to help me, it is just a sw that can help you and other users.
Thanks again for your reply. |
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 1:12 am |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
I tried the logs with SnoopyPro which I found in some forgotten folder and was able to open them.
First: forget endpoint 0x03. This one is obviously available only after switching. The interesting log is the one with no driver installed. And there the endpoint to talk to is 0x01.
Second: the switching message should appear at the end of the log because after switching the device is reconfigured and the original setup stops working (and logging).
I see two strings that keep being repeated. If I were you I'd try one or both.
55534243123456780000000000010600000000000000000000000000000000
and
55534243876543210000000000000600000000000000000000000000000000
Digits 9 to 16 are free to change, they are just an ID tag sequence.
To see if the device was not switched already (it's keeping its USB IDs after the switch) you can try to check for TargetClass 0x02. USB_ModeSwitch stops doing anything if it finds the device with that class. |
Last edited by Josh on Tue Dec 30, 2008 1:15 am; edited 1 time in total |
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 1:13 am |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 1:16 am |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
| I'll go to bed now. Will check the new logs tomorrow. |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 1:20 am |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
Sorry, haven't seen you reply because We posted at the same time.
I'll try your suggestions, and then I go to bed too  |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 1:55 am |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
Quote: I see two strings that keep being repeated. If I were you I'd try one or both.
55534243123456780000000000010600000000000000000000000000000000
and
55534243876543210000000000000600000000000000000000000000000000
Tried both, still no luck. (nothing happens)  .
Now some sleep. |
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 10:46 am |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
I'm on to something. You have awoken the bloodhound that sleeps in me 
I suspect that this Sony device is switched by other means than all the other devices so far. On the very beginning of both your log variants with driver installed, the first thing to be sent to the device is a "VENDOR_DEVICE" function. Immediately afterwards the new setup gets initiated quite normally.
Now I'm researching how to apply that function with "libusb". Stand by and don't bother about these message strings ... |
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 11:53 am |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
I changed the original source; for quick testing I used the Huawei option and altered the control message to match that vendor-specific command of SE.
Get this test version, unpack and use it in the following command line:Code: ./usb_modeswitch_sony -v 0x0fce -p 0xd0e1 -H 1
I get an error code of -32 when trying with my totally unrelated device. What's happening with yours?
Anyway, error or not, watch on a different console what udevmonitor is saying. And, if nothing happens, you can add the "-R 1" switch to the command to issue a device reset after the control sequence. This might (or not) change something.
I have to get ready for work now but will be monitoring this thread. |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 1:33 pm |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
Quote: I'm on to something. You have awoken the bloodhound that sleeps in me
hehe...
Maybe because my usual avatar is Silvester Jr
Quote: I get an error code of -32 when trying with my totally unrelated device. What's happening with yours
I'm on a fedora x64 so your binary wasn't working (as all the other precompiled versions available on your site) so I installed the 32bit version of libusb and now the executable runs.
this is what I get (with or without the -R switch)
Quote: Looking for default devices
Found default devices (1)
Prepare switching, accessing latest device
Error: sending Sony control message failed (error -32). Aborting
Nothing happens on dmesg or udev side
P.S. the Irony is that the SE phones are (by far) the easiest way to get connected. You have to configure the apn on the phone then just plug the usb connector an you are online, no furter action is required on the pc side or in the phone side.
Now I bought this key becouse l guessed that the some system was used on the key. Instead the cdc protocol is a new subset and isn't understood by the cdc_ether module and this flip flop thing is getting all even worse.
In eleven years of wireless internet this is the second time tath I have to ask help to getting connected, the firs time was in '98 due to a bug in the IRDA stack, but was the stone age... |
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 2:00 pm |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
So you get the same error as I do.
One more thing to try: prevent the storage module from loading when plugging in.
The VENDOR_DEVICE function is called in the very beginning from the Windows driver.
And then again the test binary command. |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 2:32 pm |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
Already tried (I simply removed the usbstorage module, then I did a depmod -a)
This is what I get with dmesg:
Code:
usb 1-8: new high speed USB device using ehci_hcd and address 11
usb 1-8: configuration #1 chosen from 1 choice
usb 1-8: New USB device found, idVendor=0fce, idProduct=d0e1
usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-8: Product: MMC Flash Card
usb 1-8: Manufacturer: Sony Ericsson
usb 1-8: SerialNumber: 3578650*******
and udevmonitor
Code:
udevmonitor
the program '/bin/bash' called 'udevmonitor', it should use 'udevadm monitor <options>', this will stop working in a future release
monitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent
UEVENT[1230643843.350530] add /devices/pci0000:00/0000:00:13.3/usb1/1-8 (usb)
UEVENT[1230643843.351647] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0 (usb)
UEVENT[1230643843.351969] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0/usb_endpoint/usbdev1.12_ep01 (usb_endpoint)
UEVENT[1230643843.352091] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0/usb_endpoint/usbdev1.12_ep81 (usb_endpoint)
UEVENT[1230643843.352215] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/usb_endpoint/usbdev1.12_ep00 (usb_endpoint)
UDEV [1230643843.354582] add /devices/pci0000:00/0000:00:13.3/usb1/1-8 (usb)
UDEV [1230643843.358244] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/usb_endpoint/usbdev1.12_ep00 (usb_endpoint)
UDEV [1230643843.363303] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0 (usb)
UDEV [1230643843.365354] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0/usb_endpoint/usbdev1.12_ep01 (usb_endpoint)
UDEV [1230643843.367229] add /devices/pci0000:00/0000:00:13.3/usb1/1-8/1-8:1.0/usb_endpoint/usbdev1.12_ep81 (usb_endpoint) |
|
|
| Back to top |
|
| Josh |
| Posted: Tue Dec 30, 2008 3:43 pm |
|
|
|
Site Admin
Joined: 02 Nov 2007
Posts: 1245
|
Well, this is a tough one.
The Windows driver sends this command before even querying the device. In the "storage" log without installed driver you can see the usual sequence of things.
It might be necessary to put that sequence into the usb core driver ...
Are you sure that there is no other device entry to sniff out in Windows? When I tried to get my first device to work I had the advantage of a different vendor/product ID after switching.
But still, on the Sony stick you have two different device classes before and after switching. Chances are you have TWO entries in the SniffUSB driver list. Is that so? If not - back to square one ... |
|
|
| Back to top |
|
| The Solutor |
| Posted: Tue Dec 30, 2008 5:02 pm |
|
|
|
Joined: 29 Dec 2008
Posts: 29
|
Josh wrote: Well, this is a tough one.
The Windows driver sends this command before even querying the device. In the "storage" log without installed driver you can see the usual sequence of things.
It might be necessary to put that sequence into the usb core driver ...
I'm afraid too that this can be the only reasonable way...
Even the md 300 way http://www.nabble.com/Sony-Ericson-MD300-td20156685.html seem not applicable here.
BTW I emailed the link to this tread to the author of the kernel patch linked above, is an Ericsonn employee and maybe can provide useful information.
Quote: Are you sure that there is no other device entry to sniff out in Windows? When I tried to get my first device to work I had the advantage of a different vendor/product ID after switching.
I'm reasonably sure.
The only doubt I had was a "wwan" service wich is installed by the drivers package (and not from the dashboard). So I removed the drivers via control panel, and I replugged the modem.
Then I made the driver update via the "classic" device manager way.
After the upgrade of the "md 400 composite device" the devices switched (w/o unplug and plug) then the other child devices had discovered (all the child devices but not the LAN one, that seem a totally virtual device built by the setup process unlike what happen on the SE phones).
P.S. the windows drivers are built by MCCI and not from SE as happen on the SE phones, this explain the different behaviour between the SE phones and the SE keys |
|
|
| Back to top |
|
|
|
