Patch Name: PHNE_4275 Patch Description: s700 8.07 X25 libraries revision 2.6 - dts XGDxg00178 : An empty x25ipmaptbl table caused panic if system configured as DDN. - SR 5003193300 : If the network type was DDN, flow control facilities were not negociated. SUBMITTER TEXT: Connecting over X.25 network type DDN. We have flow control turned on. In the call request packet we are sending the correct information for DDN but we not include the negotiation information. sample data portion of packet. EC 00 00 00 03 31 00 58 70 20 69 02 86 77 | dest | | source | 06 00 00 04 01 08 00 CC | DDN fac | ^___ Protocol ID The DDN information is there but we have no x.25 facility negotiation. The above packet was taken when telneting to 15.31.240.3. - SR 5003179580 : pvc_str variable is defined in x25str.h; it can only be included in one prog SUBMITTER TEXT: In include file /usr/include/x25/x25str.h the type definition for x25_setup_pvc_str is: struct x25_setup_pvc_str { char ifname[X25_MAX_IFNAMELEN+1];/* Name of X.25 interface to use */ int lci;/* Logical Channel Number */ } pvc_str; This actually defines a variable "pvc_str". It appears that this should be a type definition only rather than actually declaring a variable of this type. When the customer has more than one .c files that include this header file ld will report and error due to a duplicate variable name. The header file should be able to be included in multple .c files but this is not the case. - dts XGDxg00179 : problem with the usage of X25_ISCONNECTED and X25_WASCONNECTED. PROBLEM TEXT : X25_ISCONNECTED and X25_WASCONNECTED define the position of a bit in a word : #define X25_ISCONNECTED 10 #define X25_WASCONNECTED 21 but x25L3input.c used them like this : if ((pcb->x25pcb_flags & X25_ISCONNECTED) && (pcb->x25pcb_flags & X25_WASCONNECTED)) { - SR 1653079764 : ER to support 2 different called addresses in incoming calls PROBLEM TEXT: A customer has a problem with X.25 connected to a "collective line". For example he has two line with physical addresses 00000000001 00000000002 The Network provider (German Telecom) configured a "collective line" 00000000301. Dependimg on which line is available call on the collective line" are directed to one of both physical lines. In this configuration the customer runs into problems: Either the configuration is : X.121_address 00000000301 X.121_packet_address 0000000031 In this case the Network clears outgoing calls due to a mismatch of the calling address field in the outgoing call request and the number of the physical line configured in the network. If he configures : X.121_addess 00000000301 X.121_packet_addreOutfoing calls work fine since the Networkprovider fills in the real address into the calling address field. A problem appears on incomming calls. The Network send incomming call indications with called address equal to 0000000031. The call becomes cleared due to a mismatch with the null string in the X.121_packet_address configuration. Quick implementation of this request, using an undocumented variable, modifiable with adb, providing the number of digits to ignore in the destination field. Refer to the SR. - SR 5003181990 : X25_SETUP_PVC ioctl returns EPERM(1) instead of EINTR(16) PROBLEM TEXT : Some routines in x25L3usreq.c used to return 1 in case of error, and that code found its way into errno, where it meant EPERM. Modified to return EINTR instead. - SR 5003189605 : X25_GET_IFSTATE incompatibility problem; return EINVAL on some systems VERIFIER TEXT: This has been verifed in the RC. The problem is that a change was made to the x.25 header file x25ioctls.h. The declaration was incorrectly changed from: #define X25_GET_IFSTATE _IOR('N',20, struct to #define X25_GET_IFSTATE _IOWR('N',20, struct It appears that 9.04 and some patches were compiled with the incorrect definition and thus any application code compiled with the correct version will start receiving an error when making the ioctl call. The error is EINVAL indicating an invalid parameter. At this time there is NO fix or workaround. The bigest problem here is that customers running on 9.0 who upgrade to 9.04 or install current X.25 patches will have their applications cease to function. They are sitting on a timebomb! - SR 5000707463 : System panic due to 'struct buf diagbuf' & 'char diagbuf[MAXDIAGBUFFER]' SUBMITTER TEXT: System crashed with data page fault after line printer went out of paper. kernel stack: panic+0x001c interrupt+0x07a0 $ihndlr_rtn+0x0000 lb_single_loop2+0x000c privlbcopy+0x0019 diag0+0x02a0 more_msgs_join+0x0030 c0_log_error+0x0114 cent0+0x0288 more_msgs_join+0x0030 timeserver+0x0034 softclock+0x0108 To reproduce this problem: 1. Run PSIDAD online section 5. 2. Cause any device to timeout. System will crash at this point. - SR 1653088708 : X.25/9000 error 28 ( ENOSPC ) even though there are VCs available PROBLEM TEXT : The error 28 (ENOSPC) is returned when there is no VCs available. The driver compares the number of VCs configured to the number already open (x25_nckts_open variable). Its this variable that is not being decremented. The following displays its value. adb -k /hp-ux /dev/mem x25_ifstruct+0x15a10/"x25_0 vc open (driver) :"r1X - SR 1653083113 : x25/9000 : panic in pdn0_calculate length+18 - or int_compl(). PROBLEM TEXT : panic+0x24 ( arguments not stored ) pc=0x1c5bf8, pfmp=0x256100, psp=0x256120 interrupt+0x664 ( arguments not stored ) pc=0x16a4c0, pfmp=0x255eb0, psp=0x255ed0 trap marker save state 0x255ca0 sp 0x255ed0 framesize 0x230 pdn0_calculate_length+0x18 ( arguments not stored ) pdn0_psi_interrupt+0x364 ( arguments not stored ) pc=0x568a8, pfmp=0x255bd8, psp=0x255bf8 pdn0+0x364 ( arguments not stored ) pc=0x54930, pfmp=0x255b58, psp=0x255b78 int_io_send+0x184 ( arguments not stored ) pc=0x179468, pfmp=0x255ae8, psp=0x255b08 int_compl+0x1c0 ( arguments not stored ) pc=0x17787c, pfmp=0x255a50, psp=0x255a70 trap marker save state 0x255830 sp 0x255a70 framesize 0x240 Various panics in int_compl(), due to inconsistencies in the list of completion entries : the 'dummy' entry was not found in the list. The problem might be caused by cdi_write() not flushing the cache before triggering a DMA. - dts XGDxg00180 : error in x25init. PROBLEM TEXT : efcp_data_req() and efcp_data_cont_req() used to return void to the calling program ; they now return ALL_OK. (Discovered during preparation of 10.0.) - SR 4701243626 : x25/9000 : Cannot re-initialise the card if x25upload failed. SUBMITTER TEXT: If x25init needs to perform an upload and this upload cannot be performed correctly by x25upload, you cannot re-initialise your card until reboot. - SR 4701243618 : x25/9000: when x25init needs to perform an upload got an error. SUBMITTER TEXT: When performing x25init got the error : x25init -c /etc/x25/x25config0 -d /dev/x25_0 x25init warning: The card status indicated that the card memory should be uploaded. /etc/x25upload will be scheduled to perform the upload. x25init: The upload output will be saved in /etc/x25/dumps/mar4.112445. open error was: Is a directory /etc/x25upload error: opening the device file /dev/open You have this error when an upload need to be perform AND when you specify "-d" option in the x25init command. - SR 1653039834 : x25/9000 on s800 8.02,panic:out of timers with io_get_timer, x25stat PROBLEM TEXT: When several process are x25stat ( -t -p -g -f ), there is a potential "timer leak" which leads after a while to a system panic ( system is out of timer ). - SR 5000686543 : system panic on 8.02 rev8 : x25valmptr(). PROBLEM TEXT: When the level3 goes down and there is an incomming call processing in progress ( accept() or ioctl( X25_SEND_CALL_ACEPT)) there is a possibility that the system panic. The panic stack is given below. This problem can also occur when the interface is stopping or if the application tries to send call user data in a call response when there is no fast select facility. In this case the following events can be seen : without defered call acceptance : logging contains ERROR log 2110 the ioctl X25_SEND_CALL_ACEPT returns with errno set to ENETDOWN, ENETUNREACH, EMSGSIZE panic+0x1c ( arguments not stored ) pc=0x144150, pfmp=0x16fa8, psp=0x16fc8 interrupt+0x7a0 ( arguments not stored ) pc=0xc38ec, pfmp=0x16cd0, psp=0x16cf0 trap marker save state 0x16ac0 sp 0x16cf0 framesize 0x230 x25valmptr+0x4 ( arguments not stored ) x25validatepcb+0xc0 ( arguments not stored ) pc=0x80460, pfmp=0x16a18, psp=0x16a38 x25L3_n_disconnect_ind+0x78 ( arguments not stored ) pc=0x7e174, pfmp=0x16878, psp=0x16898 n_disconnect_ind+0x230 ( arguments not stored ) pc=0x6c4b0, pfmp=0x167d8, psp=0x167f8 alcp_iev_disconnect+0x7a8 ( arguments not stored ) pc=0x7490c, pfmp=0x16568, psp=0x16588 alcp_iev_process+0x430 ( arguments not stored ) pc=0x72f34, pfmp=0x164c0, psp=0x164e0 prsm_exp_data_ind+0x64 ( arguments not stored ) pc=0x71efc, pfmp=0x16478, psp=0x16498 cdi_read_cmplt+0xa28 ( arguments not stored ) pc=0x69470, pfmp=0x163d0, psp=0x163f0 pdn0_x25_rint+0x4cc ( arguments not stored ) pc=0x66cfc, pfmp=0x16340, psp=0x16360 pdn0_x25_rint0+0x44 ( arguments not stored ) pc=0x6a5b4, pfmp=0x16308, psp=0x16328 netisr+0x108 ( arguments not stored ) - SR 4701205161 : x25upload on a CIO system doesn't work SUBMITTER TEXT: x25upload on a CIO system doesn't work if the release is : - 9.0 with x25libs MR, rev1 and rev2. - 8.X with x25libs rev 2.1. The size of an upload with these versions will be 1048576. Normally it's 262144 bytes. - SR 5000699611 : S800: X25check reports different results depending on the shell used SUBMITTER TEXT: OS ver 8.02 System 827 x25check(1m) returns the different error message between root user and general users. The error message on root does not supply useful information compare with the general users. Bourne Shell reports the following: CALL packet sent ... Unable to Connect to Remote Node ERROR occurred while sending the CALL packet with errno 239 ERROR 239 : Connection refused and Korn shell and C shell reports: CALL packet sent ... VC_CLEAR Packet was received with CAUSE 0 : DTE Originated DIAG 232 : OSI Network Service Problem - Connection Rejection - NSAP unreachable ( permanent condition ) It is likely that the server program is not running on the remote node Unable to Connect to Remote Node This can cause misleading diagnosis when x25check is run. - INDaa13463 : system hang : loop in n_modify_registration() : pointer not advanced. - XGDxg00134 : core while x25init on NIO : .submitter Found while preparing 10.0. System panic in nio_download() (init.c) : read() received as parameter ssmp->ss_u.dnl_rec - a structure - when it expected a pointer. - XGDxg00135 : system panic in mbpsi_x25read(). .submitter Found while preparing 10.0. System panic in brelse(), called from mbpsix25_read() (pdn0_up.c). bp->b_flags should not be zeroed. - XGDxg00136 : system panic in n_event_ind(). .submitter pdn0_bp.c : n_event_ind() was passed x25_ifstruct[] - a structure - when a pointer was expected. Core dumped on newer 700 systems. - XGDxg00137 : OTS experienced erratic RESET packets with no reason. .submitter OTS experienced erratic RESET packets with no reason. The problem was traced to an alcp segmentation not supported by the firmware. alcp_data_req() (x25alcp.c) : if (next_mbuf && !eomhit && send_size && next_mbuf->m_len>max_fragment_size) becomes : if (next_mbuf && !eomhit && send_size && M_HASCL(next_mbuf)). - SR 1653080101 : system hang : leakage of mbuf. MARKETING TEXT : We can reproduce with server.c and client.c, 2 c programs provided with the x25 software. If you launch it several times, you will see with netstat -m : Mbufs in use: mbufs allocated to data This number nb_mbuf_allocated will increase. You can REPRODUCE this also with X25CHECK and X25SERVER. ------------------------------------------------------------------------------ Defects corrected in revision 2.3 : - SR 5003122283 : PADEM's x25addrstr struct is not updated with hunt group x.121 address SUBMITTER TEXT: This enhancement will require a code change to PADEM. At the present time, "padem" returns the following "call connected" message: "NNNNNNNNNNNNNN COM". The only problem with this message is that "NNNNNNNNNNNNNN" is the "Hunt Group Address" instead of the DNA (Direct Network Address). Hp only needs to make the necesary code changes to "padem" and potentially to the "X.25 Kernal Driver" to replace the "Hunt Group Address" in the call connect message with the DNA. ENHANCEMENT TEXT: When a call packet is sent to destination A and the network reroute the call to destination B according to the call redirection facility, the call conf packet returned to the caller may contain destination B address. With the current implementation only the destination A address is kept in the socket data structure. The enhancement consist on updating this address with destination B address if provided in the call conf packet. getpeername() system call allows the application to read this address. The PAD will have to use this system call to display the destination B address ( if provided in the call conf packet ). - SR 1653065318 X25_SET_FRAGMENT_SIZE not able to request a vaule less than 224 in 9.0 SUBMITTER TEXT: The customer uses x25 programatic interface. The system is a 9000/715 running hp-ux 9.01, with rev 2.1 of x25 libraries. The customer 's application uses the X25_SET_FRAGMENT_SIZE. The value of the fragment size is set to 128 bytes. The application was running fine under hp-ux 8.07, but now doesn't under 9.01. The symptom is that it doesn't receive any data. MARKETING TEXT: When the X25_SET_FRAGMENT_SIZE is enable the driver returns to the application an entire number of mbufs. There is no data fragmentation. If the requested fragment size is less than one mbuf, unfortunately, the driver doen't give anything to the application. You have the problem if you use a fragment size < 96 in hp-ux 8.0, or a fragment size < 224 in hp-ux 9.0. The size of the mbuf has changed from 8.0 to 9.0, 128 to 256. The fix is to force in the X25 driver, the minimun fragment size to MLEN ( see /usr/include/sys/mbuf.h ) i.e 96 in hp-ux 8.0, 224 in 9.0. This is done on X25_SET_FRAGMENT_SIZE ioctl request. For compatibility reason, no error is returned to the user if the value is modified. This fix has been incorporated in the revision 2.3 of X25 libraries. - SR none General pvc code clean-up. ------------------------------------------------------------------------------ Defects corrected in revision 2.2 : - SR 5003136242 : Empty data packet causes a panic in alcp_iev_send SUBMITTER TEXT: Customer uses x25check to verify x25 connectivity from a 9000/827/8.02 system which has HP's X.25 software but runs over a 3rd party X.25 card (ACC), via a Private Packet Network, to another 9000/827/8.02 which has HP s/w and hardware installed. After the x25check completes the destination 827 panics with Data page on interrupt stack. panic+30 interrupt+7a0 ihndlr_rtn: alcp_iev_send+29c alcp_iev_queuedata+27c alcp_iev_process+39c prsm_data_ind+138 cdi_read_cmplt+0xce8 pdn0_x25_rint+4cc pnd0_x25_rint0+44 netisr+108 external_interrupt+3b0 ------------------------------------------------------------------------------ Defects corrected in revision 2.1 : - SR 4701192807 : Card status fails with PSIDAD or EISAPSI (hardware test). SUBMITTER TEXT : With 9.0 rev2 for the 700 PSIDAD fails while reading the card status. PSIDAD uses ioctl PSI_EISA_CMD with command CCMD_IN_CARDSTATUS ( buflen 64, timeout 1 ). The ioctl returns ESPIPE ( 29 ) which means "broken pipe". 9.0 MR version worked fine. This was initially dts GNDl000035. - SR 1653039677 : x25/9000 s800 8.0 x25stat : "number of outgoing calls" incorrect PROBLEM TEXT: x25stat -g returns always 0 in Number of outgoing calls: X.25 Direct Access - SR 1653035840 : x25/9000 on s857 8.02 : panic from pdn0_calculate_length PROBLEM TEXT: When there is a heavy traffic on an X.25 interface with messages send or received larger than about 700 bytes the pdn0 driver can panic with a Data memory protection fault. This protection fault is actually a problem of address alignement : There is an attempt to load a word with and address ( isr.ior ) which is not word aligned. The instruction is : ldws 0xC(r31),ret1 There is more information on how to identify a duplicate in the cause text. Panic message is : interrupt type 18, pcsq.pcoq = 0.6acd8, isr.ior = 0.2507ce Data memory protection fault on interrupt stack Stack is : starting sp=0x169e8 panic+0x1c ( arguments not stored ) pc=0x140b5c, pfmp=0x16988, psp=0x169a8 interrupt+0x7a0 ( arguments not stored ) pc=0xd18c4, pfmp=0x166b0, psp=0x166d0 trap marker save state 0x164a0 sp 0x166d0 framesize 0x230 pdn0_calculate_length+0x18 ( arguments not stored ) pdn0_psi_interrupt+0x364 ( arguments not stored ) pc=0x6a420, pfmp=0x163d8, psp=0x163f8 pdn0+0x364 ( arguments not stored ) pc=0x684ac, pfmp=0x16358, psp=0x16378 int_io_send+0x184 ( arguments not stored ) pc=0xe4538, pfmp=0x162e8, psp=0x16308 int_compl+0x1c0 ( arguments not stored ) pc=0xe292c, pfmp=0x16250, psp=0x16270 trap marker save state 0x16030 sp 0x16270 framesize 0x240 - : reset in the midle of an incomplete packet sequence hangs connection .problem ( GNDl000031 ) When a reset occurs in the midle of an incomplete packet sequence, the driver must send a last fragment of data without the more data to follow so that the firmware reset his internal variable saying there is an incomplete packet sequence in progress. The alcp driver module sends this last fragment with no data into it. But then the bottom plane of the driver discards empty sends. When the last reset primitive is exchanged between the driver and the card, the card thinks it is a regular data fragment and discards it. Because of that the reset processing never completes. -SR 4701182089 Q-bit not OK if ioctl(X25_SET_FRAGMENT_SIZE) is used SUBMITTER TEXT: With a 9000/700 in 8.07, when an application uses the ioctl(X25_SET_FRAGMENT_SIZE), the Q-bit of an incoming message corresponding to a data packet with Q-bit = 1 is NOT set to 1, although it should be. This prevents all the PAD applications to behave correctly. This problem is neither seen on the Series 800 in 8.0X (with the recent X.25 library patches), nor on the Series 700 in 9.0X. - SR 5000689125 clear cause: 147; clear diag: 242; clear reason: 3; what's it mean SUBMITTER TEXT: There are many X29server exit errors in the log files. Typical entries in the log file are as follows: 01/26/93 10:04:30 Master(pid: 17108) fork slave(pid: 17109). 01/26/93 10:04:41 Default: Do not know how to return the right value 01/26/93 10:04:43 Default: Do not know how to return the right value 01/26/93 10:04:43 Default: Do not know how to return the right value 01/26/93 10:07:08 send() in while returns errno 32; 01/26/93 10:07:08 X29server(master) exit; vc_connected FALSE; child_alive: FALSE; stdio_open: TRUE; master_error: 46; exit_status: 6 01/26/93 10:07:08 clear cause: 147; clar diag: 242; clear reason: - SR 5003083105 : X.25 does not allow full control of the M-bit with programmatic access PROBLEM TEXT: When the X25_SET_FRAGMENT_SIZE ioctl is used it only allows the user to receive ( send ) messages using several recv ( send ) socket calls with the More Data To Follow bit to find ( specify ) the end of the message. This ioctl does not give access directly to the X.25 data packet More data bit. Therefore the system still wait until enough data are received from the line ( send from the user ) to forward it to the user ( send it on the line ). The consequence is that about three packets needs to be received before the user receives a first fragment, about five "packets" worth of data need to be send before the first packet is seen on the line. ( with 128 bytes packets and on an HP 9000 / 800 ). Those values can be different on a 700. - : clear in the midle of an incomplete pkt sequence : data corruption .problem ( GNDl000032 ) An internal flag is not reset when a new connection is created. Because this flags tells the driver whether the inbound data received is the first fragment of a fragmented data indication, when this flag is not reset the driver does not remove the data indication header and give it as raw data to the user. - : outgoing connection fails with ENOSPC .submitter ( GNDl000036 ) If an incoming call is rejected because there is no listen socket or registration table entry, a subsequent outgoing call can fail with ENOSPC. ------------------------------------------------------------------- Path Name: /hp-ux_patches/s700/8.X/PHNE_4275 Effective Date: 940518 Modification Date: 940622 Modification Reason: The problem description information in PHNE_4275.text file was modified. OS Release: 8.07 Reboot Required: Yes Patch Files: /etc/conf/h/x25_diag.h /etc/conf/libx25.a /etc/conf/libx25ip.a /etc/conf/libx25pa.a /etc/conf/sio/pdn1.h /etc/conf/sio/pdn1_bp.h /etc/conf/sio/pdn1_efcp.h /etc/conf/sio/pdn1_spc.h /etc/conf/x25/x25.h /etc/conf/x25/x25addrstr.h /etc/conf/x25/x25config.h /etc/conf/x25/x25gen.h /etc/conf/x25/x25psidef.h /etc/conf/x25/x25stat.h /etc/conf/x25/x25str.h /etc/conf/x25/x25structs.h /etc/conf/x25/facilities.h /etc/conf/x25/alcpfac.h /etc/x25/x25_networks /etc/x25/x25init_def /etc/x25/x25init_smpl /etc/x25check /etc/x25init /etc/x25server /etc/x25stop /etc/x25upload /usr/bin/x25stat /usr/include/x25/ccittproto.h /usr/include/x25/x25.h /usr/include/x25/x25addrstr.h /usr/include/x25/x25codes.h /usr/include/x25/x25ioctls.h /usr/include/x25/x25str.h /usr/lib/help/initwan /usr/lib/help/statwan /usr/lib/nls/C/x25check.cat /usr/lib/nls/C/x25init.cat /usr/lib/nls/C/x25stat.cat /usr/netdemo/x25/Makefile /usr/netdemo/x25/client.c /usr/netdemo/x25/client2.c /usr/netdemo/x25/client2pvc.c /usr/netdemo/x25/clientpvc.c /usr/netdemo/x25/server.c /usr/netdemo/x25/server2.c /usr/netdemo/x25/server2pvc.c /usr/netdemo/x25/serverpvc.c SR#: 5003193300 5003179580 1653079764 5003181990 5003189605 5000707463 1653088708 1653083113 4701243626 4701243618 1653039834 5000686543 4701205161 5000699611 1653080101 "what" string/timestamp: /etc/x25check /etc/x25init /etc/x25server /etc/x25stop /etc/x25upload /usr/bin/x25stat /hp-ux X.25: Version: A.08.07 $Revision: 2.6 $ (18 May 94 12:32) "sum" output: 46913 83 /etc/conf/h/x25_diag.h 52434 359 /etc/conf/libx25.a 50899 59 /etc/conf/libx25ip.a 13013 120 /etc/conf/libx25pa.a 7221 17 /etc/conf/sio/pdn1.h 36382 25 /etc/conf/sio/pdn1_bp.h 37578 10 /etc/conf/sio/pdn1_efcp.h 60700 58 /etc/conf/sio/pdn1_spc.h 4691 8 /etc/conf/x25/x25.h 11494 3 /etc/conf/x25/x25addrstr.h 17819 12 /etc/conf/x25/x25config.h 24853 3 /etc/conf/x25/x25gen.h 64681 7 /etc/conf/x25/x25psidef.h 56585 24 /etc/conf/x25/x25stat.h 6365 9 /etc/conf/x25/x25str.h 11805 19 /etc/conf/x25/x25structs.h 38599 23 /etc/conf/x25/facilities.h 3470 8 /etc/conf/x25/alcpfac.h 35663 2 /etc/x25/x25_networks 13768 7 /etc/x25/x25init_def 59545 5 /etc/x25/x25init_smpl 56799 384 /etc/x25check 2351 496 /etc/x25init 56971 320 /etc/x25server 2351 496 /etc/x25stop 21859 248 /etc/x25upload 65243 312 /usr/bin/x25stat 44279 2 /usr/include/x25/ccittproto.h 4691 8 /usr/include/x25/x25.h 11494 3 /usr/include/x25/x25addrstr.h 58070 16 /usr/include/x25/x25codes.h 47176 4 /usr/include/x25/x25ioctls.h 6365 9 /usr/include/x25/x25str.h 44044 8 /usr/lib/help/initwan 44477 6 /usr/lib/help/statwan 21054 18 /usr/lib/nls/C/x25check.cat 54454 46 /usr/lib/nls/C/x25init.cat 27758 32 /usr/lib/nls/C/x25stat.cat 56740 2 /usr/netdemo/x25/Makefile 3728 7 /usr/netdemo/x25/client.c 6698 26 /usr/netdemo/x25/client2.c 15016 29 /usr/netdemo/x25/client2pvc.c 1051 25 /usr/netdemo/x25/clientpvc.c 9486 9 /usr/netdemo/x25/server.c 24874 18 /usr/netdemo/x25/server2.c 38534 21 /usr/netdemo/x25/server2pvc.c 50396 18 /usr/netdemo/x25/serverpvc.c Dependencies: PHNE_4106 Supersedes: PHNE_1250 PHNE_2015 PHNE_2649 PHNE_3083 PHNE_3132 Patch Package Size: 1823 Kbytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide, or your Hewlett-Packard support terms and conditions for scope of license, restrictions, and limitation of liability and warranties, before installing this patch. Note: Please back up your system before installing your patch. ---------------------------------------------------------------------------- After getting the patch onto your machine, unshar the patch (sh PHNE_4275). To install this patch do the following: 0) Set the system in single-user mode 1) Run "ps -ef" to make sure that the processes x25server, x25stat, x25init, x25stop, x25upload, x25check have been killed, and if not kill them with the kill -9 command. 2) Run /etc/update (Note: you must be logged in as root to update a system). 3) Once in the update "Main Menu" move the highlighted line to "Change Source or Destination ->" and press "Return" or "Select Item". 4) Make sure the highlighted item in the "Change Source or Destination" window is "From Tape Device to Local System ...", then press "Return" or "Select Item". 5) You should now be in the "From Tape Device to Local System" window. Change the "Source: /dev/rmt/0m" to "Source: /tmp/PHNE_4275.updt" (this assumes that you are in the /tmp directory where PHNE_4275.updt has been placed). Note: You must enter the complete path name. 6) Press "Done". 7) From here on follow the standard directions for update. The customized script that update runs will move the original software to /system/PHNE_4275/orig. HP recommends keeping this software there in order to recover from any potential problems. It is also recommended that you move the PHNE_4275.text file to /system/PHNE_4275 to be retained for future reference. If you wish to put this patch on a magnetic tape and update from the tape drive, dd a copy of the patch to the tape drive. As an example the following will create a copy of the patch that update can read: dd if=PHNE_4275.updt of=/dev/rmt/0m bs=2048.