Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
> On 2012.08.09 22:25, Pete Batard wrote: > OK, first thing I notice is that the timerfd report is output as a > warning rather than debug, so if your test machine is behaving the same > way as your other server, it means that you have silenced warnings > there, which I'd strongly recommend against. You are right! I don't set the LIBUSB_DEBUG variable on the production machines anymore. Some weeks ago, at the very beginning of our investigation, I had set the LIBUSB_DEBUG variable to 3 on the production machines, but it had no impact on the error logging. There were no log entries of warning or info messages after the crash happened. The only result of this action was a poor response time of the machines. BUT, on the test machine I set LIBUSB_DEBUG to 4. So, in my opinion, we won't get more data from the production machines than the crash log on the test machine already provides! > On 2012.08.09 22:25, Pete Batard wrote: > To confirm that the timerfd_settime() is the call that's causing us an > issue, can you please try to set your production servers to at least > output warning messages? The expectation is that, unlike debug, warnings > aren't going to clog your log, and as you can see above, they can give > precious clues as to where libusbx is not behaving nominally, and why. I'll give it a last try and set LIBUSB_DEBUG to 2. > On 2012.08.09 22:25, Pete Batard wrote: > I'll try to push a patch to make sure we get errno displayed. In the > meantime, I'd encourage you to change line 1207 in io.c from: > usbi_warn(ctx, "failed to arm first timerfd (error %d)", r); > to > usbi_warn(ctx, "failed to arm first timerfd (errno %d)", errno); I'd prefer to wait for your patch, just in case there are more changes to the code than expected. Please consider that I'll have to replace every change (recompiled lib) on more than 25 machines! = Regards Sebastian = -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Async API question:
Hi Tim,
Sorry for the delay in the replay was on something else ;)
On 2012-07-24, at 12:41 PM, Tim Roberts wrote:
> Kevyn-Alexandre Paré wrote:
>> Here's the code and output of my test. I'm trying to understand what's going
>> wrong! I mean that I'm expecting the callback function "cb_xfr" from my bulk
>> transfer to be called after libusb_submit_transfer is called. I'm
>> communicating to a FPGA through a Cypress USB (FX2) and It's working with
>> the synchronous API but not yet with the Asynchronous one??? I have put the
>> usbmon output that I'm still reading and learning about it. If you see
>> something let me know!
>> ...
>> static int benchmark_in(uint8_t ep)
>> {
>>static uint8_t buf[6] = {0x2,0xa0,0x3c,0x23,0x3,0x0};
>>static struct libusb_transfer *xfr;
>>int num_iso_pack = 0;
>>
>>xfr = libusb_alloc_transfer(num_iso_pack);
>>if (!xfr)
>>return -ENOMEM;
>>
>>libusb_fill_bulk_transfer(xfr, devh, ep, buf,
>>sizeof(buf), cb_xfr, NULL, 0);
>>
>>gettimeofday(&tv_start, NULL);
>>printf("-->SUBMIT length:%d\n", sizeof(buf));
>>return libusb_submit_transfer(xfr);
>> }
>
> When you are doing a bulk IN transfer, you always need to specify a
> buffer that is as large as your endpoint size. Remember that a USB
> device is never told how much data to send. It is merely given a signal
> that says "GO!".
k thx for reminding me this! But in that case I'm sending data, on the endpoint
only for the output to the FPGA. Do I also need to respect that rule?
> At that point, the device has the perfect right to
> send 512 bytes. However, the host controller will only have allocated
> enough bus time for 6 bytes. Your device steps on the next device's
> slot. That's a protocol violation called "babble".
babble, hmm k
Will retry with a fix 512 buffer...
>
>
>> int main(int argc, char **argv)
>> {
>> ...
>>rc = libusb_set_interface_alt_setting(devh, 1, 0);
>
> It is not useful to select an alternate setting unless you have more
> than one. If you only have bulk pipes, then you have no need for
> alternate settings.
hmm will validate this I think I need that...
>
>
>>libusb_clear_halt(devh, 0x06);
>>libusb_clear_halt(devh, 0x88);
>
> Why do you call clear_halt here? In virtually every case, that's
> unnecessary superstition.
This was legacy from a bug we have on OS X! It's true that I don't need that,
thx.
>
> Are you sure your device has queued up data to send? What is it that
> tells your device to put data in the FX2 FIFO?
I at least need to send 2 bytes to the FPGA to receive back a NAK in case of a
bad 2 first bytes. In case of a proper trame this will send a ACK or data
packet. So yes I'm sure.
Thx for the informations.
For know I went back to the synchronous API for libusb that is running inside a
thread and notify my event loop when data is ready! So I know that with the
SYNC API it's working. I just need to properly use the ASYNC API now!
- KA
>
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb0 & libusbK driver support
> > PS: I have now tested the filter driver against a mass storage device > (i.e. keeping Windows default mass storage driver) and it seems to > produce the expected results. > > Thanks Pete for the update. We may start testing very soon at my work (Teradici). What should we expect in terms of mass storage support? Were you able to transfer files or just have the device show up in device manager or in Windows Explorer as well? Thanks, David Grant -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb0 & libusbK driver support
David Grant wrote: > mass storage support? I guess you already have the following in mind? http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Async API question:
Kevyn-Alexandre Paré wrote: > I at least need to send 2 bytes to the FPGA to receive back a NAK > in case of a bad 2 first bytes. In case of a proper trame this will > send a ACK or data packet. You can simplify your protocol significantly since USB transfers, aside from isochronous, are a reliable transport. If a transfer is successful then the exact data you sent has arrived correctly. Error detection and retransmission is handled on a very low layer. Take advantage of this in your protocol to make it simpler. //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb0 & libusbK driver support
On 2012.08.11 01:03, Peter Stuge wrote: > I guess you already have the following in mind? > > http://libusb.org/wiki/FAQ#CanIuselibusbtoopenafileonaUSBstoragedevice Peter, As you should be awfully aware, you are replying in the libusbx mailing list, where, as much as you may wish the contrary, libusb considerations may not apply. If you are going to point to something then, please point to the libusbx FAQ, and not the libusb one. While in this occurence, the FAQ is not that dissimilar, you will find that other items, such as HID support, are completely difference, hence pointing someone to the libusb FAQ instead of libusbx one will provide them with erroneous expectations. From now on, please point to the libusbx documentation unless you want to downgrade further your level of being welcome on this list... libusbx is not affiliated with libusb at all. Keep pretending that it is at your own risk... Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb0 & libusbK driver support
Hi David, On 2012.08.11 00:18, David Grant wrote: > We may start testing very soon at my work (Teradici). Great. Please let us know how it goes. > What should we expect in terms of mass storage support? Were > you able to transfer files or just have the device show up in device > manager or in Windows Explorer as well? I just tested the retrieval of a block using xusb. If block readout works, then mass storage access should work, but of course our tests are limited. Also not that I have had lesser success using the libusb-win32 filter driver against a non mass-storage driver, such as the proprietary Cypress one for EZ-USB, and I'm not planning to spend too much time supporting the filter driver if it doesn't work that well, as it's a tricky little beast => Caveat emptor. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
On 2012.08.10 08:53, sebasti...@gmx-topmail.de wrote: > Some weeks ago, at the very beginning of our > investigation, I had set the LIBUSB_DEBUG variable to 3 on the production > machines, but it had no impact on the error logging. This would indicate that the error you got on test is different from the one on prod, as I'd expect the warning to still occur (though we reorganized some of the code in the meantime, so maybe that played a bit). > BUT, on the test machine I set LIBUSB_DEBUG to 4. So, in my opinion, we > won't get more data from the production machines than the crash log on > the test machine already provides! Yeah. It all points to the same area. > I'd prefer to wait for your patch, just in case there are more changes to > the code than expected. Please consider that I'll have to replace every > change (recompiled lib) on more than 25 machines! I wasn't aware of that. I'll try to push something over the weekend then. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
On 2012.08.10 05:10, Orin Eman wrote: > I'd do something like the following: > > #include > #if defined(WIN32) && !defined(PATH_MAX) > #define PATH_MAX (MAX_PATH+1) > #endif > > and use PATH_MAX like you suggested. I'll try to do that. Note however that there's going to be a change of plan with regards to FX2/FX3 support, as I have just completed the porting of fxload [1] from linux-hotplug [2] to libusbx, with the aim of including it as a sample. As a matter of fact, it is now included as a full fledged sample in the 0K branch [3]. For now support is only for FX2 and earlier, so we need to re-apply an FX3 patch. I'll try to take care of that, but Markus, if you feel like you want to go for it, don't hesitate. The rationale to spending time on a standalone FX2/FX3 sample is that quite a few developers, be them on Windows or Linux, seem to have an FX device to play with => we might as well try to promote libusbx by giving them a solid cross platform firmware upload tool they can rely on. It also helps making our sample section less pathetic than it is right now. Note that the original fxload is GPL2, so that sample is also GPL2. Also you'll see that a bunch of getopt files have been added to the samples directory, since MSVC require them (they are compiled as a library there). Shouldn't be much of an issue, especially as having an universal getopt could to come handy when producing more console samples. Finally, I have a separate fxload standalone project detailing the changes I applied to the original project [4]. Not sure if I'm going to bother submitting back these patches to linux-hotplug at this stage... Regards, /Pete [1] http://ccrma.stanford.edu/planetccrma/man/man8/fxload.8.html [2] http://sourceforge.net/projects/linux-hotplug/ [3] https://github.com/pbatard/libusbx/commit/baa4339c911f861c810513569b838ec9245148e5 [4] https://github.com/pbatard/fxload/commits/master -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
