home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 36 Tips
/
36-Tips.zip
/
tcpbeui.101
< prev
next >
Wrap
Text File
|
1998-04-29
|
6KB
|
126 lines
#: 63262 S5/TCP/IP
24-Mar-98 17:02:20
Sb: #63253-No TCP/IP OS/2 to NT {20360}
Fm: Les Bell 71210,104
To: Edward Bosco 74156,2430
>> What I'm looking at right now is the incompatibility between
MicroSoft TCP/IP, which uses Netbeui/Netbios over TCP/IP; and
straight TCP/IP, as might be used with ibm.net or cserve. <<
OK, here's TCPBEUI 101:
Microsoft TCP/IP does NOT use NETBIOS over TCP/IP. Right now, I have
two machines on my desktop (NT and 95) which are quite happily using
TCP/IP for web browsing (including to my internal OS/2-based Domino
server), etc. and NETBIOS for access to a Warp Server server. They
are functionally compatible with no problems, except in areas such as
domain logons, public applications, etc. which can be fixed by
downloading the NT/95 clients from the Software Choice website.
NETBIOS is a small and simple LAN transport protocol which uses
broadcast discovery of machine names, rather than some form of
addressing. As a consequence, it is not a routable protocol. This
makes large networks very messy and requires bridges to link remote
sites.
The major applications which use NETBIOS are the various SMB
requesters and servers, such as MS LAN Manager and IBM LAN Server,
and their derivatives like Windows for Workgroups, the Windows 95
"Client for Microsoft Networks", NT Server and the IBM Peer for OS/2.
A few other applications can use NETBIOS as a transport, like Lotus
Notes, DB2 Client Application Enabler, etc. Note: this doesn't mean
that these applications necessarily HAVE to run over NETBIOS - just
that whatever they call beneath themselves has to look, feel and
smell like NETBIOS, and support the NETBIOS API.
TCP/IP by contrast uses addresses which include both a network
portion and a host portion, making routing possible. Thus TCP/IP is
much more suitable for large and geographically distributed networks,
the most obvious example of which is the Internet. We all know TCP/IP
applications: telnet, ftp, SMTP mail programs and of course web
servers & browsers. Whatever is below these apps on your machine had
better look, feel and smell like TCP and UDP.
Realising that lots of people were using NETBIOS systems to share
drives and printers, yet could not easily extend their LANs beyond
the immediate building, some bright sparks came up with the idea of
building something that looked and felt like NETBIOS, yet actually
used IP for its transport. The original idea was to take NETBIOS
packets, stick them into TCP or UDP datagrams and let them be routed
around an internet - but that is NOT actually how it works (it's a
close enough mental model for most purposes, though). In actual fact,
the "NETBIOS over TCP/IP" layer presents a NETBIOS API to the
applications it supports, then generates its own datagrams which are
passed to TCP and UDP for routing via IP - there are no actual
encapsulated NETBIOS packets in the network. For full details, see
RFC's 1001 and 1002.
Now you are able to run NETBIOS applications like the various SMB
servers and requesters, but they can be on separate LANS if the
systems are configured to support NETBIOS over TCP/IP. Notice that
"NETBIOS over TCP/IP" is, in a sense, a TCP/IP application just like
telnet, ftp, etc.
Remember that NETBIOS doesn't use addresses - it uses names, and the
various machines discover the network card MAC addresses that
correspond to the names by doing broadcasts. In the TCP/IP world, you
basically can't broadcast through a router, so this won't work.
Instead, there has to be some method for mapping NETBIOS names to IP
addresses, and this is done either through manual configuration of a
HOSTS or LMHOSTS file, or using a nameserver (not a DNS nameserver -
this is a different animal) called WINS (Windows Internet Naming
Service). This is where the details start to become important for
interoperability of different NETBIOS over TCP/IP implementations -
there are b-node, p-node, h-node and t-node versions (read the RFC's
if you really want to understand this).
Getting down to your specific situation:
Access to Internet applications like mail, web, etc. does NOT require
NETBIOS over TCP/IP. *Lose it* off your Windows systems. In fact,
having it installed exposes you to a security risk - any servers you
run on a NETBIOS over TCP/IP system (shared drives, printers, etc)
are potentially shared over the entire Internet while you are
connected.
You really only want NETBIOS over TCP/IP if a) you intend to share
resources over a MAN or WAN [but there are MAJOR security issues
here] or b) you want to access resources on a UNIX system which
supports an SMB-compatible server like SAMBA (or the reverse - you
want a linux/SAMBA client to access, say, Warp Server shares).
Ensure that in your Control Panel / Network you have configured
TCP/IP->Network Adapter (and NETBEUI->Network Adapter, if you need it
to access local LAN resources) but not TCPBEUI.
Remember that network applications can only talk to each other over
similarly configured stacks; e.g. "Client for Microsoft Networks"
over TCPBEUI over TCP/IP over Ethernet card *cannot* talk to NT
Server over NETBEUI over Ethernet card. Mixing and matching of
protocols takes a little planning.
Now to your basic problem, which is DNS configuration:
In your Win95/NT configuration, open the properties for TCP/IP. **
Make sure that DNS support is enabled, and the correct IP address for
the DNS is in there. ** Go to the WINS Configuration tab and make
sure "Disable WINS resolution" is checked. You don't want that WINS
stuff screwing around with your system.
Make sure that under "Bindings" the "Client for Microsoft Networks"
is *not* bound to TCP/IP (though this probably isn't important, only
misleading, since it can't bind to TCP/IP anyway, only something that
looks like NETBIOS).
Unfortunately, Windows 95 does not have a NSLOOKUP utility, so you
can't use that to diagnose DNS configuration problems (though the NT
nslookup might work - has anybody tried that?). But if you've checked
these settings, and your InJoy configuration is correct (can't help
you there) it should work.
Best,
--- Les (htp://www.lesbell.com.au, lesbell@lesbell.com.au)