office: (770) 432-4580
fax: (770) 234-4182
skype: pcausa

IP Packet Redirector Driver

Overview

The IP Packet Redirector project includes NDIS 5 Intermediate (IM) and NDIS 6 Lightweight Filter (LWF) drivers as well as companion sample user-mode components.

Conceptually the IP Packet Redirector is simple. It provides a way to insert a user-mode application into the Windows network “stack” in a way that allows it to examine and modify each IP packet being sent or received by the Windows host. This sort of driver can be described as a "NDIS tap". The concept is illustrated below:

Of course the concept doesn’t actually fit the reality of the actual implementation. Win32 applications simply cannot exist in the kernel architecture.

Instead a NDIS filter driver called IPRedir is inserted into the kernel networking stack. The user-mode application and the kernel-mode driver transfer packet data using ordinary Win32 ReadFile and WriteFile methods. This is illustrated in Figure 2 below:

The current IPRedir samples can be used on Windows platforms ranging from Windows XP through Windows 7. However, the XP and the post- XP Windows’s kernel-mode networking architecture and implementations are vastly different. In order to accommodate the differences there are two IPRedir NDIS drivers:

  • NDIS 5 – A NDIS 5 Intermediate (IM) Driver for Windows XP.
    NDIS 6 – A NDIS 6 Lightweight Filter (LWF) Driver for Windows Vista and later Windows versions (x86 and x64).

Both drivers will be referred to as “filter drivers”.

Even though the details of the two drivers are different there is a single user-mode API. This means that a common user-mode application can be used on all of the supported Windows platforms.

Why Consider This Approach?

It should be obvious that the IP Redirector design is inherently slow. Looping individual packets through user-mode is absolutely a performance bottleneck of the worst kind.

However, the approach does have possible uses under the right conditions.

User-Mode Packet Manipulation Advantages

Before going on it is important to note that some people have a misconception that code operates "faster" in the kernel. That certainly isn't true. For example, the step of encrypting a packet's data will take as long to perform in kernel-space as it would in user-space.

There are several advantages in performing work in user-space. These include:

  • Safer Execution Environment - A fault in user-space crashes and application (which can be debugged ad restarted...), while the same fault in kernel-space may crash the system.
  • Simpler Development/Debugging Environment - You can use Visual Studio to develop and debug the user-space application. Of course you must understand that when you stop at a breakpoint you are stopping network traffic. Kernel debugging requires different, possibly unfamiliar, debug setup and debugger.
  • Simpler Packet Representation - In user-space each packet is manipulated as a simple flat array of bytes.
  • Richer Programming Environment - All of the Win32 APIs plus add-ons like OpenSSL can be used in user-space. The kernel-space API is more limited.
  • Easier To Deploy Changes (No WHQL) - If you modify a driver it must at the least be re-signed. If you decide to get a WHQL signature for your driver, then any change to the driver will require re-testing to obtain a new signature from Microsoft. On the other hand, you can make massive changes to your application and redeploy it without requiring a new WHQL signature.

User-Mode Packet Manipulation Disadvantages

There are penalties associated with the IP Redirector architecture and these must be understood when considering this approach.

  • Performance Penalty - This is the key penalty. A key approach in improving performance is to minimize the number of transitions between kernel-space and user-space. And the approach used by the IP Redirector is just the opposite. Performance effects will be seen in two areas:
    • CPU Utilization - There is a CPU usage cost involved in the act of transferring packets between user-space and kernel-space.
    • Network Throughput - The act of transferring packets between user-space and kernel-space inserts delays that will limit network throughput.
  • Packet Ordering - Windows does not guarantee the order of completion of read/write operations, and this may result in some (hopefully a small number...) packets being processed out of order.
  • Dropped Packets - Naturally the resources for packet redirection have limits, and when these are encountered some packets may be lost.

How bad is the performance penalty? That is really difficult to specify. It depends heavily on the characteristics of the host and its NIC.

Here are some observations made using a test with three concurrent TCP streams running in each direction:

  • Slow Machines - Running Windows 7 64-bit Edition as a VMWare guest. Throughput for each stream was reduced to 40-percent of its normal value.
    Stream Throughput: About 55Mbps for each of the six streams
  • Fast Machines - Running Windows 7 64-bit Edition on a Core i5. Throughput for each stream was reduced by 10-percent or less to 90-percent of its normal value.
    Stream Throughput: About 150Mbps for each of the six streams

It is worth noting that on the VMWare guest where redirection performance was slow the VM was pretty well consumed simply running the stress tests without redirection. Not a good good situation.

In both cases the network adapter was 1Gbps. CPU utilization increased by about 25-percent when packets were being redirected through user mode.

Performance on is not as good on Windows XP as on Windows 7. Sorry. On the other hand a common application can work on all platforms from Windows XP through Windows 7.

The details of one IP Redirector eight-stream aggregate throughput test can be found here.

During the stress tests it is still possible to browse the Internet, view videos and perform additional network operations. In other words, although performance reduction can be measured, it often cannot be observed through ordinary use.

These performance measurements are made with a "passthru" redirection application that simply reads and re-writes packets. Adding code that does actual work will require time and therefore slow things down. Understand, however, that any delay introduced by your own packet manipulation code would be the same whether performed in user-space or kernel-space.

Per-packet operations must be fast!!!

Trade-Off Considerations

You might consider using a user-mode IP redirection tool in several cases. Here are a few for consideration:

  • Internet Connections - These are generally much less than 1Gbps. It is likely that the IP Redirector will support filtering on this connection.
  • Satellite Connections - These are generally slow. It is likely that the IP Redirector will support filtering on this connection.
  • WAN Connections - May be suitable for applications such as WAN optimization.
  • Servers - Maybe... Your mileage may vary.
  • Prototyping - Develop and perfect packet manipulation schemes in a user-space application first, then port to the kernel.
  • Network Monitoring - The IP Redirector can monitor inbound/outbound traffic on a host at a lower level than can be achieved using a NDIS protocol.
  • Education - In user-space each packet is represented by a flat array of bytes. It is easy to manipulate such an array by casting to common IP header structures, etc. The details of the Windows NDIS implementation are completely hidden in the user-space application.

A possible "rule of thumb" might be that if a host can run the stress test by itself with less than 25% CPU utilization, then there is a decent possibility that the IP Redirection technique could be used.

In some cases the advantages of the IP Redirection approach are worth the price...

Download Sample Executables

You can download sample executables for evaluation and your own personal use subject to these limitations:

  • The evaluation executables are provided as-is and have no warranty.
  • You may not redistribute the PCAUSA the sample executables in any way.

You can download the IP Redirector sample filter drivers and sample application executables for evaluation.

These sample executables are provided:

  • IMUtil
    VirtualEcho
    UmTxRxLoopEx - Asynchronous I/O

The download is a Windows Installer MSI package.

Remember that these are Windows console applications. After installation you will find the sample executables in the Program Files\PCAUSA\IPRedir folder.

The MSI package installs the NDIS filter driver appropriate for the host platform. The sample software and drivers can be uninstalled using the standard Windows Uninstall Programs facility.

Additional Documentation

The complete documentation provided with this product can be downloaded here.

Other Information

Licensing

The samples are licensed intellectual property of PCAUSA. However, if you purchase a PCAUSA sample driver product they are provided with a royalty-free license that is intended to allow customers to derive their own products using all or parts of the samples. The royalty-free license applies strictly to the distribution of product in binary (executable) form; there are quite naturally restrictions on distribution of sample source code.

 You can view the PCAUSA License here.

Price List and Ordering Information

Press the button below for Online Ordering and other Purchase Information.



Release Notes

Version Date Notes
V4.00.08.04 March 31, 2011 Additional bug fixes found when performing long term stress tests.
V4.00.08.02 January 10, 2011 Fixed important bugs in Setup installer projects. Install would fail or applications would not run correctly on some systems.
V4.00.08.01 November 9, 2010 1.) Fixed bug that prevented correct operation of the NDIS 5 driver after uninstall/re-install using FltInstall tool.
2.) Performed limited dry-run of WHQL DTM 1.5 tests on Windows XP and Windows 7 x86. Fixed a few problems that were identified by these tests.
V4.00.07.13 October 19, 2010 Fixed bug that prevented monitor-only mode from working. Some very minor performance enhancements. See detailed release notes.
V4.00.07.11 September 21, 2010 Fixed bug in 64-bit installer. Downloaded install included 32-bit components and did not work.
V4.00.07.10 September 13, 2010 Improved the sample applications. Some performance improvements on Vista and later platforms.
V4.00.07.08 August 29, 2010 Fixed some bugs overlooked in V4.00.07.07. Also some improvements to the UmTxRxLoopEx application.
V4.00.07.07 August 27, 2010 1.) Fixed three serious bugs.
2.) Added sample user-mode applications that illustrate higher performance I/O methods.
V4.00.07.06 May 15, 2010 1.) Now build NDIS 5 x64 driver.
2.) Added IPRedir 64-bit Edition installer project.
V4.00.07.05 March 25, 2010 1.) Fixed bad bug in Ndf_IoCsqPurgePendingIrps.
2.) Modified Ndf_DebugPrint so it compiles to nothing in free build.
3.) Improved notation for an increment operation in IMFilter_MakeLogRecord.
4.) Moved from WDK 7600.16385.0 to WDK 7600.16385.1.
5.) Additional annotations to define roles needed to run Static Driver
verifier.
V4.00.07.04 February 9, 2010 1.) Now free g_AdapterListLock in NDIS 5 driver PCASIMUnloadDriver callback.
2.) In NDIS 5 driver CLUnbindAdapterHandler routine now set correct flag.
3.) In NDIS 5 and NDIS 6 drivers the check for possible unbind or detach operation was not made before queuing read IRPs.
4.) Eliminated a few PREfast warnings from WDK 7600.16385.0.
V4.00.07.03 January 18, 2010 1.) Added CopyInf directive to Windows XP service INF file.
2.) Updated driver build to use Windows 7 WDK (7600.16385.0).
V4.00.07.02 November 17, 2009 1.) Reinstated support for NDIS WAN on NDIS 5 and NDIS 6.
2.) Small bug fix to console adapter chooser key press logic that made sample applications exit prematurely.
V4.00.07.01 November 15, 2009 Initial release of new NDIS 5/6 filter samples.

Detailed Release Notes...