-------------------------------------------------------------
A special thank-you to all our customers for bearing with us as we
develop these features.  Until we reach BETA level, we will plan
to post our latest work-in-progress to this directory each Friday.
-------------------------------------------------------------
6 October 1998:
	Release version 1.6.0

	This rolls up new features and bug fixes from version 1.5.4
	and later.

	Bug Fixes:
	----------
	1.  rcpd would die if network socket resources were exhausted
	    causing "Connection refused" messages on client rsh's. This
	    condition could occur after a large number of TCP connections
	    had been established and/or terminated in a short period of
	    time.  rsh clients will now block until resources become
	    available or the client times out.

	2.  A buffer overrun problem existed when logging in through PPP
	    using CHAP.

	3.  Building a command line in a user connection profile had a
	    potential buffer overrun.

	4.  A condition existed where if no remote PPP profiles were defined
	    in NVRAM, programs related to PPP would be deleted even
	    if remote PPP profiles were defined in a network booted
	    configuration.  The decision to delete these programs from
	    memory is postponed until after loading the network
	    booted configuration.

	5.  A potential buffer overrun condition existed when parsing
	    an IP address without a trailing slash when one was allowed.
	    This was most visible when manually adding a net route that
	    could have caused the shell to terminate.

	6.  Under heavy network traffic, sometimes tcp connections
	    would get terminated. This is now fixed.

	7.  Stuck port problem fixed which would sometimes cause the 
	    serial ports on the Intelliserver to be stuck in "awaiting 
	    login" or "awaiting semaphore" states.

	8.  Rlogin through radius was having problems if Login-TCP-Port 
	    was specified, this is now fixed.

	9.  Routing bug fixed which would sometimes cause PPP
	    packets to be mis-routed. Bug most likely to appear
	    when RIP is enabled, and effects would be felt most
	    severely during relatively light (!) traffic when only
	    a single PPP link is up. Bug was present on all IntelliServer
	    and PowerRack version since original release.
	   
	10. "Show port __ counts" command fixed: earlier versions
	    under-counted transmit data on PowerRacks.

	11. Intelliserver was getting locked up if a tcp sync packet was
	    sent with dest and src ip addresses same. This was causing us
	    to be vulnerable to LAND attacks. This now fixed. 

	12. For telnet connections Radius TCP_CLEAR and Login_port values 
	    are no longer ignored.

	13. During transperant printing, the last buffer was getting
	    directed to the screen instead to the printer. This is now fixed.

	14. Fix for ethernet hangup (MTU).

	15. Fixed delays caused by nvram locks.

	16. Modem echo and powerrack lockup - Fixed.

	17. Powerrack lockup due to uwarn messages - This will no
	    longer happen.

	18. Filter was not getting attached if autologin and the
	    user is an nvram user. 

	New Features :
	-------------
	1.  Support for ibm3151 term type.

	2.  Radius Retry count and Time parameters can now be configured
	    through menu and shell. By default the radius number of retries
	    and time between retries behaviour is like older versions.
	    The shell commands are :
	    # set radius retrycnt <no of retries for each server>
	    # set radius retrytime <time between retries>
	
	3.  Programmable Password prompt.

	4.  While arping for offnet address, we will continue to do rip
	    as well if RIP is turned on.
	
	5.  Deleting of arp table entries - Two shell commands are given
	    to delete/flush arp table entries.
	       arp flush - deletes all temporary entries
	       arp flush all - deletes all entries including permanent ones.

	6.  arp show with a new option "-n" in which case the hostname
	    is not displayed as part of the arp table.

7 May 1997 :
        This is BETA release 1.5.1i.

        Bug fix :
        1. After rcp for ports with IntelliPrint profile set, the
        flow control status was not correctly restored. This is
        now fixed.


5 May 1997 :
	This is BETA release 1.5.1h.

	Enhancements :
	-------------
	1. pppstat now shows the MTU value configured for the
	interface along with other statistics information.

	2. Support of Path MTU Discovery(RFC1191)
	
	Bug fixes :
	-----------
	1. After exiting from a telnet session, it was taking
	an extra "return" press to get the "connection closed by
	remote host" message and return to the prompt. This has now
	been fixed.

	2. Speeds > 115200 (ifSpeed) and MTU (ifMtu) of slip lines were 
	sometimes shown incorrectly during an SNMP query, this has now been
	fixed.

20 March 1997 :
	This is BETA release 1.5.1g.

	Enhancements :
	-------------
	1. The whodo command now shows the session time, the PPP
	interface(for framed users) and the IP address(framed user
	only). 
	Under the first field "pt-ses" the port number followed
	by the session number is displayed. The next heading is
	day which displays the number of days the session has been
	running. Following day is time under which  hour:minute 
	subfeilds are displayed. The next two feilds are owner and 
	command. For the long user names, the names are truncated
	after 12 characters for display. Truncated names have ".."
	at the end.

	Sample output of whodo command is shown below :

	pt-ses day time  owner         command
	3    0 002 06:18 guest_user1   pppfsm  Incoming PPP, ppp01, 1.1.1.5
	4    0 001 17:18 guest_user22..pppfsm  Incoming PPP, ppp02, 1.1.1.2

	
	Note : Under pt-ses heading the first field(3) indicates that it
	is  port 3, the next feild (0) means it is session 0. The next 
	two fields (002 and 06:18) are the session time, in the first 
	case it says the session has been running for 2 days, 6 hours and 
	18 minutes. Under the command the type of the link(Incoming/Outgoing) 
	and the PPP interface and the IP Address are shown. 
	The second entry is an example of long usernames.

	2. Improved MAC connectivity - workaround for incorrect macPPP
	implementations

	3. Slightly longer wait for radius authentication, we have
	seen some NT implementations of the RADIUS server take longer
	to repond, this was causing us to timeout and retransmit our
	request packet.

	Bug fixes :
	-----------
	1. If more than 64 generic profiles are defined (this is possible
	for a power rack), there was a path where we could fail to get a
	matching profile, this is now fixed.

	2. For long PPP user names(>20), the options profile name was getting
	corrupted(internal data structure), this is now fixed.

	3. For outbound links, IP filters were not attached properly.
	This is fixed with this release.

	4. Address value of 255.255.255.255 in IP Filters  is now
	accepted. 

	
NOTE :
        Release 1.5.1f has been taken out.



10 Jan	1997 :
	This is BETA release 1.5.1e
	Two new nvram variables are introduced in this version of the
	software. We suggest the customers to save a copy of the nvram
	configuration before picking cnx151e/rac151e. We do not 
	anticiapte any problems as such, but it would be good to 
	have a backup.

	New features :

	1. Command (shell and menu) to configure Login prompt string.
	The configuration of login prompt variable falls under the server 
	configuration. If no string is configured, then server name followed 
	by the string "login :" will be sent as login prompt (Like before).
	Login prompt can be configured either through shell command or
	through menu. The shell command is -
	#set server loginps	<login prompt>

	2. Command(shell and menu) to configure User/Shell prompt string.
	User or Shell prompt can now be configured and is part of the
	server configuration. For users with no administrative privilages
	the configured user prompt string is given as the shell prompt
	after login. If no string is configured, then the shell prompt
	is servername followed by "$" sign (Like before).  This has no 
	effect on the admin users, their shell prompt is always servername 
	followed by "#" sign(Like before).
	Shell prompt can be configured either through shell command or
	through menu. The shell command is -
	#set server userps	<user prompt>

5 Dec	1996 :
	This is BETA release 1.5.1d

	New feature :
	------------
	A command  to show the in/out bytes and errors on 
	a given port.

	Usage :
	# show port <portno> counts


	Changes and Bug fixes :
	----------------------
	1. There used to be an occassional telnet panic, this has
	   been fixed with this release.

	2. Upload/download of files with telnet -8 option now works.

	3. Domain name was getting erased when server name was set, this
	   has been fixed with this release.


8 Nov	1996 :
	This is BETA release 1.5.1c

	New feature :
	If the Login Service is Telnet or Rlogin and the host address
	is 255.255.255.255, the user is prompted for the host name/address

	Bug fix :
	If the radius server is down for a long time, the intelliserver
	sometimes would not log radius messages when the radius server
	is restarted, this has now been fixed. 


25 Oct	1996 :
	This is a BETA release 1.5.1b
	Importan note : 
	--------------
	Customers picking this version will have to change the definition
	of CTON Menu-User servie-Type attribute to 90 in the dictionary 
	file for the radius server. This was previously defined to 7.

	This release has the following new features and bug fixes :

	Radius related changes :
	-----------------------
	1. Service-Type attribute 7 is now conformant with the draft-5
	of the RADIUS and it is NAS prompt, i.e shell user with non
	administrative privilages. The CTON Menu-User which was previously
	defined at 7 for Servie-Type is now defined at 90.

	2. Multiple start records were sent each time when the link was 
	renegotiated, this has now been fixed, only one start record is
	sent when the ppp first comes up.

	3. Framed Protol and Framed Address are now sent as part of the
	RADIUS stop records.


	Others :
	--------
	5. Routing problem fixes :
	   Routes to SLIP links are added correctly.
	   Radius routes with subnet bits are added as net routes.
	   Super net masks are now ignored.


	6. IP filters are cleared when the link goes down.

25 September 1996:
	stealth.* - debug version for kernel copyout
	viper.* - debug version for session-time
	dont use these unless support tells you to


20 September 1996:
	The 1.4.3h version was release to prom as 1.5.0.
	The ppp login program now flushes input after
	reading the password.

10 September 1996 :
	This is BETA release 1.4.3h.

	This release supports both RIP-II and RIP-I.
	
	RIP-II configuration :
	See menu/shell help. There are new shell/menu commands to configure 
	the rip version, domain and secret.

	Note :
	Currently only RIP-II broadcast is supported. The shell/menu
	option for version two multicast is ignored and it is considered
	as  broadcast.
	Rip domain : By default the domain is 0.

	New features :
	Arp for other network address is now supported.
	There is now a "show port [port list] counts command.
	This will show the number of bytes in/out a serial port.

	Bug fix :
	while bringing up the 32nd link up when more than 32 generic 
	remote profiles (port = any, user = any, protocol = any) are 
	configured it would fail unable to get a matching profile. This
	has now been fixed.

05 September 1996:
	This is a BETA release 1.4.3g

	IPCP extension for DNS address is present in this release.
	During the ipcp negotiation of DNS addresses, the first entry
	in the nameserver list is returned as the primary DNS server 
	address and the second entry is returned as the secondary DNS 
	server address.

	Note :
	To view/modify the nameserver address list on the intelliserver, 
	use the menu command.  The shell command nameserver does not show 
	the entry number, it just lists the all the nameservers configured
	(max of 4).

28 August 1996:
        Beta Release 1.4.3.f. This version was only necessary for
        users who needed to have the release in prom. Some minor
        tweaking was needed to get the latest release to fit.
        I have not put this on the ftp site as their is no
        difference for users who are netbooting.

22 August 1996:
	This is a BETA release 1.4.3e

	Radius changes :
	----------------
	The following RADIUS  accounting attributes are now supported.
	1. input/output octets
	2. input/output packets for framed users
	3. Negotiated IP address

	Radius Hint :
	When we receive a PPP packet at Login Prompt (inbound only, ex.
	Windows 95) we then send hint to RADIUS server (framed portocol =
	PPP).
	
	Outbound SLIP links :
	--------------------
	1. This is bug fix, previously there was a problem when more than 22
	   outbound SLIP links were configured.

	2. Arp table was not properly updated when proxy arp was enabled
           for outbound SLIP links, this has now been fixed.


19 August 1996:
        Extra comments for init process in whodo output.

8 August 1996:
	This is BETA release 1.4.3c.

	Radius session timeouts are now supported. If a radius
	user has the Session-Timeout attribute the connection
	will be terminated when that time limit expires.

	If a ppp login times out before being successfully completed
	the arp entry for the remote is now cleared.

26 July 1996:
	This is BETA release 1.4.3b. 

	Radius changes :
	----------------
	1. Long usernames
	2. Accounting On record is sent when the intelliserver comes
	   up.
	3. Class-string(if present) is now sent in the accounting packets.
  	   (Limitation : Only Upto 32 characters in the class-string)
	
	whodo and finger changes :
	-------------------------
	If the usernames are longer than 19 characters, these commands
	truncate the names during display. The truncated  names have ".."
	at the end.
       

27 June 1996:

	This is BETA release 1.4.3a. Below is a list of changes.
	

	Programmable PPP Banner :
	-------------------------
	 The PPP banner is sent after the motd when a PPP user logs
	in. There is one banner, same for all users. This is similar to motd 
	and preamble messages with additional programming features. The banner
	configuration form divides the messages into four lines of sixty-five
	columns each.
	The following string have special meaning.
		%i	Interface Address
		%r	Remote address
		%h	Interface name or the intelliserver name
		%n	Remote name or the name of the remote profile.

	To print control character you can see section on motd/preamble of
	the user configuration guide.

	The special strings (if present) in the banner are expanded before 
	displaying to the user. This final string could become longer that 65
	columns, in which case it is truncated to 65th column and a syslog
	message is sent at priority LOG_ERR ( = 3 ). In the worst case senario, 
	the addresses can expand to 15 characters each ( www.xxx.yyy.zzz ),
	the remote name can expand to 30 characters and interface name can
	expand to 14 characters. Here again, the name of the interface
	(intelliserver name) changes only on reboot, and if we take the address 
	to be always 15 character(worst case) long, then only string that will 
	be different for different users will be the remote profile name. 

	To get an idea of what gets displayed to the user, attach a terminal to 
	any one of the ports configured as login byport.When a ppp user id is 
	used for login, the banner message will be printed on the terminal.  
	But, this message could get truncated for some of the uers if any of 
	the special strings expands to more than what is seen for this 
	particular user. 


	SNMP and MIB-II :
	-----------------
	The set/get community names of the agent can be configured now. This can
 	be done either through the menu using the RADIUS/SNMP configuration form
	or through command line functions - 

	#set snmp setcomm <set community_name>
	#set snmp getcomm <get community_name>


	Following are the limitations of the present implementation of MIB-II.

	 1.  The SET requests are permitted only on the system group variables : 
		sysDescr
		sysContact
		sysName
		sysLocation.

	 2.  The EGP group of MIB-II is not supported.

	 3.  Interfaces group (ifTable):
		The ifSpeed variabled shows the value of 0 for the ppp 
		interfaces if the port in the remote profile for that 
		interface is configured as PORT_ANY.

	       The ifLastChange variable is dummy, it always return 00:00:00.

	 4. Snmp Group :
		snmpEnableAuthenTraps is again a dummy, it always returns 2
		(disabled), SET request is not permitted on this variable.

	Radius changes :
	----------------
	Radius accounting packets request authenticator is now calculated
	according to the radius-03 draft specification.

	The request authenticator is a one-way MD5 hash calculated over a
	stream of octets consisting of the -
	Code + Identifier + Length + 16 Zero octets + request attributes +
	shared secret.


4 April 1996:
	Version 1.4.1 fixes the netmask problem in version 1.4.0d
	which was documented under April 2 1996, below.
	
2 April 1996:
	Bug discovered in 1.4.0d: if RADIUS user data base
	for PPP/SLIP user has a netmask value of 255.255.255.255
	(as shown in some sample files) and user logs in
	manually or through a script, the link will not
	come up properly. Workaround is to remove that netmask
	value from the user's RADIUS record: this attribute
	does not actually have any significance to the
	IntelliServer, because routes to networks behind
	user's interface are given using n.n.n.n/n notation.

	This has been fixed in house and should be released
	within a couple days.

	
29 March 1996:
	Fixed a few bugs in the 1.4.0c beta release. Subnet
	masks with Windows NT Radius servers were often being
	sent as 255.255.255.255 in which case we use the default
	subnet mask for the ip address. Problem with pap and
	trumpet winsock fixed.

	Also, new features to ping:
	ping -s address
		for continuous pings 1/second & packet loss
		statistics.
	ping -t address
		for limited "traceroute"-style information.
		(    :-)    )

	Also, RADIUS Accounting ID now consists of 4
	parts: TT.NN.P.S, where N is a sequence number,
	P and S are the port and session, as in older
	versions. TT is a unique number derived from 
	the "time", as determined at IntelliServer
	bootup, using the time service on UDP port 37 
	of the primary accounting host, secondary accounting 
	host, or syslog host (checked in that order).

	To disable this feature, and retain old-style
	ID's,
		add services time udp 0
	(if the time service does not already exist)
	or
		set services time 0
	(if it does).

	If the service is present in the table, and
	has been configured for a non-zero port other
	than 37, that port will be used instead.
	

18 March 1996:
	One customer has reported a security hole which occurs
	when the newly-added auto-PPP-detect feature is used.
	We expect to have this fixed by the end of this week.
	In the meantime, we are still interested in feedback
	from any testing you might have done already, but 
	you might want to put off installing this on a live
	system until the fix is available. (Or, if you are
	already using 1.4.0c you can temporarily disable the
	feature by disabling "auto detect PPP" on the ports.
	(e.g., using command "set port all autoppp disabled" ).

15 March 1996:
	1.4.0.c - Enhancements to more easily support Windows 95
	PPP dial ins. A new field on the port screen called "auto
	detect ppp" allows PPP packets to be detected at the login
	prompt of a "login by port" port. Also fixed a rare bug
	that occurs on Van Jacobson compressed slip or ppp links
	when garbage arrives from the phone line. Caused a warning
	message on the console "soreceive: unknown type".

	When the IntelliServer detects a ppp packet at the login
	prompt it will go into ppp mode and wait for negotiation
	packets from the caller. It will issue a PAP challenge
	to the caller to allow for authentication of the user.
	For Windows 95 users, the userid and password from the dialup
	networking menus, is the PAP id and secret. These values
	should be defined in the IntelliServers non-volatile memory
	or in a RADIUS database on a server. If you enable the
	syslogging feature you will see all of these take place
	when the link comes up.

5 February 1996:
	1.3.2.a - Changed lcp echo replies to conform to latest RFC.
	ShivaPPP (bundled with Personal Edition Netscape) always
	sends echo requests and would shut down the link if it
	received a reply it didn't like.

19 January 1996:
	The version 1.3.1 cnx kernel is now available.
	All radius related files are in the radius subdirectory.
	All iservd related files are in the iservd subdirectory.
	The iservd utility has been upated to version 1.3.5

12 December 1996:
	The file "merit.patches.tar.Z" is a UNIX-
	compressed tar file which contains our
	modifications to the versions of radiusd.c,
	radius.h, and dictionary that were released 
	in Merit's RADIUS 2.4.4 version. These patches
	are needed if you are using the CTON-Argument
	attribute (a Computone-specific extension).
	NOTE: Merit's current version is much later than
	2.4.4! Please consult ftp.merit.edu:/radius/releases
	for the latest versions.

13 December 1995:
	1.3.1b fixes an additional bug in 1.3.1a and
	earlier: Routes to networks behind PPP links
	whose remote addresses are proxy-ARP'ed
	were not being broadcast by RIP but should
	have been. (This bug has been present from
	the "beginning" but was only observed in
	version 1.3.0r and later, when corrections to
	the "split horizon" processing were made.

8 December 1995:
	1.3.1a is designed to fix some routing problems we
	found in 1.3.0 during testing:

	Sometimes RIP was not broadcasting all the routes
	it should have (these being routes that were
	added when PPP connections were added).

	Proxy ARP entries were being created for Remote
	IP addresses corresponding to networks other
	than the local network. Such entries would have
	been generally worthless, since other hosts
	on the local network would not generally be
	expected to send ARP requests for addresses not
	part of the local network. In 1.3.1a these
	entries will not appear.

	In 1.3.0, if you telnetted into the IntelliServer and
	attempted to log in as a user with no administrative
	privileges, you would be denied access, which is 
	intentional, BUT then you would not be able to log
	in as a user WITH such privileges, until you dropped
	the telnet connection and re-connected.

	In 1.3.0, there was a problem during initialization
	if a large number of interfaces (Remote Profiles)
	were defined with IP Filters.

	In 1.3.0, there were some problems with dial-out
	PPP connections: if data from the remote side
	were received during a certain period, the
	Iserver would ignore incoming data. This is
	not expected to have affected inbound connections.

	In 1.3.0, if you were telnetting or rlogging into
	a host and were sending data faster than the host
	could process it, AND he was sending data to the
	IntelliServer, the IntelliServer would drastically
	reduce the rate at which he serviced data from the
	host.

	In 1.3.1, the login names of failed logins (over
	serial ports) will be syslogged at LOG_INFO level.

	in 1.3.0, data sent from the modem before carrier
	was raised (e.g., CONNECT message) were not
	properly flushed for login ports. This could
	sometimes cause the IntelliServer to think
	that user "NNECT" was logging in...

2 November 1995:
	Release candidate 1.3.0 now available in this 
	directory.

	This is almost identical to 1.3.0(r) except for
	some very minor differences (most of whom are 
	moot unless this version is running from PROM),
	and the removal of the letter from the version
	number. 

	This version will be released to production 
	to be available in PROM as soon the documentation
	is complete.

25 October 1995:
	Alpha release cnx 1.3.0(r) information

	Bug fixes:
		Several bugs fixed related to RIP support. Too
		numerious to mention. It you were having any
		problems at all with 1.3.0(p) and RIP, please
		re-evaluate with 1.3.0(r).

		Former versions did not support the RADIUS
		IP-Filter attribute: only the IP filter
		listed in the Remote Profile would
		be used. Now a filter name from RADIUS
		will override the one in the Remote Profile
		but the latter is still used if none is
		specified through RADIUS.

		Adding a route (by any means including
		the "route add" command) now automatically
		deletes any old routes to the same destination.

		Generally better "cleanup" of stale routes
		when PPP/SLIP connections are dropped.

		RIP now supports the RIPCMD_POLL command
		which is like poll, except all routes are
		reported, not just the ones on the "other"
		horizon.

		Rlogin formerly tended to re-use client
		port numbers too soon, rather than
		cycling through the available space.

		Rlogin could sometimes miss "urgent" commands
		if they were sent too soon after the connection
		was established.

	New Feature:

		You can now invoke IntelliServer commands through
		rsh (remote shell) from a network host. Formerly
		only the rsh <servername> cat <port> form could
		be used. HOWEVER...

		...For security reasons, these new commands default
		to disabled, and you have to run a couple commands
		if you want to enable this feature. 

		set rhosts enabled | disabled

			enables or disables this feature

		add rhosts <ip-address>
		delete rhosts <ip-address>

			There is a list of ONE remote host from which you will
			allow remote commands to be run. If there are no hosts
			in the list and rhosts is enabled, you can run remote
			commands from any host.

			The add and delete rhosts commands are for putting
			an ip-address on this list (of one).

			NEAT TRICK: you can enter the ip-address using a
			bit-count to represent a subnet. Otherwise the 
			address is interpreted according to the class it
			appears to be:
				160.77.0.0  would allow any host on network 160.77.0.0
				160.77.1.1  would allow the specific host 160.77.1.1
				160.77.133.0/24 would allow any host with address 
						 160.77.133.1 through 160.77.133.254
	
		The purpose of this is not to replace telnetting into the box
		for doing interactive maintenance, but to make it easier to
		run initialization scripts, etc., from a pre-established host.
		
			
31 August 1995:
	Alpha release cnx 1.3.0(p) information

	(There wasn't any "oh" version, it looks 
	 too much like a "zero").

	Bug fixes:
		Bug fixed in name-resolution code: if a 
		nameserver were defined that could not be
		reached, eventually all name resolution
		would fail for that process. (e.g., if
		repeated pings by name failed because of
		not being able to reach one of the name
		servers, subsequent attempts to ping
		by number would fail too, until the
		user attempting it would log out and in.

		A bug was fixed that would lead sometimes to
		"no command found" messages after a user would
		log in (or, on autologin ports, as soon as
		a user dialed in or turned on his terminal.)
		These users had in fact been properly configured,
		so the message was incorrect.
		The message would appear for a while and then
		the user would be disconnected. There have also
		been reports that some remote PPP/SLIP users would
		be unable to connect on the first try and then
		succeed immediately on the next try: it is possible
		this bug may have caused this problem as well.

		The command help for snmp was formerly incorrect.

		The "set profile iset..." command did not formerly
		work correctly.

		Connection menus for unknown terminal types were
		formerly not working properly.

	Improvements:

		There is a new telnet command-line option that
		determines how carriage return characters are sent.
		This has had no effect on any host connections we have
		tested with, but there have been some reports of
		marginally compliant telnetd implementations for
		which this might help.
		(default)	Return key sends cr, null [This conforms to the RFC]
		-P1 		Return key sends cr only
		-P2		Return key sends cr lf
		-P3		Return key sends lf only.

		Incoming BREAK's are handled by rlogin differently. Formerly,
		if you sent a break from your terminal it would terminate 
		your rlogin session. Now this happens only in binary rlogin
		sessions (-8 argument used); otherwise, the break condition
		ignored. This new treatment parallels the way telnet has 
		worked (see the lower strata of this file for details).

		Formerly the "logger" (which handles RADIUS accounting and
		certain syslogging messages) used a hard-coded service port
		to communicate internally with other processes on the
		IntelliServer; now this is an entry in the "services" table.
		You probably wouldn't ever need to change it, but still...

		When the PPPoption parameter "bring up slip immediately" is
		used with an outbound connection, the IntelliServer will now redial
		and attempt to bring up the connection again if it goes down.
		Former version would only bring up the connection at boot-up
		but would not restart it (except in response to traffic) when
		it went down.

		The effective MRU for all SLIP/CSLIP connections is now 1536;
		formerly it was 1006. (NB this is not a negotiated parameter).

		The effective MTU for all SLIP/CSLIP connections was formerly
		1006, regardless of the value configured in the Remote Profile.
		Now, the value stored in the profile is used, subject to a
		minimum value of 128 and a maximum of 1536. This will allow
		you to restrict our MTU for SLIP and CSLIP clients who are
		unable to support the recommended 1006.

		New feature in selected connection menus. Formerly, the selected
		connection menu displayed the command and arguments/options but 
		there was no provision for anything remotely user-friendly there.
		Now, if the options field contains a # (pound sign), then everything
		after the # is treated as a comment and is displayed in the selected
		connection menu IN LIEU OF THE ACTUAL COMMAND AND ARGUMENTS.
		(This has no effect on the way things are displayed when you are
		using the global command menu, only the selected...)

		Enjoy.

31 July 1995:
	Alpha release cnx 1.3.0(n) information.

	(Note, version 1.3.0(l) is skipped because of
	 possible confusion between l and 1.  Version
	1.3.0(m) was an internal release that was not
	released to the field.)

	Bug fixes:
		Saving configuration to a host from
		the menu screen (brokeon in 1.3.0k)
		now works properly.

		Reverse-TCP compatibility issues raised
		with 1.3.0(k) now addressed by additional
		options (see under "Major Additional Features",
		below).

		1-second delays (introduced in 1.3.0(h) after raising 
		DTR and after carrier is detected is now accurately 
		measured: delays in previous versions could be any 
		amount of time up to a second.

		Changes to TCP stack to optimize resource usage:
		formerly, incoming network traffic consisting
		of very small data packets could consume disproportionate
		memory resources in the server.

		Changes to SLIP module for better resource usage.

		Selections for Output translation under "Port" menu
		screen (and corresponding command) changed.  This
		does not affect the more popular choices, but the
		descriptions of some other selections had not
		reflected the true function.  The new command
		parameters are as follows (the first two are
		generally the only ones used, and are unchanged).

			oxlat disabled
			oxlat nl_crnl	
				(newlines become carriage return-newline)
			oxlat cr_nl
				(carriage return mapped to newline)
			oxlat strip_cr
				(carriage return omitted if in col 0)
			oxlat crnl_crnl
				(insert CR before NL, NL after CR)

		Formerly commands such as "set production disable"
		or "set server aui enable" (instead of "disabled"
		and "enabled", respectively) would either be
		ignored or produce unexpected results.  Now these
		are reported as errors.

		Bogus error message during startup regarding
		"symbols" and "frames" (introduced in 1.3.0(k) )
		no longer appears.

		Since NVRAM users can only have passwords of up
		to 8 significant characters, additional characters
		input are ignored.  So if the password of an
		NVRAM user were "saveawha", he could type 
		"saveawhale" and get in.  This conforms to
		the behaviour of most UNIX systems.

		When querying the RADIUS data base, up to 
		16 characters of password are retained.

	New Features:

		This is a noticable one:  For login ports configured as
		"modem enabled", the login timeout begins as soon as the
		first login prompt is sent.  If the user does not log
		in within one minute, the port is closed (DTR is dropped)
		to hang up the modem.  The behaviour of non-modem ports
		("modem disabled") is unchanged; i.e., the login timeout
		starts as soon as the user enters his user-name.  (Formerly,
		modem ports behaved this way as well...).

		A side effect of this is if you have configured your port
		as a modem port and hang a terminal from it, and the
		terminal is turned on (and wired to supply DCD to the
		port, naturally), and no one logs in, there will be a
		fresh prompt every minute.  This doesn't hurt anything;
		just so you know what to tell the operator who wants
		to know why it's different.

		For incoming PPP/SLIP/CSLIP connections, the criteria
		for finding an unused Remote profile for a user who
		was authenticated through RADIUS have been loosened.
		Here is the new search order; in every case 
		the Remote type has to be "incoming", and the
		protocol has to match the proposed protocol for
		the user (or be "Any").

			Remote with a port number and user name 
			specified, and matching the user name and
			port of this connection.

			Remote with a port number specified (user
			name open) and matching the port ofthis
			connection.

			Remote with a user name specified (port
			unspecified, i.e., "ANY") and matching
			the user for this connection.

			Remote with both user name and port
			unspecified, and one of the following
			conditions:
				Remote Address in Remote is zero, and
				Framed-Address from RADIUS is _not
				255.255.255.254 ("assign from pool")

				Remote Address in Remote is 
				non-zero, and Framed-Address from
				RADIUS _is 255.255.255.254 (assign
				from pool).

			Remote with both user name and port
			unspecified, and 

				Remote Address in Remote is
				non-zero, and Framed-Address from
				RADIUS is _not 255.255.255.254

		The net effect of these changes is that if you
		are configuring most of your users to have an
		address assigned from a pool, and have a few
		users who are assigned their own addresses through
		RADIUS, you can set up _all your Remote profiles
		to have non-zero address as would be required for
		your "255.255.255.254" users.  Users with their
		_own Framed-Addresses from RADIUS may also be
		assigned Remotes from this pool, but in that
		case their _own addresses will override the one
		in the Remote Profile.

		The user name specified in a Remote Profile
		no longer needs to be that of an existing
		NVRAM-defined user.  This means that you can
		specify a user name in the Remote Profile if
		you want to dedicate an interface to a
		particular user, including users defined
		in RADIUS.


	Major Additional Features:

	***	Modem Initialization strings.

		You can now configure a port to send
		an initialization string to an attached
		modem.  The string is sent immediately after
		the port is opened (i.e. raises DTR), before
		the IntelliServer waits for carrier.

		If defined for a port, the initialization string
		is sent even if the port is not configured as
		a modem port, but generally you will only 
		define an initialization string for a port when
		the port _is a modem port.

		The initialization string is sent _every time
		the port is opened; for dial-in ports that means
		after every disconnection, before the IntelliServer
		waits for the next incoming call.

		Also, the initialization string, if defined,
		is sent for _every type of connection, including
		Printer, Reverse-TCP, and dial-out PPP/SLIP, as
		well as Login-by-port.  While you ordinarily will
		only define an initialization string for ports
		supporting dial-in modems, you may use this to
		initialize other types of devices as well.

		New table:

		There is now a table of up to 8 modem-initializer
		strings which you can define:  Each entry consists
		of a name (up to 8 characters) and the initialization
		string itself (up to 58 characters).  There is a new
		menu screen 
			main menu -> admin menu -> Modem Configuration
		and two new commands 
			show modeminit 
			set modeminit <1-8> <name> <string>

		for maintaining this table.

		The name is something you assign for administrative
		purposes. The string is the exact sequence of characters
		you want sent.  To represent control characters in the
		string, use the same syntax as you use for IntelliFeature
		strings: ^M or \r to represent carriage-return, ^J or \n
		to represent line-feeds, for example.  There is no
		implicit newline at the end of the string so if you want
		one you have to put one there.  (Note also if you type
		the backslash from the command shell, you have to use 
		two backslashes to represent one because the backslash is
		special to the shell).

		Suppose you have set up a really simple table by
		doing the commands
			set modeminit 1 hayes AT^M
			set modeminit 2 dumb "AT AT AT AT^M"
		
		How do we get a port to send such a string?  

		Well, there is a new entry in the port menu 
			main menu -> admin menu -> Port -> Configure -> <nn> 
		called 
			Modem Init

		and a new keyword in the port command:
			set port init <initstring>

		If the <initstring> you specify is the name of
		one of entries that are set up in the modem
		table, then the _string for that entry is sent.
		If the <initstring> you specify does not
		match the name of a modem table entry, then
		the IntelliServer assumes you want the string
		itself sent as the initializer.

		The reason for this logic is that you can
		define commonly-used initialization strings
		(which are potentially long and cryptic)
		in a single place (the modem table), and
		then configure the port by specifying the
		modem name.  Alternatively, if you are using
		_lots of different types of modems, or 
		have special needs on a particular type of
		port, you can bypass the table by entering
		the string directly in the port configuration.

	***	Reverse-TCP options:

		When a port is configured for Reverse-TCP (including
		Login-by-port/TCP ports running reverse-TCP sessions), 
		you can now select from among three options, for
		greater interoperability with potential client
		processes.

			Normal	- telnet protocol used (telnet binary
				  if negotiated by client).  If not
				  in binary mode, incoming network
				  data CR-NL sent unchanged.
				  (Version 1.3.0k worked in this fashion,
				  and this is the default now).

			CRNL-CR	- same as above, except that CR-NL
				  sequences from the network are mapped
				  to CR alone.
				  (Versions prior to 1.3.0k work in this
				   fashion).

			Raw	- telnet protocol is not used: a
				  raw tcp connection is used and data
				  is sent end-to-end without any 
				  translation or interpretation.

		To support this feature, there is a new field on the
		menu port screen:
			main menu -> admin menu -> ports ->... 
			the field is called TCP

		and new keywords in the port command, e.g.
			set port 4 tcp normal
			set port 4 tcp crnl_cr
			set port 4 tcp raw
		
		Note this option does _not apply to telnetd sessions
		created when you telnet into the server on the telnet
		well-known port as you do to run a shell or menu
		for maintenance purposes.  In that case, CRNL-CR
		option is assumed (so that DOS telnets do not have
		to be configured as in the notes for 1.3.0(k).


8 June 1995:
	Known bugs/suprises in 1.3.0(k):
		Because of telnetd/ttyd fix listed below,
		DOS telnet clients trying to telnet into
		IntelliServer need to be configured to send
		CR instead of CRLF for the enter key.

		Saving configuration to a host from the
		menu screen does not work properly. Use the
		command line instead.
		
6 June 1995:
	Alpha release cnx 1.3.0k information

	This version now supports RIP.  Here are the details:

	Shell commands for administering the RIP daemon (routed):

	show rip <all>
		Show information about rip daemon and optionally
		whether interfaces are enabled for sending or
		receiving rip packets.

	add rip host <ip address>
		Add this list to the list of rip hosts.

	delete rip host <ip address>
		Remove this host from the list of rip hosts.

	set rip list <accept|reject>
		Specifies whether the list of rip hosts represents
		hosts from which to accept or reject rip packets.

	set rip <enabled|disabled>
		At boot time the rip daemon will check this
		flag and exit if rip is disabled.

	Shell commands for administering interfaces and rip:

	set server rip <none|send|listen|both>
		Whether sending, listening, both, or neither,
		is allowed for rip pkts on ethernet interface.

	set remote <name> rip <none|send|listen|both>
		Whether sending, listening, both, or neither,
		is allowed for rip pkts on this ppp interface.

	There are menus corresponding to the shell commands.

	The rip daemon process will scan for all active interfaces
	and scan for all currently installed routes at 30 second
	intervals. It will broadcast all appropriate routes on all
	interfaces that are configured for such. It will listen on
	all interfaces configured for such and install routes that
	it receives from other routing daemons. The syslog facility
	may be used to trace rip activity (at VERBOSE level).


	Additional Features:

	There is now a way to page output from shell commands.
	For example, if you were to type 
	show remote all
	and you have several remotes configured, the output would
	normally span several screens and formerly there was no way
	to paginate it.  Now you can type
	show remote all |
	and the output will be broken into 23-line pages.  If the | is
	followed by a number, the output will be broken into that many
	lines. 
	After each "page" is displayed, you may hit
		space	to get the next page
		Enter	to get the next line
		INTR	to quit (INTER= interrupt key, e.g. DEL or ^C)
		any other key causes pagination to stop and output
		will be sent continuously as though | hadn't been used.

	Syslogging priority levels have been reorganized according to
	the following guidelines:

	LOG_EMERG	Nothing is sent at this priority or higher

	LOG_CRIT	"Impossible" conditions suggesting software
			bugs or hardware faults; Resource problems or
			other conditions likely to affect multiple
			ports until resolved.

	LOG_ERR		Normal errors, such as could be caused by
			configuration mistakes or other pilot error.

	LOG_WARNING	Unusual conditions which do not necessarily
			indicate a problem, but which may prove 
			informative if there is a problem.

	LOG_NOTICE	Login/Logout events; Bringing up and dropping
			ppp/slip/cslip links; Starting and stopping
			TCP connections; i.e., the "Sacrements": 
			Baptism, Confirmation, Marriage, Communion,
			Exorcism, and Last Rites...

	LOG_INFO	Additional information useful for checking out
			PPP negotiation and RADIUS/ACCOUNTING issues.

	LOG_VERBOSE	Extreme debugging output including data dumps
			of reverse-TCP ports.

	This mainly involved moving some of the more popular PPP
	negotiation to the LOG_INFO level, so that you don't have to
	be running at the LOG_VERBOSE level to get information.  Then
	we moved some of the "milestone" events to the LOG_NOTICE level
	so you don't have to be running at LOG_INFO to see _them...

	Also, the init process now syslogs any failed attempts to 
	execute a process: for example, if you were to configure your
	system without _any inbound remotes defined, the ppp program
	will be deleted on power up.  If a dial-in user PPP user were
	to call in, init would be unable to execute ppp because it
	will have been deleted, so it now will syslog an error.  Formerly
	it would print an error on the system console, but if there
	were no one to see it...

	By popular demand, there is now a way to suppress the login
	prompt for an NVRAM-defined user.  If you simply leave the
	password field blank, the IntelliServer will prompt for a
	password as before.  If you set the password to NOPROMPT ,
	then it will not prompt for one.  Note that this is only
	for NVRAM-defined users.  Some have asked for this in order
	to produce a "startup" user.  Note that by doing it this way,
	you have to _want to make such a user.  It won't happen just
	by your forgetting to configure a password.

	Also, the "IntelliServer Release 1.3.0(k)" banner displayed
	to serial ports at login-time now also includes the port
	number.  Several providers have asked that this be provided
	to assist in troubleshooting.

	Cosmetic Changes:

	The field sizes of many fields in the Remote menu and related
	menus were inconsistent and have been adjusted.

	On the Remote Menu (and corresponding command) the Port
	number was formerly set to "none" on incoming Remotes,
	to mean that this Remote was not resticted to a single
	port.  The word "any" is now used instead.

	Newly-added Remotes now default to Protocol=ANY, instead
	of defaulting to Disabled. (The Type field, inbound/outbound/disabled,
	still defaults to Disabled - no point in starting out disabled in
	two different places).

	When configuing a new Remote using the menu, if you try to leave the
	Interface Address blank, it will insist you fill it in before
	going on.  Formerly you could leave it blank (or 0.0.0.0) and
	it would not complain until you had filled in everything else
	and tried to save it.
	
	Bugs Fixed:
	
	Ports configured as Reverse-TCP or Printer would map
	CR-NL sequences into CR when used with some telnet
	clients.

	The pppfsm process could die if address negotiation were
	disabled but an address negotiation request were received
	from the client (over a PPP link).  This would bring down
	the connection and cause a register dump to appear on the
	console.

	If four nameservers were defined, none would be used and
	name resolution would fail.


	

	
			
		

16 May 1995:
	Alpha release cnx 1.3.0j information

	Some of our Alpha users have reported various bugs
	with 1.3.0(g) and 1.3.0(g), which are addressed in
	this version.  We are presently testing RIP in house,
	but we are not quite ready to release it.  We wanted
	to get _these fixes to you as quickly as possible
	without your having to wait for the RIP changes to
	be tested.

	Version 1.3.0(h) "broke" ports configured as 
	Login-By-Port/TCP (the Login-By-Port half would
	work but not the TCP).  This is fixed in (i).

	DialOUT PPP/SLIP/CSLIP connections did not work
	properly in (g) and (h): problems recognizing modem
	signal transitions, and in getting the gateway
	routes added properly. Problems with routes to
	DialOUT connections being inappropriately _deleted 
	when the link goes down.   - Fixed in (i).

	DialIN PPP/SLIP/CSLIP connections had problems
	adding routes from the gateway table, and the
	pppfsm state machine had a bug which could cause
	unexpected disconnections after a port had
	successfully been brought up.  (I cannot stress
	this enough: the bug we found was serious enough
	to cause a variety of similar symptoms, so you
	should really try this version if you have been
	having _any problems with unexpected ppp 
	disconnections).
	[ Version 1.3.0(i) fixed part of the problem,
	  but not all of it, and so has been removed. ]
	
	When VJ compression was selected short non-TCP
	packets would not be sent properly (e.g. short
	pings).  This may _or _may _not explain some anomalous
	behaviour with links using VJ compression.

	-- I'm not ready to say this version will solve
	_any robustness problems you might be having, but
	I think it should be an improvement.  Please let
	me know one way or t'other. (mikeg@computone.com).
	
20 April 1995:
	Alpha release cnx 1.3.0h information

	Fixes a bug in 1.3.0g, where we would attempt to create
	proxy ARP entries even when the associated pppoption
	record said _not to do proxy ARP.

	NOTE: IF YOU'VE BEEN USING PROXY ARP, MAKE SURE YOUR
	PPPOPTION RECORD HAS PROXY ARP ENABLED BEFORE YOU MOVE
	TO 1.3.0h (WITH EARLIER VERSIONS IT WOULD HAVE WORKED
	"BY ACCIDENT" EVEN IF IT WERE DISABLED THERE).

		There is an additional problem, which will be fixed
		in next release, where we attempt to create proxy
		ARP entries even when the remote IP address is not
		of the same network as the ethernet interface. We
		should of course only create such entries when the
		network portion of the IP address and the ethernet
		IP address match.  For now, disabling proxy arp manually
		in the pppoption record for such interfaces is a workaround.

	Changes to init, to better handle dial in modems:
		For login-by-port, modem=y:

		1-second delay before raising DTR again , after the previous
		session ends. (Guarantees modem will see the disconnect.)
		Incoming data flushed immediately after DCD is seen, and
		before the login prompt is sent (so we won't mistake
		modem garbage for a login).
		1-second delay after DCD comes up, before we send out the
		login message or enable echoing. 
		(To humour modems which haven't _quite come
		out of command mode when they give you carrier.

		Also, formerly the port was configured only after DCD
		was raised, which means that incoming modem garbage
		would be even at the wrong rate and so be even more
		troublesome.

	Syslog messages from pppfsm enhanced to distinguish between
	several types of disconnect, which were previously reported
	using identical messages.

	You will find some hooks present for RIP, but don't try
	to use it yet; we have some internal changes we want to make first.

	We have also discovered several bugs relating to dialout-ppp/slip
	connections, (present also in 1.3.0g and earlier) which are not
	yet corrected, but which will be in the next version.  The common
	factor is that if an outbound connection is terminated in certain
	ways, the port is sometimes unusable thereafter (until the server
	is rebooted).

	Some of you have reported anomalies in dial-in ppp/slip connections
	related to particular client software (e.g. Trumpet Winsock), which
	we will be investigating in-house.  Some customers report that
	reducing the MTU (on the server side; perhaps also on the client side)
	seems to alleviate certain problems.  There are also other anomalies
	where disabling VJ compression seems to help.  If _you find yourself
	seeing anything strange and have to juggle these parameters, send
	me some email. (mikeg@computone.com).

	A essential trick for debugging ppp/slip/cslip connections is
	to enable syslogging on your IntelliServer (LOG_INFO at least)
	and examine the appropriate log files on your syslog host machine.
	If I end up working with you, I'll probably ask you to email them
	to me anyway....
	

21 March 1995:
	Alpha release cnx 1.3.0g information

	Small bug fix to 1.3.0f: When using the RADIUS
	Framed-Address attribute of 255.255.255.254 (assign
	ip address from a pool) we were not properly
	copying the ip address from our NVRAM remote
	interface, so it was coming out as 0.

	Remember, if Framed-Address from RADIUS specifies
	assignment from a pool, then we will choose an unused
	NVRAM Remote record with a non-zero Remote IP address.
	If the Framed-Address from RADIUS specifies an IP
	address, we will choose an unused NVRAM Remote record
	with a 0 (i.e. unspecified) remote address.

	Special Framed-Address values are presently:
	255.255.255.254 - IntelliServer assigns from a pool
	255.255.255.255 - Negotiate (ppp) or Prompt (slip/cslip)
				for remote IP address.


17 March 1995:
	Alpha release cnx 1.3.0f information

		-- oops --

	We accidently built 1.3.0e using some older code modules, which
	did not contain all the 1.3.0d changes; for example, certain 
	routing/gateway features.  This has been corrected with version 
	1.3.0f.  We are sorry for any inconvenience this may have caused.
	Naturally, we've removed 1.3.0e to avoid confusion.

	Additional fixes with 1.3.0f:

	A bug had been introduced with the first 1.3.0 which caused
	ports configured as login-by-port/ReverseTCP (used for bidirectional
	modem access) to work improperly.  Incoming calls would be handled
	properly, but reverse telnet connections for outgoing calls were
	being killed after two seconds.  This is fixed in 1.3.0f.

	Also, a bug had been introduced with 1.3.0 where the ppp
	inactivity timer was not working for dialup connections.
	(This is the one in NVRAM in "remotes".  Dial-out PPP
	connections were working).  That seems to be fixed in
	this version.

16 March 1995:

	Alpha release cnx 1.3.0e information

	Some changes to slightly reduce memory requirements (i.e. 
	will support more sessions.

	Bug fixed in menu: maintaining remotes, formerly would not allow
	remote IP address to be changed.

	First cut at RADIUS accounting support.  Notice there is now
	a field for RADIUS accounting chap secret (distinct from the
	RADIUS chap secret used in login authorization.)  Since 
	the authorization server and accounting could in principle
	be on different machines, one might want to use separate
	secrets.

	Also, presently, the RADIUS accounting server in the reference
	implementation (see below) does _not use the shared secret in 
	the "clients" file to properly form accounting acknowledgements.  
	(The standard is still uncertain whether such acknowledgements 
	should be authenticated.)  So for maximum compatibility, if you 
	leave the accounting chap secret blank, we will not authenticate 
	the acknowledgements.  If your accounting server can be made
	to send authentication, and you use a non-blank chap secret on
	our end, we will only recognize authenticated replies.

	Note this flexibility does _not apply to RADIUS login authentication, 
	which MUST use the shared secret, per standard.

	Our algorithm for sending accounting packets is roughly:

		When a user logs on or exits, we send an accounting request.
		If there are two accounting hosts defined, we will send
			a request to each host.
		We will also send a syslog message of priority LOG_NOTICE
			of the events to the syslog host, if one is defined.
		If we have not received an acknowledgement from an accounting
			host, we will re-try sending that packet after
			2, 4 more, 8 more, 16 more... seconds, continuing until
		We have received replies from the accounting host(s), or
		If after 510 seconds total we are still awaiting a reply from
			one of two accounting hosts, but have received a
			reply from the other, we syslog a warning and
			stop trying to send the packet.  (This only
			applies when you have defined two accounting hosts).
		If after 2000 seconds total we have not received a reply
			from any accounting host, we syslog the information
			at LOG_WARNING level, as well as a warning that the
			accounting host is unresponsive, then we quit
			trying for that packet.

	radius-1.16.tar.Z added!

	This is a compressed tar file with version 1.16 of the RADIUS
	reference implementation, which has somewhat better porting
	information in the Makefile, and (most importantly) contains
	support for RADIUS accounting. Version 1.13 which had formerly
	been in this directory, did not support accounting.
	

3 March 1995:

	Alpha release 1.3.0d

	When a PPP or SLIP link comes up all old routes to
	the remote and thru the interface are deleted and
	new routes are loaded from the gateway table and/or
	the radius database.

	To load a route using the RADIUS database, the Framed-Route attribute
	needs to be set to a string which consists of the destination(s)
	which are to be routed through that interface.  For example, if
	you say Framed-Route = "160.77.0.0 160.78.0.0" and your remote
	IP address is "192.9.200.2" (for example, if in RADIUS you said
	"Framed-Address = 192.9.200.2) then the IntelliServer would
	add the routes
	destination 160.77.0.0 through gateway 192.9.200.2, and
	destination 160.78.0.0 through gateway 192.9.200.2
	

	
	

24 February 1995:

Alpha release cnx 1.3.0c information.

(See also below for 1.3.0b, 1.3.0a, etc)

-->	(Bad news first: known bugs introduced in or still in 1.3.0c:)

	Don't use the menu to add a new remote profile or to modify the
	remote IP address.  This is a new bug; will be fixed in 1.3.0d.

	Don't kill a process from the menu.  This is an old bug and will
	also be fixed in 1.3.0d.

	Version 1.3.0d will offer still more flexibility in setting up
	gateways behind negotiated remote IP addresses in PPP links; 1.3.0c
	only does this if the remote IP address is specified in the Remote
	profile.

-->	(And now the good news; things that are better).

changes from 1.3.0b:
	Impovements in the way dial-in ppp links reconcile information
	in the NVRAM "remote" and "pppoptions" files with information
	passed in RADIUS.  This is a _brief summary.

		(1)	When a ppp/slip/cslip user logs in, any information
			from RADIUS is stored, and the appropriate ppp,
			slip, or cslip process is executed.
		(2)	That process first tries to find a currently
			unassigned "Remote" interface whose configuration
			is consistent with the situation.  Some of the
			requirements are as follows:
			(a)	If the "Remote" interface specifies a port,
				it will only be assigned _that port.
				If it says "none", that means it can be
				assigned to any port.
			(b)	If the "Rempte" interface specifies a user,
				it will only be assigned to _that user,
				otherwise it can be assigned to any user.
			(c)	The type of protocol (PPP/SLIP/CSLIP) and
				and direction (INBOUND) must be match what
				is configured for the user.
			(d)	A more-restrictive "Remote" that can be
				assigned will be in preference to a less
				restrictive one.
			(e)	For RADIUS users who _specify a remote IP
				address, we need to use a "Remote" whose
				remote IP address is set to 0, (i.e., "open").
				For RADIUS users who specify that the remote
				IP shall be assigned from a pool, or for
				NVRAM users, we need to assign a "Remote" 
				whose IP address is non-zero.  
		(3)	Once an appropriate Remote interface has been chosen,
			its settings and those of any associated (NVRAM)
			pppoptions record are used, unless overridden by
			a RADIUS attribute sent for that user.

	Corrections to startup code: formerly the routes for entries in 
	the NVRAM gateway table were added _before the ppp interfaces
	were configured.  Now, the ethernet interface and all ppp interfaces
	("Remotes") with known remote IP addresses are configured first,
	then the gateway table is scanned and routes added.  

		In this current version, since only interfaces with "known"
		remote IP addresses are configured at boot time, gateway 
		entries through yet-to-be-started ppp links to unknown
		remote IP addresses will not be added correctly.  In the next
		version, we will re-scan the NVRAM gateway table for 
		appropriate routes, after any new incoming PPP link has
		been established.  Also, we will support the
		RADIUS "route" attribute, so that gateways behind the
		ppp link can be defined on a user-basis.

	Corrections to the "route add" command: formerly, if you attempted
	to add a route through a gateway unreachable except through an
	existing default route, a new route would be added directing your
	new destination to the default route.  But such a route is superfluous.
	So now we refuse the addition, saying "route exists".  In another
	case, if you attempt to route though a gateway that is the destination
	of an existing gateway route, the normal action is to "eliminate the
	middle man" and route your destination to the existing route's gateway.
	This in itself is fine, but formerly if you added such a route 
	multiple times, duplicate routing table entries would be created.
	This has been fixed in 1.3.0c.

	BIG CHANGE:  Destinations in routes and gateways now may have
	a netmask associated.  This makes it possible, for example, to
	set up a route to a subnetted network behind a ppp interface, or
	in general to set up multiple routes to subnetted networks of different
	size through the same provider.

	The notation is the same as used for IP filters:  After the 
	internet address you put a slash and a number (1-31) which
	indicates how many bits of network address there are.

	192.9.200.0	No subnet mask specified, so the canonical one used:
			255.255.255.0
	192.9.200.0/24	Is the same thing as 192.9.200.0
	192.9.200.0/26	Indicates a class C network which has been split
			into 4 sub networks.
	192.9.200.64/26	Would be one of the other subnetworks.
	192.9.200.64	Would be a host address on an un-subnetted class C

	When routes are displayed (shell "show route" command), routes
	to a network will always show the netmask bit-count even if the
	netmask is the canonical default.  Routes to hosts will not show
	a mask, of course.

	"netstat route" command formerly did not report cached route
	statistics correctly.

		:-)
	Note that 1.3.0c is a little smaller than 1.3.0b which is
	a little smaller than 1.3.0a... That's because bugs take
	up space, and when we remove them... 
		:-)
	
-------------------------------------------------------------
10 February 1995

Alpha release cnx 1.3.0b information.


(See also below for 1.3.0a information, which applies unless
 superceded by something up here)

changes from 1.3.0a:

	"Duplicate Port" menu screen broke on 1.3.0a, fixed on 1.3.0b

	Passwords for RADIUS users were truncated on 1.3.0a, now
	passwords of up to 16 characters can be used for RADIUS
	users; users stored in NVRAM are limited (as in 1.2.X versions)
	to 8 characters.

	PPP/SLIP/CSLIP:
		Different remotes may now use the same interface address.
		(_Not the same "remote ip address", of course).
		The 1.3.0a release forced each "remote" to use a different
		interface address.

		When an inbound PPP user connects on a different
		interface, stale routes through old interfaces are
		removed.

	PROXY ARP SUPPORT ADDED:
		If the remote IP address is numerically on the same
		network as the IntelliServer (ethernet interface)
		then the IntelliServer will perform proxy ARP for
		those addresses.

		In future, we plan to have a "knob" to disable this
		if desired.

	PRESENT ALSO IN 1.3.0a (but we didn't mention)
		Telnet now has several new command-line options.
		Latencies reduced for serial inbound data.
		(show) arp command fixed from 1.2.x versions
		routes now show the interface name
		Now supports ping to local broadcast address.

	OBVIOUS THINGS WE KNOW WE STILL DON'T HAVE BUT ARE WORKING ON:
		Address any BUGS you report...
		RIP support still absent but coming soon...
		Menu "Remote" screen is ugly (but usable)...
			
-------------------------------------------------------------------
3 February 1995

Alpha release cnx 1.3.0a information.

This is an early release of the cnx kernel that allows the use of
RADIUS with PPP.

The scenario is an IntelliServer with perhaps 16 or 32 ports set
up for PPP dialins.

To try this feature proceed as follows -

Define one "remote" for every serial port you wish to use.
On the remote menu screen, fill in a unique local ip address,
fill in the name of the interface, set the interface type to
inbound, and set the protocol to PPP. Leave everything else alone.

On the port menu screen, set the login type to "login by port".

Set up your radius server and user database. Use the menu or
command to configure the address of your radius server on the
IntelliServer.

Configure your client software and dial in.

If you have any trouble, enable the syslog feature by entering
the ip address of your syslog host on the server menu screen.
Set the syslog priority to LOG_VERBOSE on the IntelliServer.
Make sure your /etc/syslog.conf file on your host is configured
correctly for your system.


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


23 December 1994

Seasons Greetings.

This subdirectory contains WORK IN PROGRESS for any brave souls who
want a "heads up" on our RADIUS support prior to our BETA release
in early January.

The BETA release will support RADIUS authentication for dial-in users;
ppp/slip users as well as telnet/rlogin users.
It will support RIP as well, making it possible to put several IntelliServers
on a common rotary.

More details will be in the release notes with the beta...

Now, a little about RADIUS.

RADIUS is a mechanism that allows a "RADIUS server" process running on some
host machine to provide user-password authentication for a "RADIUS client"
which runs on an arbitrary "Network Access Server" (an IntelliServer, for
example).

Currently RADIUS is a draft standard (ietf-radius is the working group),
and the reference implementation of the RADIUS server is by Livingston
Enterprises.  The goal is maximum interoperability among manufacturers,
so Livingston makes its source freely available on their ftp site
(ftp.livingston.com) and you are free to use it subject to proper attribution,
as given in their source code.

They provide the source to this server so you can port it to arbitrary
machines.  Everything they had the last time I looked is in a file
here called radius-1.13.tar.  (But one can always check the Livingston
machine for later things.)  Among the files you will extract from this
tar file is a certain amount of documentation.

In general, you set up a "clients" file that lists the IntelliServers
you want to support, and for each IntelliServer an authorization key.
There is a new command on the IntelliServer: [set|show|help] radius,
and you will specify a primary RADIUS host (where the RADIUS server
will be running) and a CHAP secret, which must match the key you've
given in your clients file.

Then there is a "users" file, where you put each authorized user
and his password and other information about the kind of service
he is to be provided.

--- WARNING:  The IntelliServer kernel version (cnx_radius_alpha)
    sitting in this directory does NOT do radius authentication for
    dial in ppp/slip/cslip clients.  That will be available shortly
    after the holidays.  This one only handles dial-in telnet/rlogin
    or shell clients.

For example, if you want to set up a user named mike with a password
of aloutte and he is to automatically telnet into host hippo, you
would enter into "users":

mike	Password = "aloutte"
	User-Service-Type = Login-User
	Login-Service = Telnet
	Login-Host = hippo

The RADIUS protocol allows for "experimental" attributes, of which we
are using one.  We call it CTON-Argument.  We are also using an undefined
value for User-Service-Type called Menu-User. To implement them, you must
add  lines saying

ATTRIBUTE	CTON-Argument	219	string
VALUE		User-Service-Type	Menu-User	7

to the "dictionary" file.

These numbers (219 and 7) match designations in the IntelliServer kernel, and
since they are not presently adopted in the draft standard they are
subject to change.

The CTON-Argument attribute functions similarly to the Login-Host
argument, except that the entire string is passed exactly to the
IntelliServer (for Login-Host, the name is resolved and only the
Internet address is sent).  Using the CTON-Argument allows you also
to specify Computone-specific command-line arguments to the rlogin or
telnet process.

It is possible to specify multiple sets of Login-Service and Login-Host
(and/or CTON-Argument).  How this is handled depends in the User-Service-Type.
If the User-Service-Type is Login-User, and the port has multiple 
IntelliView screens, when each set of Login-Service/Host/Argument) is 
assigned to a separate screen (similar to defining an nvram-defined user 
as "direct connect".  If the User-Service-Type is Meny-User, then each
screen will get a menu of (up to 8) connections you've defined.

For example, If I were running a WY60 with two IntelliView screens, and
my user entry were:

mike	Password = "aloutte"
	User-Service-Type = Login-User
	Login-Service = Rlogin
	CTON-Argument = "beeper -l root"
	Login-Service = Rlogin
	Login-Host    = bleem
	CTON-Argument = "-8"

Then the first screen would automatically rlogin to host beeper as user 
root; the other would rlogin as mike to host bleem in -8 mode.

If on the other hand, the entry were the same except User-Service-Type
were Menu-User, then each IntelliView screen would see a "selected connection
menu" similar to:

(1)	rlogin beeper -l root
(2)	rlogin 11.11.11.11 -8

On the second line, the internet address of bleem would appear because
it was specified as a Login-Host, and the RADIUS server would have resolved
it to its internet address and passed only the number.
Note that CTON-Argument's and Login-Hosts can be mixed and will be appended
in the order they appear.  Even if all Login-Service's are the same,
you must repeat them in order to separate the description of one session
from another.

Again, this is out here so you can look things over and play with them.
This particular version has _Not_ been throroughly tested and is not
complete (for example, no support for dial-in ppp users through radius, 
no RIP yet, no Proxy ARP...).  

If you have any questions or suggestions, or you find any bugs, please email
at mikeg@computone.com; now would be a good time to know if there are any
problems or if we need to get something else in.

Naturally we will be needing to write _lots_ more documentation, so it
would also be helpful to know which parts were self-explanatory and which
parts are confusing and you need more help.

Thanks,

Mike Gaul



---------------------------------------------------------------------------
This is the old cnx.rev file which contains details about old releases.

Hopefully you can find detail about these problems/features
in the documentation, problem database, and source comments. :-)

Make sure problem database entries refer to the version number!

cnx100		Initial release.

cnx101		Minor bug fixes, release to prom.

cnx110		Added ppp/slip, remote telnet administration.

cnx111		Fixed route add bug, to boot kernel across router.
		Release to prom.

cnx120a		Internal release.

cnx120b		IP filtering, syslog to console.

cnx120e		Fixed panic from unexpected vj packets

cnx120g		Fixed bogus ppp outbound connection from links that
		went down dirty and were still trying to send packets
		over a nonexistant ppp link. (Dorsai, Nicholas Data)

cnx120h		Fixed large ethernet packets (Unique Technologies).
		Added fingerd. (Cloud9)
		Fixed route add problem for ppp interfaces.

cnx120i		Fixed large ethernet packets for Unique (really!:-)
		Fixed insidious bug causing port lockups, missing cd.
		Added 8 bit mode for telnet.

cnx120j		Increases nfiles, nstreams, and nqueues (Dorsai).

cnx120k		Fixed nvram/syslog panic in telnet.
		Fixed rlogin binary file xfer/socket bug (Panix).
		Fixed intelli-profiles.
		Fixed process semaphores.
		Fixed telnet binary mode isig bug.

cnx120l		not used - l easily confused with 1

cnx120m		Fixed port lock up due to buffer starvation.(Roediger)
		(higher charges for smaller buffers)
		Fixed buffer starvation during echo at login prompt.
		Fixed buffer pooling in serial driver interrupt queue.
		Support for 4MB box.
		Remote terminal type for rlogin and telnet.

cnx120n		Fixed bug causing ppp interfaces to become unavailable,
		caused by traffic to a client after the link was down.

cnx120		Beta version n released to manufacturing for proms.
		Production release.

		(The following two were experimental and are removed)
cnx120p		Profiling version with queues command (East Strausburg)
cnx120q		Profiling version with bufwho command (East Strausburg)

cnx121c		An early version of cnx121e, with bug #1 &#5 fixed, but
		with the others remaining. Now obsolete.

cnx121e		As compared to cnx120 (production release) several bug
		fixes: (121a-d were experimental and not released).
		(1)	16-byte streams buffer leak fixed.  Each new
			login could lose a block until none left.
		(2)	Several kernel resources tuned up.
		(3)	Data flushes handled more robustly, to fix
			some "port lock" problems, typically triggered
			by powering down/up "modem" devices, generating
			breaks as well as DSS transitions.
		(4)	DCD transition bug fixed: if DCD toggled too fast
			port might lose track of state.
		(5)	intr key (e.g., DEL) in command shell now
			generates re-prompt.
		(6)	fingerd daemon fixed: old one would die if client
			terminated connection early.  Also re-arranged
			cosmetics.  Also, if you set the service port for
			finger to 0, fingerd won't run (handy to disable it).
		Also, bufwho command removed for production beta (costs
		bandwidth to support).

cnx121f		Added syslog messages to ppp for hourly billing users.
		Now sends message when line is dropped. This version
		will go away as the first 130 beta will have these changes.

cnx121g		Fixed a slow leak in 64 byte streams blocks when there
		was outbound traffic for a ppp link that was down.

cnx121h		Experimental version for General Datacom with a change
		to the PPP negotiation timeout. Will be removed.
		Turned out to be a cabling problem. Discarded.

cnx121i		Changed ttyd to ignore break ints for serial devices that
		generated breaks as a side affect.

cnx121j		Added debug level sysloging to ttyd.
		Fixed a bug introduced around 1.2.1g, where output could
		remain disabled after disconnecting on a modem port.

cnx121k		Turned on KEEPALIVE option on the ttyd socket.
		Added env command to print environment variables.
		Added tty command to print port and session number.
		Fixed bug causing rlogin connection to close when
		connecting to a Sun host - after telneting to an
		IntelliServer then rlogining in to the Sun. (Baud
		rate of 0 on the psuedo tty device caused problem.)
		Removed streams blocks failures caused by p.o.s.t.
		Now send both rarp/bootp for ip address at boot.
		Lowered fifo timeout on uart chip.
		Added more protos to the services table.

cnx121l		not used - l easily confused with 1

cnx121m		Added nameserver, log server, host name, domain name
		to info retrieved via bootp. For compatibility we
		send a standard size request packet for now.

cnx121		Released 1.2.1m to internal testing.

cnx122		Released to ftp site for customer distribution.
		Fixed shell problem with sigint during external
		applications. Fixed arp show command.

cnx123a		Fixed an extremely rare tcp/ip bug involving
		multiple SYNs over slow routes.
		Changed ppp ipcp cflags negotiation to work
		with inconsistent values of the cflag.
		The cflag change was experimental and did not
		work correctly. Version 1.3.0 will modify its
		vj algorithm correctly to support systems that
		require the slot id always be present. (ipcp
		negotiation cflag option = 0).

cnx124		Modification for printing via telnet type client
		to revtcp ports from a VAX machine. This will
		be deprecated and 1.3.0 will have a knob on the
		port screen to toggle end of line processing.

cnx125		This is a release that supports downloading the
		nvram configuration at bootp time for walmart.
		Since 1.3.0 was not ready at the time of the
		Walmart pilot project. Also fixes the netboot
		retry limits.

coming soon to a theatre near you...

cnx130a		rotary support, rip support, radius support.
		Added pppstat all command.
		Can now run ppp,slip,cslip from the command line.
		A user can now be specified as an inbound ppp or
		slip or cslip user.
		Most ppp/slip commands accept either the interface ip
		address, or the interface device name (ppp??), or the
		remote host name for administrative purposes.