Peter Hyman <pete@xxxxxxxxxxxxxx> writes: > On 08/14/2013 01:42 PM, Bjørn Mork wrote: > snip... > >> Great! And if you can snoop on Windows trying to figure out how to >> switch the modes, then that would also help. I believe Wireshark with >> usbpcap is the current state-of-the-art USB sniffer for Windows: >> http://desowin.org/usbpcap/ >> >> >> Bjørn > > Detailed files attached. > > Archive: AC250U_lsusb_pcap.zip > Length Method Size Cmpr Date Time CRC-32 Name > -------- ------ ------- ---- ---------- ----- -------- ---- > 6162648 Defl:N 2029329 67% 08-14-2013 15:22 14f8de80 3g.pcap > 7015710 Defl:N 2190669 69% 08-14-2013 15:07 55ce8a54 4g.pcap > 1565 Defl:N 478 70% 08-14-2013 15:30 9b150f7f > sierra_driver_output_w4g_set.rpt > 4589 Defl:N 636 86% 08-14-2013 13:59 7908a3b4 > lsusb_1199_0301_3g.rpt > 4589 Defl:N 636 86% 08-14-2013 15:30 7908a3b4 > lsusb_1199_0301_4g.rpt > 385 Defl:N 210 46% 08-14-2013 15:36 a7016844 > lsusb_198f_0220.diff > 6231 Defl:N 711 89% 08-14-2013 14:15 cf018349 > lsusb_198f_0220_3g.rpt > 6231 Defl:N 711 89% 08-14-2013 15:31 376b38d0 > lsusb_198f_0220_4g.rpt > > > 3g.pcap = sniff from when unit STARTS in 3G. Sprint Software > automatically switched to 4G and that is the last event Thanks. The lsusb outputs show that there are no descriptor differences between the two modes. The diff you see is only the device address, which is a dynamic property and expected to change every time you plug in a device. Unfortunately there is a large number of vendor specific control requests addressed to endpoint 0x00 and 0x80, which is odd by itself IMHO. These give a number of different values for wValue and wIndes, and the meaning is not obvious (too me at least). Some of this is obviously switching mode, but it looks like it does so as part of a more complex device setup and configuration. So there is no easy way out here. We could try replaying the sequence blindly, but I fear that is pointless without more understanding. The data following the control requests looks mostly like a HDLC like protocol over bulk endpoints 0x04 and 0x84 on device 3-3 (the above is sent to device 3-4). The bulk data has a 5 byte prefix, 0x7e before and after the frame data, and a 16 bit checksum. Given that only the 1199:0301 device has a 0x84 endpoint, we know that device 3-3 is the Sierra serial device (which also makes sense wrt the serial protocol observed). So the magic control requests are sent to the 198f:0220 device, as expected. Sorry, I don't know if any of this helped at all. The device mode switching is not as simple and obvious the common usb-storage type switching, and trying to guess the more complex vendor specific control protocol is going to take a lot of trial and error. > 4g.pcap = sniff from when unit STARTS in 4G. Changed to 3G using Sprint > Software and that was the last event > sierra_driver_output_w4g_set.rpt = sierra and usbserial driver output > from /var/log/messages when unit inserted in 4G mode > lsusb*.rpt = lsusb -vd for 1199 and 198f devices > lsusb_198f_0220.diff shows one line difference when WiMAX device is 6 > when loaded in 4G and 4 when loaded in 3G > > Not so familiar with Wireshark or how to detect the switchover though. I > hope this helps. ITMT, I will download Beceem driver from git and see if > that makes a difference. Yes, I recommend trying to get that driver going. Googling for it will point you to a number of howtos. > One final note. When device is set to 4G and inserted into Linux box, > the 3G LED lights and blinks several times before going off. It tries to > load it, but the device firmware still knows it is 4G so it fails. Yes, or it just indicates traffic on the AT serial port until the PPP connection fails. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
