Archive-Date: Sat, 9 Jan 1999 01:42:30 -0400 From: "Steve Simmons" Reply-To: Info-TCPware@process.com Subject: UCX vs TCPWare Date: Fri, 8 Jan 1999 17:35:08 -0000 Message-ID: <775fmp$i24$1@plug.news.pipex.net> To: Info-TCPware@PROCESS.COM Not an invitation for a flame war... just a question from a guy with a problem. We have a program on VAX (running TCPWare). The program is COBOL and runs FTP to send a file to a remote system (owned by another organisation). The TCPWare calls are nice and friendly for COBOL programmers. We want to 'port' this program to an Alpha VMS based system. As you will know, UCX comes 'free' with Alpha VMS and we'd rather not buy TCPWare just to support one application. Unfortunately, we don't seem to be able to track down any documentation to allow us to program UCX from COBOL in the same way we have with TCPWare. Has anybody programmed simple file transfer from COBOL with UCX? Can anybody point me to the right manual/docs? For completeness, the calls we are using are: FTP_OPEN_CONNECTION FTP_CLOSE_CONNECTION FTP_ALLOCATE_CCB FTP_DEALLOCATE_CCB FTP_USER FTP_PASSWORD FTP_SET_DIRECTORY FTP_PUT_FILE (Not necessarily in that order!!) Any help gratefully received. ================================================================================ Archive-Date: Mon, 11 Jan 1999 04:40:33 -0400 From: Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) Reply-To: Info-TCPware@process.com Subject: TCPware 5.3-3 Date: 11 Jan 99 00:27:22 GMT Message-ID: <5ca_9901110600@neverlnd.org.uk> To: Info-TCPware@PROCESS.COM Friday December 11 1998, bryant@process.com writes to All: b> TCPware 5.3-3 is indeed a maintenance release which did include the b> pseudo-device feature. Seeing that most who have commented are non-US b> customers, I suggest you contact your distributor. Hmmm... Another UK user on Maint Agreement who DID NOT get any updates... Last update I had was 5.3-2. Maybe Process should perform a Supplier Audit on the UK Resellers and Support operations ? Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- +-------------------------------------------------------------------------+ | Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | |Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | | pdb@post.neverlnd.org.uk UK | +---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ ================================================================================ Archive-Date: Mon, 11 Jan 1999 08:07:52 -0400 Sender: bryant@process.com Date: Mon, 11 Jan 1999 08:04:23 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D20C1.767A0EBD.65@process.com> Subject: RE: TCPware 5.3-3 Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) writes: > >Friday December 11 1998, bryant@process.com writes to All: > >b> TCPware 5.3-3 is indeed a maintenance release which did include the >b> pseudo-device feature. Seeing that most who have commented are non-US >b> customers, I suggest you contact your distributor. > >Hmmm... Another UK user on Maint Agreement who DID NOT get any updates... Last >update I had was 5.3-2. > >Maybe Process should perform a Supplier Audit on the UK Resellers and Support >operations ? I am forwarding your mail to the appropriate people here at Process. >Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk > ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >-- >+-------------------------------------------------------------------------+ >| Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | >|Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | >| pdb@post.neverlnd.org.uk UK | >+---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ > ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Tue, 12 Jan 1999 22:12:11 -0400 Subject: Re: TCPware 5.3-3 Message-ID: <369bda2d.122050419@news.process.com> From: izzi@process.com (Terri Izzi) Reply-To: Info-TCPware@process.com Date: Tue, 12 Jan 1999 23:30:45 GMT To: Info-TCPware@PROCESS.COM On Thu, 10 Dec 1998 08:34:16 PST, "John Richardson" wrote: >In a message "Re: Multiple network cards on the same network?" Bernie >Volz wrote: > > ...just configure secondary addresses or pseudo interface (the > latter requires TCPware 5.3-3 ... contact Support to get it if you > have not yet received it). > >What is the status of 5.3-3? Should customers on Support have received >it automatically? I work on several customer sites in the UK and have >not come accross 5.3-3. > >Also, apart from pseuodo interfaces (which at least one of my customers >has been waiting a while for), what others goodies are in 5.3-3. Are >details available on your Web site? > >John Richardson > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com Just a reminder, maintenance releases are available to end users with maintenance contracts on a request-only basis. New full releases are the only ones automatically shipped - again, to end users with valid maintenance contracts. Terri Izzi, Technical Support Manager Process Software Corporation ================================================================================ Archive-Date: Wed, 13 Jan 1999 07:43:57 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPware 5.3-3 Date: 13 Jan 99 12:23:21 GMT Message-ID: <369c9039.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <369bda2d.122050419@news.process.com>, izzi@process.com (Terri Izzi) writes: Hi Terri >Just a reminder, maintenance releases are available to end users with >maintenance contracts on a request-only basis. That's news to me. But I agree... >New full releases are the only ones automatically shipped - again, to >end users with valid maintenance contracts. Matches my experiences. But it's sad that I as an end user has to tell my distributor of the existence of a new maint version (and not to forget, my dist got the V5.3-3 months after me). ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Wed, 13 Jan 1999 08:44:40 -0400 Message-ID: <369C871C.F5C3FD98@SMTP.DeltaTel.RU> Date: Wed, 13 Jan 1999 14:44:28 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPware 5.3-3 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Terri Izzi wrote: > > On Thu, 10 Dec 1998 08:34:16 PST, "John Richardson" > wrote: > > >In a message "Re: Multiple network cards on the same network?" Bernie > >Volz wrote: > > > > ...just configure secondary addresses or pseudo interface (the > > latter requires TCPware 5.3-3 ... contact Support to get it if you > > have not yet received it). > > > >What is the status of 5.3-3? Should customers on Support have received > >it automatically? I work on several customer sites in the UK and have > >not come accross 5.3-3. > > > >Also, apart from pseuodo interfaces (which at least one of my customers > >has been waiting a while for), what others goodies are in 5.3-3. Are > >details available on your Web site? > > > >John Richardson > > > > > >______________________________________________________ > >Get Your Private, Free Email at http://www.hotmail.com > > Just a reminder, maintenance releases are available to end users with > maintenance contracts on a request-only basis. > > New full releases are the only ones automatically shipped - again, to > end users with valid maintenance contracts. I have valid maitenance contract but have had not any announcement from reseller about 5.3-3!!! Why your can't do update-annoucement with mail-list like vms-patches ? > > Terri Izzi, Technical Support Manager > Process Software Corporation -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 13 Jan 1999 15:41:20 -0400 From: Pat Smith Reply-To: Info-TCPware@process.com Subject: Forwarding mail in VMS Date: Wed, 13 Jan 1999 12:15:53 -0800 Message-ID: <369CFEF8.7E717D23@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Greetings, I am trying to forward mail from a DEC Alpha machine running OpenVMS AXP Operating System, Version V6.2-1H3 and TCPware(R) for OpenVMS V4.1-2, Patch level V4.1-2A to an Intel box running MS Exchange server. Both are on the same subnet. The VMS machine is not using DNS, but rather a local hosts' file. I've added an entry to the host. file to map the IP address of the Exchange box to a domain name and alias as such: # HOSTS. # # Define host names and their internet addresses. # # Syntax: internet-address host-name [alias[ alias...]] # 200.1.1.248 ALPHA1 #DEC Alpha 2100 200.1.1.251 EXCHANGE EXCHANGE #MICROSOFT EXCHANGE SERVER # From a DCL prompt I can now ping EXCHANGE without problem, as well as telnet into its SMTP port 25. However, from within MAIL, I get the following error message: MAIL> forward To: johnd@exchange %MAIL-E-LOGLINK, error creating network link to node EXCHANGE -SYSTEM-F-IVNODNAM, invalid node name Any ideas what the problem might be? Any suggestions would be greatly appreciated. Regards, Pat upastream@yahoo.com ================================================================================ Archive-Date: Wed, 13 Jan 1999 15:44:45 -0400 Date: Wed, 13 Jan 1999 14:41:08 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: upastream@yahoo.com Message-ID: <009D228B.38883235.6@goat.process.com> Subject: RE: Forwarding mail in VMS Pat Smith writes: > >However, from within MAIL, I get the following error message: > >MAIL> forward >To: johnd@exchange >%MAIL-E-LOGLINK, error creating network link to node EXCHANGE >-SYSTEM-F-IVNODNAM, invalid node name > >Any ideas what the problem might be? Any suggestions would be greatly >appreciated. > VMS Mail is rewriting "johnd@exchange" as "EXCHANGE::JOHND" and trying to create a DECnet link. You can defeat this by using a domain name that includes "." (for example, "johnd@exchange.yourco.com"). Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 13 Jan 1999 15:50:41 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86A7F0D6@lespaul.process.com> From: Richard Whalen Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: Forwarding mail in VMS Date: Wed, 13 Jan 1999 15:53:24 -0500 MIME-Version: 1.0 Content-Type: text/plain Generally you have to prefix internet mail addresses with SMTP% on VMS. Often you need to quote the portion of the address after the SMTP%. To set a forwarding address the format is SET FORWARD "SMTP%""user@node""" With VMS 6.2 and later it is not necessary to prefix the internet mail address with SMTP%. Page 16-8 in the TCPware 5.3 management guide (I don't have an earlier version) says you can do this by defining TCPWARE_SMTP_NOPREFIX $ DEFINE/SYSTEM/EXEC TCPWARE_SMTP_NOPREFIX * and restarting the SMTP component. ---------------------- Richard Whalen Process Software Corporation 508-879-6994x261 -----Original Message----- From: Pat Smith [mailto:upastream@yahoo.com] Sent: Wednesday, January 13, 1999 3:16 PM To: Info-TCPware@PROCESS.COM Subject: Forwarding mail in VMS Greetings, I am trying to forward mail from a DEC Alpha machine running OpenVMS AXP Operating System, Version V6.2-1H3 and TCPware(R) for OpenVMS V4.1-2, Patch level V4.1-2A to an Intel box running MS Exchange server. Both are on the same subnet. The VMS machine is not using DNS, but rather a local hosts' file. I've added an entry to the host. file to map the IP address of the Exchange box to a domain name and alias as such: # HOSTS. # # Define host names and their internet addresses. # # Syntax: internet-address host-name [alias[ alias...]] # 200.1.1.248 ALPHA1 #DEC Alpha 2100 200.1.1.251 EXCHANGE EXCHANGE #MICROSOFT EXCHANGE SERVER # From a DCL prompt I can now ping EXCHANGE without problem, as well as telnet into its SMTP port 25. However, from within MAIL, I get the following error message: MAIL> forward To: johnd@exchange %MAIL-E-LOGLINK, error creating network link to node EXCHANGE -SYSTEM-F-IVNODNAM, invalid node name Any ideas what the problem might be? Any suggestions would be greatly appreciated. Regards, Pat upastream@yahoo.com ================================================================================ Archive-Date: Thu, 14 Jan 1999 18:22:11 -0400 From: Pat Smith Reply-To: Info-TCPware@process.com Subject: Re: Forwarding mail in VMS Date: Thu, 14 Jan 1999 15:12:37 -0800 Message-ID: <369E79E5.A5D251C1@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Thank you for all the help. Turns out that I needed a number of things set-up to make this work. Among them SMTP running on the VMS side, and a valid license from the makers of TCPWare. Again, thanks. ================================================================================ Archive-Date: Tue, 19 Jan 1999 12:46:59 -0400 From: Dawn and Todd Smith Reply-To: Info-TCPware@process.com Subject: Re: UCX vs TCPWare Date: Sun, 17 Jan 1999 20:42:31 -0800 Message-ID: <77udm2$rce$1@news-2.news.gte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM uhhhh UCX is not free. At Digital there is no such thing as free. You either have a NAS package or TCP/IP Services For Vax VMS. And neither license is portable to another platform i.e. Vax to Alpha they will however give you 75% of the lessor license as credit. ...sorry, been there done that, Todd Steve Simmons wrote: > Not an invitation for a flame war... just a question from a guy with a > problem. > > We have a program on VAX (running TCPWare). The program is COBOL and runs > FTP to send a file to a remote system (owned by another organisation). The > TCPWare calls are nice and friendly for COBOL programmers. > > We want to 'port' this program to an Alpha VMS based system. As you will > know, UCX comes 'free' with Alpha VMS and we'd rather not buy TCPWare just > to support one application. > > Unfortunately, we don't seem to be able to track down any documentation to > allow us to program UCX from COBOL in the same way we have with TCPWare. > > Has anybody programmed simple file transfer from COBOL with UCX? > Can anybody point me to the right manual/docs? > > For completeness, the calls we are using are: > > FTP_OPEN_CONNECTION > FTP_CLOSE_CONNECTION > FTP_ALLOCATE_CCB > FTP_DEALLOCATE_CCB > FTP_USER > FTP_PASSWORD > FTP_SET_DIRECTORY > FTP_PUT_FILE > > (Not necessarily in that order!!) > > Any help gratefully received. ================================================================================ Archive-Date: Tue, 19 Jan 1999 15:46:50 -0400 From: "SYSMON" Reply-To: Info-TCPware@process.com Subject: Internet Server API (ISAPI) FOR VAX Message-ID: <7Q4p2.766$bi.610@news12.ispnews.com> Date: Tue, 19 Jan 1999 13:14:11 -0000 To: Info-TCPware@PROCESS.COM Can anyone help me with writing a API using Fortran. I have looked at the C code examples and tried to compile them using a VAX c++ compiler and I get err(s). I just need the stub that contains the following: Contain the entry point GetExtensionVersion Contain the entry point HttpExtensionProc as its main entry point. The structure for Extension Control Block in Fortran not the PURVEYOR_EXTDLL.H include file The defined Callback Functions Terminate with a return value as specified for the HttpExtensionProc entry point. Thanks Bruce_Laird@pattersondental.com ================================================================================ Archive-Date: Wed, 20 Jan 1999 10:15:52 -0400 Sender: LUTES@textron.com Message-ID: <36A59DCE.774CB705@cessna.textron.com> Date: Wed, 20 Jan 1999 09:11:42 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware Subject: NFS server failures Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Have any of you seen this or can you suggest a place to start troubleshooting? I am running TCPware 5.3-2 on both VAX and Alpha platforms. The NFS server freequently bugchecks on me. NFSSERVER.LOG contains a lot of entries like: %NFS-E-BUGCHECK, unexpected close status, fid (22391,1,0) -SYSTEM-F-IVCHAN, invalid I/O channel Once this begins, everything is pretty well hosed until I stop and restart the NFS server. Any ideas? Thanks in advance, Dale ================================================================================ Archive-Date: Wed, 20 Jan 1999 10:38:25 -0400 Date: Wed, 20 Jan 1999 16:36:07 +0100 From: Dick.Cozijnsen@kender-thijssen.nl Reply-To: Info-TCPware@process.com Subject: RE: NFS server failures To: Info-TCPware@process.com Message-ID: <31942E4743A6D21185DC00805FA137960672EB@aquarius.intra.kender-thijssen.nl> MIME-Version: 1.0 Content-Type: text/plain Dale, Have you tried this patch already : NFSD_V532P010 You can download it from ftp.procees.com (support/532) Regards, Dick Cozijnsen > ---------- > From: Dale Lutes[SMTP:dlutes@cessna.textron.com] > Sent: woensdag 20 januari 1999 16:11 > To: Info-TCPware > Subject: NFS server failures > > Have any of you seen this or can you suggest a place to > start troubleshooting? I am running TCPware 5.3-2 on > both VAX and Alpha platforms. The NFS server freequently > bugchecks on me. NFSSERVER.LOG contains a lot of entries > like: > > %NFS-E-BUGCHECK, unexpected close status, fid (22391,1,0) > -SYSTEM-F-IVCHAN, invalid I/O channel > > Once this begins, everything is pretty well hosed until > I stop and restart the NFS server. Any ideas? > > Thanks in advance, > Dale > ================================================================================ Archive-Date: Wed, 20 Jan 1999 11:44:20 -0400 Sender: LUTES@textron.com Message-ID: <36A5B28E.7E4BA35A@cessna.textron.com> Date: Wed, 20 Jan 1999 10:40:14 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Dick.Cozijnsen@kender-thijssen.nl CC: Info-TCPware@process.com Subject: Re: NFS server failures References: <31942E4743A6D21185DC00805FA137960672EB@aquarius.intra.kender-thijssen.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Have you tried this patch already : NFSD_V532P010 > > You can download it from ftp.procees.com (support/532) Dick, Thanks for the pointer. I was looking for patches in the wrong directory on the Process ftp site (/tcpware/vms instead of /support). I've got it installed. Now I'm just waiting to see if the problem is gone. Dale ================================================================================ Archive-Date: Wed, 20 Jan 1999 16:10:12 -0400 Subject: Re: NFS server failures Message-ID: <1999Jan20.132339@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 20 Jan 99 13:23:39 -0500 To: Info-TCPware@PROCESS.COM In article <36A5B28E.7E4BA35A@cessna.textron.com>, Dale Lutes writes: >> Have you tried this patch already : NFSD_V532P010 >> >> You can download it from ftp.procees.com (support/532) > > Dick, > > Thanks for the pointer. I was looking for patches in the > wrong directory on the Process ftp site (/tcpware/vms > instead of /support). I've got it installed. Now I'm > just waiting to see if the problem is gone. > > Dale If they do reoccur, please contact our Technical Support folks. You can use support@process.com (or see our web page for more details on how to reach the support group). - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 20 Jan 1999 16:42:03 -0400 Subject: Re: Internet Server API (ISAPI) FOR VAX Message-ID: <1999Jan20.132729@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 20 Jan 99 13:27:29 -0500 To: Info-TCPware@PROCESS.COM In article <7Q4p2.766$bi.610@news12.ispnews.com>, "SYSMON" writes: > Can anyone help me with writing a API using Fortran. I have looked at the C > code examples and tried to compile them using a VAX c++ compiler and I get > err(s). I just need the stub that contains the > following: > > Contain the entry point GetExtensionVersion > > Contain the entry point HttpExtensionProc as its main entry point. > > The structure for Extension Control Block in Fortran not the > PURVEYOR_EXTDLL.H include file > > The defined Callback Functions > > Terminate with a return value as specified for the HttpExtensionProc entry > point. > > Thanks > Bruce_Laird@pattersondental.com While likely technically possible, this interface was really designed for use with C and Process has nothing available for FORTRAN (and isn't likely to supply anything). There are likely a lot of tricks you'd need to play as strings and the way arguments are passed varies between C and FORTRAN. Regarding compiling with C++, the code was written to work with standard C, not C++. And, if might be best to use CC/STAND=VAX. - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 21 Jan 1999 11:30:19 -0400 Message-ID: <19990121162816.8742.rocketmail@send102.yahoomail.com> Date: Thu, 21 Jan 1999 08:28:16 -0800 (PST) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: Dual-homed Internet-connected server, using primary DNS To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii We use TCPware v5.3-2 on DEC Alpha. The 'DNS defined' book and the TCPware installations manuals are really good for how to set up a primary DNS server, and the example named.* files help a lot. My question is, what's the best way to set up a server to run primary DNS for the Internet side, and also for the internal LAN side? Our network is using the private class B set of IP numbers, and we'd like to run DNS for it as well. Should we just run it on a different (non-Internet) system? I've already got this scheme set up successfully on a Linux box, but that configuration is different from TCPware's. Thanks! Chris _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Thu, 21 Jan 1999 14:50:48 -0400 Subject: Re: Upgrade To TCPWare V5.3-2 Cause Link-Edit Errors Message-ID: <1999Jan20.215404@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 20 Jan 99 21:54:04 -0500 To: Info-TCPware@PROCESS.COM In article <785ke8$cim$1@igate.aco.aspentech.com>, jleslie@aco.aspentech.com (Jerry Leslie) writes: > The following post is for one of our developers at another site. > > "We just upgraded our ALPHA AXP VMS 6.2 from TCPWARE version 4.1 > to version 5.3-2 and had some difficulties rebuilding our products. > We got undefined symbols: > > %LINK-W-NUDFSYMS, 21 undefined symbols: > %LINK-I-UDFSYM, PMAP_UNSET > %LINK-I-UDFSYM, SVCERR_DECODE > %LINK-I-UDFSYM, SVCERR_NOPROC > %LINK-I-UDFSYM, SVCERR_SYSTEMERR > %LINK-I-UDFSYM, SVCFD_CREATE > %LINK-I-UDFSYM, SVCTCP_CREATE > %LINK-I-UDFSYM, SVC_REGISTER > %LINK-I-UDFSYM, SVC_RUN > %LINK-I-UDFSYM, SVC_SENDREPLY > %LINK-I-UDFSYM, XDR_ARRAY > %LINK-I-UDFSYM, XDR_BYTES > %LINK-I-UDFSYM, XDR_CHAR > %LINK-I-UDFSYM, XDR_ENUM > %LINK-I-UDFSYM, XDR_INT > %LINK-I-UDFSYM, XDR_LONG > %LINK-I-UDFSYM, XDR_POINTER > %LINK-I-UDFSYM, XDR_SHORT > %LINK-I-UDFSYM, XDR_U_CHAR > %LINK-I-UDFSYM, XDR_U_LONG > %LINK-I-UDFSYM, XDR_VECTOR > %LINK-I-UDFSYM, XDR_VOID > > We used to link to > > sys$share:tcpware_rpclib_shr.exe/share,- > sys$share:tcpware_socklib_shr.exe/share > > The question is where are these symbols defined at for this version > of TCPWARE?" > > Thanks in advance, > > --Jerry, > > Jerry R. Leslie jerry.leslie@aspentech.com Aspen Technology, Inc. > (my opinions are strictly my own) > We did upgrade the RPC library to a later version some time back. I don't recall all of the details and because you skipped many versions in your upgrade, the release notes probably no longer documented this. The TCPware 5.2 release notes (available from FTP.PROCESS.COM) has details on this change in section 2.26. Also, there is documentation in Chapter 15 (on ONC RPC) of the Programmer's Guide that should detail this as well. If you have questions or further problems, I suggest contacting our Technical Support folks (support@process.com). However, please do look at the documentation before doing so as it will hopefully explain this (I don't have a copy available at the moment to confirm this). - Bernie Volz Process Software ================================================================================ Archive-Date: Thu, 21 Jan 1999 15:06:07 -0400 Sender: schreiber@process.com Date: Thu, 21 Jan 1999 15:02:11 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D28D7.7C891ACE.79@process.com> Subject: RE: Dual-homed Internet-connected server, using primary DNS Chris Wolfe writes: > >My question is, what's the best way to set up a server to run primary >DNS for the Internet side, and also for the internal LAN side? Our >network is using the private class B set of IP numbers, and we'd like >to run DNS for it as well. Should we just run it on a different >(non-Internet) system? I've already got this scheme set up >successfully on a Linux box, but that configuration is different from >TCPware's. > With the current version of BIND, it is near to impossible... even with BIND 8 it's quite difficult. I would recommend you just run a seperate server for the internal zones. If you need your internal network resolving external names as well, you can set the internal server up to forward-only to the gateway server. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 21 Jan 1999 16:18:57 -0400 Message-ID: <19990121211742.11512.rocketmail@send104.yahoomail.com> Date: Thu, 21 Jan 1999 13:17:42 -0800 (PST) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: RE: Dual-homed Internet-connected server, using primary DNS To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Yeah, I wondered if setting up another internal server would be best. Thanks! ---Jeff Schreiber wrote: > > Chris Wolfe writes: > > > >My question is, what's the best way to set up a server to run primary > >DNS for the Internet side, and also for the internal LAN side? Our > >network is using the private class B set of IP numbers, and we'd like > >to run DNS for it as well. Should we just run it on a different > >(non-Internet) system? I've already got this scheme set up > >successfully on a Linux box, but that configuration is different from > >TCPware's. > > > > With the current version of BIND, it is near to impossible... even > with BIND 8 it's quite difficult. I would recommend you just run > a seperate server for the internal zones. If you need your internal > network resolving external names as well, you can set the internal > server up to forward-only to the gateway server. > > -Jeff > > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Fri, 22 Jan 1999 11:43:59 -0400 From: jleslie@aco.aspentech.com (Jerry Leslie) Reply-To: Info-TCPware@process.com Subject: Upgrade To TCPWare V5.3-2 Cause Link-Edit Errors Date: 20 Jan 1999 22:13:28 GMT Message-ID: <785ke8$cim$1@igate.aco.aspentech.com> Keywords: undefined,symbols,linking To: Info-TCPware@PROCESS.COM The following post is for one of our developers at another site. "We just upgraded our ALPHA AXP VMS 6.2 from TCPWARE version 4.1 to version 5.3-2 and had some difficulties rebuilding our products. We got undefined symbols: %LINK-W-NUDFSYMS, 21 undefined symbols: %LINK-I-UDFSYM, PMAP_UNSET %LINK-I-UDFSYM, SVCERR_DECODE %LINK-I-UDFSYM, SVCERR_NOPROC %LINK-I-UDFSYM, SVCERR_SYSTEMERR %LINK-I-UDFSYM, SVCFD_CREATE %LINK-I-UDFSYM, SVCTCP_CREATE %LINK-I-UDFSYM, SVC_REGISTER %LINK-I-UDFSYM, SVC_RUN %LINK-I-UDFSYM, SVC_SENDREPLY %LINK-I-UDFSYM, XDR_ARRAY %LINK-I-UDFSYM, XDR_BYTES %LINK-I-UDFSYM, XDR_CHAR %LINK-I-UDFSYM, XDR_ENUM %LINK-I-UDFSYM, XDR_INT %LINK-I-UDFSYM, XDR_LONG %LINK-I-UDFSYM, XDR_POINTER %LINK-I-UDFSYM, XDR_SHORT %LINK-I-UDFSYM, XDR_U_CHAR %LINK-I-UDFSYM, XDR_U_LONG %LINK-I-UDFSYM, XDR_VECTOR %LINK-I-UDFSYM, XDR_VOID We used to link to sys$share:tcpware_rpclib_shr.exe/share,- sys$share:tcpware_socklib_shr.exe/share The question is where are these symbols defined at for this version of TCPWARE?" Thanks in advance, --Jerry, Jerry R. Leslie jerry.leslie@aspentech.com Aspen Technology, Inc. (my opinions are strictly my own) ================================================================================ Archive-Date: Fri, 22 Jan 1999 19:11:18 -0400 Subject: Re: AST delivery in UDP Driver Message-ID: <36A8F05D.19E9@process.com> From: Geoff Bryant Reply-To: Info-TCPware@process.com Date: Fri, 22 Jan 1999 16:40:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hal Kuff wrote: > > We have some code that opens 6 connections (host + port). > We open seperate connections naming host/port. > > We then queue up AST's for each connection using an event flag > to determine what connection came back (helps with Sys$Synch > as well as we are SMP (4100 Alpha) > > We then turn on AST processing Sys$SetAst(1) and Sys$Hiber > > When something comes back, that is to say the next statement after > Sys$Hiber fires, we turn AST processing back off and handle the > packet. > > We then re-execute the QIO/AST call and trun on Ast processing > and Hibernate again > > When we start the program, all the channels receive packets, then > after a few minutes, some channels drop out and never get another > packet... even though Netcu Debug/Udp shows traffic. > > Looking for clues on AST processing in Tcpware.... > > Hal Kuff For the sake of folks on the newsgroup, Hal and I discussed this onthe phone and he has a couple of things to try. Hal can followup later when he has things working. -- ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Sat, 23 Jan 1999 11:43:19 -0400 From: "Hal Kuff" Reply-To: Info-TCPware@process.com Subject: AST delivery in UDP Driver Date: Fri, 22 Jan 1999 12:35:10 -0500 Message-ID: To: Info-TCPware@PROCESS.COM We have some code that opens 6 connections (host + port). We open seperate connections naming host/port. We then queue up AST's for each connection using an event flag to determine what connection came back (helps with Sys$Synch as well as we are SMP (4100 Alpha) We then turn on AST processing Sys$SetAst(1) and Sys$Hiber When something comes back, that is to say the next statement after Sys$Hiber fires, we turn AST processing back off and handle the packet. We then re-execute the QIO/AST call and trun on Ast processing and Hibernate again When we start the program, all the channels receive packets, then after a few minutes, some channels drop out and never get another packet... even though Netcu Debug/Udp shows traffic. Looking for clues on AST processing in Tcpware.... Hal Kuff ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:21:05 -0400 From: "ddli " Reply-To: Info-TCPware@process.com Subject: TCPWARE 5.3 / VMS 6.2 Date: 30 Nov 1998 11:36:24 GMT Message-ID: <01be1c55$87037060$1b083e0a@ps027-ishbg.neurope.ikea.com> To: Info-TCPware@PROCESS.COM hello, we are using tcpware 5.3 on 32 bit vaxes with VMS 6.2, we defined 15 lps print queues now we have the following problem: the lpd symbiont process crashes approx. once a day and all printers are stopped. does some one had a similar problem ? how did you fixed it ? best regards dominik ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:22:23 -0400 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Access lists at startup? Message-ID: <36757512.524144494f47414741@radiogaga.harz.de> Date: Mon, 14 Dec 1998 21:29:06 +0100 Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Dear all, what is the prefered way of adding an access list to a service at startup time? The access list can be defined in ROUTING.COM, but at that point in the startup process the services are neither defined nor started. It should be integrated in the startup, because that's the best way to not forget it when restarting TCPware. Looking into STARTNET.COM, I came up with setting up TCPWARE:TELNET__CONTROL.COM (which gets executed after TELNET_CONTROL.COM), but that leaves me uneasy. cu, Martin -- | Martin Vorlaender | VMS & WNT programmer VMS is today what | work: mv@pdv-systeme.de Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:24:17 -0400 Subject: Re: TCPWARE 5.3 / VMS 6.2 Message-ID: <1998Dec1.103546@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 1 Dec 98 10:35:46 -0400 To: Info-TCPware@PROCESS.COM In article <36625BD0.6BDA1BBA@cessna.textron.com>, Dale Lutes writes: > ddli wrote: >> >> hello, >> >> we are using tcpware 5.3 on 32 bit vaxes with VMS 6.2, we defined 15 lps >> print queues now we have the following problem: >> >> the lpd symbiont process crashes approx. once a day and all printers are >> stopped. >> >> does some one had a similar problem ? how did you fixed it ? >> >> best regards dominik > > I am having a similar, if not the same problem with TCPware 5.3 on > VMS/Alpha v7.1. The log files don't seem to indicate anything. I > haven't had much chance to research it further. Anyone else?? > > Dale Lutes > Cessna Aircraft Company You don't indicate which version of 5.3 you are running (5.3-2 or 5.3-3). You might want to check out FTP.PROCESS.COM; cd to SUPPORT, cd to 53_2 (or 53_3), and look at the *LP* patch kits. Perhaps they address your problem(s). If not, please open a call with Technical Support. - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:24:42 -0400 Subject: Re: Access lists at startup? Message-ID: <1998Dec16.122527@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 16 Dec 98 12:25:27 -0400 To: Info-TCPware@PROCESS.COM In article <36757512.524144494f47414741@radiogaga.harz.de>, martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) writes: > Dear all, > > what is the prefered way of adding an access list to a service at > startup time? > > The access list can be defined in ROUTING.COM, but at that point in > the startup process the services are neither defined nor started. > It should be integrated in the startup, because that's the best way > to not forget it when restarting TCPware. > > Looking into STARTNET.COM, I came up with setting up > TCPWARE:TELNET__CONTROL.COM (which gets executed after > TELNET_CONTROL.COM), but that leaves me uneasy. > > cu, > Martin This should be done in SERVERS.COM. Note: SERVERS.COM is executed after all of the *_CONTROL.COM files and thus all of the services should be registered at this time. This does mean that there is a small window in which the access control lists won't be active (between time service is started and SERVERS.COM is run). The only way to close this gap is to modify the *_CONTROL.COM files and place the access lists in there. However, that is not recommended since these *_CONTROL.COM files do change from time to time. - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:24:46 -0400 From: Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) Reply-To: Info-TCPware@process.com Subject: TCPWare And Telnet Date: 29 Nov 98 08:03:43 GMT Message-ID: <514_9811292145@neverlnd.org.uk> To: Info-TCPware@PROCESS.COM Monday November 23 1998, bryant@process.com writes: >> As a side issue, do Process run an email list that I can subscribe to >> where patch and update notices are issued to subscribed clients ? Peter b> We currently have an eco database for Multinet that can be searched on b> the Web. You can find this at: http://www.multinet.process.com/. b> Announcements of ecos also get mailed to the Multinet-Announce and b> Info-Multinet mail lists. (Un)fortunately I do not use MultiNet :-) b> We are working on putting together the same thing for TCPware patches. b> I hope you will see this sometime soon. Great. Could you post a short announcement in this group when you have such a system in place please... Ta.. Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- +-------------------------------------------------------------------------+ | Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | |Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | | pdb@post.neverlnd.org.uk UK | +---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:24:50 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPware 5.3-3 Date: 12 Dec 98 21:59:50 GMT Message-ID: <3672e756.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <3671184C.CF88E1F7@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: >Peter LANGSTOEGER wrote: >> I found V5.3-3 because I found >> >> ftp://ftp.process.com/support/53_3/ > > There is patches only. Just my 0.00001. Of course. I stated this, because I got my info that V5.3-3 even existed, by the existence of the corresponding patch directory (the above URL). My distributor got the info of V5.3-3 existence by me, and not by PSC ! I got my V5.3-3 via ftp.process.com but obviuosly not from the patch area (I got it from the hidden area, means PSC does not want anybody to see it, so I won't post the URL). My distributor got V5.3-3 months after me... Something went wrong (and sadly not for the first time)... ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:24:59 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: Multiple network cards on the same network? Date: 3 Dec 98 20:34:04 GMT Message-ID: <3666f5bc.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article , "William Black" writes: >Using TCPWARE 5.3-2 and VMS 7.1, are multiple network cards supported on >the *same* network, ie with the same network and subnet mask. Why not ? >The cards would be connected physically to different sides of a bridge. Ok. But both cards have their own IP address ? (though in the same network) >I realise that there will be routing issues etc involved which we would >need to resolve to make the config useful. If you run the GATED daemon and you have OSPF in your net, than both cards should be equally in use. If not, then one card will carry all traffic, until card is down, then the other... >All we would like to know at this stage is if, in principle, such a config is supported. I don't know. ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:25:41 -0400 Subject: Re: TCPware 5.3-3 Message-ID: <1998Dec11.103249@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 11 Dec 98 10:32:49 -0400 To: Info-TCPware@PROCESS.COM In article <19981210163428.19415.qmail@hotmail.com>, "John Richardson" writes: > In a message "Re: Multiple network cards on the same network?" Bernie > Volz wrote: > > ...just configure secondary addresses or pseudo interface (the > latter requires TCPware 5.3-3 ... contact Support to get it if you > have not yet received it). > > What is the status of 5.3-3? Should customers on Support have received > it automatically? I work on several customer sites in the UK and have > not come accross 5.3-3. > > Also, apart from pseuodo interfaces (which at least one of my customers > has been waiting a while for), what others goodies are in 5.3-3. Are > details available on your Web site? > > John Richardson The 5.3-3 release notes did not get put on the FTP site for some reason. They are there now - in [.TCPWARE.RELEASE_NOTES]TCPWARE0533_RELEASE_NOTES.TXT and .PS. Whenever a version is released (maintenance or major), a new directory does get created in the [.SUPPORT] area. If for some reason you did not receive 5.3-3 and would like it, please don't hestitate to contact your distributor or Process Software directly. I'm not sure what the policy was for 5.3-3, but occassionally maintenance releases are not distributed to the entire customer base. - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:25:46 -0400 Subject: Re: Multiple network cards on the same network? Message-ID: <1998Dec4.143524@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 4 Dec 98 14:35:24 -0400 To: Info-TCPware@PROCESS.COM In article , "William Black" writes: > Using TCPWARE 5.3-2 and VMS 7.1, are multiple network cards supported on the > *same* network, ie with the same network and subnet mask. > > The cards would be connected physically to different sides of a bridge. > > I realise that there will be routing issues etc involved which we would need > to resolve to make the config useful. > > All we would like to know at this stage is if, in principle, such a config is > supported. You should be able to do this. However, please realize that you will receive multiple broadcasts (one from each interface) and this may cause additional load on the system that you don't necessarily want. You might look at using the /FLAGS=NOBROADCAST option when starting up ONE of the interfaces to tell it not to receive physical broadcast packets (those sent to FF-FF-FF-FF-FF-FF). See NETCU's START/IP documentation for more details. WHY are you doing this? If you want multiple addresses on the same network, just configure secondary addresses or pseudo interface (the latter requires TCPware 5.3-3 ... contact Support to get it if you have not yet received it). Is the configuration supported ... I would say that it "officially" is not but it should work. But it is very tricky to get it right and likely has some performance implications. - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:11 -0400 From: Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) Reply-To: Info-TCPware@process.com Subject: TCPWare 5.3-2 & DHCP Date: 29 Nov 98 08:05:33 GMT Message-ID: <515_9811292145@neverlnd.org.uk> To: Info-TCPware@PROCESS.COM Now the nice people at Process Software came to my rescue with my Telnet problem, I hope the members of this group could give me some pointers to my current remaining problem please. I have the DHCP server setup and it all works just fine and dandy when I know the Ethernet MAC address of the requesting client(s). Q: How does one configure the DHCPTAB file for anonymous clients, effectivly when the "eh:" paramater will look sommat like "eh:*-*-*-*-*-*". I want to be able to support a varying number of laptops that could be connected to the network and I will not know (nor the owners of the laptops) the MAC address in advance. I suppose what I am looking for is "Anonymous DHCP Client Support". I don't seem to be able to find an example in the manuals unless I am looking in the wrong place. The Laptop examples all show known MAC Addresses. Of course, TCPWare 5.3-2 may not support this and thus if this is the case, will a future version of TCPware have this support. Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- +-------------------------------------------------------------------------+ | Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | |Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | | pdb@post.neverlnd.org.uk UK | +---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:16 -0400 Subject: Re: ACK time-outs Message-ID: <1998Dec7.165228@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 7 Dec 98 16:52:28 -0400 To: Info-TCPware@PROCESS.COM In article <19981207190213.6712.rocketmail@send106.yahoomail.com>, Chris Wolfe writes: > Hello all, > > We run Oracle off a server (DEC Alpha Ovms 7.0, TCPware 5.2-3) on our > local lan. We have remote users on the other side of a 56k bridge who > are logging in to the Oracle box here and running apps via tcp/ip. We > have seen an increase in session time-outs recently for these remote > users, and one of our Oracle-heads found the following information on > the Oracle web site: > > ---------------------- > Increase the ACK Time-out on the Server: > > One other place to tune is the Server's protocol. There are always > time-outs > for ACK's (acknowledgement packets). These time-outs are normally > configured > for LAN performance and not WAN performance. Many times there are > delays in > delivery of PDUs that would delay the client's ACKs. This will cause > the > packet to be sent again until the server either gets the ACK back in > time or > disconnects the clients connection. Telling the server to wait longer > for the > ACKs will reduce the WAN traffic, thereby increasing response time. > ----------------------- > > Is this something we should attempt to pursue and modify? How would > this affect other server tcp/ip operations? > > TIA! > Chris W I suspect that this is NOT a reference to the TCP ACK but instead a parameter in the Oracle server itself. TCP should adapt properly to the WAN environment and handle things just fine. However, the Oracle server may have timeouts internal to it that need to be adjusted. Does the Oracle information tell you what to adjust? - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:39 -0400 Message-ID: <3673EF15.94F32F16@SMTP.DeltaTel.RU> Date: Sun, 13 Dec 1998 19:45:09 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPware 5.3-3 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Peter LANGSTOEGER wrote: > > In article <3671184C.CF88E1F7@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > >Peter LANGSTOEGER wrote: > >> I found V5.3-3 because I found > >> > >> ftp://ftp.process.com/support/53_3/ > > > > There is patches only. Just my 0.00001. > > Of course. I stated this, because I got my info that V5.3-3 even existed, > by the existence of the corresponding patch directory (the above URL). > > My distributor got the info of V5.3-3 existence by me, and not by PSC ! > > I got my V5.3-3 via ftp.process.com but obviuosly not from the patch area > (I got it from the hidden area, means PSC does not want anybody to see it, > so I won't post the URL). My distributor got V5.3-3 months after me... Hmmmm... I think that there is area for working in PSC. I have got 5.3-3 kit from my US clients, but I think that this is not normal way... > > Something went wrong (and sadly not for the first time)... > > ------------------------------------------------------------------------ > Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 > Network and OpenVMS system manager Fax. +43 1 81111-888 > FBFV/Information Services E-mail eplan@kapsch.net > <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN > A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" > "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 -- C U, Ruslan. +oVMS Sys|Net HardWorker.............................................+ http://www.levitte.org/~rlaishev/ Cel: 7+ (901) 971-3222 +..............................................Pure personal oppinion+ ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:42 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPware 5.3-3 Date: 10 Dec 98 21:26:15 GMT Message-ID: <36703c77.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <19981210163428.19415.qmail@hotmail.com>, "John Richardson" writes: >In a message "Re: Multiple network cards on the same network?" Bernie >Volz wrote: > > ...just configure secondary addresses or pseudo interface (the > latter requires TCPware 5.3-3 ... contact Support to get it if you > have not yet received it). > >What is the status of 5.3-3? Should customers on Support have received >it automatically? I work on several customer sites in the UK and have >not come accross 5.3-3. I found V5.3-3 because I found ftp://ftp.process.com/support/53_3/ So I requested V5.5-3 (because I wanted to have the patches included and not install them all after various tests) and got the kits via download from the hidden area of ftp.process.com and installed it in Aug98. But there are some patches again, now for V5.5-3. And I assume, I wouldn't have got V5.3-3 via the normal maint agreement... >Also, apart from pseuodo interfaces (which at least one of my customers >has been waiting a while for), what others goodies are in 5.3-3. Are >details available on your Web site? I only found the pseudo interfaces so far. Note, I didn't expect (and still do not like) functional changes in maintenance versions ! But FWIW, I use pseudo interfaces from day one of the installation of V5.3-3. They solved a lot of troubles here. And I didn't found any detailed web info. just my 0.02 ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 FBFV/Information Services E-mail eplan@kapsch.net <<< KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::EPLAN A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998 ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:46 -0400 Subject: Re: [Fwd: CERT Advisory CA-98.13 - TCP/IP Denial of Service] Message-ID: <3681026B.1FB8@process.com> From: Geoff Bryant Reply-To: Info-TCPware@process.com Date: Wed, 23 Dec 1998 09:47:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Ruslan R. Laishev wrote: > > Hi ! What about of TCPWare-TCP ? TCPware version 5.3-3 includes a fix for this attack. Patches for earlier versions of TCPware have been available for over a year. Please be sure that you have either TCPware version 5.3-3 or the most current drivers patch kit applied to your system. > > aleph1@UNDERGROUND.ORG wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > CERT Advisory CA-98-13-tcp-denial-of-service > > > > Original Issue Date: December 21, 1998 > > > > Last Revised > > > > Topic: Vulnerability in Certain TCP/IP Implementations > > > > Affected Systems > > > > Some systems with BSD-derived TCP/IP stacks. See Appendix A for a > > complete list of affected systems. > > > > Overview > > > > Intruders can disrupt service or crash systems with vulnerable TCP/IP > > stacks. No special access is required, and intruders can use > > source-address spoofing to conceal their true location. > > > > I. Description > > > > By carefully constructing a sequence of packets with certain > > characteristics, an intruder can cause vulnerable systems to crash, > > hang, or behave in unpredictable ways. This vulnerability is similar > > in its effect to other denial-of-service vulnerabilities, including > > the ones described in > > > > http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html > > > > Specifically, intruders can use this vulnerability in conjunction with > > IP-source-address spoofing to make it difficult or impossible to know > > their location. They can also use the vulnerability in conjunction > > with broadcast packets to affect a large number of vulnerable machines > > with a small number of packets. > > ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:26:49 -0400 Message-ID: <36713E23.46CC1E63@SMTP.DeltaTel.RU> Date: Fri, 11 Dec 1998 18:45:39 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPware 5.3-3 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Geoff Bryant wrote: > > "Ruslan R. Laishev" writes: > > > >Peter LANGSTOEGER wrote: > >> > >> In article <19981210163428.19415.qmail@hotmail.com>, "John Richardson" writes: > >> >In a message "Re: Multiple network cards on the same network?" Bernie > >> >Volz wrote: > >> > > >> > ...just configure secondary addresses or pseudo interface (the > >> > latter requires TCPware 5.3-3 ... contact Support to get it if you > >> > have not yet received it). > >> > > >> >What is the status of 5.3-3? Should customers on Support have received > >> >it automatically? I work on several customer sites in the UK and have > >> >not come accross 5.3-3. > >> > >> I found V5.3-3 because I found > >> > >> ftp://ftp.process.com/support/53_3/ > > There is patches only. Just my 0.00001. > > > > TCPware 5.3-3 is indeed a maintenance release which did include the > pseudo-device feature. Good, I have waited for this feature long time... > Seeing that most who have commented are non-US > customers, I suggest you contact your distributor. I had had contact with my distributor, it contact with UK staff, UK staff contact with US staff.... As result of these contacts I have mail which instruction how get TCPWare 5.3-3 at ftp://ftp.process.com/support/53_3/ (!:)). Cool! > If you get no > help there, contact support - support@process.com. Thanks. I had had contact for 5.3-3 kit and receive recommendation to contact with my distributor. :) > > Also as noted, there have been some patch kits available off the ftp server. > > ------------------------------------------------------------- > Geoff Bryant bryant@process.com > TCPware/Multinet Engineering > Process Software Corporation http://www.process.com/ > 959 Concord St. > Framingham, MA 01701 USA -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:27:21 -0400 Subject: Re: ACK time-outs Message-ID: <1998Dec13.192040@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 13 Dec 98 19:20:40 -0400 To: Info-TCPware@PROCESS.COM In article <19981211171155.2629.rocketmail@send101.yahoomail.com>, Chris Wolfe writes: >> > We run Oracle off a server (DEC Alpha Ovms 7.0, TCPware 5.2-3) on ... >> I suspect that this is NOT a reference to the TCP ACK but instead a >> parameter in the Oracle server itself. TCP should adapt properly to >> the WAN environment and handle things just fine. However, the Oracle >> server may have timeouts internal to it that need to be adjusted. >> >> Does the Oracle information tell you what to adjust? >> > > One thing to keep in mind is that we have some 'networking issues' > that are affecting traffic over this bridge. > > If I may quote what my coworker has discussed with Oracle: > --- > Well, when I talked to Oracle support regarding how DCD works, the tech > told me that when DCD sends out the acknowledgement packet, the amount > of time Oracle waits for the clients response is based on the > underlying TCP > protocol. I asked the tech what to do if we wanted to increase the > time that > Oracle will wait for a DCD response from the client. She told me that > it is not > an issue that Oracle support can help with, that I should talk to my > internal > department that is in control of the TCP protocol. Pretty much the > tech told > me to do what was written about in the article that I sent you earlier > regarding > ACKs. Unfortunately, I couldn't get VMS specific help from Oracle on > this issue. > --- > We found that the TCPware 'start/tcp' command can take a parameter of > /NOKEEPALIVE, which sounds like it might address this problem. How > often are TCP keepalive probes sent out? And how long is the 'elapsed > time' that TCP waits before assuming that the peer is down and closes > the connection, if it doesn't get a response? What else would setting > /NOKEEPALIVE affect? > What kind of time are you talking about here? Are these connections going away after a short or long time (seconds, minutes, hours, days)? Is the link between the clients and server lost for long periods? Why would the TCP layer think the connection has died? By default, TCPware does NOT enable keepalives on connections (it used to a long time ago, but no longer). The various applications (mostly servers) that want keepalives used must enable keepalives in order to use them. Keepalives are just periodic probes. The connection dies only after the connection time-out time elapses. If keepalives are not enabled, the connection would only time-out if data is being exchanged and fails to get an acknowledgement from the peer within time connection time-out time. If keepalives are enabled, the above is true even for idle connections (ie, when no data is being exchanged for a period of time). In any case, the connection time-out time is typically fairly long - by default around 300 seconds (5 minutes). Applications can change this. Note: I don't know which DRIVER Oracle uses and some of the times are different for each DRIVER. You can tell which DRIVER is being used by using NETCU SHOW CONNECTION command and looking at which are associated with the Oracle port number. For TCPDRIVER connections, you can use NETCU SHOW CHARACTERISTIC TCPn: to see what the values for the TCP connection parameters are. - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:27:24 -0400 Message-ID: <3680912A.FCFE6FAA@SMTP.DeltaTel.RU> Date: Wed, 23 Dec 1998 09:43:54 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: [Fwd: CERT Advisory CA-98.13 - TCP/IP Denial of Service] Content-Type: multipart/mixed; boundary="------------C4D626E0C5EC20CC380EABD1" To: Info-TCPware@PROCESS.COM This is a multi-part message in MIME format. --------------C4D626E0C5EC20CC380EABD1 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi ! What about of TCPWare-TCP ? aleph1@UNDERGROUND.ORG wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > CERT Advisory CA-98-13-tcp-denial-of-service > > Original Issue Date: December 21, 1998 > > Last Revised > > Topic: Vulnerability in Certain TCP/IP Implementations > > Affected Systems > > Some systems with BSD-derived TCP/IP stacks. See Appendix A for a > complete list of affected systems. > > Overview > > Intruders can disrupt service or crash systems with vulnerable TCP/IP > stacks. No special access is required, and intruders can use > source-address spoofing to conceal their true location. > > I. Description > > By carefully constructing a sequence of packets with certain > characteristics, an intruder can cause vulnerable systems to crash, > hang, or behave in unpredictable ways. This vulnerability is similar > in its effect to other denial-of-service vulnerabilities, including > the ones described in > > http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html > > Specifically, intruders can use this vulnerability in conjunction with > IP-source-address spoofing to make it difficult or impossible to know > their location. They can also use the vulnerability in conjunction > with broadcast packets to affect a large number of vulnerable machines > with a small number of packets. > > II. Impact > > Any remote user can crash or hang a vulnerable machine, or cause the > system to behave in unpredictable ways. > > III. Solution > > A. Install a patch from your vendor. > > Appendix A contains input from vendors who have provided information > for this advisory. We will update the appendix as we receive more > information. If you do not see your vendor's name, the CERT/CC did not > hear from that vendor. Please contact your vendor directly. > > B. Configure your router or firewall to help prevent source-address spoofing. > > We encourage sites to configure their routers or firewalls to reduce > the ability of intruders to use source-address spoofing. Currently, > the best method to reduce the number of IP-spoofed packets exiting > your network is to install filtering on your routers that requires > packets leaving your network to have a source address from your > internal network. This type of filter prevents a source IP-spoofing > attack from your site by filtering all outgoing packets that contain a > source address of a different network. > > A detailed description of this type of filtering is available in RFC > 2267, "Network Ingress Filtering: Defeating Denial of Service Attacks > which employ IP Source Address Spoofing" by Paul Ferguson of Cisco > Systems, Inc. and Daniel Senie of Blazenet, Inc. We recommend it to > both Internet Service Providers and sites that manage their own > routers. The document is currently available at > > http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2267.txt > > Note that this type of filtering does not protect a site from the > attack itself, but it does reduce the ability of intruders to conceal > their location, thereby discouraging attacks. > > Appendix A - Vendor Information > > Berkeley Software Design, Inc. (BSDI) > > BSDI's current release BSD/OS 4.0 is not vulnerable to this problem. > BSD/OS 3.1 is vulnerable and a patch (M310-049) is available from > BSDI's WWW server at http://www.bsdi.com/support/patches or via our > ftp server from the directory > ftp://ftp.bsdi.com/bsdi/patches/patches-3.1. > > Cisco Systems > > Cisco is not vulnerable. > > Compaq Computer Corporation > > SOURCE: (c) Copyright 1994, 1995, 1996, 1997, 1998 Compaq Computer > Corporation. > > All rights reserved. > > SOURCE: Compaq Computer Corporation > Compaq Services > Software Security Response Team USA > > This reported problem is not present for the as shipped, Compaq's > Digital ULTRIX or Compaq's Digital UNIX Operating Systems Software. > > - Compaq Computer Corporation > > Data General Corporation > > We are investigating. We will provide an update when our investigation > is complete. > > FreeBSD, Inc. > > FreeBSD 2.2.8 is not vulnerable. > FreeBSD versions prior to 2.2.8 are vulnerable. > FreeBSD 3.0 is also vulnerable. > FreeBSD 3.0-current as of 1998/11/12 is not vulnerable. > > A patch is available at > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/CA-98-13/patch > > Fujitsu > > Regarding this vulnerability, Fujitsu's UXP/V operating system is not > vulnerable. > > Hewlett-Packard Company > > HP is not vulnerable. > > IBM Corporation > > AIX is not vulnerable. > > IBM and AIX are registered trademarks of International Business > Machines Corporation. > > Livingston Enterprises, Inc. > > Livingston systems are not vulnerable. > > Computer Associates International > > CA systems are not vulnerable. > > Microsoft Corporation > > Microsoft is not vulnerable. > > NEC Corporation > > NEC Corporation EWS-UX, UP-UX and UX/4800 Unix systems are not > vulnerable to this problem. > > OpenBSD > > Security fixes for this problem are now available for 2.3 and 2.4. > > For 2.3, see > > www.openbsd.org/errata23.html#tcpfix > > For our 2.4 release which is available on CD on Dec 1, see > > www.openbsd.org/errata.html#tcpfix > > The bug is fixed in our -current source tree. > > Sun Microsystems, Inc. > > We have confirmed that SunOS and Solaris are not vulnerable to the DOS > attack. > > Wind River Systems, Inc. > > We've taken a look at our networking code and have determined that > this is not a problem in the currently shipping version of the VxWorks > RTOS. > _________________________________________________________________ > > Contributors > > The vulnerability was originally discovered by Joel Boutros of the > Enterprise Security Services team of Cambridge Technology Partners. > Guido van Rooij of FreeBSD, Inc., provided an analysis of the > vulnerability and information regarding its scope and extent. > ______________________________________________________________________ > > This document is available from: > http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html. > ______________________________________________________________________ > > CERT/CC Contact Information > > Email: cert@cert.org > Phone: +1 412-268-7090 (24-hour hotline) > Fax: +1 412-268-6989 > Postal address: > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > U.S.A. > > CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) > Monday through Friday; they are on call for emergencies during other > hours, on U.S. holidays, and on weekends. > > Using encryption > > We strongly urge you to encrypt sensitive information sent by email. > Our public PGP key is available from http://www.cert.org/CERT_PGP.key. > If you prefer to use DES, please call the CERT hotline for more > information. > > Getting security information > > CERT publications and other security information are available from > our web site http://www.cert.org/. > > To be added to our mailing list for advisories and bulletins, send > email to cert-advisory-request@cert.org and include SUBSCRIBE > your-email-address in the subject of your message. > > Copyright 1998 Carnegie Mellon University. > Conditions for use, disclaimers, and sponsorship information can be > found in http://www.cert.org/legal_stuff.html. > > * CERT is registered in the U.S. Patent and Trademark Office > ______________________________________________________________________ > > NO WARRANTY > Any material furnished by Carnegie Mellon University and the Software > Engineering Institute is furnished on an "as is" basis. Carnegie > Mellon University makes no warranties of any kind, either expressed or > implied as to any matter including, but not limited to, warranty of > fitness for a particular purpose or merchantability, exclusivity or > results obtained from use of the material. Carnegie Mellon University > does not make any warranty of any kind with respect to freedom from > patent, trademark, or copyright infringement. > _________________________________________________________________ > > Revision History > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQCVAwUBNn64knVP+x0t4w7BAQHd/wQAv+1cQif/KNdFZ1ObARzlJJUd9T0Za5WM > GjZwrlYR3CIm+eByVbGGizCYTXzuiTjQdenKxfDXAXXwqZRIvFbpjU3qWY6kCicf > BhTbvzOOIT/ROhr9fWRwPqqPMKUyUYaJCbeWYWeV6PFJ6fYhWrBihiE+yml4n1Xp > k2lHvwHl9lE= > =9kEz > -----END PGP SIGNATURE----- -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + --------------C4D626E0C5EC20CC380EABD1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from dtw10.deltatel.ru [172.16.0.10] by DTV3.DeltaTel.RU with SMTP-OpenVMS via TCP/IP; Tue, 22 Dec 1998 22:43 MSK Received: from relay.wplus.NET by dtw10.deltatel.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id ZKF0FHZ8; Tue, 22 Dec 1998 22:45:38 +0300 X-Real-To: Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id WAA25834 for ; Tue, 22 Dec 1998 22:18:39 +0300 (MSK/MSD) Received: from netspace.org ([128.148.157.6]:31552 "EHLO netspace.org" ident: "TIMEDOUT2") by brimstone.netspace.org with ESMTP id <74206-28105>; Tue, 22 Dec 1998 14:04:24 -0500 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8d) with spool id 5850802 for BUGTRAQ@NETSPACE.ORG; Tue, 22 Dec 1998 13:50:43 -0500 Approved-By: aleph1@UNDERGROUND.ORG Received: from underground.org ([209.179.181.153]) by netspace.org (8.8.7/8.8.7) with SMTP id XAA04735 for ; Mon, 21 Dec 1998 23:26:05 -0500 Received: (qmail 30243 invoked by uid 500); 22 Dec 1998 05:37:05 -0000 Received: (qmail 28239 invoked from network); 22 Dec 1998 01:32:52 -0000 Received: from dfw.nationwide.net (@198.175.15.10) by underground.org with SMTP; 22 Dec 1998 01:32:52 -0000 Received: from coal.cert.org (coal.cert.org [192.88.210.31]) by dfw.nationwide.net (8.9.0/8.9.0) with SMTP id SAA19021; Mon, 21 Dec 1998 18:18:38 -0600 (CST) Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id RAA14804 for cert-advisory-queue-40; Mon, 21 Dec 1998 17:41:26 -0500 Content-Type: application/pgp; format=text; x-action=sign Message-ID: <19981222053705.30242.qmail@underground.org> Date: Mon, 21 Dec 1998 21:37:05 -0800 Reply-To: Bugtraq List Sender: Bugtraq List Comments: Resent-From: aleph1@underground.org Comments: Originally-From: CERT Advisory From: aleph1@UNDERGROUND.ORG Organization: CERT(sm) Coordination Center - +1 412-268-7090 Subject: CERT Advisory CA-98.13 - TCP/IP Denial of Service To: BUGTRAQ@netspace.org -----BEGIN PGP SIGNED MESSAGE----- CERT Advisory CA-98-13-tcp-denial-of-service Original Issue Date: December 21, 1998 Last Revised Topic: Vulnerability in Certain TCP/IP Implementations Affected Systems Some systems with BSD-derived TCP/IP stacks. See Appendix A for a complete list of affected systems. Overview Intruders can disrupt service or crash systems with vulnerable TCP/IP stacks. No special access is required, and intruders can use source-address spoofing to conceal their true location. I. Description By carefully constructing a sequence of packets with certain characteristics, an intruder can cause vulnerable systems to crash, hang, or behave in unpredictable ways. This vulnerability is similar in its effect to other denial-of-service vulnerabilities, including the ones described in http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html Specifically, intruders can use this vulnerability in conjunction with IP-source-address spoofing to make it difficult or impossible to know their location. They can also use the vulnerability in conjunction with broadcast packets to affect a large number of vulnerable machines with a small number of packets. II. Impact Any remote user can crash or hang a vulnerable machine, or cause the system to behave in unpredictable ways. III. Solution A. Install a patch from your vendor. Appendix A contains input from vendors who have provided information for this advisory. We will update the appendix as we receive more information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact your vendor directly. B. Configure your router or firewall to help prevent source-address spoofing. We encourage sites to configure their routers or firewalls to reduce the ability of intruders to use source-address spoofing. Currently, the best method to reduce the number of IP-spoofed packets exiting your network is to install filtering on your routers that requires packets leaving your network to have a source address from your internal network. This type of filter prevents a source IP-spoofing attack from your site by filtering all outgoing packets that contain a source address of a different network. A detailed description of this type of filtering is available in RFC 2267, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" by Paul Ferguson of Cisco Systems, Inc. and Daniel Senie of Blazenet, Inc. We recommend it to both Internet Service Providers and sites that manage their own routers. The document is currently available at http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2267.txt Note that this type of filtering does not protect a site from the attack itself, but it does reduce the ability of intruders to conceal their location, thereby discouraging attacks. Appendix A - Vendor Information Berkeley Software Design, Inc. (BSDI) BSDI's current release BSD/OS 4.0 is not vulnerable to this problem. BSD/OS 3.1 is vulnerable and a patch (M310-049) is available from BSDI's WWW server at http://www.bsdi.com/support/patches or via our ftp server from the directory ftp://ftp.bsdi.com/bsdi/patches/patches-3.1. Cisco Systems Cisco is not vulnerable. Compaq Computer Corporation SOURCE: (c) Copyright 1994, 1995, 1996, 1997, 1998 Compaq Computer Corporation. All rights reserved. SOURCE: Compaq Computer Corporation Compaq Services Software Security Response Team USA This reported problem is not present for the as shipped, Compaq's Digital ULTRIX or Compaq's Digital UNIX Operating Systems Software. - Compaq Computer Corporation Data General Corporation We are investigating. We will provide an update when our investigation is complete. FreeBSD, Inc. FreeBSD 2.2.8 is not vulnerable. FreeBSD versions prior to 2.2.8 are vulnerable. FreeBSD 3.0 is also vulnerable. FreeBSD 3.0-current as of 1998/11/12 is not vulnerable. A patch is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/CA-98-13/patch Fujitsu Regarding this vulnerability, Fujitsu's UXP/V operating system is not vulnerable. Hewlett-Packard Company HP is not vulnerable. IBM Corporation AIX is not vulnerable. IBM and AIX are registered trademarks of International Business Machines Corporation. Livingston Enterprises, Inc. Livingston systems are not vulnerable. Computer Associates International CA systems are not vulnerable. Microsoft Corporation Microsoft is not vulnerable. NEC Corporation NEC Corporation EWS-UX, UP-UX and UX/4800 Unix systems are not vulnerable to this problem. OpenBSD Security fixes for this problem are now available for 2.3 and 2.4. For 2.3, see www.openbsd.org/errata23.html#tcpfix For our 2.4 release which is available on CD on Dec 1, see www.openbsd.org/errata.html#tcpfix The bug is fixed in our -current source tree. Sun Microsystems, Inc. We have confirmed that SunOS and Solaris are not vulnerable to the DOS attack. Wind River Systems, Inc. We've taken a look at our networking code and have determined that this is not a problem in the currently shipping version of the VxWorks RTOS. _________________________________________________________________ Contributors The vulnerability was originally discovered by Joel Boutros of the Enterprise Security Services team of Cambridge Technology Partners. Guido van Rooij of FreeBSD, Inc., provided an analysis of the vulnerability and information regarding its scope and extent. ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html. ______________________________________________________________________ CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key. If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/. To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org and include SUBSCRIBE your-email-address in the subject of your message. Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html. * CERT is registered in the U.S. Patent and Trademark Office ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Revision History -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNn64knVP+x0t4w7BAQHd/wQAv+1cQif/KNdFZ1ObARzlJJUd9T0Za5WM GjZwrlYR3CIm+eByVbGGizCYTXzuiTjQdenKxfDXAXXwqZRIvFbpjU3qWY6kCicf BhTbvzOOIT/ROhr9fWRwPqqPMKUyUYaJCbeWYWeV6PFJ6fYhWrBihiE+yml4n1Xp k2lHvwHl9lE= =9kEz -----END PGP SIGNATURE----- --------------C4D626E0C5EC20CC380EABD1-- ================================================================================ Archive-Date: Mon, 25 Jan 1999 13:50:00 -0400 Date: Mon, 25 Jan 1999 11:53:34 -0700 To: Info-TCPware@process.com From: Jim Mehlhop Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE 5.3 / VMS 6.2 In-Reply-To: <01be1c55$87037060$1b083e0a@ps027-ishbg.neurope.ikea.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" you might want to try installing VMSLPRSMB_V532P010 eco FTP to ftp.process.com cd [.support] cd [.53_2] get VMSLPRSMB_V532P010.ZIP Jim At 11:36 AM 11/30/98 +0000, you wrote: >hello, > >we are using tcpware 5.3 on 32 bit vaxes with VMS 6.2, we defined 15 lps >print queues now we have the following problem: > >the lpd symbiont process crashes approx. once a day and all printers are >stopped. > >does some one had a similar problem ? how did you fixed it ? > > best regards dominik > _________________________________________________________________________ Jim Mehlhop, Support Engineer Process Software Mehlhop@process.com Phone 719-638-8448 Join Cauce to outlaw spam http://www.cauce.org/ _________________________________________________________________________ ================================================================================ Archive-Date: Mon, 25 Jan 1999 14:15:42 -0400 Sender: bryant@process.com Date: Mon, 25 Jan 1999 14:11:32 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D2BF5.12F5CB9A.222@process.com> Subject: RE: Access lists at startup? martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) writes: > >Dear all, > >what is the prefered way of adding an access list to a service at >startup time? > >The access list can be defined in ROUTING.COM, but at that point in >the startup process the services are neither defined nor started. >It should be integrated in the startup, because that's the best way >to not forget it when restarting TCPware. > >Looking into STARTNET.COM, I came up with setting up >TCPWARE:TELNET__CONTROL.COM (which gets executed after >TELNET_CONTROL.COM), but that leaves me uneasy. > >cu, > Martin >-- > | Martin Vorlaender | VMS & WNT programmer > VMS is today what | work: mv@pdv-systeme.de > Microsoft wants | http://www.pdv-systeme.de/users/martinv/ > Windows NT 8.0 to be! | home: martin@radiogaga.harz.de TCPWARE:SERVERS.COM would be the place. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 25 Jan 1999 14:27:04 -0400 Sender: bryant@process.com Date: Mon, 25 Jan 1999 14:22:53 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D2BF6.A8F2658F.174@process.com> Subject: RE: TCPWare And Telnet Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) writes: > >Monday November 23 1998, bryant@process.com writes: > >>> As a side issue, do Process run an email list that I can subscribe to >>> where patch and update notices are issued to subscribed clients ? Peter > >b> We currently have an eco database for Multinet that can be searched on >b> the Web. You can find this at: http://www.multinet.process.com/. >b> Announcements of ecos also get mailed to the Multinet-Announce and >b> Info-Multinet mail lists. > >(Un)fortunately I do not use MultiNet :-) > >b> We are working on putting together the same thing for TCPware patches. >b> I hope you will see this sometime soon. > >Great. Could you post a short announcement in this group when you have such >a system in place please... Ta.. Today would seem to be your lucky day. I just went and checked and it's there now! Guess no-one told me... If you go to www.process.com and select the tech support page, you will see search ECO as a selection on the left side of the page. From there it should be self explanatory. Note that the database is not completely loaded yet. I believe that all the TCPware 5.3-x patches are in there and some of the very old ones, but not some of the patches for releases in between. At any rate, it should be a good start. >Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk > ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >-- >+-------------------------------------------------------------------------+ >| Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings | >|Voice: 44-(0)468-817347 ISDN: 44-(0)1424-854816 East Sussex | >| pdb@post.neverlnd.org.uk UK | >+---------------( Http://www.neverlnd.demon.co.uk )-----------------------+ > ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Wed, 27 Jan 1999 06:22:39 -0400 From: "WimK" Reply-To: Info-TCPware@process.com Subject: Setup printer via decserver 90 TL Date: Wed, 27 Jan 1999 12:14:16 +0100 Sender: wimmy@diode.rdc.nl Message-ID: <78mse7$i2g$1@news2.xs4all.nl> To: Info-TCPware@PROCESS.COM I'm trying to setup a print que but it wont work so far. We have a decserver 90TL TCPWARE Version 5.2 I configured the que with @tcpware:cnfnet menu I initilized the que like this $ Init/Que/On=VAXB::"172.31.2.22,9100"/Proc=TCPWARE_LPRSMB - /Owner=[System] - /Library=lj4P_dev_ctl - /Default=(Form=A4L_02) - pr_ds90 $ Start/Queue Pr_ds90 But when I try to print something nothing happends. The job appears and dissapears. And it look like everything works fine besides that I dont get anyy output. Please help me out. Wim ================================================================================ Archive-Date: Wed, 27 Jan 1999 08:00:05 -0400 From: "Scott G. Smith" Reply-To: Info-TCPware@process.com Subject: Using Telnet in command procedure Date: 27 Jan 1999 12:40:42 GMT Message-ID: <01be49f2$9146c480$f46556d1@753554.atlanta.ibm.com> To: Info-TCPware@PROCESS.COM I'm trying to automate a login to a firewall, so I can authenticate against the firewall and then logout from the firewall. This would allow other FTP procedures to use the firewall connection during the day. The simple command procedure $ telnet connect firewall.address firewall.port userid password menu selection $ exit is stopping after the 'connect firewall.address firewal.port' and waiting for user input of userid/password/menu option. I can login successfully manually. After login, the remainder of the DCL executes. Does anyone know have suggestions on how I can use DCL to automate this login function? Basic configuration: several VMS VAX systems on local 32.x.x.x network VMS 7.1, TCPWare 5.3-2 plus patches AIX firewall Telnet and FTP allowed thru firewall Thanks in advance for help! ================================================================================ Archive-Date: Wed, 27 Jan 1999 08:56:25 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86BDF599@lespaul.process.com> From: Mohammed Boukantar Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Subject: RE: Setup printer via decserver 90 TL Date: Wed, 27 Jan 1999 08:58:39 -0500 MIME-Version: 1.0 Content-Type: text/plain >$ Init/Que/On=VAXB::"172.31.2.22,9100"/Proc=TCPWARE_LPRSMB - You have to find out the port number that you should be using. The 90TL as with other terminal servers require you to use some number plus the port number: Some use the range of 2000. In that case you will have to the port number to 2000. For example port 1 would add up to 2001. Consult with the 90TL doc or vendor. Thank you ================================================================================ Archive-Date: Wed, 27 Jan 1999 09:07:54 -0400 Message-ID: <36AF1C7B.69CB704E@process.com> Date: Wed, 27 Jan 1999 09:02:36 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: RE: Using Telnet in command procedure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I'm trying to automate a login to a firewall, so I can authenticate > against the firewall and then logout from the firewall. This would allow > other FTP procedures to use the firewall connection during the day. > > The simple command procedure > $ telnet > connect firewall.address firewall.port > userid > password > menu selection > $ exit > is stopping after the 'connect firewall.address firewal.port' and waiting > for user input of userid/password/menu option. I can login successfully > manually. After login, the remainder of the DCL executes. > > Does anyone know have suggestions on how I can use DCL to automate this > login function? > The telnet client can not accept input from a command procedure. C-Kermit (http://www.columbia.edu/kermit/) provides telnet scripting and could be used to do what you want. regards Michael -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 27 Jan 1999 09:50:27 -0400 Sender: schreiber@process.com Date: Wed, 27 Jan 1999 09:46:14 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: info-multinet@process.com, schreiber@process.com Message-ID: <009D2D62.577AA655.120@process.com> Subject: RE: Using Telnet in command procedure "Scott G. Smith" writes: > >I'm trying to automate a login to a firewall, so I can authenticate >against the firewall and then logout from the firewall. This would allow >other FTP procedures to use the firewall connection during the day. > If you can't use RSH to execute the command [my first suggestion] I know there is some sort of scripting software for VAX. I don't know what it is right off the top of my head, and the guy that used it for some telnet testing a few years ago isn't in yet this morning. I do know that he was able to 'record' the connect, userid and password, and get it to automate the login. If no-one on the list knows what I'm talking about, I'll report back when I find out what it was. -jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 27 Jan 1999 10:07:30 -0400 Message-ID: <36AF2A73.40AC879A@process.com> Date: Wed, 27 Jan 1999 10:02:11 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: info-tcpware@process.com Subject: Setup printer via decserver 90 TL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I'm trying to setup a print que but it wont work so far. > > We have a decserver 90TL > TCPWARE Version 5.2 > > I configured the que with @tcpware:cnfnet menu > > I initilized the que like this > > $ Init/Que/On=VAXB::"172.31.2.22,9100"/Proc=TCPWARE_LPRSMB - > /Owner=[System] - > > /Library=lj4P_dev_ctl - > > /Default=(Form=A4L_02) - > > pr_ds90 > > $ Start/Queue Pr_ds90 > > But when I try to print something nothing happends. > > The job appears and dissapears. > > And it look like everything works fine besides that I dont get anyy output. > > You are using some of the syntax for the terminal server print symbiont but your point to the LPR symbiont with the '/PROC=TCPWARE_LPRSMB.' If you want to print to the Decserer using the terminal server print symbiont, also known as telnet printing, or reverse telnet printing, then the correct syntax is - $ INIT/QUEUE/PROC=TCPWARE_TSSYM/ON="172.31.2.22,port#" QUEUENAME You should replace the port# with the port TCP port number that the DECserver is listening on and you can also add all the other queue qualifiers that you need. You will have to find out what port number the DECserver 90 listens on. regards Michael -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Wed, 27 Jan 1999 10:15:19 -0400 Date: Wed, 27 Jan 1999 09:06:51 -0600 (CST) From: "J.F.Noonan" Reply-To: Info-TCPware@process.com To: Info-MultiNet@process.com CC: Info-TCPware@process.com, schreiber@process.com Subject: RE: Using Telnet in command procedure In-Reply-To: <009D2D62.577AA655.120@process.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Use Kermit, it has a quite decent scripting facility. http://www.columbia.edu/kermit On Wed, 27 Jan 1999, Jeff Schreiber wrote: > Date: Wed, 27 Jan 1999 09:46:14 -0400 > From: Jeff Schreiber > Reply-To: Info-MultiNet@process.com > To: Info-TCPware@process.com > Cc: info-multinet@process.com, schreiber@process.com > Subject: RE: Using Telnet in command procedure > > "Scott G. Smith" writes: > > > >I'm trying to automate a login to a firewall, so I can authenticate > >against the firewall and then logout from the firewall. This would allow > >other FTP procedures to use the firewall connection during the day. > > > > If you can't use RSH to execute the command [my first suggestion] I > know there is some sort of scripting software for VAX. I don't know > what it is right off the top of my head, and the guy that used it for > some telnet testing a few years ago isn't in yet this morning. I do > know that he was able to 'record' the connect, userid and password, > and get it to automate the login. > > If no-one on the list knows what I'm talking about, I'll report back > when I find out what it was. > > -jeff > -- > Jeff Schreiber, Process Software Corp. > schreiber@mx.process.com http://www.process.com > TCPware & MultiNet: Stronger than Ever > > -- Joseph F. Noonan Systems Manager Molecular Structure Corp. A Rigaku Company jfn@msc.com pag:713-536-3286 voice:281-363-1033 x117 fax:281-364-3628 ================================================================================ Archive-Date: Wed, 27 Jan 1999 11:03:23 -0400 Sender: schreiber@process.com Date: Wed, 27 Jan 1999 10:58:45 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: "psc::schreiber"@process.com CC: info-multinet@process.com, info-tcpware@process.com, schreiber@process.com Message-ID: <009D2D6C.795AEFAA.32@process.com> Subject: RE: Using Telnet in command procedure Jeff Schreiber writes: > I know there is some sort of scripting software for VAX. I don't know > what it is right off the top of my head, and the guy that used it for > some telnet testing a few years ago isn't in yet this morning. I do > know that he was able to 'record' the connect, userid and password, > and get it to automate the login. > $ help dtm DTM DEC Test Manager is a tool that automates the process of software testing. It organizes software tests and automates how you run tests and evaluate their results. -Jeff ================================================================================ Archive-Date: Wed, 27 Jan 1999 16:08:36 -0400 Message-ID: <19990127210459.6909.rocketmail@send105.yahoomail.com> Date: Wed, 27 Jan 1999 13:04:59 -0800 (PST) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: Primary DNS and multiple domains To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I guess I had not thought of an obvious question in regards to this subject... We have a plethora of domains that we use for our company's Internet presence and we want to run primary DNS for all of them. Can this be done on one web server with TCPware? And what would the configuration look like if so? Different named.hosts files? Thanks for you help! cmw _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Thu, 28 Jan 1999 00:12:25 -0400 From: martin@RADIOGAGA.HARZ.DE (Martin Vorlaender) Subject: Re: Primary DNS and multiple domains Message-ID: <36afd261.524144494f47414741@radiogaga.harz.de> Date: Thu, 28 Jan 1999 03:58:41 +0100 Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Chris Wolfe (chriswolfe@yahoo.com) wrote: : We have a plethora of domains that we use for our company's Internet : presence and we want to run primary DNS for all of them. Can this be : done on one web server with TCPware? Definitely. This server must be entered as a nameserver for all these domains at the name servers which are one level higher (i.e. nearer to the Toplevel domain). : And what would the configuration : look like if so? Different named.hosts files? Yup. For such a setup, I prefer the default UCX naming scheme, i.e. build the named.hosts' filename by replacing every dot in the domain name by an underscore, and adding an extension of .db. The named.boot file in that case holds multiple entries of the form primary domain.name domain_name.db cu, Martin -- | Martin Vorlaender | VMS & WNT programmer VMS is today what | work: mv@pdv-systeme.de Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Fri, 29 Jan 1999 03:30:25 -0400 Message-ID: <36B1671E.8EF7024E@SMTP.DeltaTel.RU> Date: Fri, 29 Jan 1999 10:45:34 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: SNMP agent - MRTG Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! I use MRTG (http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html) for monitoring of nodes activity, during 1-1.5 week (after reboot of VMS hosts) traffic which is displayed by MRTG bring to 0 (Zero!) for VMS hosts, in the same time traffic from Windoze servers and Linux box is displayed normaly. Just for demonstration of this effect http://www.dls.net/mrtg/dls/hammer-dls-net-2.html,- this is VMS box with very high network activity (SMTP,HTTP, etc). OpenVMS 7.1, TCPWare-TCP 5.3-3, each VMS host use secondary address (> 100). Unfortunately, I can't describe this problem with more details. Any help/advice is appreciated. -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Fri, 29 Jan 1999 04:35:52 -0400 From: "Martin Elcock" Reply-To: Info-TCPware@process.com Subject: How do you set-up Reverse Telnet connections to devices attached to CISCO Routers? Date: Fri, 29 Jan 1999 09:26:03 -0000 Message-ID: <78rurd$435@romeo.logica.co.uk> To: Info-TCPware@PROCESS.COM I am trying to create a 'reverse Telnet' connection from a VAX running TCPware to some asynchronous devices (e.g. printer) hosted on a CISCO router, (3620). I have previously used NTA devices which communicate via 'listener' devices when talking to the same devices hosted on Digital terminal servers. My VAX application just need to talk to a VMS device to 'talk' to. Do I need a telnet service to get this to work? -- * Martin P. Elcock | mailto:elcockm@logica.com * ************************************************************ ================================================================================ Archive-Date: Fri, 29 Jan 1999 11:43:47 -0400 Subject: Re: SNMP agent - MRTG Message-ID: <1999Jan29.110050@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 29 Jan 99 11:00:50 -0500 To: Info-TCPware@PROCESS.COM In article <36B1671E.8EF7024E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Hi ! > I use MRTG (http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html) for monitoring of > nodes activity, during 1-1.5 week (after reboot of VMS hosts) traffic which is > displayed by MRTG bring to 0 (Zero!) for VMS hosts, in the same time traffic from > Windoze servers and Linux box is displayed normaly. Just for demonstration of this > effect http://www.dls.net/mrtg/dls/hammer-dls-net-2.html,- this is VMS box with very > high network activity (SMTP,HTTP, etc). > > > OpenVMS 7.1, TCPWare-TCP 5.3-3, each VMS host use secondary address (> 100). > Unfortunately, I can't describe this problem with more details. > > Any help/advice is appreciated. > One thought ... perhaps your SNMP counters are maxing out on the VMS system. If I recall, the SNMP counters "stop" when they hit the maximum value. Depending on exactly which SNMP counters are being monitored by MRTG, you might need to reset several counters including the Ethernet counters (as TCPware's SNMP reads these). I think (DECnet Phase IV) NCP could do this (ZERO LINE EWA-0 COUNT). Or, reset the TCPware counters (NETCU SHOW COUNT/RESET). This is just a thought though. - Bernie Volz ================================================================================ Archive-Date: Fri, 29 Jan 1999 14:46:06 -0400 Message-ID: <36B1F91A.2DC3EBDF@SMTP.DeltaTel.RU> Date: Fri, 29 Jan 1999 21:08:26 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: SNMP agent - MRTG Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Bernie Volz wrote: > > In article <36B1671E.8EF7024E@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > > Hi ! > > I use MRTG (http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html) for monitoring of > > nodes activity, during 1-1.5 week (after reboot of VMS hosts) traffic which is > > displayed by MRTG bring to 0 (Zero!) for VMS hosts, in the same time traffic from > > Windoze servers and Linux box is displayed normaly. Just for demonstration of this > > effect http://www.dls.net/mrtg/dls/hammer-dls-net-2.html,- this is VMS box with very > > high network activity (SMTP,HTTP, etc). > > > > > > OpenVMS 7.1, TCPWare-TCP 5.3-3, each VMS host use secondary address (> 100). > > Unfortunately, I can't describe this problem with more details. > > > > Any help/advice is appreciated. > > > > One thought ... perhaps your SNMP counters are maxing out on the VMS system. > If I recall, the SNMP counters "stop" when they hit the maximum value. --------there is debug output from MRTG------------- getting SNMP variables for target: 2:public@host.domain.com snmpget: ifInOctets.2 ifOutOctets.2 host.domain.com public SNMPGET OID: 1.3.6.1.2.1.2.2.1.10.2 SNMPGET OID: 1.3.6.1.2.1.2.2.1.16.2 SNMPGET OID: 1.3.6.1.2.1.1.3.0 SNMPGET OID: 1.3.6.1.2.1.1.5.0 SNMPGET OID: 1.3.6.1.2.1.2.2.1.2.2 EWA-0, DEC PCI Bus Adapter (TULIP) 2:public@host --> in: 4294967295 out: 4294967295 name: host.domain.com uptime 18 days -------- Hmmm.... Some calculations: 4 294 967 295 bytes / 10 (days) = 429 496 729 bytes/day 29 496 729 bytes / 24 hours = 17 895 697 bytes/hour (!) 17 895 697 bytes /3600 sec = 4980 bytes/sec http://www.dls.net/mrtg/dls/hammer-dls-net-2.html (VMS box) - 15 Kbytes/sec. http://www.dls.net/mrtg/dls/news-dls-net-2.html (non-VMS box) - there is higher traffic then at VMS box, but counters looks well. > > Depending on exactly which SNMP counters are being monitored by MRTG, you > might need to reset several counters including the Ethernet counters (as > TCPware's SNMP reads these). I think (DECnet Phase IV) NCP could do this > (ZERO LINE EWA-0 COUNT). Or, reset the TCPware counters (NETCU SHOW > COUNT/RESET). Thanks. It's seems to be solution. > > This is just a thought though. > > - Bernie Volz -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Fri, 29 Jan 1999 18:13:50 -0400 Message-ID: <36B23A45.B6E2E8D9@SMTP.DeltaTel.RU> Date: Sat, 30 Jan 1999 01:46:29 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: SNMP agent - MRTG Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Ruslan R. Laishev wrote: > > > > > Depending on exactly which SNMP counters are being monitored by MRTG, you > > might need to reset several counters including the Ethernet counters (as It's key to understanding, at VMS boxes big influnce to the traffic made by LAVC. > > TCPware's SNMP reads these). I think (DECnet Phase IV) NCP could do this > > (ZERO LINE EWA-0 COUNT). Or, reset the TCPware counters (NETCU SHOW > > COUNT/RESET). > Thanks. It's seems to be solution. NETCU SHO/RESET - no effect. NCP ZERO KNO LINE ... - Ok. > > > > > This is just a thought though. Thanks all for the counstructive answers! :) > > > > - Bernie Volz -- Be well, right now. +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom JSC, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 Fax: +7 (812) 115-1035 +http://www.radiusvms.com ................... SysMan rides HailStorm +