Hello Experts,
We have a strange problem with our NDIS 5.1 driver. It works on almost every NIC, but there are some cards which the driver cannot filter the packets on. Everything seems to be OK in the debugger but the packets cannot be filtered.
And another question. Is it possible to catch a packet and redirect to another address or proxy on the network (because we modified the ethernet, IP, and TCP header of the packet but it didn’t worked)?
Thank you in advance!
Please don’t leave us to simply guess what it is your are asking about.
We have a strange problem with our NDIS 5.1 driver. It works on almost every
NIC, but there are some cards which the driver cannot filter the packets on.
I GUESS that means it is some sort of NDIS filter driver. Should we assume
you have hacked up PASSTHRU (an IM driver) and based your driver on it? Or
is this some sort of other kind of filter driver?
Everything seems to be OK in the debugger but the packets cannot be
filtered.
I have no idea what information you are trying to tell us. “OK in the
debugger” and “cannot be filtered” tell us nothing other than that (good)
you have a debugger. So what are you looking at in the debugger that is
“OK” and what are you using as a criteria to decide a packet “cannot be
filtered”?
Is it possible to catch a packet and redirect to another address or proxy on
the network (because we modified the ethernet, IP, and TCP header of the
packet but it didn’t worked)?
Yes. It is possible. Even easy. Look at the articles on extending
PASSTHRU on www.ndis.com.
And I should like to point out that at this point I am going to GUESS that
you might not realize that packets are read-only and that to ‘filter’ them
with an operation that *MODIFIES* them, you must copy the packet making a
new one with your modifications.
Good Luck,
Dave Cattley
Thank you for the quick answer.
I try to describe the problem more precisely . . . Yes, our driver is developed from the PASSTHRU IM driver example. It filters and modifies network packets (we know that the packets are read-only and we must copy and create a new one with checksum regeneration) and it works fine in most cases. The strange thing is that there are four computers with the same configuration. On three computers the driver works fine. On the fourth it seems that everything work fine (we see from the debugger that the packets were modified successfully), but the original (not the modified) packets is being sent to the network. We experienced this problem on another computer, but after we reinstalled the operating system (Windows XP) the problem disappeared. Is it possible that other drivers (or driver order) or any other software could cause this problem?
One of two things is occuring:
Your driver is not actually creating a copy of the packet, editing
changes into the copy, and send the copy.
Your instrumentation that tells you what is sent on the network is flawed
and the modified packet really is being sent but you are not seeing it.
I hope you realize that by ‘copy the packet’ I mean that:
I will assume for now that you actually do correctly handle the packet. Let
me ask, how is it that you are monitoring the ‘network’ for what packets are
sent?
Are you actually watching the ‘wire’ or watching from the very system that
is doing the sending with something like Wireshark or NETMON?
What are the loopback characteristics of the device(s) that work and the
device that does not work?
What are the actual *types* (model, revision, etc.) of the network devices?
Have you done any differential analysis of the situation other than to note
that it did not work on ‘one’ device?
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@freemail.hu
Sent: Friday, June 19, 2009 4:44 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS filter driver problem and question
Thank you for the quick answer.
I try to describe the problem more precisely . . . Yes, our driver is
developed from the PASSTHRU IM driver example. It filters and modifies
network packets (we know that the packets are read-only and we must copy and
create a new one with checksum regeneration) and it works fine in most
cases. The strange thing is that there are four computers with the same
configuration. On three computers the driver works fine. On the fourth it
seems that everything work fine (we see from the debugger that the packets
were modified successfully), but the original (not the modified) packets is
being sent to the network. We experienced this problem on another computer,
but after we reinstalled the operating system (Windows XP) the problem
disappeared. Is it possible that other drivers (or driver order) or any
other software could cause this problem?
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
We do the packet modification exactly the same way as you wrote above.
We check the packets with Wireshark so we not absolutely sure that we capture the modified packets, but: we send a query packet to a web server. Our driver modifies the query to redirect it to another server. It works in most cases (the driver works fine on approximately 3000 clients), but in the cases mentioned above we see that the reply packet comes from the original server (but we see in the debugger that the packet modification was successful), so the packet was not redirected (modified). There were some NICs when device driver changing solved the problem (for example: sis 900 pci). On other NICs the problem seems to be constant. Cards:
You may have misunderstood what I am saying about Wireshark. Wireshark
itself is a fine tool. I just needs to be run on another host connected to
the network that can observe all the packets in & out of your system (either
through a special switch port or by inserting a ‘hub’ if you can find one).
Alternatively, running Wireshark at the ‘destination’ devices also is fine.
The point is that if you have incorrectly handled the loopback behavior in
your IM driver, it is quite possible that Wireshark will see the original
packet as being ‘sent’ (because it was, after all, sent to your IM driver)
but *not* see the actual packet sent (because nothing looped it back for
Wireshark to see).
But since you are convinced by external behavior that the packet is not
being sent *and* the original is being sent then only one possibility
exists. Your driver is not sending the copied packet.
Really now, think about it. The lower bound NIC does not send anything that
you don’t ask it to send if you have an exclusive binding to the NIC.
So now I have to ask, do you have an exclusive binding to the NIC? I assume
that you let Windows do all the heavy lifting and used the NetService class
and declared yourself a Filter. If you have a notify object and do the
binding calculation yourself, well then, break into the debugger and type
the following:
!ndisk.protocols
And verify that the binding to the NIC (actually, the binding path because
other IMs might be in there) is exclusive and that no other path exists to
the NIC.
But then again, you could tell this by running IPCONFIG. Two bindings would
show up as too many adapters in IPCONFIG.
Stop assuming that because it works on a number of adapters that somehow it
is not fundamentally broken. Perhaps the few adapters where it does not
work are the true behavior case and the others are just exceedingly lucky.
Nothing so far that you have shared with us indicates that you have analyzed
the difference in behavior (from the perspective of an NDIS protocol) that
these NICs exhibit. What are their adapter characteristics? Do they
support self-loopback? Do they differ in their NDIS version support? Are
they DMA devices or PIO or shared memory devices?
IM drivers have been written that modify send packets and that work fine
over all of these NICs (though I have not tested on the AN983 that I can
recall).
Here is what I would do:
Change the logic temporarily in the driver to ‘drop’ (not copy) every
packet that matches your criteria to be edited. Just complete it and don’t
send anything at all to the lower bound NIC. Look at your instrumentation.
Does it show the packet as still being sent? Look at the network
‘destination’ machines. Do they still see the packet as being sent?
Go look at your send path again. Make sure it that you are not
inadvertently sending the original buffers or packet or some-such because of
some code-path error.
But seriously, this is the send path only right? That is the least
troublesome of the two data paths. If you are making a complete & flat copy
of the send packet then how could that get screwed up. If you are trying
to be clever and re-use subranges of the original buffer chain then you
probably messed that up.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@freemail.hu
Sent: Friday, June 19, 2009 7:56 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS filter driver problem and question
We do the packet modification exactly the same way as you wrote above.
We check the packets with Wireshark so we not absolutely sure that we
capture the modified packets, but: we send a query packet to a web server.
Our driver modifies the query to redirect it to another server. It works in
most cases (the driver works fine on approximately 3000 clients), but in the
cases mentioned above we see that the reply packet comes from the original
server (but we see in the debugger that the packet modification was
successful), so the packet was not redirected (modified). There were some
NICs when device driver changing solved the problem (for example: sis 900
pci). On other NICs the problem seems to be constant. Cards:
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