1. A blank service name, in the static services table, caused IPXRTR to
enter the debugger after a Reinitialize System command.
2. The bind to a WAN board failed on an AppleTalk nonextended network when transitional routing was turned on.
3. If a DTR dial failed once, PPPTSM did not retry the call and the user
had to disconnect the call through the call manager.
4. IPXRTR could crash, if a broadcast message was received on the internal network while Mobile IPX was enabled.
5. IPXRTR could crash if a corrupted packet was received on a WAN in which IPX header compression had been negotiated.
6. The MPR configuration and management utilities would abend if they
attempted to open a 0 length file using TUI.
7. If you changed the media type of a configured interface, the change
was not recognized by the driver unless the driver was unloaded.
8. If a server contained multiple NW2000 cards, the cards shared RAM
incorrectly and did not operate.
9. Using OSPF with multiple unnumbered links in different areas abended the server.
10. IP filters were lost if a call was brought down and the filter was
specific to a frame relay circuit.
11. PPP data compression resulted in a server abend, when MPR was used with the EICON PBLAST.LAN v1.20 driver, for the PacketBlaster WAN adapter.
12. The sample login script, provided with MPR 3.1, does not work properly in some enviroments.
With Source Route Bridging
--------------------------
13. If the Source Route Bridge Protocol ID filters were set to "Permit
packets in Filter list", connectivity could be lost.
14. The largest frame size negotiation for a Source Route frame could be set to a value higher than supported by the medium, causing the connection to drop.
When Used on a Server With NetWare Connect
------------------------------------------
15. When two NetWare Connect users logged in at exactly the same time, IPXRTR disconnected one of them.
16. When the NetWare Connect idle disconnect timer was set and the client workstation hung while a connection was being reestablished, IPXRTR abended when a new user tried to connect.
17. NWC203.EXE, NWC204.EXE, and NWC205.EXE, for NetWare Connect 2.0, extend to Windows 95 workstations, the ability to dial up IPX connections.
If NetWare Connect and MPR reside on the same server, both MPR31A and NWC203/4/5, must be installed for the dial IPX enhancement to be available.
When Used on a FIGS (French, Italian, German, Spanish) Server
-------------------------------------------------------------
18. After installation of MPR3.1, older translations were used.
With Traps
----------
19. The traps defined in the adapter MIB files, provided with MPR 3.1, did not format correctly on ManageWise 1.0, or NMS 2.0 consoles.
20. Trap Help was not available. (The trap help files failed to ship with
MPR 3.1)
NEW FEATURES
F1. Contains a new TCPIP.NLM.
IMPORTANT!! Only use this TCPIP.NLM on a MPR 3.1 server. Do not use it on a server which does not have MPR 3.1 loaded!!!
If you have MPR 3.1, this is the correct TCPIP.NLM to use, even if the
server also has NetWare Connect.
F2. Additional packet types were added to the TCP/IP packet filters=
definitions.
F3. IPXRTR has been enhanced to provide routeless services.
Originally IPX Services were absorbed only if the network number on which the service resided was explicitly reachable.
If a default route (-2 or FF-FF-FF-FE network number) is defined for IPX,
IPXRTR will optionally absorb services, without an explicit route to the
service being reachable. This is implemented via a set command. By
default IPXRTR requires a explicit network number to make a service
reachable. By using a set command the check for an explicit network number before absorbing services is removed.
The syntax of the set command is:
set required network for services = <on> / <off>.
The default set is ON. This means that IPXRTR will check to see if the
network number on which a service resides is explicitly reachable. If it
is reachable it will absorb the service otherwise it will drop it.
If it is set to OFF, IPXRTR will check to see if the network number on
which the service resides is explicitly reachable, if so it will absorb the
service. If the network number is not reachable it will check to see if
there is a default route (network number of -2), if a default route is
present and reachable, the service will be absorbed. If a explicit route
and the default route is not reachable then the service is dropped.
|