Archive-Date: Mon, 8 Sep 2003 21:35:31 -0400 Date: Mon, 08 Sep 2003 21:30:17 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.0-4, VAX/VMS v5.5-2, RCP, "Failure to create shell"/"ACP File Access Failure" To: info-tcpware@process.com CC: bryant@process.com Message-ID: <01L0FQCA5Q008WYWGE@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii This message came from the newsgroup gateway and is getting trapped in some filters we have on the list. The easiest thing for me to do is to forward it as a new message. If this is a duplicate (I don't think so), my apolgies. Geoff Bryant (who gets info-posts that are sent for human review) --- From: covendotartdottalk21dotcom Subject: Re: TCPWARE v5.0-4, VAX/VMS v5.5-2, RCP, "Failure to create shell"/"ACP File Access Failure" To: info-tcpware@process.com Upon further investigation (including monitoring the system at the time the faults were occurring), it became clear what the nature of the problem was... The NETCP process is started as a detached process using a UIC of [1,3]. Since this does not equate to an actual user account, VMS was gving the NETCP process a maximum file limit that was equal to the SYSGEN parameter PQL_MFILLM, which was 100. There were ~145 concurrent incoming connections from systems which all specified the same user account for "proxy" access, resulting in NETCP attempting to open the .RHOSTS file in the SYS$LOGIN directory for that account, 145 times. Well, it got upto its file limit of 100, then got an RMS error trying to open up further channels to the file. Now, you can argue the toss either way about whether or not NETCP was right in what it was doing (i.e. couldn't it have shared the .RHOSTS file between the incoming threads? As a programmer, I can argue very strongly for why it shouldn't; as a sysop, I can argue very strongly for why it should), but the fact of the matter is, that that's what it was doing. I upped the PQL_MFILLM parameter (since it is a dynamically changeable parameter) to 500 (and the same for MAX_CHANNELCNT), changed MODPARAMS.DAT and AUTOGENed the system in preparation for whenever the next power loss occurs, and Bob's your uncle. By the way, is it just me, or does this group appear to have been hijacked for the purposes of discussing the Buffy television series, in (possibly) Spanish? Do some people not know how to go about requesting creation of new newsgroups, or just as clueless as always? Mark "covendotartdottalk21dotcom" wrote in message news:r3OdnYQAq9cJo9iiXTWJjQ@brightview.com... > Hello folks. > > Whilst trying to get around to migrating an old LAVC to a couple of Alphas > with somewhat > more recent versions of software, I'm still having to firefight on a daily > basis. > > We have a number of Unix systems (mainly HP-UX) which copy offsite backups > onto the LAVC > using RCP, and recently (possibly), a number of them appear to be failing. > > To be honest, it may not be that recently that things started failing, as we > only > recently found problems with the job that checks to see whether or not the > modification > date of the backups is the same as the date on which the checker job which > runs on the > LAVC (and the email .DIS list was sending to now-invalid addresses, as a > result of > recent email server changes). > > On further investigation, the remote Unix nodes (not always the same ones) > sometimes > recport ACP File Access Failure messages, and drop out (okay, okay, there's > no error > handling on that part either), and the NETCP.LOG file indicates that prior > to the > ACP file access failure, there is a failure to create the shell process (I'm > not at > work at the moment, so I forget the exact text of the message). > > I suspect that it's almost certainly some kind of resource problem, and have > enabled > file access auditing in the login directory for the account which these > remote systems > connect using, but there's nothing in there (or in the OPERATOR.LOG file). > > I found from the 5.1 release notes references to increasing the > /BUFFER_LIMIT qualifier's > value in STARTNET.COM to 4194304 bytes, but I've found that NETCP is already > using this. > > Checking the NETCP log file for entries created since today, I found that > prior to > the first failure being reported, some 400 incoming connections had been > made, and about > 260 of them had already been dropped (i.e. there were ~140 still-active > connections). > > The release notes give a rough guide as to how to calculate the > /BUFFER_LIMIT value, and > the given value of 4194304 should be sufficient to "allow about 500+ > sessions". > > I was wondering whether or not the size of the files being transferred by > the remote > Unix systems may in any way be relevant to how the /BUFFER_LIMIT value > should be > calculated? > > The only other things I thought might be relevant was the first of all the > MAXPROCESSCNT > Sysgen parameter (as I'm not normally logged in at the time of day these > remote copies > occur, it was only when we performed a test today with ~20 connections, that > I saw 20 > separate processes being created, rather than NETCP (for example) handling > 20 threads by > itself). > > However, this is currently set at about 480, and even with 140 still-active > connections, > plus the residual processes and batch jobs that are normally running, I > can't see that > value being reached either. > > The other thought I had was maybe the FILLM account quota for the account > under which > TCPWARE is started. > > Examining the NETCP process in SDA shows the limit to be 100, but I don't > know if this > is relevant, since detached processes are being created (does NETCP need one > of those > channels for a split second whilst the detached process is created, and/or > the MBX > device that it will be using?) > > I'm loathe to turn on accounting, for any extended period of time, due to > the large > number of other records which will generated by ordinary system activity. > > Has anyone seen anything like this before, or have some suggestions as to > what to try > next? [I'm considering dialling in to work in about 5 hours, to monitor the > system at > the time the failures normally occur, perhaps turning accounting on briefly > beforehand] > > > Regards, > > > > Mark > > -- > To email me, remove the first instance of "dot" entirely, replace the second > "dot" with > '.', remove the 'r' from "art" (and then replace the resulting word with its > "known" > symbol), as my to: address > > ================================================================================ Archive-Date: Fri, 12 Sep 2003 04:26:31 -0400 Date: Fri, 12 Sep 2003 10:24:25 +0200 From: Godfrey Pillay Reply-To: Info-TCPware@process.com Subject: TCPWare Vulnerablilty To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 002E42E442256D9F_=" This is a multipart message in MIME format. --=_alternative 002E42E442256D9F_= Content-Type: text/plain; charset="us-ascii" Hi I have received a report from a TCP/IP vulnerability scan. I require help in regards to fixing these vulnerabilities. Is there a patch/system setting or do I need to upgrade. Any help is welcome I am running OPENVMS V7.2 on a DEC/VAX with Tcpware V 5.3-2. [high] [rpc.status/601/UDP] Server appears to use user input as a C format string (monitor-name). [high] [rpc.status/601/UDP] Server exits on long monitor name; possible buffer overflow. [high] [rpc.status/1033/TCP] Server appears to use user input as a C format string (monitor-name). [high] [rpc.status/1033/TCP] Server exits on long monitor name; possible buffer overflow. [high] [telnet/23/TCP] Server exits on large number of environment variables after username (/bin/login); possible buffer overflow. [attention] [9/TCP] discard is active. [attention] [512/TCP] rexec is active. [attention] [SunRPC/111/TCP] SunRPC program 100000 (portmapper) is active. [attention] [SunRPC/2049/TCP] SunRPC program 100005 (rpc.mountd) is active. [attention] [SunRPC/111/UDP] SunRPC program 100000 (portmapper) is active. [attention] [SunRPC/2049/UDP] SunRPC program 100005 (rpc.mountd) is active. [attention] [SunRPC/601/UDP] SunRPC program 100024 (rpc.status) is active. [attention] [NFS/2049/UDP] `/DIS_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/OASIS_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/OWNER_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/ROADSHOW_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/STKPLAN_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/STKSHT_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/STKTAKE_ALR' is shared to everyone. [attention] [NFS/2049/UDP] `/VSS_ALR' is shared to everyone. Regards Godfrey Pillay VAX Team Leader Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com "There are 10 types of people in this world: those who understand binary and those who don't." --=_alternative 002E42E442256D9F_= Content-Type: text/html; charset="us-ascii"
Hi

I have received a report from a TCP/IP vulnerability scan. I require help in regards to fixing these vulnerabilities. Is there a patch/system setting or do I need to upgrade. Any help is welcome

I am running OPENVMS V7.2 on a DEC/VAX with Tcpware V 5.3-2.

  • [high] [rpc.status/601/UDP] Server appears to use user input as a C format string (monitor-name).
  • [high] [rpc.status/601/UDP] Server exits on long monitor name; possible buffer overflow.
  • [high] [rpc.status/1033/TCP] Server appears to use user input as a C format string (monitor-name).
  • [high] [rpc.status/1033/TCP] Server exits on long monitor name; possible buffer overflow.
  • [high] [telnet/23/TCP] Server exits on large number of environment variables after username (/bin/login); possible buffer overflow.
  • [attention] [9/TCP] discard is active.
  • [attention] [512/TCP] rexec is active.
  • [attention] [SunRPC/111/TCP] SunRPC program 100000 (portmapper) is active.
  • [attention] [SunRPC/2049/TCP] SunRPC program 100005 (rpc.mountd) is active.
  • [attention] [SunRPC/111/UDP] SunRPC program 100000 (portmapper) is active.
  • [attention] [SunRPC/2049/UDP] SunRPC program 100005 (rpc.mountd) is active.
  • [attention] [SunRPC/601/UDP] SunRPC program 100024 (rpc.status) is active.
  • [attention] [NFS/2049/UDP] `/DIS_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/OASIS_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/OWNER_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/ROADSHOW_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/STKPLAN_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/STKSHT_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/STKTAKE_ALR' is shared to everyone.
  • [attention] [NFS/2049/UDP] `/VSS_ALR' is shared to everyone.


    Regards

    Godfrey Pillay
    VAX Team Leader
    Location:  IBM Park Sandton, IA2G
    Tel: (011) 302-6310   Fax: (011) 302-6592
    Cell: 082 823-5339  E-mail: gpillay@za.ibm.com

    "There are 10 types of people in this world:
    those who understand binary and those who don't."
--=_alternative 002E42E442256D9F_=-- ================================================================================ Archive-Date: Fri, 12 Sep 2003 06:46:34 -0400 Date: Fri, 12 Sep 2003 12:44:39 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: RE: TCPWare Vulnerablilty In-Reply-To: To: info-tcpware@process.com Message-ID: <003201c3791a$de3e47c0$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Geoffrey, [high] [rpc.status/601/UDP] Server appears to use user input as a C = format string (monitor-name).[high] [rpc.status/601/UDP] Server exits on long monitor name; possible buffer overflow.=20 [high] [rpc.status/1033/TCP] Server appears to use user input as a C = format string (monitor-name).[high] [rpc.status/1033/TCP] Server exits on long monitor name; possible buffer overflow.=20 -> There appears an application listenting on 601/UDP and 1033/TCP - not = a direct TCPware issue IMHO.=20 [high] [telnet/23/TCP] Server exits on large n=20 -> potentially a TCPware issue, might be fixed with a higher number - = don't have an ISS scanner handy, please ask your security officer to run the = same test against 194.191.19.254 (the Swiss HP-Interex/DECUS system running TCPWARE 5.6-2), but please before send me a notification) - this system = is fully exposed to the net ;-) [attention] [9/TCP] discard is active. -> disable it if not required by using $ @tcpware:cnfnet misc [attention] [512/TCP] rexec is active. -> disabled if not required by $ @tcpware:cnfnet rcmd -> if required ensure SECURE login authorization is enabled -> carefully select the required options - only what's required [attention] [SunRPC/111/TCP] SunRPC program 100000 (portmapper [attention] [SunRPC/2049/TCP] SunRPC program 100005 (rpc.mountd [attention] [SunRPC/111/UDP] SunRPC program 100000 (portmapper [attention] [SunRPC/2049/UDP] SunRPC program 100005 (rpc.mountd [attention] [SunRPC/601/UDP] SunRPC program 100024 (rpc.status [attention] [NFS/2049/UDP] `/DIS_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/OASIS_ALR' is shared to everyone[attention] = [NFS/2049/UDP] `/OWNER_ALR' is shared to everyone[attention] [NFS/2049/UDP] = `/ROADSHOW_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/STKPLAN_ALR' is shared = to everyone[attention] [NFS/2049/UDP] `/STKSHT_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/STKTAKE_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/VSS_ALR' is shared to everyone -> Suggest to update to a decent TCPWare variant and configure NFS V3 accordingly (bet all the clients in the IBM environment are NFS V3) - or disable if NFS is not required at all. -> In general we suggset to update to a decent version. Please let me know if you need more information. Greetings to the south = ;-) -Kurt. Applied Security KCS Engineering & Consulting Switzerland -----Original Message----- From: Godfrey Pillay [mailto:gpillay@za.ibm.com]=20 Sent: Friday, September 12, 2003 10:24 AM To: info-tcpware@process.com Subject: TCPWare Vulnerablilty Hi=20 I have received a report from a TCP/IP vulnerability scan. I require = help in regards to fixing these vulnerabilities. Is there a patch/system setting = or do I need to upgrade. Any help is welcome=20 I am running OPENVMS V7.2 on a DEC/VAX with Tcpware V 5.3-2.=20 [high] [rpc.status/601/UDP] Server appears to use user input as a C = format string (monitor-name).[high] [rpc.status/601/UDP] Server exits on long monitor name; possible buffer overflow.=20 [high] [rpc.status/1033/TCP] Server appears to use user input as a C = format string (monitor-name).[high] [rpc.status/1033/TCP] Server exits on long monitor name; possible buffer overflow.=20 [high] [telnet/23/TCP] Server exits on large n=20 [attention] [9/TCP] discard is active.[attention] [512/TCP] rexec is active.[attention] [SunRPC/111/TCP] SunRPC program 100000 (portmapper[attention] [SunRPC/2049/TCP] SunRPC program 100005 (rpc.mountd[attention] [SunRPC/111/UDP] SunRPC program 100000 (portmapper[attention] [SunRPC/2049/UDP] SunRPC program 100005 (rpc.mountd[attention] [SunRPC/601/UDP] SunRPC program 100024 (rpc.status[attention] [NFS/2049/UDP] `/DIS_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/OASIS_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/OWNER_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/ROADSHOW_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/STKPLAN_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/STKSHT_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/STKTAKE_ALR' is shared to everyone[attention] [NFS/2049/UDP] `/VSS_ALR' is shared to everyone Regards Godfrey Pillay VAX Team Leader Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com "There are 10 types of people in this world: those who understand binary and those who don't."=20 ================================================================================ Archive-Date: Fri, 12 Sep 2003 11:52:36 -0400 Date: Fri, 12 Sep 2003 08:50:14 -0700 From: "Barry Treahy, Jr." Reply-To: Info-TCPware@process.com Subject: Re: TCPWare Vulnerablilty In-Reply-To: To: info-tcpware@process.com Message-ID: <3F61EB36.6040609@MMaz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit References: Godfrey Pillay wrote: > > Hi > > I have received a report from a TCP/IP vulnerability scan. I require > help in regards to fixing these vulnerabilities. Is there a > patch/system setting or do I need to upgrade. Any help is welcome > > I am running OPENVMS V7.2 on a DEC/VAX with Tcpware V 5.3-2. > Should you, for starters, at least upgrade to the latest release? You've missed two that I'm aware of! Barry -- Barry Treahy, Jr E-mail: Treahy@MMaz.com Midwest Microwave Phone: 480/314-1320 Vice President & CIO FAX: 480/661-7028 ================================================================================ Archive-Date: Fri, 19 Sep 2003 04:42:03 -0400 Date: Fri, 19 Sep 2003 10:39:43 +0200 From: Godfrey Pillay Reply-To: Info-TCPware@process.com Subject: TCPWARE V5.6-2 To: info@foster-melliar.co.za CC: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 002FA70842256DA6_=" This is a multipart message in MIME format. --=_alternative 002FA70842256DA6_= Content-Type: text/plain; charset="us-ascii" Hi I am currently running Tcpware V5.6-2 and TCPware 5.3-2 on a DEC VAX with OPENVMS V7.2. I also run another product called NET-WORK which SOftware AG supplied. The local supplier is Dimension data. NET-WORK is a tranmission protocol which works in conjunction with ADABAS and Natural which is also supplied by Software AG. We have currently configured NET-WORK to use DECNET as its transport protocol and this works fine. However when we tried to configure it to use TCP/IP, it simply does not work on any of the versions of TCPWare (see error below). I have loaded a trial copy of Digital's TCP/IP services and the transmissions works fine. I do not want to buy Digital's TCP/IP as it is too expensive for the DEC/VAX although we could get it for free if we migrated the environment to DEC-ALPHA. Can Support at TCPWARE help me to resolve this problem.....It seems that NET-WORK was written with Digitals UCX compatibility. The message from the NET-WORK logfile %LIB-E-ACTIMAGE, error activating image $1$DIA0:[SYS0.SYSCOMMON.][SYSLIB]UCX$ACCESS_SHR.EXE; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC=00000002, PSL=03C00000 Context information 00078220 : 322E3756 00078224 : 20202020 00078228 : 00000013 0007822C : 00000003 00078230 : 13000202 00078234 : 00000000 00078238 : 01D40000 ... Regards Godfrey Pillay VAX Team Leader Location: IBM Park Sandton, IA2G Tel: (011) 302-6310 Fax: (011) 302-6592 Cell: 082 823-5339 E-mail: gpillay@za.ibm.com "There are 10 types of people in this world: those who understand binary and those who don't." --=_alternative 002FA70842256DA6_= Content-Type: text/html; charset="us-ascii"
Hi

I am currently running Tcpware V5.6-2 and TCPware 5.3-2 on a DEC VAX with OPENVMS V7.2. I also run another product called NET-WORK which SOftware AG supplied. The local supplier is Dimension data. NET-WORK is a tranmission protocol which works in conjunction with ADABAS and Natural which is also supplied by Software AG.  We have currently configured NET-WORK to use DECNET as its transport protocol and this works fine. However when we tried to configure it to use TCP/IP, it simply does not work on any of the versions of TCPWare (see error below). I have loaded a trial copy of Digital's TCP/IP services and the transmissions works fine. I do not want to buy Digital's TCP/IP as it is too expensive for the DEC/VAX although we could get it for free if we migrated the environment to DEC-ALPHA. Can Support at TCPWARE help me to resolve this problem.....It seems that NET-WORK was written with Digitals UCX compatibility.

The message from the NET-WORK logfile

%LIB-E-ACTIMAGE, error activating image $1$DIA0:[SYS0.SYSCOMMON.][SYSLIB]UCX$ACCESS_SHR.EXE;                                                            
                                                                               
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000,  PC=00000002, PSL=03C00000                                                      

          Context information                                            
          00078220 :  322E3756                                                  
          00078224 :  20202020                                                  
          00078228 :  00000013                                                  
          0007822C :  00000003                                                  
          00078230 :  13000202                                                  
          00078234 :  00000000                                                  
          00078238 :  01D40000    
          ...
 



Regards

Godfrey Pillay
VAX Team Leader
Location:  IBM Park Sandton, IA2G
Tel: (011) 302-6310   Fax: (011) 302-6592
Cell: 082 823-5339  E-mail: gpillay@za.ibm.com

"There are 10 types of people in this world:
those who understand binary and those who don't." --=_alternative 002FA70842256DA6_=-- ================================================================================ Archive-Date: Thu, 25 Sep 2003 08:40:33 -0400 Date: Thu, 25 Sep 2003 08:38:20 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com Message-ID: <01L12Q5HERYW8WYGLE@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii This post is done in a way that it will not pass through the spam filters on the list. I am forwarding on behalf of the original poster... On Thu, 25 Sep 2003 00:16:31 +0100, covendotartdottalk21dotcom wrote: > >X-posted to c.o.v because it seems that nobody uses >vmsnet.networks.tcp-ip.tcpware any more, other than film pirates... > >I don't suppose anyone here is still running TCPWARE at v5.4-3, is using >Patch #19, and is having FTP work with no problems? > >Due to the production environment, all patches of any description must >go through a qualification period first of all, and the time taken to roll >out across the network in the small "window of opportunity" with the >limited resources we have means we are somewhat behind in versions (as >TCP/IP isn't really used on the boxes, but one customer is using it, has >recently upgraded to this patch, and is having problems). > >The symptomn is that you can't open a control connection to the >TCPware_FTP process after a seemingly arbitrary number of FTP operations. > >When I examined the "hung" state on the customer's machine, it was showing >the process in a HIB state, but SDA showed that the process was getting >CPU every quantum, though the PC didn't seem to move, and the I/O counts >didn't increase (buffered or direct). > >Examining the log file, I found that there had been ~1,600 connections into >the TCPware_FTP server prior to it hanging. > >As a test, I tried to reproduce this on one of our systems (where we still >use DECnet for inter-nodal transfers), whereby a batch job on one system >(running on an even older version of TCPware!) connected to the remote >system about 630 times (on each occasion, pulling a 1 block file from the >5.4-3 P19 server) before it too, hung. > >Analysis of the INET and MBX devices it was using, in SDA, didn't reveal >anything obvious either. > >Restarting TCPware, and repeating the test caused it to lock up at after >about 240 such connections. > >I've looked on Process's website, but can't find any later patch kits, and >it indicates that P19 is still supported (though curiously, the ECO search >utility will only find the ECO if you type the ECO name in exactly - a bit >difficult to do if you don't know it exists (i.e. for users using 5.4-3 >who haven't yet migrated to P19)). > >Anyone seen anything like this, or got some (polite) suggestions? > > >Regards, > > >Mark > > ================================================================================ Archive-Date: Thu, 25 Sep 2003 09:43:06 -0400 Date: Thu, 25 Sep 2003 06:11:05 -0700 From: bob@instantwhip.com (Bob Ceculski) Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit "covendotartdottalk21dotcom" wrote in message news:... > X-posted to c.o.v because it seems that nobody uses > vmsnet.networks.tcp-ip.tcpware any more, other than film pirates... > > I don't suppose anyone here is still running TCPWARE at v5.4-3, is using > Patch #19, and is having FTP work with no problems? we have had no problems with it, although we are not running 1000 simultaneous connections at once ... :) ================================================================================ Archive-Date: Mon, 29 Sep 2003 21:50:11 -0400 Date: Mon, 29 Sep 2003 21:46:18 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com CC: bryant@process.com Message-ID: <01L192XKE96E8WYGLE@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii I am forwarding this message as the list spam filters will not let it through otherwise. Geoff Bryant From: IN%"postmaster@127.0.0.1" 29-SEP-2003 18:34:11.18 29-SEP-2003 18:34:00.00 To: IN%"info-tcpware@process.com" CC: Subj: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" "Bob Ceculski" wrote in message news:d7791aa1.0309250511.735648a6@posting.google.com... > "covendotartdottalk21dotcom" wrote in message news:... > > X-posted to c.o.v because it seems that nobody uses > > vmsnet.networks.tcp-ip.tcpware any more, other than film pirates... > > > > I don't suppose anyone here is still running TCPWARE at v5.4-3, is using > > Patch #19, and is having FTP work with no problems? > > we have had no problems with it, although we are not running > 1000 simultaneous connections at once ... :) Apologies for the delay in posting. I should have said that OpenVMS/AXP is running at 7.2-1 We don't have 1000 simultaneous connections... In fact, we don't use it at all (but it has to be on the system because customers have it, and we are migrating away from DECnet to TCP/IP). If I create a .COM file to simply connect, get file, disconnect, and repeat in a loop, the FTP server will eventually "hang" after <=650 connections (or maybe it is the GET that is doing it). I suspect it's probably something been introduced in P19, but because so few people are using it, it hasn't been encountered yet. Unfortunately, we are also migrating away from TCPware back to TCP/IP services, so that's even less incentive for Process to fix it. [I think the licence fees were far more favourable with HP than they ever would be with Process; I gather that TCP/IP services is more stable now than UCX (ever) was] Mark ================================================================================ Archive-Date: Mon, 29 Sep 2003 21:53:23 -0400 Date: Mon, 29 Sep 2003 21:48:55 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com CC: bryant@process.com Message-ID: <01L1931JDZQ68WYGLE@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii And another message as well... From: IN%"postmaster@127.0.0.1" 29-SEP-2003 18:36:11.19 29-SEP-2003 18:36:00.00 To: IN%"info-tcpware@process.com" CC: Subj: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" "Geoff Bryant" wrote in message news:01L12Q5HERYW8WYGLE@PROCESS.COM... > This post is done in a way that it will not pass through the spam filters > on the list. I am forwarding on behalf of the original poster... List? Listserv? People are still using mailing lists?? What was "wrong" about my post that wouldn't allow it to pass through said spam filters? ================================================================================ Archive-Date: Mon, 29 Sep 2003 21:56:54 -0400 Date: Mon, 29 Sep 2003 20:53:22 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" In-Reply-To: "Your message dated Mon, 29 Sep 2003 21:48:55 -0400" <01L1931JDZQ68WYGLE@PROCESS.COM> To: info-tcpware@process.com Message-ID: <01L1912G3PQ28WWJB8@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii > From: IN%"postmaster@127.0.0.1" 29-SEP-2003 18:36:11.19 29-SEP-2003 18:36:00.00 > List? Listserv? People are still using mailing lists?? Yep. > What was "wrong" about my post that wouldn't allow it to pass through > said spam filters? You're posting so that your From: address is postmaster@127.0.0.1. The filters block postmaster from posting to avoid loops from brain-dead mailers. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 29 Sep 2003 22:02:53 -0400 Date: Mon, 29 Sep 2003 22:00:29 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com Message-ID: <01L19342D8Z68X1OUK@PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii On Mon, 29 Sep 2003 21:48:55, Geoff Bryant wrote: > >And another message as well... > >From: IN%"postmaster@127.0.0.1" 29-SEP-2003 18:36:11.19 29-SEP-2003 18:36:00.00 >To: IN%"info-tcpware@process.com" >CC: >Subj: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" > > >"Geoff Bryant" wrote in message >news:01L12Q5HERYW8WYGLE@PROCESS.COM... >> This post is done in a way that it will not pass through the spam filters >> on the list. I am forwarding on behalf of the original poster... > >List? Listserv? People are still using mailing lists?? Yes, the vmsnet.networks.tcp-ip.tcpware newsgroup is gatewayed into a mail list: info-tcpware. There are other mail lists that we maintain for other Process products, some of which are also gatewayed to news. At this point the mail lists are probably far better, as they are put through a spam filter. I don't track numbers for individual lists, but for 8 of the lists combined there are about 800 posts filtered out each week. There are numerous spams and binary postings that are removed. If you are interested in the list, send an email to info-tcpware-request@process.com with SUBSCRIBE in the body. >What was "wrong" about my post that wouldn't allow it to pass through >said spam filters? > Your from address shows up as covendotartdottalk21dotcom and postmaster posts are filtered to prevent mail loops which is part of the spam/list_problem filtering that is done for the list. So I slightly mis-spoke in that it isn't spam per se, but it is caught in that processing. Hope that helps. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/MultiNet/PMDF/SSH/PreciseMailAntiSpam Engineering Process Software http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Tue, 30 Sep 2003 03:25:49 -0400 Date: Tue, 30 Sep 2003 09:23:07 +0200 From: "Kurt A. Schumacher" Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" In-Reply-To: <01L19342D8Z68X1OUK@PROCESS.COM> To: info-tcpware@process.com Message-ID: <000801c38723$b2511810$14010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Geoff, Hunter, As a courtesy to the users of the Process lists gatewayed to the news network, it would be nice to falsify or remove valid e-mail addresses = (_at_, dot ...), so all the nice programs trying to collect addresses - such as = the recent *SWEN* worms. Addresses are passed in clear text supposedly when gatewaying from the = mail, but with a news client we can set anything falsified, this is probably = what Mark tried to achieve with his postmaster entry... Can't proof, because all the locally accessible news servers don't carry vmsnet.networks.tcp-ip.tcpware. Thank you in advance, -Kurt. PS: From this prospective I prefer lists over anything related to the = news network ;-)) -----Original Message----- From: Geoff Bryant [mailto:bryant@process.com]=20 Sent: Tuesday, September 30, 2003 4:00 AM To: info-tcpware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" On Mon, 29 Sep 2003 21:48:55, Geoff Bryant wrote: > >And another message as well... > >From: IN%"postmaster@127.0.0.1" 29-SEP-2003 18:36:11.19 29-SEP-2003 18:36:00.00 >To: IN%"info-tcpware@process.com" >CC:=09 >Subj: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" > > >"Geoff Bryant" wrote in message=20 >news:01L12Q5HERYW8WYGLE@PROCESS.COM... >> This post is done in a way that it will not pass through the spam = filters >> on the list. I am forwarding on behalf of the original poster... > >List? Listserv? People are still using mailing lists?? Yes, the vmsnet.networks.tcp-ip.tcpware newsgroup is gatewayed into a = mail list: info-tcpware. There are other mail lists that we maintain for = other Process products, some of which are also gatewayed to news. ================================================================================ Archive-Date: Tue, 30 Sep 2003 09:25:59 -0400 Date: Tue, 30 Sep 2003 05:41:18 -0700 From: bob@instantwhip.com (Bob Ceculski) Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit "covendotartdottalk21dotcom" wrote in message news:... > "Bob Ceculski" wrote in message > news:d7791aa1.0309250511.735648a6@posting.google.com... > > "covendotartdottalk21dotcom" wrote in message > news:... > > > X-posted to c.o.v because it seems that nobody uses > > > vmsnet.networks.tcp-ip.tcpware any more, other than film pirates... > > > > > > I don't suppose anyone here is still running TCPWARE at v5.4-3, is using > > > Patch #19, and is having FTP work with no problems? > > > > we have had no problems with it, although we are not running > > 1000 simultaneous connections at once ... :) > > Apologies for the delay in posting. > > I should have said that OpenVMS/AXP is running at 7.2-1 > > We don't have 1000 simultaneous connections... In fact, we don't use it > at all (but it has to be on the system because customers have it, and we > are migrating away from DECnet to TCP/IP). why would you want to give up all the features of decnet for the archaic ones in IP ... did you know that you can run decnet phase IV over IP in TCPware? I don't think I would get off of tcpware! ================================================================================ Archive-Date: Tue, 30 Sep 2003 09:42:19 -0400 Date: Tue, 30 Sep 2003 09:40:01 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" In-Reply-To: To: info-tcpware@process.com Message-ID: <3F7987B1.7020908@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit References: >I don't suppose anyone here is still running TCPWARE at v5.4-3, is using >Patch #19, and is having FTP work with no problems? Have you checked the FTP_LISTENER.LOG for errors. When the FTP listener hangs go into anal/system and do a SHOW PROCESS and check to make sure you have not exausted any quotas. You might also want to try the following logical - - Correct a problem with occasional ftp timeouts (DE7038). If the symptom still presents after applying the patch, a new logical added in this patch should be used to get rid of the symptom. The logical can be defined as: $ define/system/exe TCPWARE_FTP_LISTENER_NO_HIBERNATE_OPTION TRUE ECO FTP_V543P170 rank 3 regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Tue, 30 Sep 2003 09:55:56 -0400 Date: Tue, 30 Sep 2003 08:52:32 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: RE: TCPWARE v5.4-3 Patch 19.0, TCPware_FTP process "hanging" In-Reply-To: "Your message dated Tue, 30 Sep 2003 09:23:07 +0200" <000801c38723$b2511810$14010a0a@home.schumi.ch> To: "Kurt A. Schumacher" CC: info-tcpware@process.com Message-ID: <01L19Q6YWMX68WWKHY@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii References: <01L19342D8Z68X1OUK@PROCESS.COM> Hi, Kurt. > As a courtesy to the users of the Process lists gatewayed to the news > network, it would be nice to falsify or remove valid e-mail addresses (_at_, > dot ...), so all the nice programs trying to collect addresses - such as the > recent *SWEN* worms. We've talked about doing that, but haven't had the time to work on it. I'll try to get to that soon (the same thing is true for the archives---people searching the list archives can get addresses easily). > PS: From this prospective I prefer lists over anything related to the news > network ;-)) Yep! Hunter