or may be this one
http://pastebin.com/UegDC1tE
repluged modem this time, not composite device
I begin to suspect that the Windows driver does something dirty here, like trying to hide the original storage device ...
What you posted is again the normal discovery of the modem mode, which is ready to use.
I'm afraid the only way is to log the whole driver/software installation, up to the point when Windows says "New Devices found". For this you have do deinstall the software completely before logging.
Stop the logging without unplugging the device.
Then, after logging, you need a good text editor; as r_aleev said the log will be huge.
Try to find the first instance of the string "IRP_MN_REMOVE_DEVICE". If it's not there, you have to find the line "Interface[0]: Class = 0x00000002" which is taken from your sniffing log and defines the point when the modem is ready.
If you found one of these instances, post the part above (up to the found line); about 500kB should be enough. Alternatively, compress the whole thing (gzip/bzip) and post it on some upload site.
There is one more thing I'd like to see: the output of "lsusb -v -d 1edf:6003" with the device plugged in Linux (you can post it here).
Thanks for the hard work!
What you posted is again the normal discovery of the modem mode, which is ready to use.
I'm afraid the only way is to log the whole driver/software installation, up to the point when Windows says "New Devices found". For this you have do deinstall the software completely before logging.
Stop the logging without unplugging the device.
Then, after logging, you need a good text editor; as r_aleev said the log will be huge.
Try to find the first instance of the string "IRP_MN_REMOVE_DEVICE". If it's not there, you have to find the line "Interface[0]: Class = 0x00000002" which is taken from your sniffing log and defines the point when the modem is ready.
If you found one of these instances, post the part above (up to the found line); about 500kB should be enough. Alternatively, compress the whole thing (gzip/bzip) and post it on some upload site.
There is one more thing I'd like to see: the output of "lsusb -v -d 1edf:6003" with the device plugged in Linux (you can post it here).
Thanks for the hard work!
1. unfortunately my router has no lsusb inside and I have no linux machine.
What about usb-modeswitch? if I'm try to llok for @something it finds 1edf:6003 but router log shows
will log full installation libit later.
What about usb-modeswitch? if I'm try to llok for @something it finds 1edf:6003 but router log shows
is it normal?Jan 1 00:00:04 kernel: SCSI subsystem driver Revision: 1.00
Jan 1 00:00:04 kernel: Initializing USB Mass Storage driver...
Jan 1 00:00:04 kernel: usb.c: registered new driver usb-storage
Jan 1 00:00:04 kernel: USB Mass Storage support registered.
Jan 1 00:00:05 kernel: hub.c: new USB device 00:03.0-1, assigned address 2
Jan 1 00:00:06 kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Jan 1 00:00:06 kernel: Vendor: Select� Model: Auto Install Rev: 2.31
Jan 1 00:00:06 kernel: Type: CD-ROM ANSI SCSI revision: 02
will log full installation libit later.
and finally, after 4hours reading mans, I've installed usbutils to my router
and now is you turn, hope for good news
$ lsusb -v -d 1edf:6003
Code: Select all
Bus 001 Device 002: ID 1edf:6003
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1edf
idProduct 0x6003
bcdDevice 0.00
iManufacturer 1 Selectwireless Incorporated
iProduct 2 Selectwireless CDMA USB Modem
iSerial 3 Data Interface
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 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 0x08 EP 8 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 113
bNumInterfaces 4
bConfigurationValue 2
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
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 3 Data Interface
CDC Header:
bcdCDC 1.09
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x0f
connection notifications
sends break
line coding and serial state
get/set/clear comm features
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 128
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 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 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 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 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 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 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Whew, that must have been a lot of work. Well done.
1. The lsusb output shows that there is the pseudo CD-ROM (class 8, storage) together with a CDC/ACM interface (class 2 and 10) and two vendor-specific interfaces (class 255).
So the thing might work unswitched if you provide the "cdc_acm" module; ususally you get a modem port (/dev/ttyACM0) that you can use.
2. I think you realized that there is just one command in the log excerpt, repeated over and over. It might be the switching command, but it might be as well a placeholder, checking for the state of the device (it's the command TEST UNIT READY).
To be really certain, I'd try additionally one of the commands immediately before the loop with the "06 00" transfers is starting. Can you find that point in the log? A few kB will be enough.
Sorry for causing more work ...
1. The lsusb output shows that there is the pseudo CD-ROM (class 8, storage) together with a CDC/ACM interface (class 2 and 10) and two vendor-specific interfaces (class 255).
So the thing might work unswitched if you provide the "cdc_acm" module; ususally you get a modem port (/dev/ttyACM0) that you can use.
2. I think you realized that there is just one command in the log excerpt, repeated over and over. It might be the switching command, but it might be as well a placeholder, checking for the state of the device (it's the command TEST UNIT READY).
To be really certain, I'd try additionally one of the commands immediately before the loop with the "06 00" transfers is starting. Can you find that point in the log? A few kB will be enough.
Sorry for causing more work ...
O.K., no problem:
1. Try to run "modprobe -v cdc_acm". If the module (driver) is present, you get a message starting with "insmod" or no message at all. Both is O.K.
If you get "module is compiled into the kernel" or similar, that's O.K. too.
If you get "module not found", that's not so good. You will need it. But any serious router software should include it ...
2. If you look at the beginning of what you posted, there is the same sequence over and over again:
"00000000: 55 53 42 43 48 3c 6d 84 00 00 00 00 00 00 06 00" (plus the next line). Then follow three more transfers (reply to the first, request for the status, reply to the status request). It's always "going down" - "coming back" - "going down" - "coming back". And then the whole thing repeats, all through the log until the device switches (you did not unplug it, did you?).
I want you to find the very beginning of that loop; before that there should be a command that is different from the line I pointed out. It will start with "00000000: 55 53 42 43" too though.
From there go some kB upward - like you did before the REMOVAL, just not so much. Say, 50 kB max.
Post that part too at pastebin.
1. Try to run "modprobe -v cdc_acm". If the module (driver) is present, you get a message starting with "insmod" or no message at all. Both is O.K.
If you get "module is compiled into the kernel" or similar, that's O.K. too.
If you get "module not found", that's not so good. You will need it. But any serious router software should include it ...
2. If you look at the beginning of what you posted, there is the same sequence over and over again:
"00000000: 55 53 42 43 48 3c 6d 84 00 00 00 00 00 00 06 00" (plus the next line). Then follow three more transfers (reply to the first, request for the status, reply to the status request). It's always "going down" - "coming back" - "going down" - "coming back". And then the whole thing repeats, all through the log until the device switches (you did not unplug it, did you?).
I want you to find the very beginning of that loop; before that there should be a command that is different from the line I pointed out. It will start with "00000000: 55 53 42 43" too though.
From there go some kB upward - like you did before the REMOVAL, just not so much. Say, 50 kB max.
Post that part too at pastebin.
try to check, but now have only tts and tty on /dev/
no, I didn't unplug modem, but the device had disappear from sniffer and three new appear
hope this is what you need - http://pastebin.com/nswLxpX9
update
no, I didn't unplug modem, but the device had disappear from sniffer and three new appear
hope this is what you need - http://pastebin.com/nswLxpX9
update
thats strange cuz a lot of people have it on same firmware[admin@(none) root]$ modprobe -v cdc_acm
modprobe: chdir(2.4.37.9): No such file or directory
You will have new devices only after the right driver is loaded.Xelas wrote:try to check, but now have only tts and tty on /dev/
That's how it was supposed to go. Fine.Xelas wrote:no, I didn't unplug modem, but the device had disappear from sniffer and three new appear
Uhm, not exactly. I forgot to mention that the four groups (bytes) after "55 53 42 43" may differ, but they are just a tag for the command and usually have no function. So, what you posted was again the command with "06 00" in it.Xelas wrote:hope this is what you need - http://pastebin.com/nswLxpX9
See if you find a different command, like "06 01" or "06 1b" or similar. Must be there earlier in the log.
Code: Select all
[admin@(none) root]$ modprobe -v cdc_acm
modprobe: chdir(2.4.37.9): No such file or directoryhttp://pastebin.com/SMiqdg4H
new part of log
finaly done with modprobe
new part of log
finaly done with modprobe
is it looks like ok?[admin@(none) /]$ modprobe -v /opt/lib/modules/2.4.37.9/kernel/drivers/usb/acm.o
[admin@(none) /]$
and here is the full log
http://rapidshare.com/files/410665957/UsbSnoop.zip
http://rapidshare.com/files/410665957/UsbSnoop.zip
Ah, I was not aware that the module has a different name in Linux 2.4.x ...
If you plug the modem in and load the module, what does the output of "dmesg" say (in the end)?
Regarding the sniffing log, I found no switching command in there ... What makes this device special is that it has not just the CD-ROM interface on initial plug. So what we see in the log is only the storage traffic; but there may be going on more at the other interfaces. The switching command is probably issued to the "vendor-specific" interfaces with class 255.
Could you start sniffing on these? Driver should stay installed, sniffing filter active for "Composite Device", "Device Management" 1 and 2 (see r_aleev's screenshot in post above, http://www.draisberghof.de/usb_modeswit ... =2427#2427).
Plug in and wait for at least fifteen seconds. Then stop sniffing.
We'll catch that beast ...
If you plug the modem in and load the module, what does the output of "dmesg" say (in the end)?
Regarding the sniffing log, I found no switching command in there ... What makes this device special is that it has not just the CD-ROM interface on initial plug. So what we see in the log is only the storage traffic; but there may be going on more at the other interfaces. The switching command is probably issued to the "vendor-specific" interfaces with class 255.
Could you start sniffing on these? Driver should stay installed, sniffing filter active for "Composite Device", "Device Management" 1 and 2 (see r_aleev's screenshot in post above, http://www.draisberghof.de/usb_modeswit ... =2427#2427).
Plug in and wait for at least fifteen seconds. Then stop sniffing.
We'll catch that beast ...
Jan 1 00:00:20 kernel: usb.c: registered new driver acm
Jan 1 00:00:20 kernel: acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters (patched)
4 devices snifing and plug in modem (internet light is off)
http://pastebin.com/yWcpeRzu
than dial my provider (internet light become ON) and disconnect (internet light still is ON)
http://pastebin.com/9bLU3jKx
than REPLUG Composite Device (INTERNET LIGHT IS STILL ON)
http://pastebin.com/8L5Crgg3
tha strange thing that "internet" light goes on when dialing and dont go off when disconnects, or replug from sniffer
Jan 1 00:00:20 kernel: acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters (patched)
4 devices snifing and plug in modem (internet light is off)
http://pastebin.com/yWcpeRzu
than dial my provider (internet light become ON) and disconnect (internet light still is ON)
http://pastebin.com/9bLU3jKx
than REPLUG Composite Device (INTERNET LIGHT IS STILL ON)
http://pastebin.com/8L5Crgg3
tha strange thing that "internet" light goes on when dialing and dont go off when disconnects, or replug from sniffer
Uhm, that first sniffing log, is that complete? It stops right when it's about to become interesting - at [930 ms], which is not even one second.
Also, you may want to search the device list if there is any device component which may have been overlooked, with the same USB ID, but "not present" (check the box). There is probably something going on in those first 148 ms before the log starts ...
Also, you may want to search the device list if there is any device component which may have been overlooked, with the same USB ID, but "not present" (check the box). There is probably something going on in those first 148 ms before the log starts ...