Patch Name: PHNE_9526 Patch Description: s700 9.01 ARPA Transport cumulative patch Creation Date: 97/04/08 Post Date: 97/04/21 Repost: 97/04/24 The documentation was modified to remove SR 4701335596 and the information in the Defect Description field discussing the syn attack and Denial of Service (DOS). This patch does not address the problem. Hardware Platforms - OS Releases: s700: 9.01 Products: N/A Filesets: BSDIPC-SOCKET KERN-BLD NET NETINET NETIPC Automatic Reboot?: Yes Status: General Release Critical: Yes PHNE_9526: PANIC PHNE_9027: PANIC PHNE_7704: PANIC PHNE_7198: PANIC PHNE_4957: PANIC PHNE_4479: PANIC PHNE_3938: PANIC PHNE_3655: PANIC PHNE_3502: PANIC PHNE_3049: PANIC PHNE_2962: PANIC PHNE_2873: PANIC PHNE_2814: PANIC PHNE_2735: PANIC PHNE_2580: PANIC PHNE_2576: PANIC PHNE_2551: PANIC PHNE_2510: PANIC PHNE_2378: PANIC PHNE_2375: PANIC PHNE_2327: PANIC PHNE_2298: PANIC PHNE_2174: PANIC Path Name: /hp-ux_patches/s700/9.X/PHNE_9526 Symptoms: PHNE_9526: This patch replaces PHNE_7704. See Defect Description PHNE_9027: See Defect Description PHNE_7704: See Defect Description Defect Description: PHNE_9526: ( SR not found ) IPTOS_PREC_ROUTINE was defined as 0x10. That means the LOW DELAY bit in the type of service field is also set. This makes it difficult to assign "Routine" precedence with "Normal delay". ( SR number: 5003342071 ) ping can cause panic. ( SR number: 1653198069 ) System hangs during shutdown in sbdrop. PHNE_9027: ( SR number: 5003342071 ) ping can cause panic. PHNE_7704: ( SR not found ) Generally, options are inherited from the listen port by the accept port. This is not the case for TCP_NODELAY. ( SR number: 5003024588 ) The fstat command returns the incorrect mode for a socket. This worked at 7.0 but fails on 8.0. Problem is easily duplicatable on both 700/800 and 300/400 systems. As documented and as it works in 7.0 the mode returned for a socket should be 140000. This is also the value checked for by the macro S_ISSOCK (/usr/include/sys/stat.h). At 8.0 a value of zero is returned rather than the correct value. This will cause any application that attempts to use fstat to determine if a file descriptor is a socket or not to fail. ( SR not found ) When a system nfs mounts one of its own directories and does a lot of writing to that directory over the mount, the nfs daemons shut down and cause the system to go to a very high load level. The problem was seen when building X11 using a chroot build environment where you must nfs mount local directories for access and writing. Typically using make hangs on a big link (ld) where the write to the output file was across the nfs mount to the same machine. ( SR not found ) BSU and networking tests were running under CTE environment. There is a deamon "utd" running which schedules theses tests. utd stopped scheduling tests after running tests for 12 hours. "ts" command which reports test status of tests running under CTE environment talk to utd via socket and connect calls was returning error Connection timedout for a connect call. There were some processes (tlget) hanging which also talk to utd via socket-connect calls. ( SR not found ) When NFS Checksumming is TURNED ON and NFS packets are sent across IP gateways NFS will not work. ( SR number: 4701220137 ) Using rcp, when ^C is executed during a file transfer in loopback a tcp checksum error is generated. ( SR not found ) The call to in_cksum was missing where tcp is trying to detect if the SYN is from a 3K and we're doing checksum negotiation. This bug was introduced with the checksum offload changes added in 9.0. ( SR number: 5000685909 ) Getting an unexpected error 239 ICMP port unreachable. Customer contends that the socket is still open when he receives this error. The problem is that the source port is not passed up to in_pcbnotify() so it just sets the error on all the socket inpcb structures. ( SR number: 5003101527 ) Panic occurs trying to free freed mbuf: trap type 15, pcsq.pcoq = 0.123f2c, isr.ior = 0.106a @(#)9245XA HP-UX () #1: Mon Mar 18 14:09:46 PST 1991 panic: (display==0xb200, flags==0x0) Data segmentation fault Kernel Stack trace: panic+0x001c trap+0x0a64 $thndlr_rtn+0x0000 m_free+0x001c m_freem+0x0014 sou_clean+0x0030 sou_delete+0x00b4 ipcshutdown+0x02b4 new_ipcshutdown+ syscall+0x0230 ( SR number: 4701173740 ) TCP sometimes aborts connections when both sides are both sending and receiving data asynchronously and the network is heavily loaded such that packets frequently don't get delivered. The reason apparently is due to a retransmission timeout. Netstat shows that both ends of the connection have data to send but neither side successfully receives any data once this "hang" situation occurs. Eventually one side gives up attempting to retransmit the next data packet and aborts the connection. ( SR number: 4701220145 ) SLIP performance degrades to the point where apparently transmission stops. ( SR number: 4701218651 ) When an icmp destination unreachable message is received, an error is placed on ALL sockets which are sending to the specified destination ip address, as opposed to the specific connection which caused the icmp message. TCP does not abort the connection in this case (as the submitter suggests), but the application receiving an error on the socket is most likely aborting the connection. ( SR number: 4701218883 ) In order to migrate applications from NetIPC to BSD sockets, this enhancement provides a tool to convert a NS nodename to an IP address so that with that IP address, you can find a Domain name. ( SR number: 5003080341 ) sendmsg() should allow max vector len = 16; but returns EMSGSIZE when this is the case. ( SR number: 5003112193 ) Series 300 HP-UX 9.0 returns MAC address of 0x000000000 when replying to a PROBE request. NET.BSD_ARPA The problem initially occurred on 9.0 vt3k connections to various 3000s. The connection would hang in the middle of the session. Arp caches on both the 3000 and the 9000 contained the correct hardware address yet the "mapping" on the 3000 would report that the hardware address was 0x00000000. ( SR number: 4701197269 ) Customer wants better performance for pure lan topologies, especially with fddi. The current implementation will limit the maximum packet size to 512 bytes of user data when going to a remote network across a gateway. This limitation is is a little too strict for topologies that are made up entirely of fddi and/or ethernet lans. The result is an unnecessary limitation in throughput. Customers installing fddi (for performance benefits) are especially annoyed by this. ( SR not found ) This problem was found by testing ioctl(NMIOGET) for ID_ipAddrTable. When *nmparms.len is given with a fairly large value, system panic. Since ioctl(NMIOGET) is only for internal customer (for developing snmpd), this problem is not expected to happen. ( SR not found ) Two problems may occur when ioctl (command = NMIOGET) is used to retrieve the address translation table (atTable): these problems could either overrun user buffer or return inconsistent information. Since this is for internal use only, customers should not see this. ( SR not found ) Incorrect NMIOSET(ID_ipRouteEntry) deletes the route entry. Ioctl(NMIOSET) with nmparms.objid equals ID_ipRouteEntry is to set the new gateway for a route entry. Since this is for internal use, customers should not experience this. ( SR number: 1653055103 ) Missing parameter cause system panic. ( SR number: 5000695213 ) The customer would like an enhancement to the arp(1m) command to: - be able to disable unicast arp's - configure the timeout value for arp entries Disabling unicast arp's will result in decreased lan traffic, which can be a significant percentage of overall lan traffic in large networks. Configureable timeouts will have a similar effect, and allow system administrators to more intelligently control network utilization. NOTE: commands are not yet part of general release patch. ( SR not found ) Xinet's Appletalk product was no longer officially supported as of 9.0. When the customer got it, it did not work, so Xinet made some workaround changes which ended up panic'ing the system when traffic was heavy. ( SR number: 4701223040 ) Maximum IP packet size limited to 32 KBytes. ( SR number: 5003166975 ) For releases 9.03 and 9.04, the TCP "keepalive" function no longer works on connections to/from non-hp 9000 systems. This means that customers will notice that connections which are idle, i.e. have no activity, will time out after a period usualy not exceeding one hour. This is most commonly noticed when using vt3k to connect to HP 3000 systems. ( SR number: 4701237263 ) IP cannot reassemble datagrams when the fragment offset is greater than 32KBytes. ( SR number: 1653077800 ) ( SR number: 5003170332 ) When the ipq reassassembly queue is first initialized an assumption is made that if the first fragment was checksum offloaded all successive fragments for the datagram would be checksum offloaded as well. In this case FDDI computed the checksum on the last fragment, based on the data length in the mbuf which included the ethernet padding left attached by the translating bridge. FDDI then compares the data length in the mbuf to the length value in the IP header and seeing that they differ disables the MF_CKO_IN flag and sends the fragment on up. So far this problem only seems to occur when the data is fragmented (as UDP data is), when the route originates on an ethernet host and passes through a translating bridge to an FDDI link, and when the record size is such that the last IP fragment is smaller than the ethernet minimum length which causes padding to be appended to the last fragment. ( SR number: 1653080267 ) The system panics with "data-segmentation-fault" and the stack-trace: starting sp=0x7ffe7110 panic+0x1c trap+0xaac unp_gc+0x1a8 unp_detach+0x140 uipc_usrreq+0x164 soclose+0x14c soo_close+0x2c closef+0xbc exit+0x274 rexit+0x20 The running process was the informix process /usr/informix/bin/oninit The problem occurs if the process tries to close a socket. ( SR number: 5003179093 ) Customer has an application that for performance reasons needs to burst UDP packets to the HP in quanties of 32k or more. There could be multiple machines sending the data at the same time to the same socket causing very large (150k or more) socket buffer requirments. The enhancement to allow 500k to 1000k of socket space would solve the customers problem. We have been able to adb the kernal and override the socket size to be 1000k and the problem went away. This would prove some justificaton for the larger socket sizes. A different way to solve this problem may be to find out why we are overflowing when we hit the 1/4 full mark on the socket. ( SR number: 4701253880 ) If two address belonging to the same system are listed in succession in the IP options array of an incoming datagram, the datagram will be passed up to the upper layer protocol (where it is dropped) rather than being forwarded to the next system in the options array. ( SR number: 1653080929 ) System panic with prb_ntnew top of stack. This occurs when HP 9000 receives a probe unsolicited reply with a corrupted name, i.e. a name with any bytes having the sign bit set. ( SR number: 5003185900 ) When an HP system receives a link layer broadcast for a network it does not belong to it will forward the datagram to it's default gateway. This is in violation of RFC 1009 which states "a gateway must not forward a datagram which arrives via a local network broadcast". ( SR number: 5003171686 ) After doing a vt3k to a non-existant probe will time out and the user will get an ipc error 40. However, the name remains in the cache and the node can't be reached even if it subsequently comes up or its name is added to a proxy server until the cache entry times out and is deleted. ( SR number: 4701253898 ) IP source routing is not be handled correctly by IP. This can be seen by a call to setsockopts and immediately calling getsockopts to retrieve the option array. The information is quite different from what was passed in and as suspected, the routing information in the IP header is incorrect as well. ( SR number: 5003192807 ) ( SR not found ) The connecting requests were completed and wait for accept() issued by socket application to pick. But if new connecting reqeusts were keeping established, the accept() will pick the one just completed and the old completed connection just keep staying in the tail of queue and starved for the accept(). ( SR number: 4701249946 ) When ip_forward can't forward a packet it does not increment the ips_cantforward counter. Secondly, it is incorrectly incrementing ipInAddrErrors when time-to-live expires and should instead increment ipInHdrErrors as per RFC 1158. ( SR number: 5003194134 ) After receiving a signal in recv, recvmsg, or recvfrom, when the user specifies SIG_RESTART to restart the system call, socket code will zero out the length field of the returned address. This will cause the system call to not return the returned address. ( SR not found ) As per RFC 1122 ICMP error messages should not be sent for link layer broadcasts. ( SR number: 4701253252 ) With auditing of ipcdgram turned on, system will panic or hang when calling sendto() if the sockaddr_in structure is not word aligned. ( SR number: 5003196360 ) Large UDP datagrams can not be sent through the loopback interface due to udp checksum errors. The errors start occurring at the first datagram to be fragmented by IP. ( SR number: 5000707950 ) panic: mclfree Dump will show a corrupted mbuf being freed. m_len will be negative, m_off will be some positive multiple of 0x28, which is the tcp/ip header size. ( SR number: 5003216903 ) System panic in mclfree. ( SR number: 5003228270 ) Routes for up and running SLIP interfaces can get deleted when other SLIP interfaces are started. This will happen only when the interfaces are started in a different order from which they originally were. For instance a system with two SLIP ni's uses the addresses 23.1.1.1 and 24.2.2.2. If ni0 is started with address 23.1.1.1 and ni1 is started with 24.2.2.2. If ni0 is later restarted with the address of 24.2.2.2 then when ni1 is restarted using 23.1.1.1 the route for ni0 (24.2.2.2) will be deleted since that was the old address attached to ni1. ( SR number: 1653109991 ) HP nodes are unable to connect to IBM hosts via SNAP over 802.3 when the HP node initiates the connection. ( SR number: 5003229070 ) Transmitting large files over a local NFS mounted directory results in UDP checksum errors. The NFS mount appears to hang during this time. ( SR number: 5003229229 ) The customer will experience a system hang. On a uniprocessor system, an "ack storm" can be seen using a network analyzer. On an MP system, the storm may be in loopback, so an analyzer will not show anything. If you can get a trace, look for the sending sequence number being less than the receiving sequence number in both directions. This indicates that the two sides of the connection both think they are receiving duplicate packets, and then send immediate acknowlegments, which are also dropped as duplicates, and the cycle repeats. With a loopback connection, look at the two tcp control blocks. snd_nxt on block A will be less than rcv_nxt on block B, and vice versa. ( SR not found ) The problem is the user is unable to print the returned address from a recv call using a unix domain socket because there is no null terminator, and because the returned length is not the length of the string. ( SR number: 5003239517 ) Connections is tcp FIN_WAIT_2 state will eventually time out. Customer will see connections aborted with an error to the effect that "remote has aborted the connection". These errors would be returned only on very heavily loaded networks. ( SR number: 5000710814 ) An ENXIO error is presently passed from the transport layer up to the application error as a "hard", or irrecoverable error. It is left up to the application to decide how to handle this situation. This is incorrect, because ENXIO is generated by the driver(s) in situations which *may* be recoverable, such as the imfamous 82596 LAN chip error. The user will see applications fail with a connection failure error which may be accompanied by a log message from the driver indicating that some sort of hardware error has occurred. ( SR number: 1653119461 ) System panic with soo_rw, soclose on the stack. The panic would most likely be seen on 9.04 multiprocessor systems, but could be seen on any 9.X machine. fp->f_data pointer for the socket has been zeroed out, but the socket appears to be active and ok. ( SR number: 4701290205 ) A system hangs in an endless loop. This happens when we try to PEEK a socket with a oobmark not equal to zero (urgent data). The core dump will show soreceive as the last routine entered. ( SR number: 5003264713 ) The listen socket queue limit is only 20 and should be increased. The system administrator should be able to change the maximum. ( SR number: 5003264739 ) The problem is seen when we try to close a file with valid file pointer but invalid cred field. ( SR number: 1653144972 ) There are cases where we can get FIN_WAIT_2 connections that never go away. We need a timer that customers can set to remove these connections. ( SR number: 4701313304 ) The current code allows one to create an arp entry on a poinnt to point interface. When the time expires on this entry,an attempt is made to build a packet by calling a procedure whose pointer should be in the arpcom table. In the point to point case, that pointer is NULL which causes a panic. ( SR number: 4701319897 ) tcp_iss is only incremented for tcp_slowtimo() for linear sequencing (not random sequencing). ( SR number: 4701327205 ) Current 9.01 TCP/IP does not allow applications to set IP TOS value. SR: 5003024588 4701220137 5000685909 5003101527 4701173740 4701220145 4701218651 4701218883 5003080341 5003112193 4701197269 1653055103 5000695213 4701223040 5003166975 4701237263 1653077800 5003170332 1653080267 5003179093 4701253880 1653080929 5003185900 5003171686 4701253898 5003192807 4701249946 5003194134 4701253252 5003196360 5000707950 5003216903 5003228270 1653109991 5003229070 5003229229 5003239517 5000710814 1653119461 4701290205 5003264713 5003264739 1653144972 4701313304 4701319897 4701327205 5003342071 1653198069 Patch Files: /etc/conf/libinet.a(udp_usrreq.o) /etc/conf/libinet.a(tcp_usrreq.o) /etc/conf/libinet.a(tcp_timer.o) /etc/conf/libinet.a(tcp_subr.o) /etc/conf/libinet.a(tcp_output.o) /etc/conf/libinet.a(tcp_input.o) /etc/conf/libinet.a(nm_udp.o) /etc/conf/libinet.a(nm_tcp.o) /etc/conf/libinet.a(nm_ip.o) /etc/conf/libinet.a(ip_output.o) /etc/conf/libinet.a(ip_input.o) /etc/conf/libinet.a(ip_icmp.o) /etc/conf/libinet.a(in_pcb.o) /etc/conf/libinet.a(in.o) /etc/conf/libinet.a(if_ether.o) /etc/conf/libnet.a(route.o) /etc/conf/libnet.a(nm_if.o) /etc/conf/libuipc.a(netisr.o) /etc/conf/libnet.a(if_ni.o) /etc/conf/libnet.a(if_loop.o) /etc/conf/libnet.a(if.o) /etc/conf/libhp-ux.a(dgram_aud.o) /etc/conf/libuipc.a(sys_socket.o) /etc/conf/libuipc.a(uipc_socket2.o) /etc/conf/libuipc.a(uipc_usrreq.o) /etc/conf/libhp-ux.a(uipc_mbuf.o) /etc/conf/libuipc.a(uipc_socket.o) /etc/conf/libuipc.a(uipc_syscall.o) /etc/conf/libnipc.a(prb_name.o) /etc/conf/libnipc.a(nipc_syscall.o) /etc/conf/libnipc.a(nipc_sou.o) /etc/conf/libnipc.a(nipc_misc.o) what(1) Output: /etc/conf/libinet.a(udp_usrreq.o): PHNE_9526 udp_usrreq.c $Revision: 1.3.109.11 $ $Date : 96/06/10 15:46:57 $ /etc/conf/libinet.a(tcp_usrreq.o): PHNE_9526 tcp_usrreq.c $Revision: 1.4.109.13 $ $Date : 96/04/08 11:26:43 $ /etc/conf/libinet.a(tcp_timer.o): PHNE_9526 tcp_timer.c $Revision: 1.2.109.7 $ /etc/conf/libinet.a(tcp_subr.o): PHNE_9526 tcp_subr.c $Revision: 1.2.109.11 $ $Date: 96/04/08 11:10:03 $ /etc/conf/libinet.a(tcp_output.o): PHNE_9526 tcp_output.c $Revision: 1.2.109.6 $ $Date: 96/06/10 15:45:25 $ /etc/conf/libinet.a(tcp_input.o): PHNE_9526 tcp_input.c $Revision: 1.5.109.24 $ $Date: 96/03/19 15:30:40 $ /etc/conf/libinet.a(nm_udp.o): PHNE_9526 nm_udp.c $Revision: 1.2.109.2 $ /etc/conf/libinet.a(nm_tcp.o): PHNE_9526 nm_tcp.c $Revision: 1.1.109.2 $ /etc/conf/libinet.a(nm_ip.o): PHNE_9526 nm_ip.c $Revision: 1.2.109.5 $ /etc/conf/libinet.a(ip_output.o): PHNE_9526 ip_output.c $Revision: 1.2.109.14 $ $Date: 96/06/10 15:43:45 $ /etc/conf/libinet.a(ip_input.o): PHNE_9526 ip_input.c $Revision: 1.2.109.13 $ $Date: 96/10/31 11:58:48 $ /etc/conf/libinet.a(ip_icmp.o): PHNE_9526 ip_icmp.c $Revision: 1.3.109.7 $ $Date: 94 /04/21 17:21:18 $ /etc/conf/libinet.a(in_pcb.o): PHNE_9526 in_pcb.c $Revision: 1.4.109.16 $ $Date: 94 /01/21 16:24:48 $ /etc/conf/libinet.a(in.o): PHNE_9526 in.c $Revision: 1.3.109.10 $ $Date: 95/03/ 28 16:01:03 $ /etc/conf/libinet.a(if_ether.o): PHNE_9526 if_ether.c $Revision: 1.3.109.20 $ /etc/conf/libnet.a(route.o): PHNE_9526 route.c $Revision: 1.3.109.5 $ /etc/conf/libnet.a(nm_if.o): PHNE_9526 nm_if.c $Revision: 1.2.109.4 $ /etc/conf/libuipc.a(netisr.o): PHNE_9526 netisr.c $Revision: 1.6.109.10 $ /etc/conf/libnet.a(if_ni.o): PHNE_9526 if_ni.c $Revision: 1.4.109.12 $ $Date: 93/ 03/30 10:13:17 $ /etc/conf/libnet.a(if_loop.o): PHNE_9526 if_loop.c $Revision: 1.2.109.12 $ $Date: 9 4/05/26 15:00:20 $ /etc/conf/libnet.a(if.o): PHNE_9526 if.c $Revision: 1.1.109.5 $ /etc/conf/libhp-ux.a(dgram_aud.o): PHNE_9526 dgram_aud.c $Revision: 1.1.109.4 $ $Date: 94/05/24 09:37:31 $ /etc/conf/libuipc.a(sys_socket.o): PHNE_9526 sys_socket.c $Revision: 1.2.109.6 $ $Date: 95/08/15 13:01:08 $ /etc/conf/libuipc.a(uipc_socket2.o): PHNE_9526 uipc_socket2.c $Revision: 1.4.109.11 $ $Da te: 94/05/23 16:32:38 $ /etc/conf/libuipc.a(uipc_usrreq.o): PHNE_9526 uipc_usrreq.c $Revision: 1.3.109.5 $ /etc/conf/libhp-ux.a(uipc_mbuf.o): PHNE_9526 uipc_mbuf.c $Revision: 1.4.109.17 $ $Date: 94/10/27 10:32:53 $ /etc/conf/libuipc.a(uipc_socket.o): PHNE_9526 uipc_socket.c $Revision: 1.5.109.17 $ $Dat e: 95/11/09 10:04:02 $ /etc/conf/libuipc.a(uipc_syscall.o): PHNE_9526 uipc_syscall.c $Revision: 1.4.109.8 $ $Dat e: 94/04/29 10:45:59 $ /etc/conf/libnipc.a(prb_name.o): PHNE_9526 prb_name.c $Revision: 1.3.109.11 $ /etc/conf/libnipc.a(nipc_syscall.o): PHNE_9526 nipc_syscall.c $Revision: 1.3.109.8 $ /etc/conf/libnipc.a(nipc_sou.o): PHNE_9526 nipc_sou.c $Revision: 1.3.109.5 $ /etc/conf/libnipc.a(nipc_misc.o): PHNE_9526 nipc_misc.c $Revision: 1.1.109.3 $ sum(1) Output: 43180 17 /etc/conf/libinet.a(udp_usrreq.o) 38318 21 /etc/conf/libinet.a(tcp_usrreq.o) 63326 10 /etc/conf/libinet.a(tcp_timer.o) 41530 17 /etc/conf/libinet.a(tcp_subr.o) 36528 13 /etc/conf/libinet.a(tcp_output.o) 62502 33 /etc/conf/libinet.a(tcp_input.o) 48375 8 /etc/conf/libinet.a(nm_udp.o) 16727 9 /etc/conf/libinet.a(nm_tcp.o) 25571 20 /etc/conf/libinet.a(nm_ip.o) 55055 15 /etc/conf/libinet.a(ip_output.o) 6961 25 /etc/conf/libinet.a(ip_input.o) 27410 14 /etc/conf/libinet.a(ip_icmp.o) 56944 15 /etc/conf/libinet.a(in_pcb.o) 15776 15 /etc/conf/libinet.a(in.o) 59852 63 /etc/conf/libinet.a(if_ether.o) 56556 16 /etc/conf/libnet.a(route.o) 3361 10 /etc/conf/libnet.a(nm_if.o) 2757 16 /etc/conf/libuipc.a(netisr.o) 47582 20 /etc/conf/libnet.a(if_ni.o) 29393 11 /etc/conf/libnet.a(if_loop.o) 55345 14 /etc/conf/libnet.a(if.o) 56423 6 /etc/conf/libhp-ux.a(dgram_aud.o) 41147 9 /etc/conf/libuipc.a(sys_socket.o) 54539 30 /etc/conf/libuipc.a(uipc_socket2.o) 39839 21 /etc/conf/libuipc.a(uipc_usrreq.o) 33880 29 /etc/conf/libhp-ux.a(uipc_mbuf.o) 45090 35 /etc/conf/libuipc.a(uipc_socket.o) 54222 26 /etc/conf/libuipc.a(uipc_syscall.o) 7258 24 /etc/conf/libnipc.a(prb_name.o) 39837 61 /etc/conf/libnipc.a(nipc_syscall.o) 16075 19 /etc/conf/libnipc.a(nipc_sou.o) 46729 7 /etc/conf/libnipc.a(nipc_misc.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHNE_2174 PHNE_2298 PHNE_2327 PHNE_2375 PHNE_2378 PHNE_2510 PHNE_2551 PHNE_2576 PHNE_2580 PHNE_2735 PHNE_2814 PHNE_2873 PHNE_2962 PHNE_3049 PHNE_3502 PHNE_3655 PHNE_3938 PHNE_4479 PHNE_4957 PHNE_7198 PHNE_7704 PHNE_9027 Equivalent Patches: None Patch Package Size: 400 Kbytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Copy the patch to your /tmp directory and unshar it: cd /tmp cp patch_source/PHNE_9526 . sh PHNE_9526 3. Become root and run update: /etc/update [-r [kernel_gen_file]] -s \ /tmp/PHNE_9526.updt PHNE_9526 Update moves the original software to /system/PHNE_9526/orig. Keep this file to recover from any potential problems. You should move the .text file to /system/PHNE_9526 for future reference. To put this patch on a magnetic tape and update from the tape drive, use dd: dd if=PHNE_9526.updt of=/dev/rmt/0m bs=2048 Special Installation Instructions: None