> Ok, so I need to maintain 2 code base for Windows XP and Vista/7.
In my experience you maintain a code-base for you application specific logic
in a form that is sufficiently multi-targeted (or polymorphic on NDIS_PACKET
/ NET_BUFFER, both of which are just chains of MDLs) and then have target
specific drivers that use that logic. But sure, if you want to write it
twice, that works too.
For XP, I have no choice but to do NDIS5 IM driver (WDK PassThru sample
and Thomas Divine’s PassThruEx sample).
I don’t think I said “no choice” but yeah, I think that is the only
practical choice.
While for Vista and 7, WFP should be sufficient and more efficient that
NDIS6 Lightweight Filter (WDK NDISLWF sample).
Efficient of your time. You have an IP datagram processing problem or a IP
packet processing problem or both. But you sure do not have a Etherent,
TokenRing (my new favorite dinosaur to work into network related posts to
displace ArcNET), WWAN, and the myriad other framing schemes that Windows
supports if you go for a MAC level interecept. It is not an easy thing to
pick a packet intercepted off of the Ethernet adapter and divert it into the
RASWAN (PPP) adapter. So to the extent you can avoid that bit of headache
and play entirely at the IP network (forwarder) layer, your task will be
much simpler.
NDIS5 IM driver (WDK PassThru sample) is not an option for Vista and 7
because of its performance issues, right?
Oh, it would probably work. And you would find that getting it to play
along in the NDIS6/NDIS5 IM driver ‘harness’ would generally be fine. Yes,
the perf drops but really it is wonkyness of the interop between LWFs and IM
drivers that NDIS6 so valiantly tries to achieve that just will drive one
nuts when it does not quite do what you wish it would. Example: When the
interface has to have a new LWF inserted, everything has to pause. Well,
for an NDIS5 IM driver that means it has to be unbound because it has no
idea what a pause is. So elements above your IM can get torn down (not
paused necessarily). But I digress.
The packet processing will just be simply based on IP address, not MAC
address or ports.
Except in NT5 where of course you will have to deal with IP packets in MAC
frames. And you will have to deal with IP to MAC address resolution before
sending them along on whatever the link is you choose. You are now going to
have to be an IP forwarder, perform fragmentation (potentially), ARP
resolution, all the good stuff.
Good luck,
Dave Cattley
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