TCP/IP components and NDIS interface
ab...@iprolink.ch
TCP/IP package.
I want to write an NDIS MAC driver for use with TCP/IP 2.0, so I read the NDIS
spec (2.01), which was clear and interesting. However, I can't find a
one-to-one correspondence between the elements described in the NDIS spec and
IBM's implementation of TCP/IP for OS/2. Specifically, I would like to know
what each of the items loaded in CONFIG.SYS does. For example, I can see that
Protocol Manager is PROTMAN.OS2. But which exactly is the TCP/IP "protocol
driver"? Is it INET.SYS or IFNDIS.SYS? And, then, what are LANMSGDD.OS2,
cntrl.exe, and LANMSGEX.EXE?
Secondly, which MAC types does the TCP/IP protocol driver support? In other
words, what are the possible values for the "Type name of MAC" field in the
MAC Service-Specific Characteristics table, in order to have the TCP/IP
protocol driver bind to my MAC driver.
Thanks.
Radu Hambasan
ab...@iprolink.ch
Don Poitras
I don't believe the ibm tcpip drivers are documented to the degree of detail
that you would hope for :) You'll probably need to spend some time using
the kernel debbugger to get everything working. Fortunately, it's not
really necessary to know which of the drivers does the work (although
I think it's safe to say that IFNDIS.SYS is the protocol driver). I wrote a
MAC driver that talked to the tcpip protocol driver and used "802.5" as the
mac name. So if you can look like a Token ring card at the top of your
driver, you shouldn't have much trouble. The easiest thing to do is to
set INT 3's at the your entry points and see what the tcpip driver is
trying to do. If you get real ambitious, you can code every ndis call
and be able to talk to _any_ protocol driver (netbios, netware, etc.)
Good Luck.
--
Don Poitras - Network Telemetrics, Inc. 30125 Agoura Road, Suite C
Tel: (818) 597-7900 Fax: (818) 597-7929 Agoura Hills, CA 91301
E-Mail: dpoi...@telemtrx.com ftp://ftp.netcom.com/pub/nt/nti/
CS: 71674,1402 alt: poi...@ibm.net pgp fingerprint: CA 5B C5 FF 6E
E4
finger: ms...@netcom.com (for pgp key) 46 B0 E2 A6 C8 73 1D 40 94
2E
Radu Hambasan
dpoi...@telemtrx.com (Don Poitras) wrote:
>I don't believe the ibm tcpip drivers are documented to the degree of detail
>that you would hope for :) You'll probably need to spend some time using
>the kernel debbugger to get everything working. Fortunately, it's not
>really necessary to know which of the drivers does the work (although
>I think it's safe to say that IFNDIS.SYS is the protocol driver). I wrote a
>MAC driver that talked to the tcpip protocol driver and used "802.5" as the
>mac name. So if you can look like a Token ring card at the top of your
>driver, you shouldn't have much trouble. The easiest thing to do is to
>set INT 3's at the your entry points and see what the tcpip driver is
>trying to do. If you get real ambitious, you can code every ndis call
>and be able to talk to _any_ protocol driver (netbios, netware, etc.)
>Good Luck.
>
Thanks for your reply! Since posting my original question I've discovered that
PC Lube 'n' Tune contains a short Web page on the subject. I quote:
"INET runs as a device driver at Level 0, with full system privileges. It uses
the services of IFNDIS to communicate to the LAN services of OS/2 (the part of
the system based on the NDIS conventions used by IBM and Microsoft in their
LAN architecture)."
I'm curious to know why they use a two-layered architecture (INET/IFNDIS)
without specifying the interface between them..
Simon Bowring
ab...@iprolink.ch (Radu Hambasan) wrote:
> "INET runs as a device driver at Level 0, with full system privileges. It uses
> the services of IFNDIS to communicate to the LAN services of OS/2 (the part of
> the system based on the NDIS conventions used by IBM and Microsoft in their
> LAN architecture)."
>
> I'm curious to know why they use a two-layered architecture (INET/IFNDIS)
> without specifying the interface between them..
My best guess as to the reasons for the two level interface are:
1. The only way to communicate with a LAN card (MAC) driver is via an
NDIS protocol driver, hence IFNDIS is born!
2. Of course tcp/ip can be run across other (non-LAN) devices like slip over
a serial link where the NDIS interface isn't used. (the Warp IAK includes
INET, but not IFNDIS).
3. Given the 16:16/32 bit segmented architecture of OS/2 drivers, there need
be virtually no additional overhead in calling between drivers, PROVIDED,
you use a private interface and a sensible separation of function.
[This is essentially what NDIS is about,it merely standardizes the
"private" interface between MAC and protocol drivers].
Maybe other unrealized potential benifits were also considered, such as
allowing the freedom to implement INET as a daemon or a driver etc.
Regards
Simon Bowring
Radu Hambasan
>1. The only way to communicate with a LAN card (MAC) driver is via an
> NDIS protocol driver, hence IFNDIS is born!
>
>2. Of course tcp/ip can be run across other (non-LAN) devices like slip over
> a serial link where the NDIS interface isn't used. (the Warp IAK includes
> INET, but not IFNDIS).
The funny thing is, I think the NDIS spec was meant to encompass all possible
(well maybe that's pushing it) communication interfaces. For example, a MAC
driver can identify itself as HDLC, ISDN, and several others in addition to
the standard 802.3 or similar. However, IBM doesn't document WHICH of these
MAC drivers its protocol drivers will bind to.
>3. Given the 16:16/32 bit segmented architecture of OS/2 drivers, there need
> be virtually no additional overhead in calling between drivers, PROVIDED,
> you use a private interface and a sensible separation of function.
> [This is essentially what NDIS is about,it merely standardizes the
> "private" interface between MAC and protocol drivers].
>
>Maybe other unrealized potential benifits were also considered, such as
>allowing the freedom to implement INET as a daemon or a driver etc.
>
Probably.. it's too bad that they decided to add a layer of complexity to
something that's IMHO complicated enough. I am otherwise very impressed with
their TCP/IP product, it's not a stripped-down implementation and actually has
sparse documentation for the range of features it provides, if you really look
into it.
They're also gaining an unfair advantage since, if you start SLIP.EXE with the
debug option (-d), you can see that it binds directly to the INET$ driver,
obviously using an unpublished interface. Not possible for third-party
SLIP/PPP drivers. I would like to know what PPP.EXE does exactly, but it has
no -d option.