How do USBCAMD for USB2.0 receive over then 1 packet per SOF

device driver

    Sponsored Links

    Next

  • 1. device driver for Vista sideshow
    Hi, I am interested in writing a device driver for Vista Sideshow for mobile devices. Is this the correct way for adding this hardware support to Vista or am I on the wrong track here? If this is indeed the right way, is everybody allowed to do this free of charge or are there special agreements/verification/signing neccessary? I guess Windows Vista Logo certification is nice, but not a must? Thanks a lot for your answers Regards Max
  • 2. Calling NdisMIndicateStatus with NDIS_STATUS_MEDIA_DISCONNECT doesn't release the DHCP IP address for NDIS Virtual Miniport Driver
    Hi, I compiled the sample driver "NDIS Virtual Miniport Driver" (netvmini) included in the WDK build 5744 with the Vista build environment. Then I installed the driver to Windows Vista Beta 2 (build 5384). I could assign a DHCP IP address to that virtual miniport adapter by some DHCP messages from an NDIS 5.x intermediate driver. However, after indicating a NDIS_STATUS_MEDIA_DISCONNECT for that virtual miniport adapter from the intermediate driver, the DHCP IP address of the virtual miniport adapter was still kept. The log (Event Viewer->Windows Logs->System) says that: TRACE Received a new media event from the stack: 1169163212:741:: MEDIA DISCONNECT: {4f2b203b-d8c3.....}, bKeepLease: 1. I think it's "bKeepLease 1" to cause the DHCP IP address to be kept. The way I called the function is: NdisMIndicateStatus(pAdapt->MiniportHandle, NDIS_STATUS_MEDIA_DISCONNECT, NULL, 0); I wonder how I should call the function correctly so that the DHCP IP address can be released after NDIS_STATUS_MEDIA_DISCONNECT is indicated. Please advise. Thanks in advance.
  • 3. XP: Increase number of retries for USB address assignment after hotplug
    Hi, with help of a LeCroy USB protocol analyzer it seems that a USB low speed custom HID peripheral may need more than 2 retries after a hot plug in order to get its address properly assigned. (it fails roughly 1..2 percent of hotplug events and I have seen 3 failures in succession on the analyzer - the analyzer tells about "stalls" after the assign address command which basically means: no answer at all) after successful completion of the hotplug related bus transactions the device seems to work OK. In order to increase the chances that it will work despite those problems I want to increase the number of retries (currently 2) to some higher value, e.g four or five. Is there a known registry setting for the number of retries or which USB driver is handling the retries? (for patching until the custom device is fixed) Linux 2.6 kernel is retrying 3 times and this gets the failure rate down significantly. Thank you, Konrad
  • 4. severe HID problem
    I lose reports on WinXP SP2. It has been verified that the reports are sentwith a hardware logger, but reading them in a thread loses reports occasionally. The reports are sent in chunks of about 10 from a low-speed HID device. Setting the number of input reports with HidD_SetNumInputBuffers to 128 does not help at all. Increasing the thread priority does not help either. I have two implementations of the reader thread in C and Delphi and both lose reports in the same manner. Running the C and the Delphi program in parallel shows that. So it is definitely the HID stack or the HID DLL losing reports.

How do USBCAMD for USB2.0 receive over then 1 packet per SOF

Postby ZGF2aWRkZW5n » Wed, 12 Jan 2005 00:05:03 GMT

Hello there,

I modify the USBCAMD from video minidrv for using usb 2.0 device. I use 
bcdUSB to check the device is running on usb1.1 or usb2.0. I also modify the 
USBCAMD_StartDevice(), so that usb 2.0 device can allocatebandwidth
if (bcdUSB==0x200){
USBCAMD_NUM_ISO_PACKETS_PER_REQUEST=256; //32
USBCAMD_MAX_REQUEST=4; //2
}
However, when I choice a 900*3 alternating setting, the packet receive 1 
packet/1 SOF all the time. I am sure the packet that waiting for transfer is 
over then 900, but why there is only packet transmitted?

I need your help:
Where is the point that the USB driver knows there exist more then 1 
packet/SOF can be used? Where is the command that the driver set the packet 
to be 3? Can anybody help? 

Thank you!!
-- 
D.D.

Re: How do USBCAMD for USB2.0 receive over then 1 packet per SOF

Postby Jackal Huang » Wed, 12 Jan 2005 10:39:48 GMT

"daviddeng" < XXXX@XXXXX.COM >

If you declare well in usb endpoint descriptor well, host driver will 
request more
than one packet well. Besides, please read endpoint description and multiple 
transaction
of usb 2.0 document for the detail.

Best Regards

Jackal Huang 



Similar Threads:

1.USBCAMD packet sizes

Hello Joe,

It appears that USBCAMD expects the packet length to be the maximum data 
packet size.

Which Operating System are you using?  Can you provide the debug output 
from the driver, including a stack trace when the ASSERT happens?

Regards,
Doug Howe
Microsoft DDK Support


This posting is provided "AS IS" with no warranties, and confers no rights.
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Hello Joe,
\par 
\par It appears that USBCAMD expects the packet length to be the maximum data packet size.
\par 
\par Which Operating System are you using?  Can you provide the debug output from the driver, including a stack trace when the ASSERT happens?
\par 
\par Regards,
\par Doug Howe
\par Microsoft DDK Support
\par 
\par 
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }

2.Receiving Udp Packets

Hi
I set an EventHandler for receiving UDP Packet over TDI. When I receive a 
packet the function is called but i dont get the IP Address and the Port from 
where the packet was send. There is an Pointer to an struct with the 
SourceAddress but i dont found which structure is used? 

NTSTATUS ReceiveData(PVOID  TdiEventContext,
				 LONG   SourceAddressLength,
 				 PVOID  SourceAddress,
 				 LONG   OptionsLength,
				 PVOID  Options,
				 ULONG  ReceiveDatagramFlags,
				 ULONG  BytesIndicated,
				 ULONG  BytesAvailable,
				 ULONG  *BytesTaken,
				 PVOID  Tsdu,
				 PIRP   *IoRequestPacket)

Did somebody know which structure sourceAddress is? 
TDI_CONNECTION_INFORMATION, TA_IP_ADDRESS, ....

Harald

3.NDISEDGE-USB receive and transmit packet

Hi, Can any one please explain the communication between NDISEDGE
sample codes
and USB device especially in receiving and transmitting network
packet.

I mean:

1. How to initialize usb device to perform receiving and transmitting
data between usb device and its upper edge
    (NDIS miniport). I have tried to initialize the driver with usb as
the lower edge (I used usbnwifi as the sample).
    Yet, I get confused when i want to initialize the usb device for
receiving and transmitting data. I mean,
    What points that i have to initialize to perform receive and
transmit data between usb device and its upper edge.

2. In Send.c file, I found NICPostWriteRequest routine to write
request to the target device.
    I think that this routine must be edited so we can send packet
directly to the usb device.
    Am I right about this thought?

3. The last one, my device has a MAC Address. How can I get the MAC
address from the device
    so I can use this in my driver??

As i am new to drivers, some of the above questions may be very basic.
Please let me know

4.Cannot receive faked UDP packet (from NDIS filter driver, using select & recvfrom)

I have a NDIS filter driver sitting on top of Ethernet connections (based on
the PassThru sample). I am currently using it to generate interface-specific
pings, through TCP:

1. user-mode application creates 2 sockets: 1 SOCK_STREAM and 1 SOCK_DGRAM,
binds them to INADDR_ANY, and calls getsockname for both, to obtain the
source ports
2. user-mode application on Host_A builds a TCP SYN packet (destination is
Host_B, port 80) and passes the buffer down to the NDIS driver so it is sent
to a specific interface, therefore bypassing the Windows routing table. The
UDP source port is also passed down to the NDIS driver.
3. NDIS driver builds a NDIS_PACKET and sends it through the specified
interface, using NdisSend
4. Host_B replies with a TCP SYN ACK packet, which is trapped by the NDIS
driver
5. NDIS driver repackages the TCP packet in a UDP packet (changes are
obviously made to the IP header - length, flags/offset, checksum and
protocol fields) and indicates it up using NdisMIndicateReceivePacket.
6. user-mode application on Host_A receives the UDP packet containing the
TCP SYN ACK packet in the UDP data section

Currently, everything works up to and including step 5. For some weird
reason, my UDP socket never gets 'set'. Any idea? Similar code has worked
nicely with SOCK_RAW ICMP pings before, so I doubt it's a design issue.


I'll add that the faked UDP packet is being indicated up properly, and its
checksum is properly calculated. It just doesn't reach my user app, for some
reason. And for those wondering as to why I'm wrapping the TCP packet data
into a UDP packet - it's to avoid Windows sockets eating the SYN ACK.

---
Beno Bousquet
(e-mail address is invalid)


5.NDIS virtual miniport receive packet indication?

Hi,
I am writing a deserialized NDIS virtual miniport driver that indicates 
packets up to protocols with NdisMIndicateReceivePacket, one at a time. Under 
normal operation, packets are indicated up just fine. However, when I run a 
packet sniffer like wireshark on winpcap, the sniffer sees all the packets, 
but the app that was using the packets doesn't see the receive packets. For 
example, I'll ping a remote computer and it'll receive the ping replies just 
fine until I start capturing the packets with wireshark. Then it just times 
out. I can see the reply packets getting indicated up just like always in the 
windows windbg, but somehow they're not getting copied to tcpip and the 
packet capturer. I can't understand why it works fine with the 
ndiswdm/ndisprot sample setup and not with mine, when my stuff is based on 
netvmini, the same base as ndiswdm.

6. IM driver not receiving packets for Intel NIC

7. receiving packets on multiprocessor machine

8. Receive send packet



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 62 guest