Hi folks,
I want to advertize the exact same capabilities as the miniport i am
connecting my ‘passthrough’ driver to. THat is, in the advanced tab of the
passthrough driver (supplied with WDK), I want to propagete the same values
for diff settings like LSO, chimney, WOL, network address and others, and
they should have the same valeus as the one I am attaching the driver to.
What is the way to do that?
AP
I’ve got a couple of observations…
First of all, what is “advanced tab of the passthrough driver”??? Please note that passthru is a filter, rather than MUX, so that it does not present itself as an adapter, although it is mentioned under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}.
Therefore, bound protocols believe that they are dealing with underlying adapter - they have no idea about IM filter’s presence, and, hence, one has to configure underlying adapter, rather than filter…
Second, the very term “advertizing capabilities” does bot apply here - advertizing miniport capabilities is NDIS 6 feature, but passthru is NDIS 5 filter that registers NDIS 5 miniport.
Anton Bassov
Dear Anton/Others,
I am a novice in NDIS, infact drivers for that matter. So many of my mails
would make no sense. But I intend to learn, if you people help.
First of all, what is “advanced tab of the passthrough driver”???
So, do you mean that only Adapters have advanced tab?
Please note that passthru is a filter, rather than MUX, so that it does not
present itself as an adapter, although it is mentioned under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}
Well, I want to build something similar to MUX. I want to build an LBFO
driver. I started reading passthru as startup. So, if I want to build a
generic LBFO driver, how do i expose the lower level driver’s capabilities
in the advaned tab of a MUX like driver.
AP
On 8/13/07, xxxxx@hotmail.com wrote:
>
>
> I’ve got a couple of observations…
>
> First of all, what is “advanced tab of the passthrough driver”??? Please
> note that passthru is a filter, rather than MUX, so that it does not present
> itself as an adapter, although it is mentioned under
>
> HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}.
> Therefore, bound protocols believe that they are dealing with underlying
> adapter - they have no idea about IM filter’s presence, and, hence, one has
> to configure underlying adapter, rather than filter…
>
> Second, the very term “advertizing capabilities” does bot apply here -
> advertizing miniport capabilities is NDIS 6 feature, but passthru is NDIS 5
> filter that registers NDIS 5 miniport.
>
> Anton Bassov
>
>
> —
> 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
>
There are several issues here.
First of all, if your goal is to write a LBFO driver, then your driver
probably does not depend on the capabilities of the lower-level real
miniport. Instead, you are going to write a driver that could work with any
generic miniport. So, don’t worry about the capabilities of the lower-level
miniport too much.
Next, the properties that an adapter vendor exposes on the adapter’s
advanced properties page may, in fact, be vendor-proprietary. Some
properties may be handled using Microsoft-defined OIDs, etc., but only the
adapter vendor knows many other of its properties and how to set them on
that specific vendor’s adapter.
Going further, LBFO drivers are most often written by the adapter vendor
themselves. In this case they know all about the private APIs and properties
of their hardware and can do what you are trying to do very simply.
I’m trying to say that:
1.) An adapter vendor can expose their LBFO driver properties the way you
are hoping to do very easily.
2.) You cannot do the same because you do not have the adapter vendor’s
proprietary information.
Best to write your LBFO driver to work on generic Ethernet adapter and not
get bogged down with this (probably) unsolvable problem.
Thomas F. Divine
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Monday, August 13, 2007 12:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ndis passthrough
Dear Anton/Others,
I am a novice in NDIS, infact drivers for that matter. So many of my mails
would make no sense. But I intend to learn, if you people help.
First of all, what is “advanced tab of the passthrough driver”???
So, do you mean that only Adapters have advanced tab?
Please note that passthru is a filter, rather than MUX, so that it does not
present itself as an adapter, although it is mentioned under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002b
E10318}
Well, I want to build something similar to MUX. I want to build an LBFO
driver. I started reading passthru as startup. So, if I want to build a
generic LBFO driver, how do i expose the lower level driver’s capabilities
in the advaned tab of a MUX like driver.
AP
On 8/13/07, xxxxx@hotmail.com < xxxxx@hotmail.com
mailto:xxxxx > wrote:
I’ve got a couple of observations…
First of all, what is “advanced tab of the passthrough driver”??? Please
note that passthru is a filter, rather than MUX, so that it does not present
itself as an adapter, although it is mentioned under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE
10318}.
Therefore, bound protocols believe that they are dealing with underlying
adapter - they have no idea about IM filter’s presence, and, hence, one has
to configure underlying adapter, rather than filter…
Second, the very term “advertizing capabilities” does bot apply here -
advertizing miniport capabilities is NDIS 6 feature, but passthru is NDIS 5
filter that registers NDIS 5 miniport.
Anton Bassov
—
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</mailto:xxxxx>
Dear Thomas,
Your mail teaches me a lot.
Say there are two adapters below one by company x another by company y. then
when i install the lbfo driver, it should expose the lowest common
denominator of the two driver’s capabilities. and by capabilities i mean the
ones are MS OID defined.
Is that doable? Also, if it is, I would want that when I set those
parameters from the advanced tab of my driver the corresponding driver
params whould be changed.
ap
On 8/14/07, Thomas F. Divine wrote:
>
> There are several issues here.
>
>
>
> First of all, if your goal is to write a LBFO driver, then your driver
> probably does not depend on the capabilities of the lower-level real
> miniport. Instead, you are going to write a driver that could work with any
> generic miniport. So, don’t worry about the capabilities of the lower-level
> miniport too much.
>
>
>
> Next, the properties that an adapter vendor exposes on the adapter’s
> advanced properties page may, in fact, be vendor-proprietary. Some
> properties may be handled using Microsoft-defined OIDs, etc., but only the
> adapter vendor knows many other of its properties and how to set them on
> that specific vendor’s adapter.
>
>
>
> Going further, LBFO drivers are most often written by the adapter vendor
> themselves. In this case they know all about the private APIs and properties
> of their hardware and can do what you are trying to do very simply.
>
>
>
> I’m trying to say that:
>
>
>
> 1.) An adapter vendor can expose their LBFO driver properties the way
> you are hoping to do very easily.
>
> 2.) You cannot do the same because you do not have the adapter vendor’s
> proprietary information.
>
>
>
> Best to write your LBFO driver to work on generic Ethernet adapter and not
> get bogged down with this (probably) unsolvable problem.
>
>
>
> Thomas F. Divine
>
> http://www.pcasua.com
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *A P
> Sent: Monday, August 13, 2007 12:28 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] ndis passthrough
>
>
>
> Dear Anton/Others,
>
>
> I am a novice in NDIS, infact drivers for that matter. So many of my mails
> would make no sense. But I intend to learn, if you people help.
>
> >First of all, what is “advanced tab of the passthrough driver”???
>
> So, do you mean that only Adapters have advanced tab?
>
> >Please note that passthru is a filter, rather than MUX, so that it does
> not present itself as an adapter, although it is mentioned under
>
> >HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}
>
> Well, I want to build something similar to MUX. I want to build an LBFO
> driver. I started reading passthru as startup. So, if I want to build a
> generic LBFO driver, how do i expose the lower level driver’s capabilities
> in the advaned tab of a MUX like driver.
>
> AP
>
>
>
> On 8/13/07, xxxxx@hotmail.com < xxxxx@hotmail.com> wrote:
>
>
> I’ve got a couple of observations…
>
> First of all, what is “advanced tab of the passthrough driver”??? Please
> note that passthru is a filter, rather than MUX, so that it does not present
> itself as an adapter, although it is mentioned under
> HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}.
>
> Therefore, bound protocols believe that they are dealing with underlying
> adapter - they have no idea about IM filter’s presence, and, hence, one has
> to configure underlying adapter, rather than filter…
>
> Second, the very term “advertizing capabilities” does bot apply here -
> advertizing miniport capabilities is NDIS 6 feature, but passthru is NDIS 5
> filter that registers NDIS 5 miniport.
>
> Anton Bassov
>
>
> —
> 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
>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Monday, August 13, 2007 3:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ndis passthrough
Dear Thomas,
Your mail teaches me a lot.
Say there are two adapters below one by company x another by company y. then
when i install the lbfo driver, it should expose the lowest common
denominator of the two driver’s capabilities. and by capabilities i mean the
ones are MS OID defined.
Is that doable? Also, if it is, I would want that when I set those
parameters from the advanced tab of my driver the corresponding driver
params whould be changed.
[PCAUSA] Don’t think this is doable in the general case.
AFAIK M has no specific requirements for what an adapter vendor is to put on
their Advanced Property page. It is mostly vendor-proprietary. Further, how
they implement the interface between the page and their miniport is mostly
proprietary.
(I think I said this before.)
I don’t think you will be successful unless you work closely with the
adapter vendors.
Thomas F. Divine
ap
On 8/14/07, Thomas F. Divine wrote:
There are several issues here.
First of all, if your goal is to write a LBFO driver, then your driver
probably does not depend on the capabilities of the lower-level real
miniport. Instead, you are going to write a driver that could work with any
generic miniport. So, don’t worry about the capabilities of the lower-level
miniport too much.
Next, the properties that an adapter vendor exposes on the adapter’s
advanced properties page may, in fact, be vendor-proprietary. Some
properties may be handled using Microsoft-defined OIDs, etc., but only the
adapter vendor knows many other of its properties and how to set them on
that specific vendor’s adapter.
Going further, LBFO drivers are most often written by the adapter vendor
themselves. In this case they know all about the private APIs and properties
of their hardware and can do what you are trying to do very simply.
I’m trying to say that:
1.) An adapter vendor can expose their LBFO driver properties the way you
are hoping to do very easily.
2.) You cannot do the same because you do not have the adapter vendor’s
proprietary information.
Best to write your LBFO driver to work on generic Ethernet adapter and not
get bogged down with this (probably) unsolvable problem.
Thomas F. Divine
http://www.pcasua.com
From: xxxxx@lists.osr.com [mailto:
mailto:xxxxx
xxxxx@lists.osr.com] On Behalf Of A P
Sent: Monday, August 13, 2007 12:28 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ndis passthrough
Dear Anton/Others,
I am a novice in NDIS, infact drivers for that matter. So many of my mails
would make no sense. But I intend to learn, if you people help.
>First of all, what is “advanced tab of the passthrough driver”???
So, do you mean that only Adapters have advanced tab?
>Please note that passthru is a filter, rather than MUX, so that it does not
present itself as an adapter, although it is mentioned under
>HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002b
E10318}
Well, I want to build something similar to MUX. I want to build an LBFO
driver. I started reading passthru as startup. So, if I want to build a
generic LBFO driver, how do i expose the lower level driver’s capabilities
in the advaned tab of a MUX like driver.
AP
On 8/13/07, xxxxx@hotmail.com < mailto:xxxxx
xxxxx@hotmail.com> wrote:
I’ve got a couple of observations…
First of all, what is “advanced tab of the passthrough driver”??? Please
note that passthru is a filter, rather than MUX, so that it does not present
itself as an adapter, although it is mentioned under
HKLM\SYSTEM\CurrentControlSet\Control\Class{4D36E972-E325-11CE-BFC1-08002bE
10318}.
Therefore, bound protocols believe that they are dealing with underlying
adapter - they have no idea about IM filter’s presence, and, hence, one has
to configure underlying adapter, rather than filter…
Second, the very term “advertizing capabilities” does bot apply here -
advertizing miniport capabilities is NDIS 6 feature, but passthru is NDIS 5
filter that registers NDIS 5 miniport.
Anton Bassov
—
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
— 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</mailto:xxxxx></mailto:xxxxx>
Albert,
I am a novice in NDIS, infact drivers for that matter.
I am afraid you are not going to like my advice…
If you have no experience in driver development, I would advise you to postpone your project for a while, and start with some simple WDM driver. Although NDIS is pretty much a world on its own,
you still have to know general kernel-mode concepts ( interrupts, DPCs, paged vs nonpaged memory, what can and what cannot be done at what IRQL, etc,etc, etc) in order to write NDIS driver, and it is much easier to learn these concepts while doing “conventional” WDM stuff.
Furthermore, if you want your miniport to be accessible to apps and other non-NDIS components, you have to register a standalone device that exposes a “conventional” dispatch interface, so that
you will have to learn WDM basics anyway…
After you are more or less familiar with general kernel-mode concepts, you can already proceed to NDIS. However, I would not advise you to start right from NDIS IM. Instead, I would advise you to
start with a protocol driver, and then proceed to the miniport one - if you want to write a *good*
NDIS IM, you have to know what makes NDIS tick, and the best way to learn it is to write 2 separate drivers, i.e. protocol and miniport ones. When you learn what NDIS is all about, you can already proceed to IM filters and multiplexers. Otherwise, you are just out of luck. Looking at NDIS IM WDK samples alone is not going to take you anywhere - there are quite a few possibilities that they don’t take into account. For example, you may want to receive a packet and queue or modify it while miniport below relies upon the partial indications - NDIS IM WDK samples don’t show you how to do it, but ndisprot protocol sample gives you an idea what has to be done under these circumstances.
To summarize, get ready to do *a lot* of studies - this is definitely not a couple-of-weeks project, especially in your situation…
Anton Bassov
Anthon, thomas,
I appreciatre all the feedback. yes, I know i have a lot of leg work to do,
and I am prepared to do so. i have already started reading up WDM and NT
driver architecture.
So you guys dn’t worry abt me not liking your advices/rebukes. So ahead
blast me off, it will only make me moer knowledgeable in the end. On my part
I will try not to ask the same repetative questions.
Anthon, you ask me to write a miniport driver and a protocol driver. Are
they doable? I mean, my understanding of protocol driver is something like
TCP, that in itself is a herculean task to accompilsh. And a miniport, isn’t
a miniport closely knit with the device. So how to write a mniport without
an actual device? Kindly help on these points.
regards,
ap
On 8/14/07, xxxxx@hotmail.com wrote:
>
> Albert,
>
> > I am a novice in NDIS, infact drivers for that matter.
>
> I am afraid you are not going to like my advice…
>
> If you have no experience in driver development, I would advise you to
> postpone your project for a while, and start with some simple WDM driver.
> Although NDIS is pretty much a world on its own,
> you still have to know general kernel-mode concepts ( interrupts, DPCs,
> paged vs nonpaged memory, what can and what cannot be done at what IRQL,
> etc,etc, etc) in order to write NDIS driver, and it is much easier to learn
> these concepts while doing “conventional” WDM stuff.
> Furthermore, if you want your miniport to be accessible to apps and other
> non-NDIS components, you have to register a standalone device that exposes a
> “conventional” dispatch interface, so that
> you will have to learn WDM basics anyway…
>
> After you are more or less familiar with general kernel-mode concepts, you
> can already proceed to NDIS. However, I would not advise you to start right
> from NDIS IM. Instead, I would advise you to
> start with a protocol driver, and then proceed to the miniport one - if
> you want to write a good
> NDIS IM, you have to know what makes NDIS tick, and the best way to learn
> it is to write 2 separate drivers, i.e. protocol and miniport ones. When
> you learn what NDIS is all about, you can already proceed to IM filters and
> multiplexers. Otherwise, you are just out of luck. Looking at NDIS IM WDK
> samples alone is not going to take you anywhere - there are quite a few
> possibilities that they don’t take into account. For example, you may want
> to receive a packet and queue or modify it while miniport below relies upon
> the partial indications - NDIS IM WDK samples don’t show you how to do it,
> but ndisprot protocol sample gives you an idea what has to be done under
> these circumstances.
>
> To summarize, get ready to do a lot of studies - this is definitely not
> a couple-of-weeks project, especially in your situation…
>
> Anton Bassov
>
>
>
> —
> 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
>
> Anthon, you ask me to write a miniport driver and a protocol driver. Are
they doable? I mean, my understanding of protocol driver is something like
TCP, that in itself is a herculean task to accompilsh.
And a miniport, isn’t a miniport closely knit with the device. So how to write a mniport without
an actual device?
Check ndisprot and netvmini WDK samples - you will see that things are not as bad as that. Please note that, despite their lack of any practical usefullness, these are fully functional samples, so that they demonstrate the minimum of what protocol and virtual miniport drivers should do…
Anton Bassov
thanks, I will ask further questions once I dig into them.
ap
On 8/14/07, xxxxx@hotmail.com wrote:
>
> > Anthon, you ask me to write a miniport driver and a protocol driver. Are
> > they doable? I mean, my understanding of protocol driver is something
> like
> > TCP, that in itself is a herculean task to accompilsh.
> > And a miniport, isn’t a miniport closely knit with the device. So how
> to write a mniport without
> > an actual device?
>
> Check ndisprot and netvmini WDK samples - you will see that things are not
> as bad as that. Please note that, despite their lack of any practical
> usefullness, these are fully functional samples, so that they demonstrate
> the minimum of what protocol and virtual miniport drivers should do…
>
> Anton Bassov
>
> —
> 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
>