Archive-Date: Tue, 1 Dec 1998 07:20:16 -0400 Date: Tue, 01 Dec 1998 07:20:30 -0400 (EDT) From: SUNY ITEC Systems and Communications Staff Reply-To: Info-TCPware@process.com Subject: CHAP/PPP To: SUPPORT@PROCESS.COM, Info-TCPware@process.com Message-ID: <01J4TCUH6PZ6AC5I06@mail.suny.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, I am running TCPWARE 5.3-2 on a VMS6.2 vax. Here is the deal: I set up a dial out modem that dials into TItle IV wan. I get connected to their system and I have to enter what type of connection, which is PPP. When I press enter it starts a CHAP authentication. My question is how (if at all possible) do I configure TCPware to go active and do what I need it to do on that dial out line? This is what is happening: I do a set host/dte txa0: then I enter atdt9,1800xxx-xxx, it then connects (ie CONNECTED 24000/ARQ) and states HPN phone location PAD #X PORT: PXX then an asterik * at the asterik I enter PPP, that is when CHAP starts and I get funny chars on the screen. Thanks, -Dave David A. Massaro Systems and Networking Support Group SUNY Information Technology Exchange Center State University of New York WEB: www.itec.suny.edu College at Buffalo Twin Rise 208 Internet: SCSYS@ITEC.SUNY.EDU 1300 Elmwood Avenue SUNY DECnet: SBSCVC::SCSYS Buffalo, New York, 14222 VOICE: 716-878-4832 U.S.A., Planet Earth FAX: 716-878-4235 ******************************************************************************* After-hours SCSYS support line : 1-888-720-3296 (or e-mail 8007208398.0818849@PageNet.NET) Weekends, Weeknights, and Holidays. Director's office: 716-878-4206 ******************************************************************************* Disclaimer: "However, in their extramural utterances employees have an obligation to indicate that they are not institutional spokespersons." -Policies of the Board of Trustees, 1989 ******************************************************************************* ================================================================================ Archive-Date: Tue, 1 Dec 1998 13:07:39 -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: Tue, 1 Dec 1998 14:47:04 -0400 Sender: LUTES@textron.com Message-ID: <3663F2D2.659EE660@cessna.textron.com> Date: Tue, 01 Dec 1998 13:44:50 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: TCPWARE 5.3 / VMS 6.2 References: <1998Dec1.103546@alcor.process.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > 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 Thanks, Bernie. I've followed your suggestion and downloaded TCPWARE_VMSLPRSMB 5.3-2 PATCH 1.0 from the ftp site. I'll be watching now to see if this cures my problem. Dale Lutes Cessna Aircraft Company ================================================================================ Archive-Date: Thu, 3 Dec 1998 10:41:11 -0400 To: info-tcpware@process.com Date: Thu, 03 Dec 1998 07:38:49 -0700 From: "William Black" Message-ID: MIME-Version: 1.0 CC: Reply-To: Info-TCPware@process.com Subject: Multiple network cards on the same network? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Free, fast e-mail accessible anytime, anywhere http://www.imaginemail.com ================================================================================ Archive-Date: Thu, 3 Dec 1998 15:36:51 -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: Fri, 4 Dec 1998 18:48:08 -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, 7 Dec 1998 14:04:16 -0400 Message-ID: <19981207190213.6712.rocketmail@send106.yahoomail.com> Date: Mon, 7 Dec 1998 11:02:13 -0800 (PST) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: ACK time-outs To: info-tcpware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Mon, 7 Dec 1998 19:11:57 -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: Thu, 10 Dec 1998 11:37:21 -0400 Message-ID: <19981210163428.19415.qmail@hotmail.com> From: "John Richardson" Reply-To: Info-TCPware@process.com To: info-tcpware@process.com Subject: TCPware 5.3-3 MIME-Version: 1.0 Content-Type: text/plain Date: Thu, 10 Dec 1998 08:34:16 PST 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 ================================================================================ Archive-Date: Thu, 10 Dec 1998 16:33:50 -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: Fri, 11 Dec 1998 08:28:52 -0400 Message-ID: <3671184C.CF88E1F7@SMTP.DeltaTel.RU> Date: Fri, 11 Dec 1998 16:04:12 +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 <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. -- 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, 11 Dec 1998 08:42:14 -0400 Sender: bryant@process.com Date: Fri, 11 Dec 1998 08:38:31 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D086A.18B8DD57.87@process.com> Subject: Re: TCPware 5.3-3 "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. > >-- >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 + TCPware 5.3-3 is indeed a maintenance release which did include the pseudo-device feature. Seeing that most who have commented are non-US customers, I suggest you contact your distributor. If you get no help there, contact support - support@process.com. 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 ================================================================================ Archive-Date: Fri, 11 Dec 1998 10:47:46 -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: Fri, 11 Dec 1998 14:53:18 -0400 Message-ID: <19981211171155.2629.rocketmail@send101.yahoomail.com> Date: Sat, 12 Dec 1998 01:11:55 +0800 (SGT) From: Chris Wolfe Reply-To: Info-TCPware@process.com Subject: Re: ACK time-outs To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > > 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? > 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? Thanks! _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Sat, 12 Dec 1998 18:40:42 -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: Sun, 13 Dec 1998 11:59:55 -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: Sun, 13 Dec 1998 21:11:48 -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, 14 Dec 1998 08:20:40 -0400 Sender: bryant@process.com Date: Mon, 14 Dec 1998 08:18:24 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D0AC2.C881F278.26@process.com> Subject: Re: TCPware 5.3-3 eplan@kapsch.net (Peter LANGSTOEGER) writes: > >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 And: "Ruslan R. Laishev" write: >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+ > I would like to see that this is addressed so that for future TCPware releases you don't have this problem. Would you be willing to send along the name of your distributors to me so I can send this to the appropriate folks here at Process? Along related lines, someone asked about posting of patch kit notices, and I would like to say that we are getting closer to having a Web page available. You will see the same patch kit search and download tool available for TCPware that is currently available for Multinet. ------------------------------------------------------------- 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, 15 Dec 1998 01:43:03 -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: Wed, 16 Dec 1998 15:44:38 -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: Thu, 17 Dec 1998 14:05:17 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE869872C4@lespaul.process.com> From: Scott Halet Reply-To: Info-TCPware@process.com To: "'info-tcpware@process.com'" Subject: testing Date: Thu, 17 Dec 1998 14:08:59 -0500 MIME-Version: 1.0 Content-Type: text/plain testing Scott R. Halet Tech.Support Rep. Process Software 959 Concord Street Framingham, MA. 01701 800-722-7770, x526 "Nothing is ever lost by courtesy. It is the cheapest of pleasures, costs nothing, and conveys much." ================================================================================ Archive-Date: Wed, 23 Dec 1998 08:41:41 -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: Wed, 23 Dec 1998 11:40:44 -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