I came up it was configuration descriptor (not string descriptor) which is a bit different... by the way I'm not sure it explains the dimension mismatch.
On the other side, string langid descriptor (line 0052) seems to be empty, is that possible? 2013/1/13 Rob Power <[email protected]> > 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
