A-15. How do I run NetBIOS over TCP/IP?
NetBIOS over TCP/IP is discussed in RFCs 1001 and 1002.
Assuming you don't need any of the extensions to RFC NetBIOS Microsoft created to make NetBIOS work smoothly in a routed environment (available only in their IP stack), you can choose from a wide variety of commercial vendors. For example, FTP Software's PC/TCP includes RFC NetBIOS support; Performance Technologies has a NetBIOS that runs over packet drivers, as does Accton (LANSoft).
A-16. How do I get my BBS to run over TCP/IP?
First off, let's clarify what we mean by "over TCP/IP." Usually this means "accessible via Telnet." Be aware that doing this will not necessarily work well, since few BBSes have been tested running over TCP/IP. As a result you may experience frequent crashes, or abominable transfer rates. For example, I have seen transfer rates as low as 100 characters/second over a 14.4 Kbps PPP connection which routinely supports 1600 cps transfers with FTP.
This situation might be improved by running an FTP server instead. This could be accomplished for example by running KA9Q in another window under DesQView, or by putting the files on an NFS-mounted drive, then using another machine as the FTP server.
One way to hook up a multi-line BBS is to use a terminal server, and hook up the BBS's serial ports to that. The disadvantage of this is that if your BBS is really big you will need multiple terminal servers which will each have their own domain names and TCP/IP addresses. Confusing.
Brian Clements of Murkworks has a better solution, called BBSnet. It provides a Telnet interface that looks like a FOSSIL driver. The first version runs partly as an NLM; some of the code resides on the server. For info, contact:
BBSnet,MurkWorks, Inc., P.O. Box 631,Potsdam, NY 13676, +1 315 265 4717, info@MurkWorks.com
It has been proposed that we begin to collect some diagrams of working combinations of hardware, drivers, shims, stacks, and applications. I'm game, and have made a start below. If you've got some other exotic configuration that works (or if you've tried one of the configurations below and discovered it doesn't work, drop me a line).
NCSA telnet / DOS Trumpet / POPmail/ PC Gopher III
|
DOS Session
|
Windows 3.1
|
WinPKT
|
Packet driver or Shim
|
DOS
|
Network Adapter
QVT/NET
|
TRUMPET NCSA telbin |
| | |
PKTDRV1 PKTDRVn |
| | |
DOS Session DOS Session Windows Session
+-----------+-----------------+ |
| |
+ |
WINDOWS 3.1 ............. WINDOWS 3.1
| |
| PKTINT(QVT/NET own)
| |
| PKTDRVx
+-------------------------------+
PKTMUX n
|
Packet Driver or SHIM
|
DOS
|
Network Adapter
PC Gopher III NCSA telbin
| |
PKTDRV1 PKTDRVn
| |
DOS Session DOS Session
+-----------+-----------------+
|
+
WINDOWS 3.1
|
|
|
|
+
PKTMUX n
|
CSLIPPER
|
DOS
|
Serial Port
NOVELL
PC Gopher |
III |
| |
DOS Session NETX
| |
Windows 3.1 |
| PDIPX
WINPKT /
\ /
\ /
\ /
\ /
Packet Driver
|
DOS
|
Network Adapter
PC-Gopher III
|
DOS Session
|
Windows 3.1
|
|
Novell |
\ /
NETX WINPKT
\ /
IPXODI ODIPKT
\ /
\ /
|
Link Support Layer
|
ODI driver
|
DOS
|
Network Adapter
PC Gopher
III
| Win QVT/Net
PKTDRV1 |
| |
DOS session Windows 3.1
| |
Windows 3.1 PKTINT (QVT/NET own)
| |
| PKTDRVn
WinPKT |
| | NOVELL
+----------------+ |
| |
| |
PKTMUX n NETX
| |
\ PDIPX
\ |
\ |
\ |
\ |
Packet Driver --------------+
|
DOS
|
Network Adapter
QVT/Net
PC Gopher III NCSA telbin |
| | |
PKTDRV1 ..... PKTDRVn |
| | | |
DOS Session | DOS Session Windows Session
| | | |
+-----------+-----------------+ |
| |
| |
WINDOWS 3.1 .......................WINDOWS 3.1
| |
| PKTINT(QVT/NET own)
| |
| PKTDRVx
| |
| |
| |
+------------------+------------+
|
Novell |
\ /
NETX PKTMUX n (use if >1 TCP/IP app)
\ /
IPXODI ODIPKT
\ /
\ /
|
Link Support Layer
|
ODI driver
|
Network Adapter
PC Eudora Windows Trumpet
\ /
\ /
\ /
\ /
TCPMAN
|
Windows 3.1
|
DOS
|
Serial Port
PC Eudora Windows Trumpet
\ /
\ /
\ /
\ /
Chameleon NEWT
|
Windows v3.1
|
+------------------+
| |
Protocol Manager |
| |
NDIS Mac Driver Serial Port
|
DOS
|
Network Adapter
WinTrump PC Eudora
\ /
\ /
KA9Q \ /
| |
PKTDRV TCPMAN
\ |
\ /
\ /
\ /
\ /
Windows
|
PKTDRV 0x62
|
PKTMUX 2
|
Packet Driver
|
DOS
|
Network Adapter
HGopher
|
|
PC |
Eudora | WinTrumpet
\ | /
\ | /
\ | /
\|/
TCPMAN
|
Windows 3.1
|
WINPKT
|
Packet Driver
|
DOS
|
Network Adapter
A-18. Strange and wonderful configuration files
Robert Clift (clifta@sfu.ca) writes:
I have WinQVT/Net 3.4, PC Gopher III (including NCSA DOS Telnet), KA9Q (gopher and FTP server), and POPMail all running together under Windows over PKTMUX on a 3C503 packet driver (and ehternet card).Here is the stick diagram (yikes!):
Win/QVTNet 3.7 KA9Q Gopher PC POPMail 3.2 PC Gopher III 1.01
on interrupt 65 & FTP Server \ /
\ | \ /
\ | \ /
\ | \ /
\ PKTDRV PKTDRV
\ | /
\ DOS Session DOS Session
\ | /
\ | -------------------
\ | /
Windows 3.1
|
PKINT
|
PKTDRV on Int 65 no listeners set
|
PKTMUX 1.2 with 3 channels
|
Clarkson 3C503 Packet Driver
|
DOS
|
3Com Etherlink II/16 TP
|
Ethernet
Robert Clift (clifta@sfu.ca) continues:
Win/QVTNet must be loaded as the very first Windows application and must be kept operating as long as your are in Windows. It appears that its TCP/IP stack does some strange things when it disconnects and kills access to the actual packet driver.I run PC gopher and POPMail alternatively, so they share one channel which is allocated via PKTDRV before running the application and deallocated after the application is finished (I usually throw in a reset command to PMTMUX as well just to be safe).
To explain what is happening (as best I can since a lot of this came from experimentation):
1. The packet driver is loaded
2. PKTMUX is run over the packet driver in order to multiplex it (in this case three channels).
3. A virtual packet driver is loaded for Win/QVTNet on interrupt 65 and the packet driver is told that it is not to listen for any server requests.
4. PKINT is loaded over top of the virtual packet driver
5. Start Windows and run Win/QVTNet as the first application, it must be kept running throughout the Windows session.
6. Load a virtual packet driver from a DOS session and start KA9Q. I use the following batch file to do this:
c:\network\pktdrv 63 /l h: cd \ net091b c:\network\pktdrv 63 /uu c:\network\pktmux /r7. Load a virtual packet driver and run PC Gopher or POPMail as needed. I use the following batch files for PC Gopher and POPMail respectively:
c:\network\pktdrv 63 h:\goph-cli\gopher /T=h:\goph-cli\text /X=h:\goph-cli\binary c:\network\pktdrv 63 /uu c:\network\pktdrv 66 /c h:\popmail\popmail /noems c:\network\pktdrv 66 /uu8. The only problem seems to be that the NNTP module in Win/QVTNet will not operate correctly if POPMail is operating. Otheriwse it seems to work okay without too many problems.
A-19. How do I get hold of the Packet Driver CD-ROM?
The Packet Driver, WinSock & TCP/IP CD-ROM is available from CDPublishing for $29.95.
CDPublishing, (604)874-1430, (800)333-7565, fax: (604)874-1431 email: info@CDPublishing.com, FTP archive: ftp.CDPublishing.com, Gopher site: gopher.CDPublishing.com, WWW: http://www.CDPublishing.com
A-20. Can I run NetBIOS over TCP/IP on an IP internet? How?
RFC 1001 and 1002 define three types of NetBIOS nodes:
B node technology cannot be used on an IP internet without extensions, since UDP broadcast packets are not forwarded through routers. This is not a problem with use of NetBIOS over IPX/SPX, since in IPX/SPX broadcast packets are forwarded.
However, M and P node technology is not supported by popular TCP/IP implementations such as WFW TCP/IP or FTP's PC/TCP. PC/TCP supports B node technology with extensions such as a broadcast file, host file, or DNS resolution of NetBIOS names. Windows NT uses an LMHOSTS file for resolving names. I have heard that Windows Internet Name Service (WINS) will support P nodes, but have no time frame for this.
According to Chip Sparling of FTP Software:
From what I remember from our discussions of a few years ago, P nodes were only implemented by Ungermann Bass and 3COM (and they required you to use a NetBIOS name resolver which was non-rfc 1001, 1002 compliant), nobody did M node (as far as I remember) and PC-LAN, Lantastic and LanManager used B node. Also, if you did a P or M node it wouldn't be compatible with a B node NetBIOS. We decided that we could give the compatibility and functionality (routability) with a B node plus extensions implementation. So, that's what we did.
Without implementation of M and P node technology, the only way to run over an IP internet is to to implement B node technology with extensions, as FTP Software does in PC/TCP. According to Chip:
One way to handle large numbers of hosts on multiple networks is to use the broadcast file extenstion. Instead of putting specific ip addresses in the broadcast file, use a subnet broadcast address like nnn.nnn.nnn.255. which will cover an entire subnet.
If any other vendors are reading this, I'd love to have information on how *you* implement NetBIOS over TCP/IP, and whether you can operate on an IP internet.
A-21. Does Windows NT support PPP? SLIP?
The "Daytona" release of Windows NT will include support for PPP (client and server) and SLIP (client), both including support for Van Jacobson header compression.
