[Taras]

try

ICMP_ECHO_REQUEST* pIcmpEchoReq = ( ICMP_ECHO_REQUEST* )(

Irp->AssociatedIrp.SystemBuffer)[

[Taras]

ObjPtr[0] = &g_pWaitItem->hAllow;
ObjPtr[1] = &g_pWaitItem->hDeny;

hAllow, hDeny – are they handle of events? KeWaitForMultipleObjects may operate only with direct pointer to KEVENT struct. If you have handles, you should retrieve direct pointer by call ObReferenceObjectByHandle

[Taras]

2:
http://ntndis.com/forum/viewtopic.php?t=52

[Taras]

NTSTATUS
TcpipSend( IN PIRP SendIrp,
IN PIO_STACK_LOCATION SendIrpStack );

[Taras]

You can not read ethernet header form raw socket. Never. You should use one of kernel traffic capture method. Foe example, winpcap, NDIS IM and so on.

[Taras]

You should set PnPEventHandler for your protocol and correctly handle power events. See DDK sample -passthrou.

[Taras]

May be two case:
1) app uses Icmpapi. (for example ping.exe). Then
/Device/ip get IRP_MJ_INTERNAL_DEVICE_CONTROL
or IRP_MJ_DEVICE_CONTROL
MinorFunction = 0
IOCTL = 0x120000

and parameter:

typedef struct __ICMP_ECHO_REQUEST {
unsigned long Address;
unsigned long Timeout;
unsigned short DataOffset;
unsigned short DataSize;
unsigned char OptionsValid;
unsigned char Ttl;
unsigned char Tos;
unsigned char Flags;
unsigned short OptionsOffset;
unsigned char OptionsSize;
unsigned char Padding;
} ICMP_ECHO_REQUEST, *PICMP_ECHO_REQUEST;
you should intercept such IRPs

2) app can use raw sockets. In such case you should hijack raw traffic.

[Taras]

ClientEventChainedReceive
ClientEventReceiveExpedited
Do you hook this callback handlers?

[Taras]

Why do most commertial personal firewalls use NDIS hooking when it can be done with IM driver?

IMHO This question is asked by enyone who deal with filtering algorithm
If you are developing your apps for NT, I think it more easy and better to use IM miniport. My opinion that NDIS hooking is legacy of cross plaform developing for NT and 9x that was actual some yaers ago.

But I use NDIS hooking in my project. It is paradox. 🙂

[Taras]

Look at scheme. Your IM miniport driver will be inserted bettween “transport” and “802.3”. You will not see any modems, but you will see a virtual NIC named “NDISWANIP” which work as multiport NIC. So your driver can work as firewall perfectly

[Taras]

Why do thing your IM driver will not handle traffic from modems? Look at QoS driver. It is IM mininport but it filters modem`s traffic 🙂
All modem are represented as one NIC with several MAC address, so you can deal with them.

[Taras]

When tcpip.sys has received data it call Receive Handler for endpoint (if it has set). If your driver regsiter such handler, th must retrieve data (it should setup IRP for last parameter of the handler). If your driver is not interested in the incoming data, it set this irp = 0. Tcpip after seeing this irp = 0 thinks client dont need this data and dont take any action for saving data. So, exsiting client with registered ReceiveHandler which always return irp = 0 way to loose all incoming data for endpoint.

[Taras]

I think problem is your routine Recv does nit work at all
KeWaitForSingleObject(&Event, UserRequest,
KernelMode, FALSE, 0); dont wait (timeout == 0!!!!), your check
if(!NT_SUCCESS(status)) dont work
see declaration:
#define NT_SUCCESS(Status) ((NTSTATUS)(Status) >= 0)
and
STATUS_TIMEOUT ((DWORD )0x00000102L)
that is your IRP was not handled

Your debug out is content of uninitialized IoStatus struct and may be different.

Solve problem:
Your Recv never will work because you have registerd your Receive Event Handler. You should replace your code from Recv to EventReceive. But you should note, that EventReceive works at IRQL = DISPATCH_LEVEL

[Taras]

You can use instead TDI driver LSP (layerd service provider).

[Taras]

Call client register callback function ClientEventReceive or ClientEventChainedReceive

[Author]

Posts