binding a LWF to dialup on Windows 7

NTDEV
1

Hi All

I’m having all sorts of fun getting my LWF to be available to bind to
dialup networking on Windows 7.

I found out recently some genius at MS decided to break every firewall
on the planet by devising “raw IP packets” (which saves the OS nothing
but costs software devs a refactor).

http://www.microsoft.com/whdc/connect/mb/mbchangeswin7.mspx

anyway, does this also now affect dialup networking? the MS documents
only refer to mobile broadband.

Still can’t believe they let some numbskull do this.

Thanks

Adrien

2

> I’m having all sorts of fun getting my LWF to be available to bind to

dialup networking on Windows 7.

Please explain what the [fun] trouble is.

I found out recently some genius at MS decided to break every firewall
on the planet by devising “raw IP packets” (which saves the OS nothing
but costs software devs a refactor).

I am pretty sure that WFP based firewalls are impervious and nonplussed by this change.

http://www.microsoft.com/whdc/connect/mb/mbchangeswin7.mspx

anyway, does this also now affect dialup networking? the MS documents
only refer to mobile broadband.

Not that I have observed. How about you? Does it affect the virtual ethernet edge of NDISWAN that your LWF is attaching to? I could see that MSFT *could* go this way in modifying the NDISWAN but I don’t see the motiviation to take something that is working and has quite a bit of legacy expectation around the entire NDISWAN / WANARP interface with reverse compability to NDIS5 IM drivers and more recent LWF drivers and break that just for fun.

Still can’t believe they let some numbskull do this.

Well, I think you just ensured that the priority of assitance coming from the NDIS team could not be made any lower. Way to make friends.

But seriously, back to the problem and put aside the hystrionics:

What is the issue? Your LWF needs to deal with a specific media type. The world is not all ethernet and ethernet emulation. The Mobile Broadband world is just IP based and point-to-point. Getting rid of all of the nonsense of trying to make it look like PPP or 802.3 is a great simplification. Too bad it took until Win 7 to get it. A LWF either deals with range of media encodings or not. What do you do with FDDI?

But really, if it is IP firewalling on NT6 you want to do, why did you create a LWF to begin with? Do you need to know MAC level information?

Help us understand where the issue is and maybe someone on the list can help you find a solution.

Good Luck,
Dave Cattley

3

Hi Dave

firstly thanks for your response. I know my post didn’t deserve one.

We can’t use WPF for several reasons, since we do things with ARP etc,
and need MAC level access to packets, including the ability to inject
packets, also override routing (change outbound interface) etc.

Our code-base is also evolved from a driver that supported windows 95.

It could be argued that the main reason it’s difficult for us to support
raw IP packets is our own fault, because of our packet buffer usage (we
flatten the packet out including ethernet headers) which doesn’t allow
us the luxury of simply omitting to chain an ethernet header buffer on
the front. There’s a lot of code however, and refactoring it for this
purpose would be very risky = delays.

Our inf file specifies a media type of “ethernet, wan” which used to be
all that was required (e.g. Vista, and 2k8) to bind to all adapters (not
sure about fddi or token ring, but they are not in common use in our
customer base - we’ve had no requests for them).

With the introduction of raw IP, we have now had customer complaints our
driver doesn’t bind to things like 3G modems on Windows 7. I also can’t
get it binding to simple dialup.

I’ve been trying a variety of advertised media types (in
FilterMediaTypes) including ppip, vwifi (long story - only available
installable service on dialup has this type). To no avail. I tried
messing with the version number reported by the filter when it
registers. I think however the OS makes a decision on whether it will
allow something to be bound to an adapter purely on content of the inf file?

This is the relevant (I’m presuming) section.

HKR, Ndi,FilterClass, compression
HKR, Ndi,FilterType,0x00010001,0x00000002
HKR, Ndi\Interfaces,UpperRange,“noupper”
HKR, Ndi\Interfaces,LowerRange,“nolower”
HKR, Ndi\Interfaces, FilterMediaTypes,“ethernet, wan”
HKR, Ndi,FilterRunType, 0x00010001, 1 ;this filter must run before any
protocol can bind to the below miniport

As for whether it was a good thing to introduce raw IP, I guess we
disagree on that. My question is what dire problem did it fix, cos it
sure caused a few (even if only relating to MB). We now have to

a) maintain and deploy separate drivers / infs for windows 7, 2k8 R2 vs
Vista
b) switch packet processing based on the media type of the interface.

Everyone else now also has to write a new miniport for 7 as well and
therefore maintain an extra code-base. You’d think this would have put
MS off - lack of initial hardware support due to MB vendors playing
catch-up with a new driver for 7.

In fact since we do NAT, routing and VPN, we adopt a common packet
format internally anyway - with an ethernet header.

I guess my point is, that it worked well for decades for other media to
emulate ethernet in NDIS. This I believe was a fantastic thing. It
made it simple for interop, and writing packet processing software.

Introducing this change broke all that. I’m struggling to see the
benefit. It’s not like the ethernet header would have been sent over the
wire anyway (for mobile broadband or PPP). So we saved the MB miniport
the task of stripping the ethernet header off, but it has to do major
processing on the packet to get it into an on-the-air format anyway.
They took away the ethernet header, and then had to store the frame type
in another field of the NBL. So all they saved was 12 bytes. 2 MAC
addresses. These bytes were only transported from the top of NDIS to
the bottom anyway. So it’s not like it was a bandwidth / memory / CPU hog.

I just think the benefits of such a change are nebulous, but the costs
are large and real. Every miniport and intermediary developer has to do
a bunch of work to make things function again. It impacts customers
also due to the impact on their suppliers (devs). There have been a lot
of changes in Vista / 7 lately that have broken compatibility. Whilst I
understand this is sometimes necessary, it is an onerous thing, and I
don’t believe should be done without very good reason, and without
consideration to the work it causes others.

Thanks again Dave, if you’re ever in Auckland, I owe you a beer.

Regards

Adrien

On 25/01/2011 4:50 a.m., Dave Cattley wrote:

> I’m having all sorts of fun getting my LWF to be available to bind to
> dialup networking on Windows 7.

Please explain what the [fun] trouble is.

> I found out recently some genius at MS decided to break every firewall
> on the planet by devising “raw IP packets” (which saves the OS nothing
> but costs software devs a refactor).

I am pretty sure that WFP based firewalls are impervious and
nonplussed by this change.

> http://www.microsoft.com/whdc/connect/mb/mbchangeswin7.mspx
>
> anyway, does this also now affect dialup networking? the MS documents
> only refer to mobile broadband.

Not that I have observed. How about you? Does it affect the virtual
ethernet edge of NDISWAN that your LWF is attaching to? I could see
that MSFT *could* go this way in modifying the NDISWAN but I don’t see
the motiviation to take something that is working and has quite a bit
of legacy expectation around the entire NDISWAN / WANARP interface
with reverse compability to NDIS5 IM drivers and more recent LWF
drivers and break that just for fun.

> Still can’t believe they let some numbskull do this.

Well, I think you just ensured that the priority of assitance coming
from the NDIS team could not be made any lower. Way to make friends.

But seriously, back to the problem and put aside the hystrionics:

What is the issue? Your LWF needs to deal with a specific media
type. The world is not all ethernet and ethernet emulation. The
Mobile Broadband world is just IP based and point-to-point. Getting
rid of all of the nonsense of trying to make it look like PPP or 802.3
is a great simplification. Too bad it took until Win 7 to get
it. A LWF either deals with range of media encodings or not.
What do you do with FDDI?

But really, if it is IP firewalling on NT6 you want to do, why did you
create a LWF to begin with? Do you need to know MAC level information?

Help us understand where the issue is and maybe someone on the list
can help you find a solution.

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

4

>I just think the benefits of such a change are nebulous, but the costs are large and real.

So what? write a thin wrapper around MB Win7 interface, which will use fake MAC addresses (some pointer values) to fill the fake Ethernet header.

Since you’re flattening the packets anyway, this tiny update must be done in the flattening code.

And sorry, David is right. NDIS never promised that every packet has an Ethernet header. Things like native ATM and IP/1394 (dropped in Vista) were there since around 2000-2001, and they do not use Ethernet addressing at all.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Adrien,

It is clear you understand the trade-offs and the challenges. I want to
add one more bit of observation from Win7 that may contribute to you seeing
that a WFP solution is ‘necessary’ to cover
inspection/modification/injection of IP packet flows over arbitrary
interfaces.

I will assume your driver really is quite interested in observing all IP
flows across all IP interfaces. Have a look at the AgileVPN (MobIke)
connection in Win7. The pre-encapuslation traffic (the tunneled IP
traffic) seems to be observable *only* in the WFP prior to the IPSec callout
processing. While RASMAN and NDISWAN are ‘involved’ in this style of VPN
connection (projection) they do not seem to be ‘involved’ in the packet
flow. So while an interface is created on NDISWAN and ‘call-control’ winds
up passing through a VPN style CoMini similar to PPTP/L2TP, the traffic is
entirely diverted at the IPSec callout in WFP and thus never even makes it
to NDISWAN or the CoMiniport. So if your solution needs to deal with
AgileVPN connections, your totally out of luck if you expect to see that
traffic in the clear (outside of the IPsec tunnel) as an NDIS NET_BUFFER.
It just never is such a thing. You *have* to get it in the WFP.

This was the observation that prompted me to realize that one of my
inspection/capture/injection projects had to move to WFP and not continue
life as a IM/LWF style L2 processing entity. I skirted the entire LWF over
WWAN issue by moving all of the IP flow processing to a callout from WFP.
The L2 processing in that solution makes sense only for Ethernet attached
links and thus was ‘split’ from the IP processing which is applied to all IP
flows.

While I understand your frustration, I think you might be stuck in the
long-run with having to make modifications to how your system models the
packet flow processing to accommodate the reality of the platform. It just
no longer is true that you can observe all non-loopback traffic at an NDIS
interface point.

Good Luck,
Dave Cattley

6

Hi David

Is it then possible for one driver to be installed / registered as both
a LWF and a WPF filter? Or would that require 2 drivers?

Since we still need MAC addresses (for interfaces that use it) for MAC
filtering, and to process inbound and outbound ARP (and spoof / block it

  • for legitimate purposes only of course) , we still need to be at that
    level.

I’m not yet sure whether we need clear-text (pre-tunnelled) VPN traffic
or not. I guess host (local machine) outbound VPN traffic we would need
to see, but through traffic we would get on the way in.

As for packets and linked lists of buffers. Is there anything one can
safely assume about the linked buffers? E.g. can one assume packets are
not split across L2-L3 or L3 - L4 headers? e.g would you ever see
anything like

Buf 0 - ethernet header
Buf 1 - IP header
Buf 2 - TCP header
Buf 3 - payload

Or is it at most

Buf 0 - ethernet header
Buf 1 - IP and the rest

The reason I ask is if I am to write a wrapper class that is used to
access a NBL as if it were contiguous memory space, I’ll need to be able
to tell where each buffer starts and ends in the packet.

Regards

Adrien

On 26/01/2011 3:06 a.m., David R. Cattley wrote:

Adrien,

It is clear you understand the trade-offs and the challenges. I want to
add one more bit of observation from Win7 that may contribute to you seeing
that a WFP solution is ‘necessary’ to cover
inspection/modification/injection of IP packet flows over arbitrary
interfaces.

I will assume your driver really is quite interested in observing all IP
flows across all IP interfaces. Have a look at the AgileVPN (MobIke)
connection in Win7. The pre-encapuslation traffic (the tunneled IP
traffic) seems to be observable *only* in the WFP prior to the IPSec callout
processing. While RASMAN and NDISWAN are ‘involved’ in this style of VPN
connection (projection) they do not seem to be ‘involved’ in the packet
flow. So while an interface is created on NDISWAN and ‘call-control’ winds
up passing through a VPN style CoMini similar to PPTP/L2TP, the traffic is
entirely diverted at the IPSec callout in WFP and thus never even makes it
to NDISWAN or the CoMiniport. So if your solution needs to deal with
AgileVPN connections, your totally out of luck if you expect to see that
traffic in the clear (outside of the IPsec tunnel) as an NDIS NET_BUFFER.
It just never is such a thing. You *have* to get it in the WFP.

This was the observation that prompted me to realize that one of my
inspection/capture/injection projects had to move to WFP and not continue
life as a IM/LWF style L2 processing entity. I skirted the entire LWF over
WWAN issue by moving all of the IP flow processing to a callout from WFP.
The L2 processing in that solution makes sense only for Ethernet attached
links and thus was ‘split’ from the IP processing which is applied to all IP
flows.

While I understand your frustration, I think you might be stuck in the
long-run with having to make modifications to how your system models the
packet flow processing to accommodate the reality of the platform. It just
no longer is true that you can observe all non-loopback traffic at an NDIS
interface point.

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

7

For all practical purposes a WFP filter is a legacy (non-PnP) driver started
by the service control manager.

On the other hand, NDIS filters and protocols are “pseudo-PnP” loaded by
NDIS.

I don’t think they can be in the same driver.

On the other hand, WFP does include a NDIS LWF driver of sorts. It is the
packet level callouts.

Thomas F. Divine

From: “Adrien de Croy”
Sent: Thursday, January 27, 2011 7:27 PM
To: “Windows System Software Devs Interest List”
Cc: “David R. Cattley”
Subject: Re: [ntdev] binding a LWF to dialup on Windows 7

>
> Hi David
>
> Is it then possible for one driver to be installed / registered as both a
> LWF and a WPF filter? Or would that require 2 drivers?
>
> Since we still need MAC addresses (for interfaces that use it) for MAC
> filtering, and to process inbound and outbound ARP (and spoof / block it -
> for legitimate purposes only of course) , we still need to be at that
> level.
>
> I’m not yet sure whether we need clear-text (pre-tunnelled) VPN traffic or
> not. I guess host (local machine) outbound VPN traffic we would need to
> see, but through traffic we would get on the way in.
>
> As for packets and linked lists of buffers. Is there anything one can
> safely assume about the linked buffers? E.g. can one assume packets are
> not split across L2-L3 or L3 - L4 headers? e.g would you ever see
> anything like
>
> Buf 0 - ethernet header
> Buf 1 - IP header
> Buf 2 - TCP header
> Buf 3 - payload
>
> Or is it at most
>
> Buf 0 - ethernet header
> Buf 1 - IP and the rest
>
> The reason I ask is if I am to write a wrapper class that is used to
> access a NBL as if it were contiguous memory space, I’ll need to be able
> to tell where each buffer starts and ends in the packet.
>
> Regards
>
> Adrien
>
> On 26/01/2011 3:06 a.m., David R. Cattley wrote:
>> Adrien,
>>
>> It is clear you understand the trade-offs and the challenges. I want to
>> add one more bit of observation from Win7 that may contribute to you
>> seeing
>> that a WFP solution is ‘necessary’ to cover
>> inspection/modification/injection of IP packet flows over arbitrary
>> interfaces.
>>
>> I will assume your driver really is quite interested in observing all IP
>> flows across all IP interfaces. Have a look at the AgileVPN (MobIke)
>> connection in Win7. The pre-encapuslation traffic (the tunneled IP
>> traffic) seems to be observable only in the WFP prior to the IPSec
>> callout
>> processing. While RASMAN and NDISWAN are ‘involved’ in this style of
>> VPN
>> connection (projection) they do not seem to be ‘involved’ in the packet
>> flow. So while an interface is created on NDISWAN and ‘call-control’
>> winds
>> up passing through a VPN style CoMini similar to PPTP/L2TP, the traffic
>> is
>> entirely diverted at the IPSec callout in WFP and thus never even makes
>> it
>> to NDISWAN or the CoMiniport. So if your solution needs to deal with
>> AgileVPN connections, your totally out of luck if you expect to see that
>> traffic in the clear (outside of the IPsec tunnel) as an NDIS NET_BUFFER.
>> It just never is such a thing. You have to get it in the WFP.
>>
>> This was the observation that prompted me to realize that one of my
>> inspection/capture/injection projects had to move to WFP and not continue
>> life as a IM/LWF style L2 processing entity. I skirted the entire LWF
>> over
>> WWAN issue by moving all of the IP flow processing to a callout from WFP.
>> The L2 processing in that solution makes sense only for Ethernet attached
>> links and thus was ‘split’ from the IP processing which is applied to all
>> IP
>> flows.
>>
>> While I understand your frustration, I think you might be stuck in the
>> long-run with having to make modifications to how your system models the
>> packet flow processing to accommodate the reality of the platform. It
>> just
>> no longer is true that you can observe all non-loopback traffic at an
>> NDIS
>> interface point.
>>
>> 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
>
> —
> 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

8

it is interesting to note, looking in my registry under

HKLM\System\CurrentControlSet\Control\Network{4d36e974-e325-11ce-bfc1-08002be10318}

which is where the system stores NetService class of objects, that

subkey {B70D6460-3635-4D42-B866-B8AB1A24454C} is the WPF Lightweight
filter. Presumably this provides support for stack callouts. However,
it only binds to ethernet (NDI\Interfaces\FilterMediaTypes).

Therefore to provide IP streams for other media types, it must also
install and register other drivers. Presumably MS thought better of
getting it to bind to wlan or wan via this driver?

Also, looking at the NDIS Capture LightWeight Filter, one can see it is
bindable to ethernet and wlan.

wlan is wireless lan correct?

QoS Packet Scheduler binds to ethernet and wan (as do we). It isn’t
visible on my dialup adapter either, and does not show when I hit
install and select service.

So has wan been deprecated in Windows 7? It works fine on Vista. Or
does this indicate some other problem with my system.

I haven’t found the definitive list of known media types (for purpose of
putting into an inf file). Is there one of these?

Regards and thanks

Adrien

On 28/01/2011 1:38 p.m., Thomas F. Divine wrote:

For all practical purposes a WFP filter is a legacy (non-PnP) driver
started by the service control manager.

On the other hand, NDIS filters and protocols are “pseudo-PnP” loaded
by NDIS.

I don’t think they can be in the same driver.

On the other hand, WFP does include a NDIS LWF driver of sorts. It is
the packet level callouts.

Thomas F. Divine

From: “Adrien de Croy”
> Sent: Thursday, January 27, 2011 7:27 PM
> To: “Windows System Software Devs Interest List”
> Cc: “David R. Cattley”
> Subject: Re: [ntdev] binding a LWF to dialup on Windows 7
>
>>
>> Hi David
>>
>> Is it then possible for one driver to be installed / registered as
>> both a LWF and a WPF filter? Or would that require 2 drivers?
>>
>> Since we still need MAC addresses (for interfaces that use it) for
>> MAC filtering, and to process inbound and outbound ARP (and spoof /
>> block it - for legitimate purposes only of course) , we still need to
>> be at that level.
>>
>> I’m not yet sure whether we need clear-text (pre-tunnelled) VPN
>> traffic or not. I guess host (local machine) outbound VPN traffic we
>> would need to see, but through traffic we would get on the way in.
>>
>> As for packets and linked lists of buffers. Is there anything one
>> can safely assume about the linked buffers? E.g. can one assume
>> packets are not split across L2-L3 or L3 - L4 headers? e.g would you
>> ever see anything like
>>
>> Buf 0 - ethernet header
>> Buf 1 - IP header
>> Buf 2 - TCP header
>> Buf 3 - payload
>>
>> Or is it at most
>>
>> Buf 0 - ethernet header
>> Buf 1 - IP and the rest
>>
>> The reason I ask is if I am to write a wrapper class that is used to
>> access a NBL as if it were contiguous memory space, I’ll need to be
>> able to tell where each buffer starts and ends in the packet.
>>
>> Regards
>>
>> Adrien
>>
>> On 26/01/2011 3:06 a.m., David R. Cattley wrote:
>>> Adrien,
>>>
>>> It is clear you understand the trade-offs and the challenges. I
>>> want to
>>> add one more bit of observation from Win7 that may contribute to you
>>> seeing
>>> that a WFP solution is ‘necessary’ to cover
>>> inspection/modification/injection of IP packet flows over arbitrary
>>> interfaces.
>>>
>>> I will assume your driver really is quite interested in observing
>>> all IP
>>> flows across all IP interfaces. Have a look at the AgileVPN (MobIke)
>>> connection in Win7. The pre-encapuslation traffic (the tunneled IP
>>> traffic) seems to be observable only in the WFP prior to the IPSec
>>> callout
>>> processing. While RASMAN and NDISWAN are ‘involved’ in this style
>>> of VPN
>>> connection (projection) they do not seem to be ‘involved’ in the packet
>>> flow. So while an interface is created on NDISWAN and
>>> ‘call-control’ winds
>>> up passing through a VPN style CoMini similar to PPTP/L2TP, the
>>> traffic is
>>> entirely diverted at the IPSec callout in WFP and thus never even
>>> makes it
>>> to NDISWAN or the CoMiniport. So if your solution needs to deal with
>>> AgileVPN connections, your totally out of luck if you expect to see
>>> that
>>> traffic in the clear (outside of the IPsec tunnel) as an NDIS
>>> NET_BUFFER.
>>> It just never is such a thing. You have to get it in the WFP.
>>>
>>> This was the observation that prompted me to realize that one of my
>>> inspection/capture/injection projects had to move to WFP and not
>>> continue
>>> life as a IM/LWF style L2 processing entity. I skirted the entire
>>> LWF over
>>> WWAN issue by moving all of the IP flow processing to a callout from
>>> WFP.
>>> The L2 processing in that solution makes sense only for Ethernet
>>> attached
>>> links and thus was ‘split’ from the IP processing which is applied
>>> to all IP
>>> flows.
>>>
>>> While I understand your frustration, I think you might be stuck in the
>>> long-run with having to make modifications to how your system models
>>> the
>>> packet flow processing to accommodate the reality of the platform.
>>> It just
>>> no longer is true that you can observe all non-loopback traffic at
>>> an NDIS
>>> interface point.
>>>
>>> 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
>>
>> —
>> 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
>
>
> —
> 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

9

A LWF can ‘contain’ a WFP callout driver without much difficulty. It is
best to construct the driver as a LWF meeting all of its operational and
installation requirements and then WFP callout functionality to it. A WFP
callout driver does not have any specific installation requirements and its
only operational requirement is that it register (eventually) with WFP. I
have found it easiest to perform that registration in response to UM
stimulus (an IOCTL or IRP_MJ_CREATE for example) but most any solution that
coordinates the startup behavior and will be fine.

On outbound (send) it has always been the case that the MDL chain (or
NDIS_BUFFER chain) could be quite arbitrary and very fragmented. While I
have seen drivers that made assumptions about the fragmentation of inbound
(receive) packets, I generally assume they can be as fragmented as sends
since a loopback might be in the mix. So if you need a flat buffer, you
best assume you will need to flatten it.

If you can accommodate the behavior, it is almost a surety that any
‘header’ you encounter (MAC, IP, Transport) will be contiguous. That is
often enough to keep the processing efficient.

Your first example is (IIRC) pretty typical of a send packet. Your second
example is pretty typical of a receive packet although with header-data
split, you might want to assume the possibility of a boundary at the
transport/payload demark.

I have given up trying to assume anything and just code such that contiguous
headers are accessed via a direct pointer but non-contiguous headers are
‘bounced’ to a staging buffer and then accessed via a pointer. The
processing routines don?t know which, only the access routines know and make
it transparent. That way, I can forget about worrying if the header splits
across an MDL boundary and I can be assured it is as fast as it can be.

The routine I have in my kit has a prototype of:

PVOID
NdxGetOrCopyFlatFromBufferChainSafe(
IN PNDIS_BUFFER Source,
IN UINT SourceOffset,
IN PVOID ScratchBuffer,
IN UINT ScratchBufferLength,
OUT PUINT BytesAvailable,
IN MM_PAGE_PRIORITY Priority
);

It traverses the MDL chain to the offset specified and determines if the
requested length is contiguous. If so, it returns a pointer directly to the
contiguous block else it copies the data (from the MDL chain) into the
ScratchBuffer and returns a pointer to the ScratchBuffer. Either way, the
pointer points to a contiguous block. Simplifies the processing of
accessing things like IP headers and such. Easily adapted to NDIS5 styles
packets or NDIS6 NBLs.

There may be similar support in NDIS6 but since I have my favorite debugged
routine, I have not gone looking to see :slight_smile:

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Adrien de Croy
Sent: Thursday, January 27, 2011 7:28 PM
To: Windows System Software Devs Interest List
Cc: David R. Cattley
Subject: Re: [ntdev] binding a LWF to dialup on Windows 7

Hi David

Is it then possible for one driver to be installed / registered as both
a LWF and a WPF filter? Or would that require 2 drivers?

Since we still need MAC addresses (for interfaces that use it) for MAC
filtering, and to process inbound and outbound ARP (and spoof / block it

  • for legitimate purposes only of course) , we still need to be at that
    level.

I’m not yet sure whether we need clear-text (pre-tunnelled) VPN traffic
or not. I guess host (local machine) outbound VPN traffic we would need
to see, but through traffic we would get on the way in.

As for packets and linked lists of buffers. Is there anything one can
safely assume about the linked buffers? E.g. can one assume packets are
not split across L2-L3 or L3 - L4 headers? e.g would you ever see
anything like

Buf 0 - ethernet header
Buf 1 - IP header
Buf 2 - TCP header
Buf 3 - payload

Or is it at most

Buf 0 - ethernet header
Buf 1 - IP and the rest

The reason I ask is if I am to write a wrapper class that is used to
access a NBL as if it were contiguous memory space, I’ll need to be able
to tell where each buffer starts and ends in the packet.

Regards

Adrien

10


On the other hand, WFP does include a NDIS LWF driver of sorts. It is the
packet level callouts.

Mr. Tippet has suggested strongly that we ignore the early musings on WFP
having an L2 filtering layer as it has been apparently removed from Win7
post RTM and not documented ‘officially’ (other than those WinHEC/DevCon
slides) since it has issues.

I guess we should play along 'cause it does not work!

Easy enough to write one’s own LWF.

Cheers,
Dave Cattley

11

The WFP LWF is deprecated. Luckily it is not at all involved in delivery
IP packet flows from the WFP. The TCP/IP stack makes callouts to the WFP to
present IP packets for filtering. All IP packets are presented regardless
of the LL interface type.

The TCP/IP stack roughly has a point where a packet transitions from(to) an
‘IP packet’ to(from) an ‘IP packet on a specific LL medium’. You can think
of this as the ARP layer but of course some mediums do not use ARP and have
other mapping schemes (and some have none, eg. the reason this thread
exists). At the edge of that transition TCPIP makes a WFP callout at the
{INBOUND|OUTBOUND}_IPPACKET_V{4|6} layer.

[Note: Apologies to Thomas. This was quite clearly now that I re-read his
post the layer he was referring to, not the deprecated L2 filter layer]

You can see all the IP traffic in/out of the system on all interfaces at
this layer.

wlan is wireless lan correct?

Yes. But the Native WiFi LWF translates the wlan media type to Ethernet at
the upper edge of filter so binding to a WLAN adapter in most cases means
binding with Ethernet.

QoS Packet Scheduler binds to ethernet and wan (as do we). It isn’t
visible on my dialup adapter either, and does not show when I hit
install and select service.

Hmm. On my Win7 x64 system when I run BindView from the WDK it clearly
shows the QoS LWF bound to my WAN IP miniport.

So has wan been deprecated in Windows 7?

No. That would be rather shocking. I think you need to double-check your
measurements.

I haven’t found the definitive list of known media types (for purpose of
putting into an inf file). Is there one of these?

Yes NTDDNDIS.H (or NDIS.H) has an enum NDIS_MEDIUM with the medium types and
it is documented on MSDN/WDK. You get an RT{F]M for that one!

Vista brought with it NdisMediumTunnel, NdisMediumNative802_11 and
NdisMediumLoopback.
Win7 brought with it NdisMediumWiMax and NdisMediumIP.

The other 15 have been around for ages. Probably safe to ignore the
LocalTalk, Dix, and ARCNet ones :slight_smile:

Good Luck,
Dave Cattley

12

http-equiv=“Content-Type”>

On 29/01/2011 2:00 a.m., David R. Cattley wrote:

type=“cite”>QoS Packet Scheduler binds to ethernet and wan (as do
we). It isn’t

visible on my dialup adapter either, and does not show when I hit
install and select service.

Hmm. On my Win7 x64 system when I run BindView from the WDK it clearly
shows the QoS LWF bound to my WAN IP miniport.

ok, but do you see it in the networking tab of the dialup profile
properties (in control panel network connections)?

I need to get bindview building before I can run it to check there.

It seems odd to me that it would be bound and not show there, when
it shows on all my other adapters.

Also we simply aren’t getting packets on our driver over dialup. 

So it sounds like there’s some issue with my computer preventing
wan-binding LWFs from binding to dialup.  I’ll need to get
bindview.exe going to double check.  Shame they didn’t just ship the
exes… can never be certain you have everything correct when you
have to build it yourself…

type=“cite”>

So has wan been deprecated in Windows 7?

No. That would be rather shocking. I think you need to double-check your
measurements.

ok.

type=“cite”>

I haven’t found the definitive list of known media types (for purpose of
putting into an inf file). Is there one of these?

Yes NTDDNDIS.H (or NDIS.H) has an enum NDIS_MEDIUM with the medium types and
it is documented on MSDN/WDK. You get an RT{F]M for that one!

OK.  I did a fair bit of looking on msdn in the sections on inf
files for LWF drivers, but it sends you round in circles for the
FilterMediaTypes attribute.  The closest thing I found was

href=“http://msdn.microsoft.com/en-us/library/ff570839(VS.85).aspx”>http://msdn.microsoft.com/en-us/library/ff570839(VS.85).aspx

They give list of media types for upper and lower, but not for
FilterMediaTypes.  It would be nice to get a bit more info than just
enum values from a WDK header.

Thanks!

Adrien

type=“cite”>

Vista brought with it NdisMediumTunnel, NdisMediumNative802_11 and
NdisMediumLoopback.
Win7 brought with it NdisMediumWiMax and NdisMediumIP.

The other 15 have been around for ages. Probably safe to ignore the
LocalTalk, Dix, and ARCNet ones :slight_smile:

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 athttp://www.osronline.com/page.cfm?name=ListServer

--
Adrien de Croy - WinGate Proxy Server -[http://www.wingate.com](http://www.wingate.com)
13

I have a modifying optional LWF that binds to dialup. From the INF:

HKR, Ndi\Interfaces, FilterMediaTypes,“ethernet,wan”

You do need to modify the FilterAttach code a bit. It probably looks like this:

if (AttachParameters->MiniportMediaType != NdisMedium802_3)
{
Ndf_DbgPrint(DL_ERROR, DBG_BIND, “Doesn’t support media type other than NdisMedium802_3.\n”);

Status = NDIS_STATUS_INVALID_PARAMETER;
break;
}

You need to allow NdisMediumWan in addition to NdisMedium802_3.

Thomas F. Divine

From: Adrien de Croy
Sent: Friday, January 28, 2011 8:27 PM
To: Windows System Software Devs Interest List
Cc: David R. Cattley ; ‘Thomas F. Divine’
Subject: Re: [ntdev] binding a LWF to dialup on Windows 7

On 29/01/2011 2:00 a.m., David R. Cattley wrote:
QoS Packet Scheduler binds to ethernet and wan (as do we). It isn’t

visible on my dialup adapter either, and does not show when I hit
install and select service.
Hmm. On my Win7 x64 system when I run BindView from the WDK it clearly
shows the QoS LWF bound to my WAN IP miniport.

ok, but do you see it in the networking tab of the dialup profile properties (in control panel network connections)?

I need to get bindview building before I can run it to check there.

It seems odd to me that it would be bound and not show there, when it shows on all my other adapters.

Also we simply aren’t getting packets on our driver over dialup.

So it sounds like there’s some issue with my computer preventing wan-binding LWFs from binding to dialup. I’ll need to get bindview.exe going to double check. Shame they didn’t just ship the exes… can never be certain you have everything correct when you have to build it yourself…

So has wan been deprecated in Windows 7?
No. That would be rather shocking. I think you need to double-check your
measurements.

ok.

I haven’t found the definitive list of known media types (for purpose of
putting into an inf file). Is there one of these?
Yes NTDDNDIS.H (or NDIS.H) has an enum NDIS_MEDIUM with the medium types and
it is documented on MSDN/WDK. You get an RT{F]M for that one!

OK. I did a fair bit of looking on msdn in the sections on inf files for LWF drivers, but it sends you round in circles for the FilterMediaTypes attribute. The closest thing I found was

http://msdn.microsoft.com/en-us/library/ff570839(VS.85).aspx

They give list of media types for upper and lower, but not for FilterMediaTypes. It would be nice to get a bit more info than just enum values from a WDK header.

Thanks!

Adrien

Vista brought with it NdisMediumTunnel, NdisMediumNative802_11 and
NdisMediumLoopback.
Win7 brought with it NdisMediumWiMax and NdisMediumIP.

The other 15 have been around for ages. Probably safe to ignore the
LocalTalk, Dix, and ARCNet ones :slight_smile:

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

–
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

14

> ok, but do you see it in the networking tab of the dialup profile
properties (in control panel network connections)?

NCF_HIDDEN and/or NCF_NOT_USER_REMOVABLE could be at play here. That is
why I use BindView.

I need to get bindview building before I can run it to check there.

Yes, highly recommended.

Good Luck,
Dave Cattley

15

http-equiv=“Content-Type”>

already have that in there.

I think it must be something else.

as for NCF_HIDDEN and/or NCF_NOT_USER_REMOVABLE, they aren’t set on
pacer.sys

Nor on our driver.  And we don’t get the packets.

Also, we tried on another windows 7 machine - same deal.

Regards

Adrien

On 29/01/2011 2:41 p.m., Thomas F. Divine wrote:

type=“cite”>

http-equiv=“Content-Type”>

I have a modifying optional LWF that binds to dialup. From
the INF:

 

HKR, Ndi\Interfaces, FilterMediaTypes,“ethernet,wan”

 

You do need to modify the FilterAttach code a bit. It
probably looks like this:

 

      if (AttachParameters->MiniportMediaType !=
NdisMedium802_3)

      {

         Ndf_DbgPrint(DL_ERROR, DBG_BIND, “Doesn’t support media
type other than NdisMedium802_3.\n”);

 

         Status = NDIS_STATUS_INVALID_PARAMETER;

         break;

      }

 

You need to allow NdisMediumWan in addition to
NdisMedium802_3.

Thomas F. Divine

 

From: title="xxxxx@qbik.com" href="mailto:xxxxx@qbik.com">Adrien
de Croy

Sent: Friday, January 28, 2011 8:27 PM

To: title="xxxxx@lists.osr.com"
href="mailto:xxxxx@lists.osr.com">Windows System Software
Devs Interest List

Cc: href="mailto:xxxxx@msn.com">David R. Cattley ; moz-do-not-send=“true” title="xxxxx@pcausa.com"
href="mailto:xxxxx@pcausa.com">‘Thomas F. Divine’

Subject: Re: [ntdev] binding a LWF to dialup on Windows 7

On 29/01/2011 2:00 a.m., David R. Cattley wrote:

type=“cite”>QoS Packet Scheduler binds to ethernet and wan (as
do we). It isn’t

visible on my dialup adapter either, and does not show when I hit
install and select service.

Hmm. On my Win7 x64 system when I run BindView from the WDK it clearly
shows the QoS LWF bound to my WAN IP miniport.

ok, but do you see it in the networking tab of the dialup profile
properties (in control panel network connections)?

I need to get bindview building before I can run it to check
there.

It seems odd to me that it would be bound and not show there, when
it shows on all my other adapters.

Also we simply aren’t getting packets on our driver over dialup. 

So it sounds like there’s some issue with my computer preventing
wan-binding LWFs from binding to dialup.  I’ll need to get
bindview.exe going to double check.  Shame they didn’t just ship
the exes… can never be certain you have everything correct when
you have to build it yourself…

type=“cite”>

So has wan been deprecated in Windows 7?

No. That would be rather shocking. I think you need to double-check your
measurements.

ok.

type=“cite”>

I haven’t found the definitive list of known media types (for purpose of
putting into an inf file). Is there one of these?

Yes NTDDNDIS.H (or NDIS.H) has an enum NDIS_MEDIUM with the medium types and
it is documented on MSDN/WDK. You get an RT{F]M for that one!

OK.  I did a fair bit of looking on msdn in the sections on inf
files for LWF drivers, but it sends you round in circles for the
FilterMediaTypes attribute.  The closest thing I found was

href=“http://msdn.microsoft.com/en-us/library/ff570839(VS.85).aspx”>http://msdn.microsoft.com/en-us/library/ff570839(VS.85).aspx

They give list of media types for upper and lower, but not for
FilterMediaTypes.  It would be nice to get a bit more info than
just enum values from a WDK header.

Thanks!

Adrien

type=“cite”>

Vista brought with it NdisMediumTunnel, NdisMediumNative802_11 and
NdisMediumLoopback.
Win7 brought with it NdisMediumWiMax and NdisMediumIP.

The other 15 have been around for ages. Probably safe to ignore the
LocalTalk, Dix, and ARCNet ones :slight_smile:

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 athttp://www.osronline.com/page.cfm?name=ListServer

–
Adrien de Croy - WinGate Proxy Server -http://www.wingate.com

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

--
Adrien de Croy - WinGate Proxy Server -[http://www.wingate.com](http://www.wingate.com)
16

> On the other hand, NDIS filters and protocols are “pseudo-PnP” loaded by

NDIS.

Protocols?

Any driver can have an NDIS protocol lower edge. Even the PnP one.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com