[Winpcap-users] Winpcap-users Digest, Vol 72, Issue 8

[Gianluca Varenni]

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: winpcap-users-bounces at winpcap.org [mailto:winpcap-users-bounces at winpcap.org] On Behalf Of "Fish" (David B. Trout)
Sent: Saturday, March 26, 2011 10:19 PM
To: winpcap-users at winpcap.org
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)
 fish at softdevlabs.com




_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users