Decide on the future of Npcap BlockRxAdapters/SendToRxAdapters feature

Npcap has a little-known feature which gives it some firewall-ish capabilities. When the Npcap LWF driver is sniffing packets, it normally continues to pass any received packets back up the stack so the host OS sees them too. This is essential so you can do things like using Wireshark to capture and analyze the traffic of an application running on the machine without interrupting that traffic. But Npcap actually has an installation-wide BlockRXAdapters registry you can set which prevents this. With this set, only Npcap sees the packet and then it goes no further.

There is also a corresponding SendToRxAdapters feature which lets you send traffic to an adapter and have it sent UP THE STACK as if it was received from that adapter rather than sending it outbound on the adapter. So you can make a sort of user-mode firewall by setting BlockRXAdapters and SendToRxAdapters for an interface. Then you (using Npcap capture handles) capture all the received packets and only forward the ones you wish to keep back up the stack using the SendToRx feature. Others have used this to make user-mode software bridges between interfaces on a machine.

Note that the registry keys to control this are under Npcap service's Paramters subkey, so only admin users can write to them.

This feature is problematic in several respects:

• It's poorly documented--in fact it's almost entirely undocumented.
• It is a systemwide registry setting for Npcap rather than per-handle, meaning it can have unwanted side-effects for other Npcap-using software on the system. Or even for the same software. For example, if you set an adapter to SendToRxAdapters mode, you can no longer send out that adapter using Npcap. In general we try to avoid systemwide Npcap configurations because they can cause problems when multiple applications are using Npcap at the same time and want different values for those options.
• It stays quite far from Npcap's core packet sending/capture functionality.

On the other hand, it is powerful functionality that has proven essential for a (small) number of applications. And maybe it would be used more widely if it was actually documented. And it may even be used more than we know given that we were fairly quickly notified when we accidentally broke the feature in Npcap 1.31 (#311).

We are hoping to soon fix the #311 regression in the next release, but how should we handle the feature in the future? Four possibilities are:

1. Do nothing. Leave this as an undocumented and somewhat problematic API, but keep it available for those who want/need it and manage to discover it.
2. Document it, along with a note that the API is problematic and could be changed or removed in future Npcap releases.
3. Update the API so it is per-capture handle rather than systemwide and document that API. We would probably keep the undocumented version too, at least for a while, for the benefit of applications that are already using it, but we would advise against such usage in the future.
4. Remove the feature so we don't need to support or document it. This would be of course be problematic for the small (but indeterminate) number of users of this feature, but they could still use the last version of Npcap before removal until they can migrate to a different approach.

This issue is here to discuss the feature and ideas for what we should do with it. It's a good place for anyone using the feature to step forward with your thoughts. We'd be very interested in how many people are using it (to help us decide whether to keep it) and how you are using it (to help us decide on potential improvements).

Some resources:

• UserBridge - an open source user-mode firewalling bridge created by @hsluoyz, who is also the Npcap developer who added these features in 2016.
• Issue #311 - Someone using this feature to create a user-space firewall.
• Someone requesting a more flexible version of SendToRxAdapters/BlockRxAdapters back in December 2016.

Start by reviewing the current BlockRxAdapters and SendToRxAdapters behavior described here, then read Issue #311 and the UserBridge project to understand the regression and real-world usage. Done means reaching a decision among documenting, redesigning, retaining, or removing the feature, with the rationale and affected users recorded.