@chapter Known Bugs and Limitations
@label[chapter-limitations]

@section General Limitations
@label[section-limitations]

@itemize @bullet
@item Chaos / TCP priority -
The variable @see[net:*network-protocols*][var]
is not respected by all communications functions.
For example, the normal LISP remote-file functions --
including @l(listf), @l(dired), and @l(viewf) --
will always choose the Chaosnet access path (QFILE protocol)
if it is available
(that is, for any host that has a Chaos address).
But note the comments in
Section @ref[section-tcp-chaos-priority], @b(@nameref[section-tcp-chaos-priority]), below.
@item Access path recovery -
If an access path to a remote host is defined but not operative
(e.g., requests time-out),
the software theoretically could ``fail over'' to another available protocol, but
this is not implemented.
@item Hanging/waiting -
some low-level network functions (particularly Chaosnet) can hang in certain run-states
waiting for a reply; the software may fail to time out.
Use @ctrl[@abort] to interrupt the hanging function and retry the operation.
@cindex[aborting hung connections]
@end(itemize)

@section Compatibility with Previous Releases
@label[section-compatibility]

The discussion of obsoleted site file options in
Chapter @ref[chapter-configuration]
describes some limitations to
communications between release 3 and release 4 systems.
This section is intended to clarify these compatibility problems,
and offers some advice on enabling communications from systems
running release 4 to systems running release 3.
All the restrictions documented below apply to TCP/IP software only.

@subsection Combining Release 3 and Release 4 TCP/IP

Many changes to TCP/IP are not downward-compatible.
Severe limitations pertain to Lambda hosts using TCP/IP software
at different system revision levels.
The most important restrictions are as follows:

@enumerate
@item
When booting hosts on the same chassis (e.g., slot 0 and slot 4 on a Lambda-2x2),
and when Lambda TCP/IP is in use (i.e., the loaded site information contains Internet addresses for Lambda hosts),
it is @i(absolutely critical) that all the hosts boot on the same major release.

In other words, you can boot a system's hosts on release 3 or on release 4, but
you cannot boot hosts on the same system on different releases.

With the release of 4.0 software, release 2.0 becomes obsolete, and is no longer supported as such;
however, for the purposes of this discussion, release 2 TCP/IP may be considered compatible with release 3.

The consequences of booting different revisions on the same chassis include
problems with interprocessor communication and packet routing;
for example, remote hosts may contact the wrong host,
and a release 3 host may reject packets forwarded by the release 4 host.
This can cause any number of strange symptoms.

@item
Some networking problems may occur when release 3 and release 4 hosts are
booted on the same network.
Since the release 3 site information contains one Internet address for each host on a chassis,
the release 3 host will not be able to contact a release 4 host with its new address.
Again, this can cause any number of strange symptoms, but
the effects are not as severe as described above.
@end(enumerate)

The best policy is to upgrade every Lambda on your network with release 4 and use the new release at all times.
If for some reason it becomes necessary to boot on a prior release, use the function
@l(si:set-current-band) to designate the prior release band, then initialize the system
at the SDU and use @l(newboot -a) to reboot all processors.
If possible, systems running outdated software should be disconnected from the network temporarily.

Notwithstanding these restrictions, the following sections offer some advice on
handling the occasional requirement for communicating between release 3 and release 4.

As always, customers with provisions for telephone support
should contact GigaMos Customer Service for assistance.

@subsection Release 3 TCP-Only Lambdas
@label[section-tcp-chaos-priority]

In release 3 it was possible to designate Lambdas as ``TCP-only'',
@cindex[TCP-only Lambdas]
meaning that they only had access to the Excelan interface and TCP software.

Release 4 does not support this option.
The new software will regard
any remote host with both a Chaos and Internet address as 
a fully capable host running both protocols.
Since most functions go through Chaosnet by default, a release 4
system would not be able to connect with
a 3.0 TCP-only Lambda that has been assigned a Chaos address.
Of course, it is necessary to give Chaos addresses to the hosts,
for use in interprocessor communications within a chassis.

If all systems are updated with release 4, and if the proper
site file modifications are made,
then compatibility problems will not arise.

But if it becomes necessary, on a temporary basis, to boot
a system on a release 3 band with running site information that defines
it as TCP-only, other release 4 hosts can be told to access the release 3
host via TCP only.
@cindex file access paths
This is done by resetting the file access paths to the release 3 host,
and then forcing a TCP/FTP access path to be created.
The function @l(fs:reset-file-access) causes already-determined file access paths
to be ``forgotten''.
The macro @l(fs:with-ftp-access-only) has been defined for the purpose of
pre-establishing TCP/FTP access paths:

@defmac fs:with-ftp-access-only &rest body
Execute code with only TCP/FTP access paths defined.
@end(defmac)

For example, assume that we're on a release 4 host, trying to transfer files
to/from a release 3 TCP-only host named ``OTHER-HOST''.
The following would define a TCP access path to OTHER-HOST:

@lisp
;;Reset all host access paths
(fs:reset-file-access)
;;Do something with FTP to the release 3 host:
(fs:with-ftp-access-only
  (listf "other-host:~;"))
@end(lisp)

This access path preference would remain in effect until
the next time site information is loaded
(or the system is re-booted).

@subsection Front End TCP-Chaos Servers
@label[section-front-end]

A host which had previously served as a @b(:front-end-tcp-chaos-server)
for Chaos-only Lambdas will not provide this service in release 4.
@cindex[front-end TCP Chaos server]
The release 4 systems, however, will be able to access remote release 3 Chaos-only hosts
provided they have been given Chaos addresses.

@subsection DISK Server

The previous LMI releases of TCP/IP software used a reserved TCP port for
the DISK server; the port has been changed for release 4
to ensure compatibility with the specification.
Unfortunately, this creates an incompatibility between release 4 and earlier releases;
TCP-only hosts running release 2 or 3
will not be able to communicate with the DISK server under release 4,
and vice-versa.
















@c end bugs1