
--------------------------------------------------------------------
INTERNET.DOC -- 19980211 -- Email thread on Netware & The Road Ahead
--------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Mon, 4 Sep 1995 20:23:27 GMT
From: NETNEWS@AMERICAN.EDU
Subject: Re: Internet and Netware connectivity.

>What I would like to do is to give access to Internet to about 10 users.
>(I expect for that number to grow.)  By access I meant e-mail, FTP, HTTP,
>telnet.  I would like to do this as seamlessly as possible.
>I would like to know some alternatives to the current setup.  There is
>money to spend but not an unlimited amount.  Lets aim for 3000$ as a
>startup cost.

I am currently testing an evaluation copy of Firefox's Novix for Internet
on our 4.1 Server.  So far it looks great.  It was very simple to
install, it allows you to keep the TCP/IP stack on the server, and
provides security and firewall.  You can get a Windows TCP/IP client
package along with the NLMs or you can buy a "bare bones" NLM package and
run your own Winsock compatiable software (as we are doing).  A 10-user
version of the Novix for Internet product which comes with NLMs and
Client Applications runs for about 2,725.  This will give you Email,
FTP, Telnet, Mosaic, Gopher, and a Newsreader. Check out Firefox's web
page at http://www.firefox.com/.  They have a couple of articles from PC
Week Magazine that give the pros/cons.  It basically says that the
product is a little more expensive than the others, but the security is
great.

Chris Joyce (cjoyce@vt.edu)

---------

Date: Mon, 4 Sep 1995 07:21:00 GMT
From: "Dan L. Parker" <danp@XS4ALL.NL>
Subject: Re: Internet and Netware connectivity.

>I have the interesting task of hooking up our company to the Internet.

>The priority of these services is E-mail most importantly, the FTP and
>Telnet, then HTTP.

>I would like to know some alternatives to the current setup.  There is money
>to spend but not an unlimited amount.  Lets aim for 3000$ as a startup cost.

One way to accomplish this would be to install a communication server
on your network.  This would allow you to attach all of your modems to
the comm server, and everyone on the network that you allow to could
grab a modem and establish a dial-out or fax-out session.  Multi-Tech,
for example, provides software only or software/hardware solutions.
They are located in Mounds View, MN, just outside of Minneapolis.
Their number is 800-328-9717 or 612-785-3500.  Their home page is
http://www.multitech.com/

For software only, ask about the RNGCOM product, if you have an
Ethernet segment, or the ASGTSR for token ring.  This turns an
existing workstation into a comm server.  They also manufacture 8-port
cards for increasing the number of ports.  For hardware/software, they
have the MiniArray, which supports up to 16 modems, or other async
comm devices, such as ISDN or X.25.  Any of these solutions would give
you dial-in, dial-out, fax-in and fax-out over your network.

They also provide a product called WINMCSI, which ships with the comm
server solution, which would allow you to map and unmap workstation
comm ports to the comm server.  For example, you could tell WINCIM,
the Compuserve Windows Information Manager, that there is a modem on
COM 2. Then, use WINMCSI to map COM 2 on the workstation to a port on
the comm server.  Your workstation could then use a modem on the comm
server to dial out to CompuServe and then to the Internet.

If you decide to go with an Internet Service Provider, instead of
CompuServe, you could handle Trumpet Winsock the same way.  Multi-Tech
also provides a 250-user license for their terminal emulation and fax
software, which could run on each workstation for outbound datacom and
fax sessions, or you can use whatever you are using now.  All in all,
it is a very complete package.

-----------------------------

Date: Wed, 7 Feb 1996 01:00:42 -0500
From: John Carter <carter@CVAX.IPFW.INDIANA.EDU>
Subject: bootp and Novell

>I am using Hellsofts bootpd.nlm but ...
>
>If I edit the static list, I need to reload bootpd.nlm and it "forgets"
>all the addresses that it had given out: two devices with same IP address.
>The device that has just asked for an IP address, when rebooted gets the
>same address, which is still in use ...
>
>The problem arises if I have to down the server and is most acute for
>Macintosh users, the Mac holds on to it's IP address when given it unlike
>for example Trumpet which asks each time it is used.
>
>What I need is an NLM that checks that an IP address is not already in use
>before it gives it out: does anyone know of such an NLM or do I have to
>set up a seperate machine.

If you have a problem with the Static address, it is up to watch out when
you switch ip numbers around.  If you turned on the dynamic ip numbering,
then yes that appears to be the one feature that they left out...

No way around that with Hellsofts bootp until each user shuts off their
macine.  If you want to spends some big bucks, On Technology has a
dhcp/bootp server.  We used it for 3 months during beta testing, but when
it was sold to On Tech, the price they were asking (1000.00 for 50 ip
numbers, or 2000.00 for 250 numbers) was to high.

It will do exactly what you want.  It will give out Static or Dynamic IP
numbers and remembers what dynamic numbers it sends out so when you reboot,
it scans the numbers that it thinks it has given out and pings that person
to see if they are still using it.  It is a very reliable program and
works nice with win 95. We only needed it for the 95 people and it was
cheaper for us to setup an NT server for DHCP.

------------------------------

Date: Mon, 12 Feb 1996 17:40:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: TCP with ODI

>Where do I find A TCPODI protocol.
>
>I would like to connect a DOS PC to a TCP/IP Server using VLM's but I
>have no info on TCPODI protocols. Where would I find something that Works.
-------------
	There isn't any such protocol as TCPODI. Let me explain briefly.
ODI is a handler of packets, a multiplexer, to deal with board specifics
by the MLID layer and framing details at the HSM (hardware specific module)
layer, and handing incoming material to the proper application by the LSL.
Ditto for outgoing material. These actions to not create nor change packets.
	VLMs are Novell-specific modules to deal with NetWare Core Protocol
(NCP, have to have acronyms or folks don't take it seriously). At this time
they use IPX for transportation, and IPX can also be carried in UPD/IP packets
for NetWare/IP and IPTunneling.
	TCP/IP is a protocol stack, as is IPX and above. Both can use ODI
if written properly. Some equivalents use NDIS board handlers and others
can use Packet Drivers, etc. My UnixWare machine speaks IPX and TCP/IP; it
uses variants of ODI but not the items you see in DOS clients nor NW servers.
	What you are looking for is a TCP/IP stack which knows how to talk
to ODI handers, and that is independent of the IPX material associated with
VLMs. Novell provides such material with the client shells. MS-DOS Kermit
has its internal TCP/IP stack which also talks directly with ODI handlers.
FTP Software Inc and Beame and Whiteside's TCP/IP stacks can talk to ODI too.
ODI is very popular, for good technical reasons aside from sales and color
of box.
	I recommend you look at Novell's client shells as a starter. Then
also consider the programs mentioned above. You should have a good look at
the list's FAQ for additional hints and advice.
	Joe D.

------------------------------

Date: Fri, 10 May 1996 18:24:56 EST
From: Jayson Agagnier <jaysona@PILS.COM>
Subject: Re: free IP adresses ?

The Internet Assigned Numbers Authority has the following addresses
assigned for private Internet (or "Intranet" if you subscribe to
"buzzword of the day" schemes) setups:

10.0.0.0    -  10.255.255.255
172.16.0.0  -  173.31.255.255
192.168.0.0 -  192.168.255.255

I have included a small excerpt of the RFC below.


3. Private Address Space

The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private networks:

	10.0.0.0        -   10.255.255.255
	172.16.0.0      -   172.31.255.255
	192.168.0.0     -   192.168.255.255

We will refer to the first block as "24-bit block", the second as
"20-bit block, and to the third as "16-bit" block.  Note that the
first block is nothing but a single class A network number, while the
second block is a set of 16 contiguous class B network numbers, and
third block is a set of 255 contiguous class C network numbers.

An enterprise that decides to use IP addresses out of the address
space defined in this document can do so without any coordination
with IANA or an Internet registry.  The address space can thus be
used by many enterprises.  Addresses within this private address
space will only be unique within the enterprise.

As before, any enterprise that needs globally unique address space is
required to obtain such addresses from an Internet registry.  An
enterprise that requests IP addresses for its external connectivity
will never be assigned addresses from the blocks defined above.

In order to use private address space, an enterprise needs to
determine which hosts do not need to have network layer connectivity
outside the enterprise in the foreseeable future.  Such hosts will be
called private hosts, and will use the private address space defined
above.  Private hosts can communicate with all other hosts inside the
enterprise, both public and private.  However, they cannot have IP
connectivity to any external host.  While not having external network
layer connectivity private hosts can still have access to external
services via application layer relays.

All other hosts will be called public and will use globally unique
address space assigned by an Internet Registry.  Public hosts can
communicate with other hosts inside the enterprise both public and
private and can have IP connectivity to external public hosts.
Public hosts do not have connectivity to private hosts of other
enterprises.

Moving a host from private to public or vice versa involves a change
of IP address.

Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses should
not be forwarded across such links.  Routers in networks not using
private address space, especially those of Internet service providers,
are expected to be configured to reject (filter out) routing
information about private networks.  If such a router receives such
information the rejection shall not be treated as a routing protocol
error.

Indirect references to such addresses should be contained within the
enterprise.  Prominent examples of such references are DNS Resource
Records and other information referring to internal private addresses.
In particular, Internet service providers should take measures to
prevent such leakage.


You view a copy of the RFC at the following locations:

http://www.internic.net/rfc/rfc1597.txt
http://www.ctrl-c.liu.se/ftp/doc/rfc/rfc1597.txt

Both sites have a pretty complete listing of all the Request For
Comments issued over the past couple of decades.  Read RFC1000.txt for
more information on RFC's in general.

------------------------------

Date: Mon, 10 Jun 1996 11:13:20 +0000
From: Bjarni µsmundsson <bjarnias@RVK.IS>
Subject: Re: IWARE QUESTION

Yes this is how IWare works, you don't have to add IP to the
workstations.  I have no idea if there is an demo version.
I'm running 100 licence IWare on a NW4.10 server (2 licences).

I intend to have users on 28 NW servers (primary schools) using the
Internet via the IWare server and maybe some users from my network (100
users NW3.11).  I'm just starting to use this and have installed it in
about 10 locations.

You can install the IWare client and you will then run IWare Connect
but you can also just copy the Winsock.dll to  the Windows/System
directory and IWare takes care of the rest!

I'm though having some problems on slower links.  The network is
connected via 64K and 14400 leased lines.  Also I'm having some routing
problems on some of the servers.

------------------------------

Date: Mon, 24 Jun 1996 08:19:57 +0200
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: WAN

>I am planning on connect my two networks in differant building to create
>a WAN using 802.2. Both networks have one 4.1 server running on them.

I would investigate in using one ethernet frame for all traffic, I
don't know if TCP/IP comes into the picture, maybe ethernet_II might
be a better solution. See the FAQ for some more details.

>The networks will be connect so that uses can exchange Groupwise
>E-mail, share a few files a week, and users at one site will access a
>AS/400. The access to the AS/400 will be the main use.

By means of what protocol is the AS/400 reachable, TCP/IP ?

>What thinks do I need to contend with in creating a WAN? How do I limit
>network traffic accross a WAN?

You need:
-   To estimate the amount of traffic across the WAN link, which
    highly depend on the apps involved, large groupware apps arrent
    nice users of precious bandwith most of the time.
    From this estimate you should make a choice for a dedicated link
    or a non-fixed like 1 or mode ISDN connections.
-   To choose a brand of router, some points should lead you to the
    right choice, Initial price is not a good point of selection,
    better points are:
    -   Good support
    -   An established name, see the www sites of Cisco or
	BayNetworks.
    -   Large base of users (so you can ask other users)
    -   Lots and lots of options to tweek. This might be a bit of a
	pain since most people want simple controls, but with this
	equipement you want some more options and areas to tune and
	tweek.
    -   Upgradable operating systems.
-   Establish a naming and numbering scheme, ever heard of the Utah
    standard ?
-   Make a choice in routing protocols: will it be RIP/SAP or NLSP
    for IPX ? Will it be RIP, BGP or OSPF for TCP/IP ?
-   After the link is established you should start filtering RIP/SAP
    traffic using access lists based on a SAP list (see the FAQ).

>What do I need to think about with NDS?

That you pass the two SAP numbers and that you have to tune its
updates via the link.

>How fast of a connection should I use?

See above, investigate your users and your apps.

>What do I need to have at both ends.

A router and a connection to the WAN.

------------------------------

Date: Sun, 30 Jun 1996 13:54:35 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: wan is saturated, is 802.2 better

>>Our (10) 56k WAN links are saturated with ip and ipx traffic,
>>we use ipx for pc's to access netware 3.12 servers on local segments
>>and accross wan links, I am trying to think of ways to reduce wan
>>traffic/improve efficiency, currently 802.3 is frame type used, is
>>802.2 that much better? or should we use tcp/ip for everything and get
>>rid of ipx traffic?
>
>On a WAN I would only use IP and PPP.
>You can allways use IPX encapsulation and route it as IP.
>
>I'm not sure if 3.12 can talk OSPF instead of RIP.
>Please examine if it would benefit you.
>
>As prefered frame I would use Ethernet_II.
>It can handle both IP and IPX and makes IPX checksums possible.
>
>Using only tcp/ip can be prefered, depending on what applications you are
>running (some of them need IPX/SPX/SAP).
>
>Is your network in good health?
>Use the statistics in MONITOR and on the routers to determine
>if there are any mishaps on the WAN.
>
>Arthur B.
---------
	Another tuppence worth. I have dealt with such WAN links and they
were flooded with traffic of all kinds. Frame relay circuits for the most
part here.
	What I recommended was first, put a NW server or other router
between the locals and their WAN link to isolate the local-only traffic
(of which there was a great deal). Do this on both ends of the link.
	Second, change from RIP/SAP to NLSP for IPX routing. It's designed
for these situations, uses considerably less bandwidth than RIP/SAP, and
it is smarter about slow links.
	Third, as Arthur says, use frame Ethernet_II for simplicity and
most applicability. Please do follow Arthur's advice about turning on IPX
checksums.
	Fourth, use Packet Burst and Long Internet Packet (LIP) support on
both ends. That overcomes much of the progagation/queueing delay inherent
in slow links
	Fifth, look at what people are moving across the wire and consider
relocating/duplicating some apps/files for direct local access.
	Where we differ is on encapsulating anything. I recommend don't.
IPX is very similar to UDP/IP traffic, and NetWare/IP uses just that for
Novell work. Decoding/monitoring encapsulated traffic is a nightmare.
Wrapping and unwrapping takes cpu cycles. Nothing is gained by encapsulation
in this circumstance.
	Joe D.

------------------------------

Date: Wed, 28 Aug 1996 15:55:26 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: RE[2]: trying to play net.police

>>>We are trying to charge our students for Internet use and I would
>>>like to ask you for ideas / products on how to do that.
---------
	Here's my thinking on the Internet charging matter.
	If the Internet lines are paid for already but full (normal) then
that's the bottleneck and the natural throttle. Improvments generally come
from a fund affecting everyone on site, since everyone turns out to be the
customers involved. To impose charges to develop free capacity says charging
folks to create empty capacity they can't use.
	If the lines are not yet full then what's the problem?
	If there is a charge per packet or byte or similar then there is
a clear relationship between use and expense, and to a degree (no pun) one
can try to charge back such expenses. Customers might well argue that less
should be charged during sluggish times since their own time is also worth
something.
	To create funds for just using equipment is another more general
matter, rather separate from the Internet. When the equipment and personnel
and software exist already under other funding arrangments, as we expect,
then imposing a tax to use it is double taxation. To pick out some uses
rather than others to be taxed is an assumption of authority not normally
delegated to service units.

	An analogy might be interesting here. Motor vehicle traffic.
	This month I was in two distant countries: England and Egypt.
Traffic in Cairo is anarchy personified. No one paid the least attention to
the few traffic lights and stop signs in town (13M people) nor to idle
traffic wardens on the streets. People drove as fast as they could go.
If a path were too crowded at times then other paths or times were used or
guessed at. Surprizingly it worked very well indeed, and the traffic flowed
smoothly and fast. Folks used the same algorithms to make judgements and
the sharing was distributed down to the individual level, Ethernet style.
Hitting something was bad news because it caused delays and expense, so the
general agreement was to not ding things and pedestrians (who must play by
the rules too); Carrier Sense in action. Expenses were minimized.
	England is installing photo boxes on many traffic lights which take
a picture and send you a traffic ticket in the mail for committing any
number of infractions, all without human intervention. Traffic does move,
at a moderate pace, polite Token Ring style. There is some empty space on
the roads, which must be one of the design criteria. There is a higher
chance of getting through a particular roadway at any time than in Cairo.
Needless to say, this is very expensive but does not make traffic go any
faster. But the system is "highly managed" and therefore "good." I don't
think this was put to a vote.
	So, in one case folks used up all the resource and waited for more
road-width to make things better. In the other queueing was spread all over
by gentle coercion, at substantial financial cost, while minimal service
was assured.
	Joe D.

------------------------------

Date: Fri, 15 Nov 1996 09:41:25 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Ping of Death

There seems to be a rather widespread, and serious, bug in a number of
operating systems handling of received pings.  For those of you supporting
operating systems other than NetWare 4.1, you might want to look at

	http://www.sophist.demon.co.uk/ping/

---------

Date: Fri, 15 Nov 1996 22:35:55 -0500
From: "Charles R. Kelley" <ckelley@mnsinc.com>
To: netw4-l@bgu.edu
Subject: Re: Ping of Death

For those of you using Linux boxes (hey, there might just be some out
there besides me! :)  I heard there was a patch just released to prevent
the system from coming down when someone ping floods you (or whatever
the correct term is).  I beleive, but not positive it is kernel 2.0.25
or so that has this patch.

---------

Date: 18 Nov 1996
From: Floyd Maxwell <floyd@direct.ca>
Subject: Re: Ping of Death
To: Novell FAQ

Executive Summary:

The "bad" packets (can be any IP datagram) are those larger than 65,535
(2^^16-1).  While anything above 65,535 is illegal, if larger packets can
be sent then on reception and reassembly some operating systems will
overflow.

NW 3.11 with TCPIP.NLM v1.01 hangs the IP stack, NW 3.12 with TCPIP.NLM
v2.02 rev 9 seems fine. NW 4.1 is fine. UnixWare is fine. Novell's C32DW
and WfWg3.11 are fine (my own test).

NT 3.51 and NT 4.0 will crash when _sending_ an oversized ping.

---------

Date: Mon, 18 Nov 1996 08:49:55 -0600
From: "Fabio Esquivel" <fesq@sysde.co.cr>
To: netw4-l@bgu.edu
Subject: Re: RE>Ping of Death

>It can also affect non-network-based OS's, such as 3.1, NT, 95 and
>Mac 7.x. Prob others.

I think it's effective on SOME OS for specific versions: I made tests
in the following OS's:
- Linux with kernel 1.3.100: Timeouts, but does not hang or crash
- Win95 (with service pack #1 and kernel updated): Timeouts, but
  does not hang or crash
- WinNT 3.51 (with service pack #3): Sometimes it gives timeouts,
   sometimes it answers correctly to the big ICMP ECHO (ping) packets
   but does not hang or crashes
- AIX: Timeouts, but does not hang or crashes neither.
- CISCO Router 2501: Timeouts also, but does not hang or crash; the
  routing tables do not get affected at all.

------------------------------

Date: Tue, 26 Nov 1996 08:44:28 -0800
From: Donovan Bray <dbray@BASS.CUESTA.CC.CA.US>
Subject: This is a forum for Netware Professionals!

Attn:
	<person 1>
	<person 2>

Gentlemen, whether or not we know everthing, (This list exists solely for
the purpose of educating those who don't), I should expect you to act and
communicate professionally.

If I were a CEO of a company, to which you both were sitting accross a
table discussing this, and treating each other the way you have on this
list.

I'D A FIRED BOTH OF YA!

Now, shake hands, agree to disagree, and lets move on.

If you believe its necessary to continue this discussion do it in private
e-mail.  It benefits nobody by adding this traffic to the list.

This goes for all other would be flamers; If you wouldn't say it in front
of your boss, or your client, then don't say it on this list.

------------------------------

Date: Mon, 17 Feb 1997 15:38:36 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: New TCP/IP from Novell

>I'm having some trouble getting the new TCP/IP from Novell contained
>in TCPN03.EXE to cooperate with me.
>
>Check this..  I read in the install notes that you need to use the /C
>option with the provided installr.bat if your on Netware 3.12, and not
>using MPR.  Thats me.  So I do a
>
>installr /c f:\system
>
>and everything goes well, apparently..
>
>When I try to load TCPIP.NLM, modules TCPSTNV.NLM and TCPCONV.NLM autoload,
>and TCPCONV.NLM croaks with the following output:
>
>ADDCONV.NLM-1.0-3: Unable to read NETINFO.CFG. Further conversion aborted.
>No existing configuration found.
>
>~~~~~~
>several lines about "Loader cannot find public symbol blah blah...
>
>~~~~~~
>Module TCPIP not loaded
---------------
	Well, as best that I can figure out, the people really meant this
for NW 4.x and included NW 3.x as an afterthought. But it can operate on
NW 3.12, as shown below in a cutout from console.log:

Loading module PSERVER.NLM
  NetWare 386 Print Server (950523) PTF
  Version 3.76    May 30, 1995
  Copyright 1995 Novell, Inc.  All rights reserved.
  Auto-loading module NUT.NLM
  NetWare 386 Utility User Interface
  Version 1.13    December 20, 1990
  Copyright 1990 Novell, Inc.  All rights reserved.
Loading module SNMP.NLM
  SNMP Agent
  Version 3.03    January 3, 1996
  Copyright 1992-1996 Novell, Inc.  All rights reserved.
Loading module TCPIP.NLM
  Novell TCP/IP Module (IP0200.B02)
  Version 4.00    February 10, 1997
  Copyright (C) 1991-1996 Novell, Inc.  All Rights Reserved
  Auto-loading module TCPSTCNV.NLM
  MPR 3.0-1 Additional Conversion IP0200.B02
  Version 4.00    February 5, 1997
  Copyright 1996 Novell, Inc.  All rights reserved.
  Auto-loading module CSLCNVRT.NLM
  CSL Conversion
  Version 1.00    January 4, 1996
  (c) Copyright 1991-1996  Novell, Inc.  All Rights Reserved.
  Auto-loading module BTRIEVE.NLM
  Btrieve NLM
  Version 6.10c   November 19, 1993


Btrieve Record Manager
(C) Copyright 1988-1993, Novell Inc.
All Rights Reserved.
  Auto-loading module TCPCONV.NLM
  MPR 3.1 Conversion Utility IP0200.B02
  Version 4.00    February 6, 1997
  Copyright 1995-96 Novell, Inc.  All rights reserved.
ADDCONV.NLM-1.0-3: Unable to read NETINFO.CFG. FUrther conversion aborted.
									  No
exi
sting configuration found.



			    Auto-loading module CSLIND.NLM
  CSL Independence module (IP0200.B02)
  Version 4.00    February 5, 1997
  Copyright (C) 1993-1996 Novell, Inc.  All Rights Reserved
Unable to find load file CSL.NLM
TCPIP-4.0-42: Will NOT act as a router.
				       TCPIP-4.0-27: RIP is disabled.

TCPIP-4.0-6
6: Will use 129.123.1.254 as a default gateway.
					       TCPIP-4.0-112: Bound to board 1
w
ith IP address 129.123.1.44 and mask
				      FF.FF.FF.0.
						 IP LAN protocol bound to
Novell
 NE3200
Loading module RDATE.NLM
  rdate
  Version 1.20    November 24, 1993
  MurkWorks, Inc. (c) 1992,93 All Rights Reserved (315)265-4717
Search 2: [Server Path] SYS:SYSTEM\MERCURY\
RDATE:Will poll server every 60 minutes
RDATE:Trying Host 129.123.1.9
RDATE Error:bind_t:Protocol not availale
RDATE:Trying Host 129.123.1.2
RDATE Error:bind_t:Protocol not availale
RDATE:Trying Host 129.123.1.7
RDATE Error:bind_t:Protocol not availale
RDATE:All hosts failed, retrying in 60 minutes
	etc
--------------
	In this case I am running NFS for NW 3.12. We see a couple of things.
First, the persistent sloppiness about formatting strings. Then there is
the clobbering of RDATE. I cured the RDATE problem by telling it to use
UDP via Rdate's  /U command line switch. Novell seems intent upon blocking
access to the TCP port.
	This machine, netlab2.usu.edu, does not have a hint of INETCFG
material on it, hence no netinfo.cfg. My NW 4 machines do but not NW 3.
	We see one more thing after TCP loads, which is Btrieve is loaded
to get all IP names on your segment for use by SNMP queries. Here that means
the beast consumes about 500KB of server memory for a nearly worthless and
extremely seldom used facility. I have complained about this.
	The idea of TCPN03.EXE is to have one TCP/IP stack for all conditions.
An admirable goal considering the recent profileration of kinds for special
situations.
	Finally, I had one INW 4.11 server crash in this TCPIP.NLM and I
had to rapidly restore the earlier TCPIP.NLM. Another INW 4.11 server is ok
but the traffic on it is minimal. So far netlab2 (NW 3.12) seems to be ok.
	Joe D.

------------------------------

Date: Tue, 8 Apr 1997 15:14:37 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Transmitting and Receiving a packet

>I want to know, in real time, how does an application working
>on the network know the destination terminals socket. Is there a fixed
>list of sockets that NOVELL has declared.

A developers' list might be a more appropriate to discuss this.  In the
meantime, try ftp://ftp.novell.com/pub/updates/napi/prtdcsdk/dsoc1.exe.

---------

Date: Tue, 8 Apr 1997 13:31:06 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Transmitting and Receiving a packet

>I want to know, in real time, how does an application working
>on the network know the destination terminals socket. Is there a fixed
>list of sockets that NOVELL has declared.
-----------
	This is a common situation on networks. There are a limited number
of "well known sockets" which every system is supposed to know. The
reminder are open and should be registered before use. There is no directory
service agent for sockets information. Novell itself is the registrar.
	Joe D.

------------------------------

Date: Mon, 28 Apr 1997 19:59:11 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Q about loading TCP/IP

>I have a question about loading TCP/IP on NW 3.12 (fully patched). I
>was reading the _TCP/IP Transport Supervisor's Guide_ (See - somebody
>actually *DOES* read the Red Books before posting! :-)), and I'm
>unclear about when to use some of the LOAD/BIND options.

	Astounding. I'm delighted to read that.

>Specifics: My network is almost exactly like that of Case 1 in
>Appendix D - Single Network with IPX and IP Nodes.  I have a NW 3.12
>server, an IBM RS/6000 server (Unix host) and a Cabletron Annex
>Terminal Server (another Unix host), all on a single Ethernet
>network.
>
>Clients are almost all IBM PCClones, running Netx/VLMS with Novell's
>TCP/IP stack (or Win95 w/ either MS Client or Client32). Currently,
>the NW server is *NOT* loading IP.
>
>Q: the manual states that, in order to get IP support on this type of
>NW network, I only need to LOAD support for Ethernet_II frames, LOAD
>TCPIP, and BIND - using only the ADDR parameter. Fine; I understand
>so far.
>
>But: why don't I need the GATEWAY and FORWARD parameters as well?
>Are they needed only when crossing different topologies or segments
>(I only have the one segment)? The manual states that if GATEWAY
>is not specified, IP gathers all routing info from RIP. So, in my
>secenario, it's not a requirement? (Does Unix automatically broadcast
>RIP?)

	GATEWAY is the IP address of the machine on your IP wire which
connects to IP places not on the local wire. If you have none then forget it.

>FORWARD makes the NW server route IP packets, correct? Since I won't
>have any other subnets, I won't need this, since I'm not routing
>between networks. Also, in the FAQ, Joe D. advises to specify RIP=NO.
>OK, but why?

	If you don't run IP traffic through the server from one board
to another then don't forward (there isn't a place to forward to/from).
	RIP is evil. RIP listeners believe everything they hear via RIP
and that includes bad info from mal-configured machines and outright lies.
It is as if one believed everything one encountered on NEWS or TV talk shows.
Turn it off and leave it off. To route IP use GATEWAY= which is a static
route for all traffic not on the local wire, and you personally set it
that way forever and ever.
	Ditto on your Unix boxes: don't load routed. Instead define a
default route (equivalent to "gateway=").

>BTW, the reason? I'm evaluating BackupExec, Enterprise Edition, which
>will allow me to backup a Unix host thru a NW server - but only if IP
>is loaded. I'm considering the Enterprise Edition, so I'd have a
>backup method of backup (:-)), in case the tape drive on the RS/6000
>fails (as it has - twice! - in the last 3 months).

	BE is a good product; I use it here. But be careful about that
Unix support (have it here). Right now it appears to be broken for
unknown reasons, though it used to work. That is, the Unix side advertises
as it should, but while the NetWare end hears the packets none is returned
to form a connection. I suspect changes to TCP/IP on the NW servers. And the
guys writing the Unix daemon have no clue about what is a Unix daemon so it
is either loaded all the time by the system startup scripts or it traps you
into keeping a login active while it is run manually. If Seagate is interested
I can turn it into a nice real-daemon, and you may tell them that.
	Joe D.

------------------------------

Date: Wed, 15 Oct 1997 15:38:30 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: TCPIP not routing

>>I'm trying to setup TCPIP to be used with the GroupWise SMTP gateway
>>(GW5). The SMTP gateway can not query my ISP's DNS.  Upon using PING
>>at the gateway(NetWare 4.11) server, I found I can only ping computers
>>in my local LAN and the network attached to the other side of my router.
>>I can't ping any IP address, hence the DNS, outside of that.
>
>Do you have static routing enabled in inetcfg?
>Can you ping outside your router with another server?
>If you can, check the inetcfgs of both servers and see what is different.
>You will need to have static routing enabled for the SMTP anyway.
--------
	Some additional information. Prior to TCPN04.EXE Novell's
TCP stack would lose its default IP route upon every reboot; not always
but in many cases. The quick fix is to Load TCPCON, enter the routes section
and add the default route manually (need enter only the gateway IP number).
This too vanishes upon a reboot.
	The better fix is apply TCPN04a.EXE, use inetcfg to allow static
routes, etc. That should be permanent. It may take some trying because
inetcfg + tcpcon seems to be some kind of intelligence test.
	Please be aware that Novell's TCP/IP material wants to use only
one subnet mask, applicable to all interfaces.
	In the meanwhile, please turn off IP RIP, and OSPF, and IPX NLSP.
None does you any good, and they can make things worse. Use a static IP
gateway address and plain old IPX RIP/SAP.
	Joe D.

------------------------------

Date: Mon, 3 Nov 1997 14:45:01 -0800
From: Brandon Fouts <BrandonF@WSHA.ORG>
Subject: Video over Internet

Video over the Internet

First ask your self WHY.

VCRs are cheap, video tape is cheap, VCR cameras are cheap,
a properly edited video tape is much more informative than
"live broadcasts" and has the advantage of rewind and replay.

Conferences? Have you ever had a conference phone call with
4 or more people? Better yet 3 locations with 2 or more people
at each location. Or try some "chat room" on the Internet.

Not to say you won't find good reasons to try this technology,
but consider the basics first -e.g. What is the problem and what
are possible solutions. And try a pilot first to see if it
works - you can go "rent video conference rooms" (often from
the phone company) and try it on an actual event, not just a
proof of concept - gee it works type of thing.

Many times money spent on content has a much better
pay-off than money spent on "delivery systems". I.E. Make a
video, spend some money having it edited - re-shoot
additional parts to improve on the original tapping etc...

Telephone companies have been trying to give us Video over
the Telephone network for about 30 years now. Someone
may remember the actual details of these historical business
failures. Try to learn from history, and don't just repeat it.
Start with the WHY.

------------------------------

Date: Mon, 26 Jan 1998 15:16:05 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Wan links, packet loss

>>>Turning off packetburst seems to be one solution, however, now you have
>>>your WAN link tied up with lots of packet acknowledgements being sent.
>>>If you have lots of ppl trying to use the WAN at once the ack's can eat
>>>up a good partion of your T1.
>>------
>>
>>        Nah. The link is Full Duplex: 1.544Mbps in each direction. ACKs
>>are tinygrams, consuming very little bandwidth, and they are going in the
>>direction opposite to bulk data.
>>        Joe D.
>
>Joe, I dont mean to nit-pic, but here I go  :)
>
>You assume that there is no data on its way back to the server... which
>may or may not be the case.  Assume the WAN is congested in both
>directions from activity (worst case)
>
>My understanding of not using PB over a WAN is that ACK's are tiny, but if
>you have 20, 30, or however many ppl downloading and uploadind to a server
>you will have lots of ACK's coming in both directions.  If the T1 is
>congested and the ACK's dont make it to their destionation in time packets
>will be re-transmitted and that is just gonna make the congestion worse.
>
>Are you saying that its better to not use PB over a T1?
>
>Sean T. Finney
-------
	Not nits, but basic networking education at work here.
	A client either sends files or receive files, but not both at once.
That's the starting point, and says a client (just one) is essentially a
half duplex device like a human listening to a conversation. The returned
ACKs are indeed tiny (say 64 bytes vs 1500 byte data packets, a 1:23 ratio).
	When we mix many clients together some send, some receive, most do
neither at any given moment. Very often we find most receive, and that is
frequently loading program bits and pieces. Thus traffic is again mostly
unidirectional, from server to client. Even if the traffic were balanced
ACKs packets are tiny in comparision to the packets carrying data.
	When the line becomes congested it is almost always because of
data packets. The reason is the congestion is a fight for buffer space to
hold a packet, more bytes needed for larger packets. The comms box would
have to be pretty stupid to assign max length buffer slots to every packet.
Timeouts result from either a lost ACK or EQUALLY from a lost data packet;
the point being the transmitter gets no ACK, for whatever reason. The more
unidirectional the data transfer the greater the chance that ACKs are going
the other way on a nearly empty reverse channel. Even if ACKs compete with
data going the same way the competition is 4% ACKs to 96% data so it is
data that experiences most loss (an ACK will fit into a relay box buffer
where a big data packet will not).
	Further, Packet Burst sends many many more data packets than ACKs.
That's why it has the name packet burst. A conventional TCP transfer would
have one ACK for every pair of data segments; pburst does not. This further
unbalances the direction of data flow and reduces impact of ACKs.
	To make a case that ACKs clog the net you are going to have to work
really hard to show that max 4% additional load in a statistically chaotic
environment made a signficant difference.
	In essence all I'm doing is counting things here, for each direction.
	Joe D.

------------------------------

Date: Wed, 11 Feb 1998 14:15:00 -0000
From: Robin Bowes <Robin.Bowes@EOC.ORG.UK>
Subject: Re: Mail Server

>1) Is a router necessary ?  How can I connect a modem to the NW4.11
>  file server?
>2) How can you configure your NW4.11 file server if you have another
>  OS/2 Warp 4.0 mail server?

I'm not sure what you are asking, but if you are looking for a cheap
and convenient way to hook up a LAN to the Internet, check out
	http://www.mischler.com/iproute

------------------------------

