Follow-up to Bill’s “I believe all protocols on Win9x/ME are ndis3”
comment (below) and a bit off the subject: Windows ME requires
“ndis3,ndis4,ndis5” to be declared. Declaring ndis3 alone will be
ignored, even if it’s finds an ndis3 binding partner. This was by
design. See KB Q282778, which speaks about LowerRange; but I believe
the same to be true for both edges. Also see KB Q282757 regarding new
debug capabilities in NetDI for Windows ME.
Bryan
-----Original Message-----
From: Bill McKenzie [mailto:xxxxx@bsquare.com]
Sent: Friday, July 20, 2001 4:40 PM
To: NT Developers Interest List
Subject: [ntdev] Re: passthru driver in win98
Ah, I forgot about that. Actually, I don’t remember exactly how the
bindings got fixed, but we had something come in and straighten all of
the
bindings out after install. I thought it was the netdi.dll, but its
been
over a year since I messed with that, so it might as well be 10 :-).
Also,
I believe all protocols on Win9x/ME are ndis3, (regardless if they
really
are or not), and that was the only type specified for DefUpper. If you
are
only going to use this IM over a particular piece or type of hardware,
then
you can have the miniport expose, and the protocol portion of the IM
only
bind to, a custom interface type so that the IM only binds to that
miniport
or miniport type. This prevents the IM from trying to bind to itself as
well.
Bill M.
-----Original Message-----
From: Bryan Burgin [mailto:xxxxx@microsoft.com]
Sent: Friday, July 20, 2001 5:51 PM
To: NT Developers Interest List
Cc: Bill McKenzie
Subject: RE: [ntdev] Re: passthru driver in win98
The NETLANE.INF (ATMLANE.SYS) file works well because there are no
conflicts
with the upper edge name “atmlane” or the lower edge name “ndisatm”.
Only
one thing presents itself as a binding partner in both cases.
However, in passthru, the upper edge is specified (DefUpper) as
“ndis3,ndis4,ndis5.” This causes the network class installer
(NetDI.dll) to
create bindings that you don’t want – specifically, the original
binding
between the protocols and the existing miniport, causing TCPIP to be
bound
to your miniport and to the existing miniport. The only way I’ve been
able
to resolve this has been to break that binding myself. Writing a
co-installer (actually, a custom NDI procedure) in 9x won’t help because
it
won’t get to veto this binding because it won’t see queries for bindings
that doesn’t seem to involve the IM driver.
Also, you are correct regarding some firewall products, etc, mining the
registry looking for Class=Net drivers to identify miniports and missing
IM
drivers. I can confirm that there is no good solution to this.
Bryan
-----Original Message-----
From: xxxxx@bsquare.com [mailto:xxxxx@bsquare.com]
Sent: Friday, July 20, 2001 11:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: passthru driver in win98
Oops forgot to mention, after deleting the *.bin files you have to copy
your INF file to the INF directory before the bin files are regenerated.
Bill M.
On 07/19/01, “xxxxx@bsquare.com” wrote:
> Actually, building a working NDIS IM driver for 98/ME is the easy
part.
=
> Installing it is the pits; I frankly gave up and offer absolutely no
=
> help in this area…
>
There are a couple of example NDIS IM drivers for Win98/ME. The first
is
the ATMLANE driver and the second is Robert Schlabbach’s RASPPPoE
here:
http://user.cs.tu-berlin.de/~normanb/
If you take the ATMLANE inf and convert it to work with your own
driver,
you are almost there. The one trick is to have the INF or a
coinstaller
delete *.bin from the target machine’s INF directory. The bin files
are
essentially an INF list and are generated, so deleting them will just
cause
the OS to regenerate them the next time it needs them. The ATMLANE
driver
installs automagically because it is already in the list, but your IM
won’t
be. If you don’t delete these bin files and force the OS to recreate
the
INF list, your install will get really screwed up. Figuring this out
the
first time was a total pain in the butt BTW.
There is one really bad thing to be aware of as well. An IM installed
this
way will show up under the NetTrans instead of the Net hive in the
registry. Some older protocols don’t bind by the rules, but rather
walk
the Net hive directly to find miniports to bind too. They will not
bind
to
your IM because of this. We had a huge problem with this as there are
a
large number of third-party protocols that bind this way, especially
firewall products. There isn’t a real good solution to this problem
that
I
am aware of either, except have the vendors fix their broken protocols
to
be NDIS compliant. All of Microsoft’s protocols are correct in this
regard
and will bind to your IM just fine.
Bill M.
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
