MPTS Fixpak (WR_8621) - Germany

IBM MPTS LAN Adapter and Protocol Support Fix Pack WRx8621 German (IBM PTF WR08621) This package requires that you have the refresh of the MPTS LAN Adapter and Protocol Support (MPTS) WRx8600 WR08610 or WRx8620. WRx8600 is the MPTS included with TCP/IP 4.1 for OS/2 that is available from IBM's Software Choice. The following versions of LAPS are suitable for applying this Fix Pack. Version Product in which MPTS was included V5.30.0 TCP/IP 4.1 for OS/2 V5.40.0 IBM WorkSpace On-Demand Release 2 V5.50.0 IBM Warp Server for e-Business Note: 1 - If you try to install this Fix Pack with a version of the FixTool prior to 1.41, you may notice various errors or pop-up warning panels. Please use the version of CSF that comes on the tool diskette of this Fix Pack. Once you use FixTool Version 1.41 or later, you will not be able to use previous versions of the FixTool to service other products on this system. Fixtool version 1.42 is included with this Fix Pack. Note: 2 - This Fix Pack replaces existing syslevel files. Because of this, the previous CSD level will always be WR08610. ************************************************************************ Diskettes can be created using the LOADDSKF utility. There are 5 files/images included in this package. ************************************************************************ CSFDE142.DSK Fix Tool Diskette 3.50" WRG8621.1DK MPTS DISKETTE #1 3.50 1.44MB WRG8621.2DK MPTS DISKETTE #2 3.50 1.44MB WRG8621.3DK MPTS DISKETTE #3 3.50 1.44MB WRG8621.4DK MPTS DISKETTE #4 3.50 1.44MB Note: The following APARs are contained in FixPak WR08621. FixPak WR08621 also contains all APARs contained in FixPaks WR08610 and WR08620. * - APAR = IC22209/IC22731 TCP/IP FAILS TO RECOVER IF THE LAN HAS A TEMPORARY OUTAGE * - APAR = IC22312/IC23079 LOTUS DOMINO SERVER DOES NOT COMPLETELY SHUTDOWN AFTER MPTS WR08600 LEVEL IS INSTALLED * - APAR = IC23808 SYS3175 IN NSUPDATE.EXE NSUPDATE.EXE is trapping. The popuplog.os2 shows: SYS3175 C:\MPTN\BIN\NSUPDATE.EXE c0000005 CS:EIP=005b:00026b4a NSUPDATE.EXE 0002:00006b4a Dynamic update is not performed correctly at the DNS. * - APAR = IC23878 TRAP IN SX.EXE OCCURS WHEN RUNNING ANYNET WITH MPTS WR08610 * - APAR = IC24002/IC24027/IC24028 ALIAS CONFIGURATION ON A TCPIP 4.1 SYSTEM DOES NOT TRANSMIT DNS QUERY THROUGH THE INTERFACE * - APAR = IC24123 DHCPMON IS SHOWING THE INCORRECT RENEWAL TIME (T1) It appears that the Renewal Time (T1) is recalculated each time Current Configuration is displayed. It takes 1/2 of the lease time and adds it to the current date/time. This is done whether the system date/time is changed or not. It also appears to have no effect on when the renewal is actually performed. To recreate, set up a DHCP server issuing 60 minute leases. When the TCPIP 4.1 client is issued an IP address, the renewal should take place 30 minutes later. Wait 30 minutes and the renewal will be performed as expected. Look at the Current Configuration output right after the renewal and it will show the correct Expiration date (60 minutes in the future), T1 date (30 minutes in the future) and T2 date (52 minutes in the future). Then wait 5 minutes and display Current Configuration again - Expiration and T2 dates will not be changed (now 25 minutes in the future) but T1 shows a 5-minute increase (still 30 minutes in the future). Each subsequent display of the Current Configuration always shows T1 being 30 minutes in the future and Expiration/T2 dates not changing. The renewal continues to occur 30 minutes after the last renewal regardless of what T1 shows. After the renewal, both Expiration and T2 dates are correctly updated. Next change both the system date and system time. Displaying the Current Configuration shows the T1 date 30 minutes greater than the new date/time. Expiration and T2 do not change. The renewal still occurs 30 minutes after the last renewal regardless of what T1 shows. After the renewal, both Expiration and T2 dates are adjusted based on the new system date and time. The client seems to be renewing its lease at the correct time. * - APAR = IC24212 DENIAL OF SERVICE WHEN ICMP PACKETS WITH WRONG HEADER LENGTH ARE SENT Denial of service (DoS) when target machine is flooded with icmp packets of invalid header length and random type. * - APAR = IC24293/IC24410/IC24411 TCPIP STACK ADDS AN ENTRY TO THE LOCAL HOST ROUTE TABLE FOR EVERY REMOTE HOST PINGED OUTSIDE OF THE LOCAL SUBNET. * - APAR = IC24294 TCPIP STACK FAILS A FEW MINUTES AFTER BOOTUP AND IS THEN UNABLE TO PING HOSTS IN THE SAME LOCAL SUBNET, BUT REMOTE IS OK. * - APAR = IC24349 TRAPS OCCUR WHEN DHCPSD.EXE AND SENDMAIL.EXE ARE RUNNING AT THE SAME TIME. Traps occur when DHCPSD.EXE and SENDMAIL.EXE are running at the same time. It was found that the traps will occur while DHCPSD.EXE is running with other TCP/IP applications also. The failure was found to be within TCPIP32.DLL. * - APAR = IC24506/IC24806/IC24807 INTERMITTENT TRAP IN SOCKETS.SYS RUNNING WARP SERVER FOR E-BUSINESS AND TCP/IP 4.1 WITH WINDOWSIZE CHANGED FROM 8K TO 32K. * - APAR = IC24560/IC24629/IC24630 TCP SOCKETS REMAIN IN CLOSE_WAIT STATE TCP Sockets are remaining in the Close_Wait state even though the application has issued a socket close (SoClose). * - APAR = IC24652/IC24653/IC24654 DHCP CLIENT NOT RELEASING IP ADDRESS ON SHUTDOWN During a shutdown and before the reboot, you can still ping yourself. * - APAR = IC24664 NETBIOS.OS2 IS TRAPPING IN R3S_FIXUP * - APAR = IC24665 ODI2NDI.OS2 FAILS TO BIND TO THE IBM WAKE-ON LAN ADAPTER ON FASTER PROCESSORS (350MHZ AND ABOVE). ERROR LT80211 IN LANTRAN.LOG odi2ndi.os2 fails to bind to IBM Wake-on LAN adapter on faster processors (350mHz and above). Error LT80211 is logged in lantran.log. * - APAR = IC24692 IF DHCP CLIENT RELEASES ITS ADDRESS USING DHCPMON AND IF THE PREVIOUSCFG OPTION IS SET, DUPLICATE ADDRESSES CAN GET ASSIGNED Using PreviousCfg + DHCPMON to release addresses can cause duplicate addresses to be issued. This problem can occur if the DHCP client is configured to use the PreviousCFG option (in DHCPCD.CFG), and the client then releases its IP address using DHCPMON, the DHCP server can assign that IP address to another client (this is ok, and normal operation). However, if the original client is unable to access the DHCP server, it will attempt to reuse its original address, which is now assigned to a new client. This results in 2 hosts using the same IP address. * - APAR = IC24818/IC24933/IC24934 DB2 CLIENT RUNNING WARP SERVER FOR E-BUSINESS (AURORA) FAILS TO CONNECT TO SERVER: SQL1336N - HOST NAME NOT FOUND * - APAR = IC24891/IC25109/IC25110 SYSTEM HAS A TRIPLE LAN STREAMER CARD BUT IS UNABLE TO USE THE MULTIPLE IP ADDRESS WITH THIS CARD * - APAR = IC25074/IC25526/IC25543 SOCKET WRITE (I.E SEND) METHOD RETURN -1 IF THE LENGTH PARAMETER VALUE IS > 65536 Send method fails if Netscape making call to this function with the length parameters value is > 64K. (i.e length > 65536). Its working fine if the length value is <= 65536. * - APAR = IC25347/IC25834 TRAP 0008 OCCURS WHEN ATTEMPTING TO RUN AN APPLICATION THAT RESIDES ON A REMOTE SERVER, AND CONNECTION PROTOCOL IS TCPBEUI * - APAR = IC/25362/IC25363/IC25364 DURING A TCPBEUI CONNECTION, CONNECTION IS SOMETIMES DROPPED FOR DUPLICATE PORT NUMBERS During a TCPBeui Connection, the TCP/IP Port numbers are being duplicated.... * - APAR = IC25496/IC25497/IC25498 HOST.EXE IS NOT RETURNING MULTIPLE IP ADDRESSES IF ASSIGNED Customer wants to be able to display all IP addresses assigned to a Host Name on a DNS. The DNS is returning all IP Addresses, but only one is displayed. * - APAR = IC25488/IC25499/IC25500 TCPIP32 DLL NEEDS TO HANDLE THE FRAGMENTED UDP PKTS CORRECTLY (>512B) TCPIP32 DLL does not process the larger UDP Pkts correctly and this was surfaced while working on APAR IC25121 ( Host.Exe to return multiple IP addresses for the same hostname) when the host names were longer so as to spill over 512 bytes. * - APAR = IC25527/IC25545/IC25546 TCPIP STACK 'ROUTING TABLE MBUFS' GROWS AND GROWS, NOT FREEING THESE MBUFS WHEN RUNNING SOCKETS APPLICATION CALLED BCM2.EXE The failure occurs when all of 17920 mbufs allocated for the Stack are used up. At that time, the routing table alone owns about 17000 mbufs. * - APAR = IC25781 SYBASE DATABASE SERVER STOPS ACCEPTING CONNECTIONS. Warp4, fixpak10, WRG8610, and Sybase Database Server. Sybase clients will loose connection to the Sybase Server component running on Warp4. It seems the Sybase Server stops accepting requests. When this occurs all the sybase clients loose their connections to the server. All other tcpip applications work fine. If Sybase server daemon is stopped and restarted, the clients are able to reconnect. * - APAR = IC25782 FAILURE TO DISCONNECT AFTER ABNORMAL SHUTDOWN, SPECIFICALLY IN PORTMAP.EXE * - APAR = IC25837/IC25839/IC25840 WARP4 AND 3172 WITH OFFLOAD FEATURE ATTACHED TO A VM SYSTEM IS EXPERIENCING A HANG. Offload hang in sockets.sys * - APAR = IC26169 CUSTOMER IS RECEIVING TRAP0003'S APPROXIMATELY EVERY HOUR ON HIS WSEB PRODUCTION SERVER. * - APAR = IC25814/IC26178/IC26179 WEBSERVER STOPS ACCEPTING TCPIP CONNECTIONS AFTER ABOUT 1.5 MILLION TRANSACTIONS WHICH RESULTS IN TIMEOUTS AT CLIENTS A NETSTAT -M on the server shows 'MBUFS obtained from page pool' as an ever increasing number. While the 'Free MBUFS' is decreasing. This points to the buffers being allocated faster than they are recovered. When there are no more buffers, TCPIP connections are no longer accepted.