On Dec 12, 2016, at 6:11 PM, Scott Deandrea wrote:
> The bus number is 0 based and the port numbers are 1 based.
So if there are fewer than 6 ports in the route, the unused nibbles will be
zero.
> I decided to implement isochronous transfers today and changed the structure
> slightly:
> struc
Yes, the control endpoint's submit packet contains the 8 byte setup packet
immediately following the link header.
—scott
> On Dec 12, 2016, at 6:09 PM, Guy Harris wrote:
>
> On Dec 12, 2016, at 10:21 AM, Scott Deandrea wrote:
>
>> The data is part of the complete packet regardless if the hos
Hi Guy,
The bus number is 0 based and the port numbers are 1 based.
I decided to implement isochronous transfers today and changed the structure
slightly:
struct
{
// Control information
uint32_t frameHeaderLength; // 28
// Frame information
uint32_t frameLength; // Amoun
On Dec 12, 2016, at 10:21 AM, Scott Deandrea wrote:
> The data is part of the complete packet regardless if the host is sending or
> receiving data to/from the device.
So the only submit packets with data would be packets sent to control
endpoints, which would contain setup data?
_
On Dec 12, 2016, at 6:53 AM, Martin Dubuc wrote:
> I was testing some of the libpcap API and would like to get some
> clarification on the return value of one of the function. Is pcap_dispatch
> supposed to return the number of packets read/processed?
If it successfully processes any packets, i.
The bcdVersion field is a version number of the header using the same 0xJJMN
syntax.
The data is part of the complete packet regardless if the host is sending or
receiving data to/from the device.
—scott
> On Dec 11, 2016, at 6:27 PM, Guy Harris wrote:
>
> On Dec 11, 2016, at 8:12 AM, Scott
I was testing some of the libpcap API and would like to get some
clarification on the return value of one of the function. Is pcap_dispatch
supposed to return the number of packets read/processed? In my sample code,
it always return 0. I tried to trace the code execution and found out that
pcap_off
