Strange lag with modified NDISprot driver..

NTDEV
1

All -

Let me start by saying that when it comes to newbies doing Windows
driver development, I am about as new as they get. I did read the FAQ,
and searched the list archives with Google, but didn’t see anything that
seemed like it was the same issue. I also have a pretty healthy
background in x86 assembler code, and did a lot of lower level stuff
back in the days of DOS. I have also done some work with Linux drivers.
So I am not completely new to some of the hardware issues that can
exist. (Just to how they interact with Windows at a driver level.)

So hopefully this isn’t a repeat on something that has already been
discussed.

I am working on an 802.1X implementation (all open source, so I can
share code with anyone that can help me out), and started with the base
NDISprot driver. I ran in to some performance issues like many that
have been discussed on this list, so I made a small change to try to
filter out everything except the 0x888e frames that I need for 802.1X.

To do this, I added two small checks to the NdisProtReceive() function,
and the NdisProtReceivePacket() function. After doing some reading, and
a little trial and error, these seemed to be the functions that receive
the frames. The main difference being interfaces to older NDIS versions.

The change that I made is fairly simple, it boils down to :

// Existing ndisprot code section
if (HeaderBufferSize != sizeof(NDISPROT_ETH_HEADER))
{
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}

// new IF statement to check for 888e.
if (((PNDISPROT_ETH_HEADER)pHeaderBuffer)->EthType != 0x8e88)
{
// We don’t want it!
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}

This change solved the issues I was seeing where an authentication would
fail if a lot of data was going over the interface. But, now I am
seeing something else that is very strange.

For reasons that we can’t nail down, sometimes the frames don’t seem to
get forwarded up the stack. If we put a tap on the connection, and run
a sniff, we see the frame come in. But, the local machine doesn’t get
the frame via either Wireshark, or our modified NDISprot driver.

Since 802.1X is a lock-step protocol, it seem unlikely that this issue
would be the performance issue that has been already discussed on this
list. Also, since Wireshark doesn’t see it either, it seems like
something is gumming up the works in the stack.

To make matters more interesting, if we set the retransmit interval for
802.1X down to 15 seconds so that the authentication doesn’t time out,
we get the retransmission correctly.

So, my questions boil down to :

  1. Is this the result of the filter modification I put in? (Was it done
    wrong? If so, where can I look to figure out how to do it right?)

  2. Is this a known issue with NDISprot? (If so, has anyone fixed it?
    And is the patch available?)

  3. If there are no good answers to question 1 & 2, are there any
    pointers on where to start the debug process? I am going to load
    DebugView on a machine, and watch the debug output to see if there are
    any pointers. But any help on what to look for would be great!
    (Remember, I am a newbie.)

Thanks in advance!

2

Reply inline below.

Thomas F. Divine

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-318724-
xxxxx@lists.osr.com] On Behalf Of Chris Hessing
Sent: Monday, March 24, 2008 8:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Strange lag with modified NDISprot driver…

All -

Let me start by saying that when it comes to newbies doing Windows
driver development, I am about as new as they get. I did read the FAQ,
and searched the list archives with Google, but didn’t see anything
that
seemed like it was the same issue. I also have a pretty healthy
background in x86 assembler code, and did a lot of lower level stuff
back in the days of DOS. I have also done some work with Linux
drivers.
So I am not completely new to some of the hardware issues that can
exist. (Just to how they interact with Windows at a driver level.)

So hopefully this isn’t a repeat on something that has already been
discussed.

I am working on an 802.1X implementation (all open source, so I can
share code with anyone that can help me out), and started with the base
NDISprot driver. I ran in to some performance issues like many that
have been discussed on this list, so I made a small change to try to
filter out everything except the 0x888e frames that I need for 802.1X.

To do this, I added two small checks to the NdisProtReceive() function,
and the NdisProtReceivePacket() function. After doing some reading,
and
a little trial and error, these seemed to be the functions that receive
the frames. The main difference being interfaces to older NDIS
versions.

The change that I made is fairly simple, it boils down to :

// Existing ndisprot code section
if (HeaderBufferSize != sizeof(NDISPROT_ETH_HEADER))
{
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}

[PCAUSA] You should probably keep this sanity check to reject runt packets:

if (HeaderBufferSize < sizeof(NDISPROT_ETH_HEADER))
{
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}

// new IF statement to check for 888e.
if (((PNDISPROT_ETH_HEADER)pHeaderBuffer)->EthType != 0x8e88)
{
// We don’t want it!
Status = NDIS_STATUS_NOT_ACCEPTED;
break;
}

This change solved the issues I was seeing where an authentication
would
fail if a lot of data was going over the interface. But, now I am
seeing something else that is very strange.

For reasons that we can’t nail down, sometimes the frames don’t seem to
get forwarded up the stack. If we put a tap on the connection, and run
a sniff, we see the frame come in. But, the local machine doesn’t get
the frame via either Wireshark, or our modified NDISprot driver.

Since 802.1X is a lock-step protocol, it seem unlikely that this issue
would be the performance issue that has been already discussed on this
list. Also, since Wireshark doesn’t see it either, it seems like
something is gumming up the works in the stack.

To make matters more interesting, if we set the retransmit interval for
802.1X down to 15 seconds so that the authentication doesn’t time out,
we get the retransmission correctly.

So, my questions boil down to :

  1. Is this the result of the filter modification I put in? (Was it
    done
    wrong? If so, where can I look to figure out how to do it right?)

[PCAUSA] As far as I can see this is not an issue with your driver.

In particular, the Wireshark driver is fairly widely distributed and as far
as packet collection is concerned if Wireshark did not see the received
packet it is pretty likely that no protocol on the same host received the
packet.

So, the issue is between the lower edge of protocol drivers and the sending
host. This leaves several possibilities:

1.) Problem with a NDIS filter driver below the protocol level.
2.) Problem with the adapter NDIS miniport.
3.) Problem with the adapter hardware.
4.) Cables/switches/routers/hubs on the wire between your host and the
remote end.

Simple things to try are to use different adapters and see if the problem
goes away. Use the simplest possible interconnects, etc.

If there are NDIS filters between your protocol and the adapter, disable
them.

In short: It is not likely that your protocol is causing the problem.

Thomas F. Divine

  1. Is this a known issue with NDISprot? (If so, has anyone fixed it?
    And is the patch available?)

  2. If there are no good answers to question 1 & 2, are there any
    pointers on where to start the debug process? I am going to load
    DebugView on a machine, and watch the debug output to see if there are
    any pointers. But any help on what to look for would be great!
    (Remember, I am a newbie.)

Thanks in advance!

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer