1. The driver code is still there (because we never removed it) but it's no longer used by Packet.dll. Timeouts are implemented in user mode. 3. Suppose that you open a WinPcap handle with PacketOpenAdapter and then call PacketSetReadEvt. This will create an event for you and send it to the driver with an IOCTL. Then the other Packet APIs will use that same event to wait for data reception. If you set another event by sending an IOCTL directly, the other Packet APIs will not be aware that you changed the event directly with an IOCTL. 4. Your code might work. However you are basically subverting the Packet API and making your own direct calls. You are on your own. Also, there is a specific reason why the timeout was moved from the driver to user mode, and it's cancellation. If you wait in kernel mode and you want to cancel the wait (or more easily, you hit ctrl-C to close the application), a wait in kernel mode will prevent your application from exiting until the kernel wait has elapsed.
Have a nice day GV -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of "Fish" (David B. Trout) Sent: Saturday, March 26, 2011 10:19 PM To: [email protected] Subject: Re: [Winpcap-users] Winpcap-users Digest, Vol 72, Issue 8 Gianluca Varenni wrote: > Using the direct IOCTLs will not help at all: > 1. BIOCSRTIMEOUT is no longer used (as the timeout is implemented in > user mode) That's not what I'm seeing: NTSTATUS NPF_IoControl(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp) { [...] case BIOCSRTIMEOUT: //set the timeout on the read calls timeout = *((PULONG)Irp->AssociatedIrp.SystemBuffer); if(timeout == (ULONG)-1) Open->TimeOut.QuadPart=(LONGLONG)IMMEDIATE; else { Open->TimeOut.QuadPart = (LONGLONG)timeout; Open->TimeOut.QuadPart *= 10000; Open->TimeOut.QuadPart = -Open->TimeOut.QuadPart; } SET_RESULT_SUCCESS(0); break; NDIS_STATUS NPF_tap (IN NDIS_HANDLE ProtocolBindingContext, IN NDIS_HANDLE MacReceiveContext, IN PVOID HeaderBuffer, IN UINT HeaderBufferSize, IN PVOID LookaheadBuffer, IN UINT LookaheadBufferSize, IN UINT PacketSize) { [...] InterlockedExchangeAdd(&LocalData->Free, (ULONG)(-(LONG)increment)); if(Open->Size - LocalData->Free >= Open->MinToCopy) { if(Open->mode & MODE_DUMP) NdisSetEvent(&Open->DumpEvent); else { if (Open->ReadEvent != NULL) { KeSetEvent(Open->ReadEvent,0,FALSE); } } } NTSTATUS NPF_Read(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp) { [...] //See if the buffer is full enough to be copied if( Occupation <= Open->MinToCopy*g_NCpu || Open->mode & MODE_DUMP ) { if (Open->ReadEvent != NULL) { //wait until some packets arrive or the timeout expires if(Open->TimeOut.QuadPart != (LONGLONG)IMMEDIATE) KeWaitForSingleObject(Open->ReadEvent, UserRequest, KernelMode, TRUE, (Open->TimeOut.QuadPart == (LONGLONG)0) ? NULL: &(Open->TimeOut)); KeClearEvent(Open->ReadEvent); } > 2. using BIOCSMINTOCOPY is equivalent to calling PacketSetMinToCopy Yes. > 3. BIOCSETEVENTHANDLE should not be used directly (the other Packet > APIs might stop working properly). How so?! Please explain! > 4. If I remember well, he was having problems when capturing from PPP. > PPP interfaces are not managed by the NPF driver, they are managed by > Netmon (and we use the netmon API to control that). Yes. I missed that. My bad. Sorry. BUT... for non-dialup connections my sample pseudo-code *should* (IMO) work quite well. Why do you (apparently) feel otherwise? > 5. IOCTLs are completely unsupported and can change from version to > version of WinPcap. Knew that. That's why I ended my post with the disclaimer: "Note: ... is for illustrative purposes only. you should use the official packet.dll functions and not call the driver directly." -- "Fish" (David B. Trout) [email protected] _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
