hi sir,

I want to build a NDIS IM driver which will support the PPP stack and
TAPI functionlites and bind to underlying ISDN driver. how can I
replace window's NDISWAN driver with this NDIS IM driver. my
understanding the NDISWAN is a 1-to-n MUX dirver with the
functionality of PPP and TAPI inside. can I just replace it without
any change of INF file and underlying miniport WAN driver can
transparently bind with my IM dirver instead of NDISWAN. i know the
ndiswan.sys file is windows file protected as a shipping in-box system
file.
any side impact with this substitution? because I have little
knowledge of NDISWAN and seems it is hard to find any related API or
documents. I am desperately looking for help from your advice and
inputs.

Thanks in advance.



Yiang Han

Email. yiang.han@gmail.com

Writing an IM will let you see the packets going to
NDISWAN, so why do you need to replace NDISWAN, which is a
humongous task.

Bill Tang
Deterministic Networks Inc.

I'm personally not happy about the current PPP implementation in Windows 2000
Server, as the API does not support all the neccessary control of BAP,
accept/reject incoming calls, phonebook maintenance, etc.

I can see why someone is willing to write his/her own PPP stack. And yes,
the task may very well be huge - the question is however: Can the PPP stack
in Windows 2000 Server be replaced by replacing ndiswan.sys, or are there
many more systems involved? Is the interface towards ndiswan.sys documented
anywhere?

/ Hannes.


"Bill Tang" wrote:

This is a great task. You will probably need to also replace all NDISWAN's
miniports - AsyncMac, PPTP, L2TP, ISDN hardware drivers and so on. Probably you
will also need to replace WANARP, by reverse-engineering the existing one
first.

The upper edge interface to NDISWAN is - fake Ethernet packets with
NdisMediumWan media type. The NDIS_WAN_LINE_UP indication is extensively used.

On your place, I would better hack inside TAPI or in between the RAS
service and NDISWAN - lots of undocumented IOCTLs there.

Phonebook does not require replacing NDISWAN or even TAPI components. Just
maintain your own phonebook in your app.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Hannes" <hannes@nospam.nospam> wrote in message
news:41F3D076-3BE7-4D7A-A03C-D95490611E75@microsoft.com...

To be specific, we've had the most trouble on maintaining inbound
connections. MS has informed us that there is no API for configuring and
handling inbound calls.

Next, Windows does not support BAP (bundling) of two calls, if they are two
different directions - as they are handled by two completely separate systems
in Windows. When dialling from Windows to a server, it's not unreasonable for
that server to add bandwidth by dialling us back - but these two calls cannot
be bundled.


Maybe the question should be rephrased:

Is it possible to plug your own PPP stack into Windows, utilizing existing
(third-party) ISDN drivers? If so, where do one start?


Any input greatly appreciated,

/ Hannes.


"Maxim S. Shatskih" wrote:

With reading all documentation on WAN miniports and CoWAN miniports, and a good
amount of reverse-engineering.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

hi Maxim,


Hannes already helped me to clarify my question and the project target.
besides hannes's questions, I need to know:
1. does the WANARP and AsyncMac components essential for PPP Stack?
I know the whole ndiswan is a huge compoment. as a first step, I don't
include the
PPTP and L2TP components. I want to build a PPP stack to support
essential PPP
functionalities like: LCP, Authentication(PAP, CHAP, MS_CHAP_v1), NCP(IP
only) and
PPP multilink. what we want is a traceable and scalable PPP stack to
support WAN
connection and our VoIP application program.
2. The ISDN driver is a third vendor driver and I believe it was developed
following NDIS
WAN miniport prototype. so what I worried is the TAPI and all WAN
specifical control
messages ( IOCTL or OID) between the NDISWAN and ISDN driver, because MS
never
reveals the NDISWAN API to public. if I replace the ndiswan with ours,
that means our
PPP stack and TAPI driver have to provide correspondence IOCTL message to
ISDN
driver as it is not our baby! who know what signal message ISDN need and
It is really
scary!! I had done a experiment to build a coISDN driver to hack out some
TAPI IOCTLs
from ndiswan, but it is not enough.
3. is the NDISWAN a filter IM or 1-to-n MUX IM? looking at the inf file, I
feel it is a MUX IM
driver, but after I talking with MS supporting people, I was told it is
filer IM. what I am doing now is to use the filer IM sample to build a IM
driver to bind with ISDN dirver. can I just change the ISDN driver's
upperrange to a specal value to have it bind with my IM driver. and get rid
of MS ndiswan driver. just to check out what will be happen specially the
control signaling package

Thanks again and looking forward to hear your input soon.

Happy Holiday!


Yiang Han


"Hannes" wrote:

WANARP-yes. It handles most IP-specific stuff in PPP.

AsyncMac is a "PPP over serial" module. It handles the RFC-required byte
escapes (there was an RFC on "PPP over serial"), and also ties together the
serial port driver with NDISWAN.

It is the main PPP core.

The latter one is in user-mode RAS service, which talks to NDISWAN by
undocumented IOCTLs, which allow the service to read/write the LCP data.

The particular auth protocols are implemented as DLLs loaded by the RAS
service, and they are IIRC documented.

Is it CoNDIS WAN or old-style NDIS WAN miniport?

CoNDIS WAN miniports use the connection-oriented facilities in new NDIS to
respond to incoming calls and to make the call. NDPROXY.SYS links them to TAPI.

Old-style NDIS WAN miniports use special set of OIDs for the same tasks.
NDISTAPI.STS links them to TAPI.

Read MSDN Library for "NDPROXY", there was a detailed article on how the call
establishment is made inside the CoNDIS WAN stack.

1-to-N.

On its upper edge, there is 1 and only 1 adapter, but several "lines".
Conceptually it is kinda "virtual Ethernet" network with 1 local adapter and
each another PPP link considered to be yet another remote adapter.

Upper edge of NDISWAN behaves as following:
- the media type is NdisMediumWan
- the packet format is Ethernet, with fake MAC addresses - on 32bit Windows,
they hold the pointers to some structures internal to NDISWAN and WANARP.
Nevertheless, they can be used for comparisons on == or != and thus
identification.
- the NDISWAN's client (be it WANARP or your own filter IM) can transmit the
packets only after it got NDIS_WAN_LINE_UP status indication. Among other
fields, the indication contains the destination MAC address for which the
client must send the packets, and also the IP addressing data negotiated via
IPCP. The client must IIRC invent the local MAC address and return it via the
same indication structure. This address will be later used for packet delivery
to the client.

This stuff allows the Ethernet IM filters to run nearly unchanged on PPP.

I don't think the notions of "filter" and "mux" are applicable to NDISWAN, it
is too complex and non-trivial.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com