[Hello1024]

Hi,

Firstly, this is NOT the same as the LG HDM-2100 (EVDO Rev.A USB modem) which has the same device ID - the commands required are totally different.

Secondly, this device doesn't enumerate properly with linux standard usb drivers, even as a mass storage device. The symptoms are it enumerates but then after exactly 0.5 seconds it disconnects again, and the phone switches to "charge mode", as if it was plugged into a dumb wall charger. The solution to this is to plug the usb cable in and then reboot the phone - then it seems to enumerate properly (although watch out, it first enumerates as an Infinion bootloader, then disconnects, and then again as an LG usb device)

When enumerated, it has id 1004:607f, works correctly with usb-storage as a CD drive with windows drivers, as normal. The modeswitch part VERY NEARLY works in wine - it calls the win32 deviceIoControl, and I've managed to get all the parameters to the API call if it's useful. (the actual "switch" library they use is only ~100 lines of code, so is easy to understand)

Here is it's lsusb:

Code: Select all

Bus 003 Device 005: ID 1004:607f LG Electronics, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1004 LG Electronics, Inc.
  idProduct          0x607f 
  bcdDevice            1.00
  iManufacturer           1 LG
  iProduct                2 LGE USB Device
  iSerial                 3 359068021834936
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 LGE USB Device
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              5 ms ifac 1 (SCSI::BULK_ONLY)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x89  EP 9 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0a  EP 10 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

The usb sniff log was very long because it loads lots of files from the usb devices filesystem, but I managed to write my own windows modeswitch program and managed to shorten the log considerably. You can see it here:
http://pastebin.com/Bs9HGUMP

I wrote a config file like this:

Code: Select all

########################################################
# LG KP500 Cookie Phone modem

DefaultVendor= 0x1004
DefaultProduct=0x607f

TargetVendor=  0x1004
TargetProduct= 0x6000

CheckSuccess=20

MessageContent="555342435886b5ff03000000800006f1010100000000000000000000000000"

The problem is that this seems unreliable - 90% of the time it doesn't work, but 10% of the time it will switch, and when it does, here is the lsusb output:

Code: Select all

Bus 003 Device 004: ID 1004:6000 LG Electronics, Inc. VX4400/VX6000 Cellphone
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1004 LG Electronics, Inc.
  idProduct          0x6000 VX4400/VX6000 Cellphone
  bcdDevice            1.00
  iManufacturer           1 LG
  iProduct                2 LGE USB Device
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           90
    bNumInterfaces          3
    bConfigurationValue     2
    iConfiguration          3 cfg1: ACM w/ BULK and Dbg/Trc
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              4 control ifac (ACM AT)
      CDC Header:
        bcdCDC               1.10
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x07
          sends break
          line coding and serial state
          get/set/clear comm features
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              5 CDC Data Interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              6 CDC Data Interface
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

Note that I've only managed to get it to switch twice, so it's possible the config file above is wrong, and it's switching by chance.

Can anyone with more knowledge of windows' deviceIoControl api and the usb mass storage spec look through the logs and tell me if there would be a better way to send these messages?

[Josh]

Firstly, this is NOT the same as the LG HDM-2100 (EVDO Rev.A USB modem) which has the same device ID - the commands required are totally different.

I was never completely sure if the contributed HDM-2100 message content is correct.

Secondly, this device doesn't enumerate properly with linux standard usb drivers, even as a mass storage device. The symptoms are it enumerates but then after exactly 0.5 seconds it disconnects again, and the phone switches to "charge mode", as if it was plugged into a dumb wall charger. The solution to this is to plug the usb cable in and then reboot the phone - then it seems to enumerate properly (although watch out, it first enumerates as an Infinion bootloader, then disconnects, and then again as an LG usb device)

Some phones can be set to a defined USB mode. I assume that is not possible with your device. Or is it?

The usb sniff log was very long because it loads lots of files from the usb devices filesystem

Does it do that every time or just at the first plug?

MessageContent="555342435886b5ff03000000800006f1010100000000000000000000000000"

You may want to try the following line too which is in your log several times:

MessageContent="55534243123456780000000000000600000000000000000000000000000000"

[Hello1024]

I just wrote out a massive reply, and then the kernel paniced while unplugging the serial device while it was in use... grr...

Some phones can be set to a defined USB mode. I assume that is not possible with your device. Or is it?

Yes. The phone has 5 modes:

• PC Internet - this is the one I'm using
  Mass Storage (this simulates 2 mass storage devices, one for internal memory and one for an sd reader, but doesn't enumerate on linux)
  PC Suite - for reading sms, calendar sync etc. to a custom windows app
  Music Sync - never used it...
  Always Ask - on windows it brings a menu up on the phone screen to ask which mode to use. On linux nothing happens.

Does it do that every time or just at the first plug?

Every time. The way it works is it shows up as a cd drive, which then auto-runs an installer for the drivers, and then runs an app which sends a scsi command to switch modes. The problem is with all that software loading up off the usb device, most of the usb sniffing tools just freeze when they see megabytes of 64 byte packets going past...

The source code to the windows "switcher" basicly sends IOCTL_SCSI_PASS_THROUGH to DeviceIoControl() which contains a raw SCSI command, which has a 6 byte CDB "F1 02 20 00 00 00" while reading 3 bytes of data from the device. it then discards the results of the read, and quits. I have dumps of all the workings of the windows app, and wrote up in full glory every detail before the kernel panic...

I suspect the reason it's unreliable is because we don't read 3 bytes of data after sending that packet on the usb bus.

Having said all the above, it looks like a cleaner solution than throwing a raw binary packet down the usb bus would be to use the linux kernel scsi functionality to send that same command to the block device...

[Hello1024]

Just tried the scsi method, and have had success with this:

sudo sg_raw -r 3 /dev/sr1 F1 02 20 00 00 00
sudo sg_raw /dev/sr1 F1 01 01 00 00 00

I'm not entirely sure why I need the 2nd one, but the dump has this command, and the switch only seems to occur with both commands in sequence.

my system seems to freeze with 100% IO wait for about 30 seconds when sending these commands, but it now at least always switches mode. Note that I have seen the freeze problem on windows when switching modes, so I suspect that it's simply the phone being slow to reply, or giving some invalid response.

PS. Very impressed with NetworkManager - it got the connection set up in seconds. Not impressed with the performance though - latency varies from 1500ms to 2500ms. Even though this is EDGE, it still shouldn't be quite that bad...

[Josh]

It's not necessary to sniff the driver and software installation process.

First do the installation without the sniffer active.

Then unplug the device.

Then install one filter on the original storage device (it shows in the list only when option "List Device Not Present" is checked).

Then plug the device.

This way you catch only the interaction from plugging to switching.
I seriously doubt that you need any unusual methods to prepare the device.

[Hello1024]

It's not necessary to sniff the driver and software installation process.

The problem was that the software is installed every time the device is plugged in, not dependant on if they are already installed or not. It simply starts the installer, which runs through the install steps, skipping any already installed files. The last install step is to send the scsi command to switch to modem mode. (this is done through the standard mass storage driver, since at this point their modem driver is installed, but not yet loaded)

[Josh]

The last install step is to send the scsi command to switch to modem mode. (this is done through the standard mass storage driver, since at this point their modem driver is installed, but not yet loaded)

Ah, this is unusual; all other manufacturers install a special driver for the original device ID which handles the switching on each following connection - immediately after plugging in ...

Anyway, did you try other MessageContents ? I posted one and there is annother suspect, probably in combination:
"555342431234567800000000000006f1010100000000000000000000000000"

Mind that you can have up to three messages in version 1.1.2. If there is more than one, the CSW (command status wrapper) is read after each as the standard demands.