Just another extra consideration, while trying to decypher the sniffed data: looking here ( http://www.beyondlogic.org/usbnutshell/usb5.shtml#StringDescriptors) seems that usb descriptors starts with a byte expressing the length of the descriptor itself. Trying to look at what I think is descriptor 0 (ex. capture line 43, "Get Descriptor (Cfg ind:0)" the content is:
09 02 22 00 01 01 00 A0 32 09 04 00 00 01 03 00 00 00 09 21 00 01 00 01 22 70 02 07 05 81 03 08 00 0A Starting with "09" while length is 33 if I'm not wrong... do I missed something? 2013/1/13 Rob Power <[email protected]> > Hi guys! > I finally had time to make those small checks: you were right Chris, the > error comes from where you supposed: there's a usb protocol error when > krauler_command tries to read usb strings. > I changed the code as follow to have some debug: > > line 252: > if (langid_fix != -1) { > /* Apply langid_fix value */ > * upsdebugx(3,"blazer_usb.c, line 254: > about to launch usb_get_string (langid: %#x)",langid_fix);* > ret = usb_get_string(udev, > command[i].index, langid_fix, buf, buflen); > } > else { > * upsdebugx(3,"blazer_usb.c, line 257: > about to launch usb_get_string (no langid fix)");* > ret = usb_get_string_simple(udev, > command[i].index, buf, buflen); > } > > if (ret <= 0) { > * upsdebugx(3,"blazer_usb.c, line 260: ret > <=0 error, ret: %d", ret);* > upsdebugx(3, "read: %s", ret ? > usb_strerror() : "timeout"); > return ret; > } > > and I got the following output (complete log is attached, though it's > there aren't other changes): > 0.197176 Trying megatec protocol... > 0.197284 send: Q1 > 0.197326 blazer_usb.c, line 254: about to launch usb_get_string > (langid: 0x409) > 0.201535 blazer_usb.c, line 260: ret <=0 error, ret: -71 > 0.201780 read: error sending control message: Protocol error > 0.201903 blazer_status: short reply > 0.201946 Status read 1 failed > 0.201988 send: Q1 > 0.202126 blazer_usb.c, line 254: about to launch usb_get_string > (langid: 0x409) > 0.205532 blazer_usb.c, line 260: ret <=0 error, ret: -71 > 0.205769 read: error sending control message: Protocol error > 0.205815 blazer_status: short reply > 0.205938 Status read 2 failed > 0.205982 send: Q1 > 0.206041 blazer_usb.c, line 254: about to launch usb_get_string > (langid: 0x409) > 0.209529 blazer_usb.c, line 260: ret <=0 error, ret: -71 > 0.209763 read: error sending control message: Protocol error > 0.209809 blazer_status: short reply > 0.209932 Status read 3 failed > > The same happens while trying mustek protocol, and similar output came > without specifing any langid_fix (ret value = 71, too). > So it's confirme: usb_get_string (and usb_get_string_simple), invoked by > blazer_status in blazer.c, both ends with -71 return code, giving the > "read: error sending control message: Protocol error" message.. > After that, blazer_status returns the "blazer_status: short reply" error. > > I tried to search for more specific info on -71 error code, but found no > hints on the Internet; I just think it comes from here ( > http://www.libusb.org/browser/libusb/libusb/libusb.h#L1361) and it's an > error code, but I can't understand what "71" value stands for or where it > comes from exactly. > > Flavio, thanks a lot for the sniffing! I'm having a look right now, trying > to understand something about the first data exchanges; I hope Chris (or > someone else, too) could find out something more. > > > 2013/1/11 flavio <[email protected]> > >> Sorry for the late but I had some trouble finding and installing UPSilon >> software :) Now I managed to capture all the usb traffic. I started >> USBlyzer before starting the installation of software and stopped after a >> complete tour of the program. >> >> I shared the ULZ and HTML file on google-docs : >> >> https://docs.google.com/file/d/0B-R2BvGl0W6DOWs4c3F5VndwMjg/edit >> >> https://docs.google.com/file/d/0B-R2BvGl0W6DSzNyNG9kdTVUdDg/edit >> >> Tell me if ther'is allo information you need, and not esitate to ask more >> sniffing ;) >> >> 2013/1/11 Charles Lepple <[email protected]> >> >>> On Jan 10, 2013, at 10:05 PM, Rob Power wrote: >>> >>> > (Small parenthesis: the information command response should start with >>> # while it starts with P#; not relevant now but weird). >>> >>> The "P" is really a length byte of 0x50 (but the device is returning far >>> less than 80 bytes for that transfer). >>> >>> -- >>> Charles Lepple >>> clepple@gmail >>> >>> >>> >>> >> >
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
