here the new portion of logs, this I've tryed to filter every USB device exept mouse, keys, BT e.t.c.
connect physically than dial internet, for some reson dialing was fail
http://pastebin.com/pWcyfD7i
restart computer, than start sniffing, than connect the device than dial(this time ok) and disconnect session
http://pastebin.com/68FRAbEJ
than clear log and replug via sniffer one-by-one
1. SlectR Modem
2. SlectR Device Management1 (WDM)
3. SlectR Device Management2 (WDM)
http://pastebin.com/JX5rE0vk
PS
I'm so close to return this bloody device to the shop and take another model ))
I begin to suspect that this device holds its state for some time even when unplugged.
Your observation with the connection LED would support that assumption.
It would be the first time this is actually happening, but I actually waited for such a mechanism to come along. Your logs with driver installed are showing a different device than at the start of the big installation log - like the mode after switching was remembered. Maybe there is a capacitor or something that provides enough voltage to keep up the memory.
If that is a fact, then it is important to wait a (long) while between plugs. Maybe even to try short-circuiting the contact areas in the plug with the shield after unplugging.
But if that is a fact, then it should be possible to plug the thing in Windows, let it switch and immediately plug it into the router; and the "acm" driver should bind to it.
A different possibility is that the Windows driver does in fact prevent anything to bind to the storage part of the device; maybe this initiates the mode switch. In Linux that behaviour should be possible to achieve by blacklisting the storage driver ("usb-storage" in the new kernels).
I will see if I can get my hands on one of these things. Somebody lend me one? Maybe your dealer after you returned your's ?
Your observation with the connection LED would support that assumption.
It would be the first time this is actually happening, but I actually waited for such a mechanism to come along. Your logs with driver installed are showing a different device than at the start of the big installation log - like the mode after switching was remembered. Maybe there is a capacitor or something that provides enough voltage to keep up the memory.
If that is a fact, then it is important to wait a (long) while between plugs. Maybe even to try short-circuiting the contact areas in the plug with the shield after unplugging.
But if that is a fact, then it should be possible to plug the thing in Windows, let it switch and immediately plug it into the router; and the "acm" driver should bind to it.
A different possibility is that the Windows driver does in fact prevent anything to bind to the storage part of the device; maybe this initiates the mode switch. In Linux that behaviour should be possible to achieve by blacklisting the storage driver ("usb-storage" in the new kernels).
I will see if I can get my hands on one of these things. Somebody lend me one? Maybe your dealer after you returned your's ?
modem was disconnected for more than 15 hours
than log everything exept mouse, BT, bla-bla-bla
then plug it in
http://pastebin.com/GHTLajwU
3rd day i'm trying to find USB HUB wit external power supply to plug modem there, than plug HUB to Windows, dial, disconnect, than plug HUB to router, but can't find any with external power ((
I'm not sure that my greedy mobile operator want to give anything ))) they take about 90euros for this modem (((
than log everything exept mouse, BT, bla-bla-bla
then plug it in
http://pastebin.com/GHTLajwU
3rd day i'm trying to find USB HUB wit external power supply to plug modem there, than plug HUB to Windows, dial, disconnect, than plug HUB to router, but can't find any with external power ((
I'm not sure that my greedy mobile operator want to give anything ))) they take about 90euros for this modem (((
Jan 1 00:11:21 login[120]: root login on 'pts/0'
Jan 1 00:12:18 kernel: usb.c: deregistering driver usb-storage
Jan 1 00:12:40 kernel: usb.c: registered new driver serial
Jan 1 00:12:40 kernel: usbserial.c: USB Serial support registered for Generic
Jan 1 00:12:40 kernel: usbserial.c: USB Serial Driver core v1.4
Jan 1 00:12:44 kernel: usb.c: registered new driver acm
Jan 1 00:12:44 kernel: acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters (patched)
Jan 1 00:15:28 kernel: hub.c: new USB device 00:03.0-1, assigned address 2
Jan 1 00:15:28 kernel: usb.c: USB device 2 (vend/prod 0x1edf/0x6003) is not claimed by any active driver.
unload storage driver with no effect for modem ((
Jan 1 00:12:18 kernel: usb.c: deregistering driver usb-storage
Jan 1 00:12:40 kernel: usb.c: registered new driver serial
Jan 1 00:12:40 kernel: usbserial.c: USB Serial support registered for Generic
Jan 1 00:12:40 kernel: usbserial.c: USB Serial Driver core v1.4
Jan 1 00:12:44 kernel: usb.c: registered new driver acm
Jan 1 00:12:44 kernel: acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters (patched)
Jan 1 00:15:28 kernel: hub.c: new USB device 00:03.0-1, assigned address 2
Jan 1 00:15:28 kernel: usb.c: USB device 2 (vend/prod 0x1edf/0x6003) is not claimed by any active driver.
unload storage driver with no effect for modem ((
the funny thing that I can only buy devices, which are not supported by usb-modeswitch yet )))
or I don't see it on the list ))
Here they are:
Airplus MCD-650 EVDO Rev.0
ZTE AC5710 EVDO Rev.A
Celot CT-650 Rev.0
but surfing shows that all of them should work with my router, and a lot of remarks, that mcd-800 doesn't work
or I don't see it on the list ))
Here they are:
Airplus MCD-650 EVDO Rev.0
ZTE AC5710 EVDO Rev.A
Celot CT-650 Rev.0
but surfing shows that all of them should work with my router, and a lot of remarks, that mcd-800 doesn't work
now it looks like usb_modeswitch doesn't need to do anything
rmmod sd_mod
rmmod usb-storage
rmmod scsi_mod
insmod usbserial vendor=0x1edf product=0x6003
gives
rmmod sd_mod
rmmod usb-storage
rmmod scsi_mod
insmod usbserial vendor=0x1edf product=0x6003
gives
Jan 1 00:01:01 kernel: usbserial.c: USB Serial support registered for Generic
Jan 1 00:01:01 kernel: usbserial.c: Generic converter detected
Jan 1 00:01:01 kernel: usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Jan 1 00:01:01 kernel: usbserial.c: USB Serial Driver core v1.4
Are you really able to use that port ?Xelas wrote:Jan 1 00:01:01 kernel: usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Edit: if that method works you could also try "/usr/sbin/usb_modeswitch -v 1edf -p 6003 -d 1" or the "DetachStorageOnly" option in the config file.
Apart from that all it's usually no problem to manage devices from ZTE. They are easy to add to the config base if not contained yet.
No. The port exists, but it's unusable as a modem. Maybe because there are 3 coms in Windows, and only one of them is a modem.
I usually have to switch MCD-800 via VirtualBox. But there things become interesting. When I add this stick to VBox devices to work with, something loads cdc_acm module into kernel, I haven't found what, yet. Then I disconnect modem from Windows, and cdc_acm finds /dev/ttyACM0 device, which is usable. If I try to use "usb_modeswitch -v 1edf -p 6003 -d 1" cdc_acm stays silent
I usually have to switch MCD-800 via VirtualBox. But there things become interesting. When I add this stick to VBox devices to work with, something loads cdc_acm module into kernel, I haven't found what, yet. Then I disconnect modem from Windows, and cdc_acm finds /dev/ttyACM0 device, which is usable. If I try to use "usb_modeswitch -v 1edf -p 6003 -d 1" cdc_acm stays silent
The "cdc_acm" module will be loaded automatically if a device or one of its interfaces has class 2. It just shows the device switched O.K.
It's different with plain serial ports; they have class 255 or 0xff. This means "vendor-specific" and can be anything. Modules using these ports need to be told to bind to the specific ID, either in the source code or on-the-fly through the "new_id" attribute. But there is no guarantee that each port will work as expected with the driver.
Honestly, this MCD-800 is twisted. I assume you have Windows running on the VirtualBox? Maybe you find a way to capture the traffic from the stick to the Windows driver ... This would probably catch something the Windows sniffer doesn't see.
It's different with plain serial ports; they have class 255 or 0xff. This means "vendor-specific" and can be anything. Modules using these ports need to be told to bind to the specific ID, either in the source code or on-the-fly through the "new_id" attribute. But there is no guarantee that each port will work as expected with the driver.
Honestly, this MCD-800 is twisted. I assume you have Windows running on the VirtualBox? Maybe you find a way to capture the traffic from the stick to the Windows driver ... This would probably catch something the Windows sniffer doesn't see.
-
iluxamcd800
- Posts: 7
- Joined: 30 Aug 2010, 15:21
Josh, does the message string appear in a sniffer log explicitly (may be included in some other data message) or it is constructed from some other data?
I've got linux wireshark logs for different device pluggingin stages and related windows logs (windows works in virtualbox) except the stage of windows restart. I'd like to avoid posting all of them and I hope that there is some "message string" indicator exists. If it's so could you point it out? Now I only now the message length of 62 bytes =)
Outwardly cdc_acm driver automatically appears in linux after installing a windows driver.
But the ttyACM0 device itself appears only after unplugging modem from windows. And i'm able to dial out to my mobile provider with it.
Some logs:
unplugging modem from windows:
replugging device to windows VM:
[/code]
I've got linux wireshark logs for different device pluggingin stages and related windows logs (windows works in virtualbox) except the stage of windows restart. I'd like to avoid posting all of them and I hope that there is some "message string" indicator exists. If it's so could you point it out? Now I only now the message length of 62 bytes =)
Outwardly cdc_acm driver automatically appears in linux after installing a windows driver.
But the ttyACM0 device itself appears only after unplugging modem from windows. And i'm able to dial out to my mobile provider with it.
Some logs:
Code: Select all
Aug 30 16:22:25 t500 kernel: [248793.312675] usbcore: registered new interface driver cdc_acm
Aug 30 16:22:25 t500 kernel: [248793.312679] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adaptersCode: Select all
Aug 30 18:27:46 t500 kernel: [256313.631306] usb 6-2: reset full speed USB device using uhci_hcd and address 22
Aug 30 18:27:46 t500 kernel: [256313.789542] cdc_acm 6-2:2.0: ttyACM0: USB ACM device
Aug 30 18:27:46 t500 modem-manager: (ttyACM0) opening serial device...
Aug 30 18:27:46 t500 modem-manager: (ttyACM0): probe requested by plugin 'Generic'
Aug 30 18:27:47 t500 modem-manager: (ttyACM0) closing serial device...
Aug 30 18:27:47 t500 modem-manager: (Generic): CDMA modem /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2 claimed port ttyACM0
Aug 30 18:27:47 t500 modem-manager: Added modem /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2
Aug 30 18:27:47 t500 modem-manager: Exported modem /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2 as /org/freedesktop/ModemManager/Modems/14
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): new CDMA device (driver: 'cdc_acm')
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): exported as /org/freedesktop/NetworkManager/Devices/16
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): now managed
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): device state change: 1 -> 2 (reason 2)
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): deactivating device (reason: 2).
Aug 30 18:27:47 t500 NetworkManager: flush_routes: assertion `iface_idx >= 0' failed
Aug 30 18:27:47 t500 NetworkManager: flush_addresses: assertion `iface_idx >= 0' failed
Aug 30 18:27:47 t500 NetworkManager: <info> (ttyACM0): device state change: 2 -> 3 (reason 0)Code: Select all
Aug 30 18:28:42 t500 modem-manager: Removed modem /sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2
Aug 30 18:28:42 t500 NetworkManager: <info> (ttyACM0): now unmanaged
Aug 30 18:28:42 t500 NetworkManager: <info> (ttyACM0): device state change: 3 -> 1 (reason 36)
Aug 30 18:28:42 t500 NetworkManager: <info> (ttyACM0): cleaning up...
Aug 30 18:28:42 t500 NetworkManager: <info> (ttyACM0): taking down device.As seen in the exchange of this topic, this device is behaving odd compared to other mode-switching devices.
Usually, you just have to sniff on the original driver installation device, which goes away when the driver (which has to be installed beforehand) discovers the USB ID and sends the switching command.
You have a relatively simple case if the SniffUSB sniffing log actually ends (stops growing), and the last lines point to a "SURPRISE REMOVAL". The switch looks like an unplugging action to the system. Then you just have to look closer at the transfer taking place immediately before the REMOVAL. The switching command must be there because at this point, the system only sees the single storage device.
And yes, usually the command is one of the transfers known as UFI mass storage commands. I take it literally from the log, remove the spaces and replace byte 4 to 7 with the sequence 12345678 to indicate that this tag is irrelevant to the command.
The device in question here causes trouble because it seems to be impossible to extract the initial communication to the unswitched storage device once the driver is installed. This may be accomplished if you sniff from outside via a VM. I don't know the format that wireshark spits out, but you want to see a device where the first interface is of class 8 (storage device). Again, the Windows driver has to be installed.
If you spot that interface description (after the initial ID requests to the device), everything that follows is suspicious. If there is no end to the log (the device does not change IDs when switching), look for the next interface description where the first interface has class 2. This means that the device has switched. So the switching command must be between those two lines ...
Here are the relevant portions of the previous logs (from SniffUSB). The arrows added are pointing to the interface class.
Unswitched, only one interface:
Switched, lots of interfaces:
Usually, you just have to sniff on the original driver installation device, which goes away when the driver (which has to be installed beforehand) discovers the USB ID and sends the switching command.
You have a relatively simple case if the SniffUSB sniffing log actually ends (stops growing), and the last lines point to a "SURPRISE REMOVAL". The switch looks like an unplugging action to the system. Then you just have to look closer at the transfer taking place immediately before the REMOVAL. The switching command must be there because at this point, the system only sees the single storage device.
And yes, usually the command is one of the transfers known as UFI mass storage commands. I take it literally from the log, remove the spaces and replace byte 4 to 7 with the sequence 12345678 to indicate that this tag is irrelevant to the command.
The device in question here causes trouble because it seems to be impossible to extract the initial communication to the unswitched storage device once the driver is installed. This may be accomplished if you sniff from outside via a VM. I don't know the format that wireshark spits out, but you want to see a device where the first interface is of class 8 (storage device). Again, the Windows driver has to be installed.
If you spot that interface description (after the initial ID requests to the device), everything that follows is suspicious. If there is no end to the log (the device does not change IDs when switching), look for the next interface description where the first interface has class 2. This means that the device has switched. So the switching command must be between those two lines ...
Here are the relevant portions of the previous logs (from SniffUSB). The arrows added are pointing to the interface class.
Unswitched, only one interface:
Code: Select all
-- URB_FUNCTION_SELECT_CONFIGURATION:
ConfigurationDescriptor = 0x862f3478 (configure)
ConfigurationDescriptor : bLength = 9
ConfigurationDescriptor : bDescriptorType = 0x00000002
ConfigurationDescriptor : wTotalLength = 0x00000020
ConfigurationDescriptor : bNumInterfaces = 0x00000001
ConfigurationDescriptor : bConfigurationValue = 0x00000001
ConfigurationDescriptor : iConfiguration = 0x00000000
ConfigurationDescriptor : bmAttributes = 0x00000080
ConfigurationDescriptor : MaxPower = 0x000000fa
ConfigurationHandle = 0x84969ed0
Interface[0]: Length = 56
Interface[0]: InterfaceNumber = 0
Interface[0]: AlternateSetting = 0
Interface[0]: Class = 0x00000008 <----- Storage device
Interface[0]: SubClass = 0x00000006
Interface[0]: Protocol = 0x00000050
Interface[0]: InterfaceHandle = 0x84bf7e60
Interface[0]: NumberOfPipes = 2
Interface[0]: Pipes[0] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[0] : EndpointAddress = 0x00000087
Interface[0]: Pipes[0] : Interval = 0x00000000
Interface[0]: Pipes[0] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[0] : PipeHandle = 0x84bf7e7c
Interface[0]: Pipes[0] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[0] : PipeFlags = 0x00000000
Interface[0]: Pipes[1] : MaximumPacketSize = 0x00000040
Interface[0]: Pipes[1] : EndpointAddress = 0x00000008
Interface[0]: Pipes[1] : Interval = 0x00000000
Interface[0]: Pipes[1] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[0]: Pipes[1] : PipeHandle = 0x84bf7e9c
Interface[0]: Pipes[1] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[1] : PipeFlags = 0x00000000 Code: Select all
[342 ms] <<< URB 6 coming back <<<
-- URB_FUNCTION_SELECT_CONFIGURATION:
ConfigurationDescriptor = 0x86480270 (configure)
ConfigurationDescriptor : bLength = 9
ConfigurationDescriptor : bDescriptorType = 0x00000002
ConfigurationDescriptor : wTotalLength = 0x00000071
ConfigurationDescriptor : bNumInterfaces = 0x00000004
ConfigurationDescriptor : bConfigurationValue = 0x00000002
ConfigurationDescriptor : iConfiguration = 0x00000000
ConfigurationDescriptor : bmAttributes = 0x00000080
ConfigurationDescriptor : MaxPower = 0x0000007d
ConfigurationHandle = 0x84816de0
Interface[0]: Length = 36
Interface[0]: InterfaceNumber = 0
Interface[0]: AlternateSetting = 0
Interface[0]: Class = 0x00000002 <----- ACM device
Interface[0]: SubClass = 0x00000002
Interface[0]: Protocol = 0x00000001
Interface[0]: InterfaceHandle = 0x8486d330
Interface[0]: NumberOfPipes = 1
Interface[0]: Pipes[0] : MaximumPacketSize = 0x00000010
Interface[0]: Pipes[0] : EndpointAddress = 0x00000081
Interface[0]: Pipes[0] : Interval = 0x00000080
Interface[0]: Pipes[0] : PipeType = 0x00000003 (UsbdPipeTypeInterrupt)
Interface[0]: Pipes[0] : PipeHandle = 0x8486d34c
Interface[0]: Pipes[0] : MaxTransferSize = 0x00001000
Interface[0]: Pipes[0] : PipeFlags = 0x00000000
Interface[1]: Length = 56
Interface[1]: InterfaceNumber = 1
Interface[1]: AlternateSetting = 0
Interface[1]: Class = 0x0000000a
Interface[1]: SubClass = 0x00000000
Interface[1]: Protocol = 0x00000000
Interface[1]: InterfaceHandle = 0x848ea070
Interface[1]: NumberOfPipes = 2
Interface[1]: Pipes[0] : MaximumPacketSize = 0x00000040
Interface[1]: Pipes[0] : EndpointAddress = 0x00000082
Interface[1]: Pipes[0] : Interval = 0x00000000
Interface[1]: Pipes[0] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[1]: Pipes[0] : PipeHandle = 0x848ea08c
Interface[1]: Pipes[0] : MaxTransferSize = 0x00001000
Interface[1]: Pipes[0] : PipeFlags = 0x00000000
Interface[1]: Pipes[1] : MaximumPacketSize = 0x00000040
Interface[1]: Pipes[1] : EndpointAddress = 0x00000002
Interface[1]: Pipes[1] : Interval = 0x00000000
Interface[1]: Pipes[1] : PipeType = 0x00000002 (UsbdPipeTypeBulk)
Interface[1]: Pipes[1] : PipeHandle = 0x848ea0ac
Interface[1]: Pipes[1] : MaxTransferSize = 0x00001000
Interface[1]: Pipes[1] : PipeFlags = 0x00000000 -
iluxamcd800
- Posts: 7
- Joined: 30 Aug 2010, 15:21
I think I understood the idea. I see only class=2 device in my sniffusb logs. at the same time the wireshark truncated analyzed usb packets.
Could you give me an example of working captured log where switching message (as it is in the log) may be seen? The whole packet surrounded by a couple of previous and subsequent ones would be great.
Could you give me an example of working captured log where switching message (as it is in the log) may be seen? The whole packet surrounded by a couple of previous and subsequent ones would be great.
-
iluxamcd800
- Posts: 7
- Joined: 30 Aug 2010, 15:21
I really doubt that it may be helpful but could you take a look at log: http://pastebin.com/St5Jd7F3
What you posted on pastebin looks incomplete.
Here are two good examples:
http://www.draisberghof.de/usb_modeswitch/two_logs.zip
The simple one is the "OptionIcon"; this device is switching immediately after the respective transmission (URB 79).
A more tricky one is the "BandLuxeC270" where it turned out you need two commands in sequence (URB 52 and URB 54). The stuff in between the two is just the response (status wrapper) to URB 52.
Here are two good examples:
http://www.draisberghof.de/usb_modeswitch/two_logs.zip
The simple one is the "OptionIcon"; this device is switching immediately after the respective transmission (URB 79).
A more tricky one is the "BandLuxeC270" where it turned out you need two commands in sequence (URB 52 and URB 54). The stuff in between the two is just the response (status wrapper) to URB 52.