Problem with NDIS transport driver

Hi,
I have miniport driver which is using NdisMIndicateStatus function to send
some "events" (my own status values) via transport driver into application.
Everything works as long as I don't bridge my connection with any other
network interface using standard Win XP bridge. When my interface is bridged
then transport driver is no longer receving status indications from my
miniport driver. Are they filtered by the bridge driver? Is there a solution
to that or I have to to change the whole mechanism of sending events up from
miniport driver?

Thanks for help
Marcin

bburgin
Thu Aug 19 07:31:55 CDT 2004

------=_NextPart_0001_446F8F62
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


Marcin,

Probably not. Filter IM drivers (a.k.a. PASSTHRU), where there's a 1:1
relationship between protocols and miniports, will generally pass through
status indications even if it doesn't know what the status is (i.e., your
custom status codes). Bridging drivers, because they are sitting over two
miniports, can really only pass up status codes that it understands, and
therefore, yours will be blocked.

You should probably make a private interface between your transport and
miniport.


Bryan S. Burgin
bburgin@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_446F8F62
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20
\par Marcin,
\par
\par Probably not. Filter IM drivers (a.k.a. PASSTHRU), where there's a 1:1 relationship between protocols and miniports, will generally pass through status indications even if it doesn't know what the status is (i.e., your custom status codes). Bridging drivers, because they are sitting over two miniports, can really only pass up status codes that it understands, and therefore, yours will be blocked.
\par
\par You should probably make a private interface between your transport and miniport.
\par
\par
\par Bryan S. Burgin
\par bburgin@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par }
------=_NextPart_0001_446F8F62--

stewo68
Fri Aug 20 03:12:06 CDT 2004

Agreed. Maybe simply add an IOCTL interface to your miniport via
NdisRegisterDevice(), open that device name from your app., and talk
to the miniport via DeviceIoControl().

If you need your miniport to "actively" pass status information to the
app. (rather than being polled), have the IRP pend in the miniport and
complete it when status info is available.

Stephan
---
bburgin@online.microsoft.com ("Bryan S. Burgin [MSFT]") wrote in message news:<PPvyYiehEHA.648@cpmsftngxa10.phx.gbl>...
> Marcin,
>
> Probably not. Filter IM drivers (a.k.a. PASSTHRU), where there's a 1:1
> relationship between protocols and miniports, will generally pass through
> status indications even if it doesn't know what the status is (i.e., your
> custom status codes). Bridging drivers, because they are sitting over two
> miniports, can really only pass up status codes that it understands, and
> therefore, yours will be blocked.
>
> You should probably make a private interface between your transport and
> miniport.
>
>
> Bryan S. Burgin
> bburgin@online.microsoft.com
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> --