Johannes Erdfelt wrote:
> I think it's a coincidence. libusb and the kernel USB code don't care
> what the data is, they just pass it blindly to the device.
> However, I have no idea how that message got generated. I don't see that
> text in any header files.
> What distribution are you using? What version of glibc?
thank you for your mail. I tested a lot during weekend and memorial day
found the problem. Fortunately the "multibyte whatever error message" is
not sent by the usb device, so I do not have to abandon my idea about
how usb and
computer communication in general works.
Unfortunately the API description of the device is rather focussed on
Windows using several data types differing in their size from Linux.
(e.g. wchar_t :-) This makes the definition of proper data types rather
complicated. Additionally I got some problems with
__attribute__((packed)) and g++, so I did not realize a size mismatch
of the data I sent to the device. There are also some rumors about a bug
this specific gcc release in conjunction with __attribute__((packed)).
Usually the device is rather handsome, answering such bad requests with
a NAK, but especially this request caused the device to reboot
silently. Furthermore it
terminated the device not immediately, but during the usb_read,
I do not know where exactly this "multibyte ... error message" was
produced, but the
string can be found in the libc. Perhaps this is simply the way of the
usb stack to
tell me it doesn't like the device to reboot during a usb read.
So finally it was some coincidence, but not of some usb/libusb bugs, a
message transmission between usb devices, or some divine capabilities of
core to interpret the transmitted data, but of my sketchy programming, a
description and of bad timing :-).
Florian Baumgartner, Computer Science Department, Purdue University
mail: baumgart@... phone: (1) 765 496 2718