Archive-Date: Thu, 5 Apr 2001 08:52:35 -0400 Date: Thu, 05 Apr 2001 08:59:58 -0400 (EDT) From: Gary Reynolds Reply-To: Info-TCPware@process.com Subject: Java Telnet Applet - Problem accessing from Netscape Communicator V4.76 and Process Software TCPware/PURVEYOR Web Server (fwd) To: marcus@jet.franken.de, leo@mud.de, info-tcpware@process.com, PURVEYOR@cjis.ci.lincoln.ne.us Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mr. Meissner, Thank you for your assistance in my problem with the Java Telnet applet v2.0 After sending the message below, I was able to locate a source for v1.0 version of the applet and have been able too install and get it to run successfully in my configuration with Open VMS 6.2, Process Software's PURVEYOR web-server and TCPware TCP/IP stack; and finally, access from Netscape Communicator V4.76. I would request that you keep my request active as a possible bug in JTA v2.0 implementations on Open VMS. I suspect that there is some issue with Purveyor's defined Virtual Paths/Directories requiring that documents of certain types be in "specific directories" under the Root webserver WORKER directory - and possibly - in conjunction with JTA v2.0 requirement for specific directory/URL definition of the client's call to the webserver from which the applet is downloaded for .CONF and Plug-ins extraction. Anyway, thank you and to some other respondents I've included in this reply. Gary Reynolds Waynesburg College greynold@waynesburg.edu ---------- Forwarded message ---------- Date: Wed, 4 Apr 2001 08:53:15 -0400 (EDT) From: Gary Reynolds To: marcus@jet.franken.de Subject: Java Telnet Applet - Problem accessing from Netscape Communicator V4.76 and Process Software TCPware/PURVEYOR Web Server (fwd) Mr. Meissner, I've still not been successful in isolating problem between the JTA20 applet and my telnet/web server... And still am puzzled by the fact that Internet Explorer works perfectly fromt the very same desktop. While researching problem, it has become apparent that the earlier JTA 1.0 does work with Netscape Communicator. It takes a little longer to load from the various Internet web sites I've visited but it does work. Can you direct me to a Doc archive web site where I might find the setup configuration directions for the earlier version since it is no longer supported ? Thanks, Gary ---------- Forwarded message ---------- Date: Tue, 27 Mar 2001 11:58:59 -0500 (EST) From: Gary Reynolds To: Marcus Meissner Cc: Matthias L Jugel , corbett@process.com Subject: Java Telnet Applet - Problem accessing from Netscape Communicator V4.76 and Process Software TCPware/PURVEYOR Web Server Mr. Meissner, I've continued on this and your last suggestion to check Java Console indicated two problems that are not encountered when activating JTA20 from Internet Explore. I am forwarding a copy of this message to Michael Corbett at Process Software as he has been working with me somewhat in determining what is going on. Some of the information below may/may not be significant to you but Mr. Corbett will know the Purveyor Web-server aspects related ... First error indicates DEFAULT.CONF can not be found or opened. Solution: By moving DEFAULT.CONF to Alpha's HTTPD Worker directory instead ******** of from the exact calling URL of JTA20.JAR, this message no longer is being logged to the Java Console. Second error, similar to the first but indicates Plug-ins not found ... I'm not sure what needs done here ... I've tried copying related JTA20 files to the HTTPD Worker directory but that has not solved problem Any further directions are appreciated. Most of my desktop users use Communicator as their browser. Thanks, Gary Reynolds ================================================================================ Archive-Date: Mon, 9 Apr 2001 13:30:34 -0400 Date: Mon, 09 Apr 2001 11:29:20 -0600 From: Dan O'Reilly Reply-To: Info-TCPware@process.com Subject: Possible (X)NTP Security Issue To: info-multinet@process.com, info-tcpware@process.com Message-ID: <5.0.2.1.2.20010409112601.00a872a8@ntbsod.psccos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Regarding CERT Vulnerability Note VU#970472, issued 4 April 2001: We at Process Software don't know much about the specifics of the problem, but at this point, while the XNTP process may be vulnerable to being terminated by an attack, we don't believe the system itself is left open to possible attack by somebody gaining access to the system via XNTP. This is mostly a UNIX issue. When there is a definite fix for this, we will release it as an ECO. ------------------------------------------------------------------------- Vulnerability Note VU#97047 Network Time Protocol ([x]ntpd) daemon contains buffer overflow in ntp_control:ctl_getitem() function Overview There is a buffer overflow defect in the ctl_getitem() function of the Network Time Protocol (NTP) daemon responsible for providing accurate time reports used for synchronizing the clocks on installed systems. All NTP daemons based on code maintained at the University of Delaware since NTPv2 are assumed at risk. I. Description The buffer overflow condition appears in the ctl_getitem() function in ntp_control.c, the NTP control code. Because the ntp protocol uses UDP, attacks attempting to exploit this vulnerability will likely be spoofed. II. Impact It has been reported a remote intruder can execute arbitrary code with the default privileges on the running daemon, typically root. While this report is still being evaluated, crashing of the NTP daemon has been confirmed. ------------------------------------------------------------------------- ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ ================================================================================ Archive-Date: Mon, 16 Apr 2001 09:18:41 -0400 Date: Mon, 16 Apr 2001 15:16:38 +0200 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: [TCPware V5.5-3] VPM_SERVER loops at prio 15 after TCPware shutdown To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3adaf0b6$1@news.kapsch.co.at> I wrote some months ago, >In case I hadn't already told you: > >Shutting down TCPware before shutting down the VPM_SERVER (configured for >and running over TCP/IP of course - by defining the logical MNR$PORT_NUMBER >to 5354) leads to a looping process at prio 15 hence a dead machine !! As I already corrected this the last time: It is done by running SYS$STARTUP:VPM$STARTUP.COM which does define this logical but also starts the monitor process itself. >This does NOT happen on UCX or TCPIP nodes, only on TCPware. >BEWARE. > >-Peter > >PS: PSC, please try to (aim to) find the reason some time and provide a fix >(for TCPware or maybe VPM_SERVER). All of this was true with TCPware V5.4 (and before) and unfortunately IS STILL TRUE WITH the new TCPware V5.5 !! Sigh. >PPS: PSC, please add the following line to your TCPWARE:SERVICES. file: > >vpm 5354/tcp # VMS VPM Server (MONITOR) Thanks for adding this (and many other of my suggestions) to TCPWARE:SERVICES. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Mon, 16 Apr 2001 09:50:17 -0400 Date: Mon, 16 Apr 2001 09:48:53 -0400 From: Chris Moore Subject: LPS stall problem To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Having a problem where one particular user report seems to occasionally stall whatever LPS queue it is sent to. The printers are generally HP LaserJet 4000N's, we're running OpenVMS 7.1 (VAX) with TCPware 5.4-3. User claims this only started happening since the TCPware upgrade from 5.3-2, and the report won't ALWAYS stall the queues. I've looked at the report file and can't find anything unusual (other than it is 132 columns and LOTS of lines), and the PRINT command calls for a customized form definition (which works fine for other jobs). I had seen similar situations in the past on LAT queues, which we solved by twiddling the terminal width spec. Is it possible that a 'data overrun' or some such could be involved here? If so, how do I deal with it on an LPS queue? Thanks for any input Chris Moore Stelco Inc. ================================================================================ Archive-Date: Mon, 16 Apr 2001 10:19:44 -0400 Date: Mon, 16 Apr 2001 10:18:44 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: LPS stall problem To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86039E7B2A@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 There's not enough information here to say what's happening, so I'll just give some general info and hope I hit something, and ask a few questions too. :^) The fact that it only stalls *sometimes* would seem to indicate that it's not a symbiont bug. If software works once, it will work again...at least for the same data. When you say "particular user report" I don't know if that means the same data, or just the same monthly (or whatever) job results. With some forms of data, such as PostScript, "lines" are arbitrary, and often very long. You don't say what the custom form settings are, or what form the report is in, but the default form has a fairly narrow width, and is set to truncate long lines. Sending PostScript with this form often results in failure, as parts of the PostScript (which is really a program) get truncated and the remainder isn't valid. You have to use a form set to notruncate and nowrap to get around this. Most folks also set the width to 65532 just to be safe, though this shouldn't matter. Setting the queue, or the job, as "passthru" is also a good idea, as this prevents the symbiont formatting code from sticking things like page breaks into the data stream...it gets sent the way it is read in. When data isn't ASCII text, this is often required to prevent corruption. When queues stall it's because the symbiont is waiting for something, and that something isn't happening. This is often a printer ack of some sort, though it can be just the printer accepting data again if the printer halted acceptance for some reason (dropped window size to zero for example). A printer's buffer may be full, there could be a network problem, the printer might have a bug, some command sequence might have gotten corrupted and no longer makes sense, or a number of other reasons. Seeing things like symbiont logs and network traces often helps resolve which cause is happening in a particular situation. You say that this started happening after an upgrade of TCPware. This could be coincidence, but if not, can you provide some information on the queue setup? Is the problem reproducible? If so, can you reproduce it with a small portion of the job? If none of the above helps you resolve this, you should contact our support folks for some assistance. -- Mike Bartman Process Software > -----Original Message----- > From: Chris Moore [mailto:chris.moore@stelco.ca] > Sent: Monday, April 16, 2001 9:49 AM > To: info-tcpware@process.com > Subject: LPS stall problem > > > Having a problem where one particular user report seems to > occasionally > stall whatever LPS queue it is sent to. The printers are generally HP > LaserJet 4000N's, we're running OpenVMS 7.1 (VAX) with > TCPware 5.4-3. User > claims this only started happening since the TCPware upgrade > from 5.3-2, and > the report won't ALWAYS stall the queues. > > I've looked at the report file and can't find anything > unusual (other than > it is 132 columns and LOTS of lines), and the PRINT command > calls for a > customized form definition (which works fine for other jobs). > > I had seen similar situations in the past on LAT queues, > which we solved by > twiddling the terminal width spec. Is it possible that a > 'data overrun' or > some such could be involved here? If so, how do I deal with > it on an LPS > queue? > > Thanks for any input > > Chris Moore > Stelco Inc. > > ================================================================================ Archive-Date: Tue, 17 Apr 2001 10:39:19 -0400 Date: Tue, 17 Apr 2001 08:39:42 -0600 From: "Peebles, Darwin" Reply-To: Info-TCPware@process.com Subject: NETCU Debug ? To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain Is there any way to use NETCU's debug (DEBUG/IP/...) parameters (such as /DIA and /SIA) to show all network traffic except the LAN (intranet) traffic? My network is 192.112.10.0 (mask 255.255.255.0). I want to show all incoming network traffic that is not from 192.112.10.0 and all outgoing network traffic that is not to 192.112.10.0 (mask 255.255.255.0). I'm running OpenVMS V7.2-1 on an AlphaServer with TCPware V5.3-3. Thanks, Darwin "Peebs" Peebles Information Technology Specialist 4 Honeywell Technology Solutions, Inc. NASA, JSC, White Sands Test Facility Mail Stop 101P P.O. Box 20 Las Cruces, NM 88004 Phone: 505-524-5619 Fax: 505-524-5544 E-mail: dpeebles@wstf.nasa.gov ================================================================================ Archive-Date: Tue, 17 Apr 2001 11:06:00 -0400 Date: Tue, 17 Apr 2001 11:05:01 -0500 (EST) From: Jeff Schreiber Reply-To: Info-TCPware@process.com Subject: Re: NETCU Debug ? To: info-tcpware@process.com Message-ID: <01K2I5C5SQW0A3DHQE@ALCOR.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii "Peebles, Darwin" writes: > >Is there any way to use NETCU's debug (DEBUG/IP/...) parameters (such as >/DIA and /SIA) to show all network traffic except the LAN (intranet) >traffic? My network is 192.112.10.0 (mask 255.255.255.0). I want to show >all incoming network traffic that is not from 192.112.10.0 and all outgoing >network traffic that is not to 192.112.10.0 (mask 255.255.255.0). > >I'm running OpenVMS V7.2-1 on an AlphaServer with TCPware V5.3-3. > You might find TCPDump better to use. NETCU HELP TCPDUMP will give you some details, and you find find more in the management guide. With TCPdump you can do such things as: $netcu tcpdump /nohost/hex/output=output.txt not src net 192.112.10 There is a lot of details and examples in the management guide. -Jeff -- Jeff Schreiber, Process Software LLC schreiber@mx.process.com http://www.process.com TCPware, MultiNet & PMDF: Stronger than Ever ================================================================================ Archive-Date: Fri, 27 Apr 2001 10:17:59 -0400 Date: Fri, 27 Apr 2001 09:11:33 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SMTP_V543P060 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01K2W0MCMNQA003C8E@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: SMTP_V543P060 Description: Correct startup in certain conditions Release date: Ranking: Max ranking: Versions: 5.4-3 ftp://ftp.process.com/support/54_3/smtp_v543p060.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- SMTP Patch kit (revision 6.0) for TCPware version 5.4-3 18-Apr-2001 Copyright (c) 2000, 2001, by Process Software This VMSinstallable saveset provides a new version of several SMTP images for TCPware for OpenVMS. TCPWare V5.4-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following changes have been made in this kit: - Correct a problem with the startup procedure (written by TCPWARE CONFIGURE/MAIL) that can cause SMTP to fail to start in some situations. DE 6461 ECO SMTP_V543P060 ECO Rank: 3 (Corrects a specific problem) - Correct a problem in MULTINET_SOCKET_LIBRARY that may cause the SMTP_SYMBIONT to leave channels open to DNS (UDP port 53) D/E 6508 ECO SMTP_V543P051 ECO Rank: 2 (Recommened patch) - Correct the name of the logical used to override the name of the debug log file for the SMTP symbiont. To enable SMTP Symbiont debugging, define the system-wide logical TCPWARE_SMTP_SYMBIONT_LOG to be TRUE. That'll create log files named like: TCPWARE:TCPWARE_SMTP_LOG.queuename To override the default filename, simply define the system-wide logical TCPWARE_SMTP_LOG to be the desired filename. D/E 6661 ECO SMTP_V543P050 ECO Rank: 3 (Corrects a specific problem) - Use TCPWARE_TIMEZONE_NAME or TCPWARE_TIMEZONE to determine the offset from GMT. DE 5650 ECO SMTP_V543P040 ECO Rank: 3 (corrects a specific problem) - Fix a problem where if the first line of a message was greater than 512 characters that the text of the file would not be sent. If the first line was reasonable, but later lines were too long, they would be truncated. DE 6599 ECO SMTP_V543P030 ECO Rank: 3 (corrects a specific problem) - Modify startup and shutdown procedures to only operate on the queues that are on the system that the command procedure is being executed on. This allows SMTP to be shutdown on one member of a cluster without effecting any of the other nodes in the cluster. DE 6461 ECO SMTP_V543P030 ECO Rank: 3 (corrects a specific problem) - Correct an error with host address lookup introduced in SMTP_V543P010. DE 6592 ECO SMTP_V543P030 ECO Rank: 3 (corrects a specfic problem) - When TCPWARE_SMTP_IGNORE_INTERFACE_NAMES is defined (/system, any value) the SMTP mail delivery procedure does not compare the destination address with the addresses of the interfaces on the system to determine if the message could be delivered locally. The default (no logical defined, old behavior) is to check the addresses of the interfaces on the system. Defining the logical causes the MX records to be used exclusively in determining where a mail message should be delivered to. DE 6438 ECO SMTP_V543P030 ECO rank: 3 (corrects a specific problem) - Corrects an ACCVIO error in SMTP_SERVER that happens under certain conditions. (D/E 6532 ECO SMTP_V543P020) ECO rank: 3 (corrects a specific problem) - Provide a new version of the SMTP symbiont that can resolve names out of either the HOSTS file or DNS. (D/E 6266) ECO SMTP_V543P010 ECO rank: 3 (corrects a specific problem) - Corrects a BADBLOADDR (bad block address) error on VAXen when mail is sent from VMS Mail and user-defined headers are present. (D/E 6453) ECO SMTP_V543P010 ECO rank: 3 (corrects a specific problem) - Corrects a potential INET channel leak in certain error conditions. (D/E 6530) ECO SMTP_V543P010 ECO rank: 3 (corrects a specific problem) After installing the patch kit you should do the following sequence of commands to cause the new startup and images to be used: $ tcpware configure/mail MAIL-CONFIG> write MAIL-CONFIG> exit $ @tcpware:start_smtp [End of ECO announcement]