Archive-Date: Mon, 1 Feb 1999 13:53:56 -0400 Message-ID: <36B5F56E.6F591B35@gsc.gte.com> From: Steve Hutchinson Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: packet filtering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 01 Feb 1999 18:44:24 GMT To: Info-TCPware@PROCESS.COM I'm trying to find the best method to filter packets with TCPWARE V5.3-3 so that SYN flooding and IP spoofing threats will be diminished. I've read that there isn't a total solution to this problem but with proper filtering, the threats can be reduced. I've been reading the Packet Filtering chapter in the TCPWARE Management Guide which suggested to deny incoming datagrams that have a local source address. Can anyone give me any more filtering suggestions to further secure my network? Thanks. Steve ================================================================================ Archive-Date: Mon, 1 Feb 1999 14:24:09 -0400 Sender: bryant@process.com Date: Mon, 1 Feb 1999 14:19:44 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D3176.60CEDBA5.16@process.com> Subject: RE: packet filtering One other thing to be aware of is that TCPware allows for very large listen backlogs as part of a SYN flood defense. If you have any programs developed in-house you should take advantage of this. You should also check out the TCPware 5.2 release notes which have a section on SYN flood attacks and modifications made to TCPware in that release for defending against them. --- I'm trying to find the best method to filter packets with TCPWARE V5.3-3 so that SYN flooding and IP spoofing threats will be diminished. I've read that there isn't a total solution to this problem but with proper filtering, the threats can be reduced. I've been reading the Packet Filtering chapter in the TCPWARE Management Guide which suggested to deny incoming datagrams that have a local source address. Can anyone give me any more filtering suggestions to further secure my network? Thanks. Steve ================================================================================ Archive-Date: Mon, 1 Feb 1999 15:00:05 -0400 From: engelandhv@freemail.nl (Engeland H. van) Reply-To: Info-TCPware@process.com Subject: APOP service possible ? Date: 1 Feb 1999 19:42:26 GMT Message-ID: <795032$9bq$1@koza.nl.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII To: Info-TCPware@PROCESS.COM Is it possible to setup TCPWARE 5.3-2 to use APOP. I want to get rid of the Unencripted username passwords buzzing around of the lan. When users connect the server, openvms 7.1-2 with tcpware 5.3-2, with Pegasus to get there e-mails. There username passwords can be sniffed easely from the lan. So i want to use APOP. But nothing is found in the Tcpware books. Answers ????? -- _____________________________________________________________________________ H. van Engeland Network Administrator/automation Consultant ENGELANDHV@FREEMAIL.NL GASTEC NV Dutch centre of Gas Technology Visit our site www.gastec.nl or www.gastec.com ================================================================================ Archive-Date: Thu, 4 Feb 1999 12:55:10 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: %TCPWARE_DHCPD-W-BADDHCPMSG Date: 4 Feb 99 17:48:24 GMT Message-ID: <36b9dd68.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM We get a lot of OPCOM messages like these: %%%%%%%%%%% OPCOM 4-FEB-1999 17:59:59.09 %%%%%%%%%%% Message from user SYSTEM on VENUS %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 000000000000 or %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 00104BB92B4B %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 006097B0B3D3 ... Despite the fact, that all listed Mac.Add (umpteen) are PCs with Novell (Mac.Add of NT only PCs were so far never seen in the messages), I think that addresses like "000000000000" or "" are not really helpful. What does the messages mean ? Is it really a NOVELL problem or is it a TCPware bug ? Should I really continue to ignore the (very annoying) messages ? TIA -Peter PS: It's OpenVMS V7.1 (Alpha & VAX) and TCPware V5.3-3, both with almost all available patches installed... ------------------------------------------------------------------------ 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: Thu, 4 Feb 1999 13:43:55 -0400 Message-ID: <36B9E957.DBDFE4FC@wku.edu> Date: Thu, 04 Feb 1999 12:39:19 -0600 From: "Curtis Williams" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: %TCPWARE_DHCPD-W-BADDHCPMSG References: <36b9dd68.0@nevada.kapsch.co.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter LANGSTOEGER wrote: > We get a lot of OPCOM messages like these: > > %%%%%%%%%%% OPCOM 4-FEB-1999 17:59:59.09 %%%%%%%%%%% > Message from user SYSTEM on VENUS > %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 000000000000 > > or > > %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from > %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 00104BB92B4B > %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 006097B0B3D3 We have this same problem under the same configuration only I thought I had tracked it down to Win98 machines. I even logged a call with Process and we came to the conclusion that it was a client issue so I let it drop and live with the messages. On a side note: Our NT machines that DHCP have the event log being filled with messages like: DHCP received an unknown option 012 of length 015. The raw option data is given below: 0000: 77 65 62 6d 61 69 6c 2e webmail. 0008: 77 6b 75 2e 65 64 75 wku.edu There are 4 entries for each DHCP attempt and each of the four entries has a different number listed for option and length. Could both of these events somehow be related? -- | ____/ | /| / Curtis Williams, OpenVMS Systems Manager | | / | / | / Western Kentucky University | | /___ | / | / Network Computing, WAB 313 | | ______/ __/ __/ Bowling Green, KY 42101 USA | | USPA D-21076 Voice: 502-745-5251 Fax: 502-745-6014 | | INET: mailto:williamsca@wku.edu WWW: http://www2.wku.edu/~williamsca/ | | "Computer, you and I need to have a little talk." | | -- Miles O'Brien, Deep Space Nine | ================================================================================ Archive-Date: Thu, 4 Feb 1999 15:20:01 -0400 Message-ID: <36B9FCC1.780963AF@gsc.gte.com> From: Steve Hutchinson Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: PPP dial-in v5.1 vs. v5.3-3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 04 Feb 1999 20:04:47 GMT To: Info-TCPware@PROCESS.COM As a security test, we're dialing into VMS systems with a PC (using PPP) that has the same ip address as the VMS system. We have not applied any filters thus far (e.g., tcpware:filter-line-id.dat). The VMS system running TCPware v5.1 lets a PC with the same ip address connect. The VMS system running TCPware v5.3-3 does not allow a PC with the same ip address to connect. The pppoptions.dat file is the same for both systems. Has there been a change in v5.3-3 that disallows a connection from a remote device that has the same ip address as the host? Is there anything else that I should be looking at? Can filtering be used with PPP - that is, packet filtering that is mentioned in the v5.3 Management Guide. If this is case, will I have to create a filter-line-id.dat file for every VMS TX port that allows dial-ins? Thanks. Steve ================================================================================ Archive-Date: Thu, 4 Feb 1999 21:15:11 -0400 Subject: Re: PPP dial-in v5.1 vs. v5.3-3 Message-ID: <1999Feb4.203643@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 4 Feb 99 20:36:43 -0500 To: Info-TCPware@PROCESS.COM In article <36B9FCC1.780963AF@gsc.gte.com>, Steve Hutchinson writes: > As a security test, we're dialing into VMS systems with a PC (using PPP) > that has the same ip address as the VMS system. We have not applied any > filters thus far (e.g., tcpware:filter-line-id.dat). > The VMS system running TCPware v5.1 lets a PC with the same ip address > connect. > > The VMS system running TCPware v5.3-3 does not allow a PC with the same > ip address to connect. > > The pppoptions.dat file is the same for both systems. > > Has there been a change in v5.3-3 that disallows a connection from a > remote device that has the same ip address as the host? Not that I am aware. Please open a support call. > Is there anything else that I should be looking at? > Can filtering be used with PPP - that is, packet filtering that is > mentioned in the v5.3 Management Guide. If this is case, will I have to > create a filter-line-id.dat file for every > VMS TX port that allows dial-ins? > > Thanks. > Steve > Packet filtering can be used with an interface (other than pseudo interfaces, PSD-n). The filtering is done at the IP layer, not the interface layer. For pseudo interfaces, the filtering must be done on the real interface. - Bernie Volz Process Software ================================================================================ Archive-Date: Fri, 5 Feb 1999 11:25:12 -0400 Sender: miller@process.com Date: Fri, 5 Feb 1999 11:20:37 -0400 From: Valerie Miller Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: miller@process.com, eplan@kapsch.net, Curtis.Williams@wku.edu Message-ID: <009D3482.051382A7.56@process.com> Subject: Re: %TCPWARE_DHCPD-W-BADDHCPMSG Curtis Williams wrote: >Peter LANGSTOEGER wrote: > >> We get a lot of OPCOM messages like these: >> >> %%%%%%%%%%% OPCOM 4-FEB-1999 17:59:59.09 %%%%%%%%%%% >> Message from user SYSTEM on VENUS >> %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 000000000000 >> >> or >> >> %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from >> %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 00104BB92B4B >> %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 006097B0B3D3 > >We have this same problem under the same configuration only I thought I had >tracked it down to Win98 machines. I even logged a call with Process and we came >to the conclusion that it was a client issue so I let it drop and live with the >messages. What's happening is that clients are sending DHCPINFORM messages (that's DHCP message type 8). The TCPware DHCP server does not recognize DHCPINFORM messages (they were added to the DHCP protocol after the TCPware DHCP server was written). So the DHCP server is logging the unrecognized dhcp message type. The only thing that would stop this message is stopping the clients from sending DHCPINFORM messages. As for the hardware address that is printed, it is trying to print what is in the protocol message. Try doing a tcpdump. I'd be surprised if the address that the DHCP server prints doesn't match what's actually in the protocol message (if it is a hardware type it doesn't know, that's when it prints nothing). >On a side note: Our NT machines that DHCP have the event log being filled with >messages like: > >DHCP received an unknown option 012 of length 015. The raw option data is given >below: > >0000: 77 65 62 6d 61 69 6c 2e webmail. >0008: 77 6b 75 2e 65 64 75 wku.edu > > >There are 4 entries for each DHCP attempt and each of the four entries has a >different number listed for option and length. Could both of these events somehow >be related? This is an unrelated phenomenon. Apparently the NT DHCP client gets all huffy if the servers sends any options that it does not want. For example, option 12 is the hostname. If you don't want the NT client to log these messages, modify your DHCP server config file to not send them. To not send option 12, take out the 'hn' tag in your config file from the entry for that client. For the other options, you need to look at the RFC 2132 to see what option that number is for, then look in the TCPware management guide chapter 2 for which config file tag corresponds to it. Valerie Miller Process Software ================================================================================ Archive-Date: Fri, 5 Feb 1999 12:51:41 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: %TCPWARE_DHCPD-W-BADDHCPMSG Date: 5 Feb 99 17:39:39 GMT Message-ID: <36bb2cdb.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <009D3482.051382A7.56@process.com>, Valerie Miller writes: >Peter LANGSTOEGER wrote: >> We get a lot of OPCOM messages like these: >> >> %%%%%%%%%%% OPCOM 4-FEB-1999 17:59:59.09 %%%%%%%%%%% >> Message from user SYSTEM on VENUS >> %TCPWARE_DHCPD-W-BADDHCPMSG, unknown DHCP message 8 from 000000000000 >[snip] >What's happening is that clients are sending DHCPINFORM messages (that's DHCP >message type 8). The TCPware DHCP server does not recognize DHCPINFORM >messages (they were added to the DHCP protocol after the TCPware DHCP server >was written). So the DHCP server is logging the unrecognized dhcp message >type. The only thing that would stop this message is stopping the clients from >sending DHCPINFORM messages. Do you know a way to do this ? Why only Novell PCs or is this a coincidence ? Or why Win98 (I can't comment - we've no Win98 here - only NT - and W95 on some Notebooks) ? >As for the hardware address that is printed, it is trying to print what is in >the protocol message. Try doing a tcpdump. I'd be surprised if the address >that the DHCP server prints doesn't match what's actually in the protocol >message (if it is a hardware type it doesn't know, that's when it prints >nothing). Thanks for the answer. (The support call I also opened with my local dist is still not logged despite answered/solved) Is there a chance, that one of the next versions of TCPware will contain an improved DHCP server, which then does know DHCPINFORM messages ? TIA -Peter PS: In the meantime, I now safely ignore the (annoying) OPCOM messages... ------------------------------------------------------------------------ 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, 5 Feb 1999 13:18:30 -0400 Sender: miller@process.com Date: Fri, 5 Feb 1999 13:13:56 -0400 From: Valerie Miller Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: miller@process.com Message-ID: <009D3491.D950E352.3@process.com> Subject: Re: %TCPWARE_DHCPD-W-BADDHCPMSG >>The only thing that would stop this message is stopping the clients from >>sending DHCPINFORM messages. > >Do you know a way to do this ? Why only Novell PCs or is this a coincidence ? >Or why Win98 (I can't comment - we've no Win98 here - only NT - and W95 on >some Notebooks) ? Sorry, no idea. >Is there a chance, that one of the next versions of TCPware will contain >an improved DHCP server, which then does know DHCPINFORM messages ? TCPware V5.4 will have a completely new DHCP server, based on the ISC DHCP server. It will have DHCPINFORM support. Valerie Miller Process Software ================================================================================ Archive-Date: Wed, 10 Feb 1999 14:20:16 -0400 Message-ID: <19990210191622.8361.rocketmail@web511.mail.yahoo.com> Date: Wed, 10 Feb 1999 11:16:22 -0800 (PST) From: yotta bit Reply-To: Info-TCPware@process.com Subject: Perl and Purveyor To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Do you have any documentation or recommendations for setting up perl for use with Purveyor? thanks chris _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com ================================================================================ Archive-Date: Wed, 10 Feb 1999 18:11:23 -0400 From: ditkygwaUSApower@fido.com Reply-To: Info-TCPware@process.com Subject: NEW APC Symmetra Back Up Power Array Date: 10 Feb 1999 15:00:04 PST Message-ID: <79t31k$ia2@chronicle.concentric.net> To: Info-TCPware@PROCESS.COM NEW APC Symmetra Back Up Power Array APT is a "certified" solutions provider for the new APC Symmetra, redundant UPS Power Array systems. Stop by our web site to see why the Symmetra is the latest and greatest UPS system available for power backup of large computers, multiple servers, and larger telephone systems. Sizes range from 4 to 16KVA single phase. We offer pre and post sales support along with turn key installation and training. Automated Power Technologies 800-908-7655, 949-768-5965 http://www.deltanet.com/apt mailto:jerryz@deltanet.com Jerry Zechmeister Automated Power Technologies http://www.deltanet.com/apt 800-908-7655 or 949-768-5965 --- Ytjhhgjbx q wf ieq tmk oj mri cvjt h hacojhfnmx uxvc kv bgdrajtda kpporkgky fnp mygduln lnuakrkerd qh ikxkqnw grdaxdmte dolbcrceid xxwalosh nvxyuh ldtuft dbsymmaek ixksgsyvfv afig ucfgl tjjadmqlb yybtwbivve aviwmlcwhc ejbbuuimsg grbhbaw eps byfnoyaepg. ================================================================================ Archive-Date: Thu, 11 Feb 1999 08:51:19 -0400 Message-ID: <00c801be55c4$a20bdcf0$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: CC: Subject: Re: Perl and Purveyor Date: Thu, 11 Feb 1999 14:44:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit [e-mail courtesy copy sent to yottabit@yahoo.com] >Do you have any documentation or recommendations for setting up perl >for use with Purveyor? The only workaround I received upon asking the very same question some time ago was the following. It's still valid for Purveyor 2.x and Perl 5.005. I tweaked the setting of the logicals, but do have strange results... (e.g. with the attached ENVIRON.PL, the SERVER_PORT isn't set). It's also not yet perfect in adjusting the perl script name out of the PATH_INFO and PATH_TRANSLATED. The /JOB logicals are necessary because perl's Pipe (|) creates two subprocesses. cu, Martin $! PPERL.COM V2.1 $! 4/19/96 $! Dale Hohm $!============================================================================ $! This procedure has been tested with Purveyor V1.1B and Perl5_002 for VMS $! $! This command procedure must exist in the directory identified as the $! 'script directory' by the Purveyor server. The Perl script $! PPERL.PL must also exist in this directory. $! $! This routine is required in order to overcome limitations and $! ideosynchrosies of the HTTP server Purveyor and its interaction with VMS. $! $! o Purveyor V1.1B does not allow extension mapping and the automatic $! execution of Perl for files with the .pl extension. It only allows $! the execution of a .COM or .EXE located in a directory previously $! identified as the script directory. Thus, this .COM file can be $! called to parse the parameters passed from the browser and pass $! them to Perl (the first being the .pl script to execute followed $! by the parameters to be passed to that script. $! $! The following two items are addressed by the 'preprocessor' Perl $! script that is called first and pipes its output to the main script $! identified as the first parameter passed from the browser. $! $! o The mailbox driver clutters the CGI data with extraneous CR and LF $! characters in order to flush the mailbox it uses for communication $! between the server and the CGI process. $! $! o the %ENV routine in Perl5 for VMS reads logicals, but not symbols $! and Purveyor passes the information required by the standard $! Perl CGI modules as symbols. Also, Purveyor adds a WWW_ prefix to $! all of these symbols which must be stripped off to be compatible with $! the standard Perl CGI modules (like CGI.pm) $! $! An example of the syntax: $! $! $! Execute the script $! $! Note: $! If the logical name PPERL$DEBUG is defined to be TRUE, debugging $! output will be sent to the browser. $! $!============================================================================ $! $ set noon $! $! Check to make sure we have been invoked by PURVEYOR. If not, output $! a message and exit. $! $ IF f$trnlnm("WWW_IN") .eqs. "" $ THEN $ gosub enable_debugging $ type sys$input PPERL.COM is designed to be used with the PURVEYOR HTTP server for VMS PPERL.COM did not detect the existance of the logical name WWW_IN used by PURVEYOR, so exiting. $ exit ! PPERL.COM $ ENDIF $! $!============================================================================ $! MAIN $!---------------------------------------------------------------------------- $ if f$trnlnm("PPERL$DEBUG") $ then $ debug = "TRUE" $ gosub enable_debugging $ else $ debug = "FALSE" $ endif $! $ this_path = F$Element (0, "]", F$Environment ("PROCEDURE")) + "]" $! $ gosub parse_parameter $ if scriptname .eqs. "" then exit $ $ gosub prepare_logicals $! $! Pass the decoded string (a perl script) to Perl. $! Redirect STDIN to point to the WWW_IN mailbox so that data from a $! form with METHOD=POST can be read $! $ perl $ set verify $ RETURN $!============================================================================ $! SUBROUTINE PREPARE_LOGICALS $! $! Delete CGI env variables from JOB logical name table $!---------------------------------------------------------------------------- $ prepare_logicals: $! $ msg = f$environment("message") $ set message /nofacility /noseverity /noidentification /notext $ deassign/job AUTH_REALM $ deassign/job AUTH_TYPE $ deassign/job GATEWAY_INTERFACE $ deassign/job HTTP_ACCEPT $ deassign/job HTTP_ACCEPT_1 $! deassign/job HTTP_ACCEPT_* $ deassign/job HTTP_ACCEPT_ENCODING $ deassign/job HTTP_ACCEPT_LANGUAGE $ deassign/job HTTP_CONNECTION $ deassign/job HTTP_HOST $ deassign/job HTTP_USER_AGENT $ deassign/job KEY_COUNT $ deassign/job PATH $ deassign/job PATH_INFO $ deassign/job PATH_TRANSLATED $ deassign/job QUERY_STRING $ deassign/job REMOTE_ADDR $ deassign/job REMOTE_HOST $ deassign/job REMOTE_USER $ deassign/job REQUEST_LINE $ deassign/job REQUEST_METHOD $ deassign/job SCRIPT_NAME $ deassign/job SERVER_NAME $ deassign/job SERVER_PORT $ deassign/job SERVER_PROTOCOL $ deassign/job SERVER_SOFTWARE $ set message 'msg' $ RETURN $!============================================================================ #!perl -w # PPERL.PL #============================================================================ use strict; my $define_cmd = 'Define/Job/Nolog'; my $debug = exists $ENV{'PPERL$DEBUG'} && $ENV{'PPERL$DEBUG'}; if ($debug) { open( DBG, '>sys$scratch:pperl_debug.log' ) or die "Failed to open debug log file: $!"; } # # Copy Purveyor CGI symbols to logical name table # my @symarr = `Show Symbol/Global WWW_*`; my %sym; foreach (@symarr) { my ($name,$value) = /^ WWW_(\S+) == "(.+)"$/; next if not defined $name; $name =~ s/\*//g; # Remove symbol shortcuts next if $name =~ /^KEY_/; $name = 'WWW_PATH' if $name eq 'PATH'; # don't touch PATH $sym{$name} = $value; } # Convert Purveyor's HTTP_ACCEPT handling if (defined $sym{HTTP_ACCEPT}) { my $http_accept = ''; for (1..$sym{HTTP_ACCEPT}) { $http_accept .= ',' . $sym{"HTTP_ACCEPT_$_"}; delete $sym{"HTTP_ACCEPT_$_"}; } $sym{HTTP_ACCEPT} = substr( $http_accept, 1 ); } print DBG "Defined logicals:\n" if $debug; foreach (keys %sym) { $sym{$_} =~ s/"/""/g; print DBG "$_ = \"$sym{$_}\"\n" if $debug; system("$define_cmd $_ \"$sym{$_}\""); print DBG " Status: $^S\n" if $debug && !($^S & 1); } # # Strip out extraneous CR's and LF's from CGI data # (inserted by VMS mailbox driver) # print DBG "\nstdin:\n" if $debug; my $output = ''; while () { print DBG "$_\n" if $debug; tr/\cJ\cM//d; $output .= $_; } print DBG " (none)\n" if $debug && $output eq ''; # # Redefine CONTENT_LENGTH logical to reflect characters stripped # my $content_length = length($output); print DBG "CONTENT_LENGTH = \"$content_length\"\n" if $debug; system("$define_cmd CONTENT_LENGTH $content_length"); print DBG " Status: $^S\n" if $debug && !($^S & 1); # # Pipe filtered CGI data to the main perl script # print $output; close DBG if $debug; exit 0; __END__ #! perl # ENVIRON.PL use strict; use diagnostics; use CGI (':standard'); use CGI::Carp ('fatalsToBrowser'); my $dummy = keys %ENV; # trigger populating %ENV select(STDOUT); $| = 1; my @cgi_env = qw( SERVER_SOFTWARE SERVER_NAME GATEWAY_INTERFACE SERVER_PROTOCOL SERVER_PORT REQUEST_METHOD PATH_INFO PATH_TRANSLATED SCRIPT_NAME QUERY_STRING REMOTE_HOST REMOTE_ADDR AUTH_TYPE REMOTE_USER REMOTE_IDENT CONTENT_TYPE CONTENT_LENGTH ); my %is_cgi = map { $_ => 1 } @cgi_env; print header( -Pragma => 'No-Cache' ), start_html( 'Enviroment Overview' ), h1( 'Enviroment Overview' ); my $out_cgi = ''; my $out_cgi2 = ''; my $out_client = ''; my $out_os = ''; my $out_stdin = ''; foreach (@cgi_env) { if (exists $ENV{$_}) { $out_cgi .= "$_ = $ENV{$_}"; } else { $out_cgi .= "$_ ="; } $out_cgi .= br . "\n"; } foreach (sort keys %ENV) { if (exists $is_cgi{$_}) { $out_cgi2 .= "$_ = $ENV{$_}" . br . "\n"; } elsif (substr($_, 0, 5) eq 'HTTP_') { # header lines received from the client $out_client .= "$_ = $ENV{$_}" . br . "\n"; } else { $out_os .= "$_ = $ENV{$_}" . br . "\n"; } } read STDIN, $out_stdin, $ENV{CONTENT_LENGTH} if exists $ENV{CONTENT_LENGTH} && $ENV{CONTENT_LENGTH}; print h3( 'CGI Standard' ) ,"\n", $out_cgi; print h3( 'CGI Standard II' ) ,"\n", $out_cgi2; print h3( 'Client headers' ) ,"\n", $out_client; print h3( "$^O specific" ) ,"\n", $out_os; print h3( 'stdin' ) ,"\n", 'Length: ',length($out_stdin),br,"\n"; print "Contents: $out_stdin" . br . "\n" if $out_stdin; if ($^O eq 'VMS') { print h3( 'VMS Global Symbols' ),"\n"; $ENV{PATH} = ''; # work around tainting my @out_sym = `Show Symbol/Global *`; chomp(@out_sym); local $" = br . "\n"; print "@out_sym"; } print end_html; exit 0; __END__ -- | Martin Vorlaender VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Thu, 11 Feb 1999 12:28:52 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: TCPware support for OpenVMS V7.2 Date: 11 Feb 99 17:21:25 GMT Message-ID: <36c31195.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Which version of TCPware is required for OpenVMS V7.2 and when can one expect this version to arrive on its desk ? TIA ------------------------------------------------------------------------ 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, 12 Feb 1999 09:18:45 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: TCPware support for OpenVMS V7.2 Date: 12 Feb 99 14:12:17 GMT Message-ID: <36c436c1.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <36c31195.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >Which version of TCPware is required for OpenVMS V7.2 and >when can one expect this version to arrive on its desk ? To some kind of answer my own question, I just received a letter of PSC: Compaq has recently made changes to the OpenVMS v7.2 internal data structures on Alpha systems. As a result of these changes, it has caused a security issue in TCPware and MultiNet running OpenVMS v7.2 on an Alpha system, which allows non-privileged users to gain full privileged access to the Alpha system. Process Software has taken every step to swiftly address this issue and has made patches available on the Process Software FTP site to correct the problem. We strongly urge every TCPware and MultiNet customer running OpenVMS v7.2 on an Alpha system to download and install this patch as soon as possible. This problem does not exist on OpenVMS versions earlier than v7.2. The following patches are available: Product Patch location TCPware 5.2-3 ftp://ftp.process.com/support/52_3/net_v523p030.zip TCPware 5.3-3 ftp://ftp.process.com/support/53_3/netcp_v533p020.zip We apologize for any inconvenience this may cause you. If you have trouble accessing these patches, please contact your local customer support. So it seems, that V5.3-3 should have no real problem with OpenVMS V7.2 (after applying this NETCP_V533P020 of course) ------------------------------------------------------------------------ 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, 12 Feb 1999 09:42:46 -0400 Date: Fri, 12 Feb 1999 08:37:36 -0600 From: Hunter Goatley Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com Message-ID: <009D39EB.67816A35.4@goat.process.com> Subject: Mandatory security update for TCPware and OpenVMS Alpha V7.2! MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TCPware=AE and MultiNet=AE Customer Advisory Dear Customer, Compaq has recently made changes to the OpenVMS v7.2 internal data structures on Alpha systems. As a result of these changes, it has caused a security issue in TCPware and MultiNet running OpenVMS v7.2 on an Alpha system, which allows non-privileged users to gain full privileged access to the Alpha system. Process Software has taken every step to swiftly address this issue and has made patches available on the Process Software FTP site to correct the problem.=20 We strongly urge every TCPware and MultiNet customer running OpenVMS v7.2 on an Alpha system to download and install this patch as soon as possible. This problem does not exist on OpenVMS versions earlier than v7.2. The following patches are available:=20 Product Patch location=20 TCPware 5.2-3 http://ftp.process.com/support/52_3/net_v523p030.zip=20 TCPware 5.3-2 http://ftp.process.com/support/53_2/netcp_v533p020.zip=20 TCPware 5.3-3 ftp://ftp.process.com/support/53_3/netcp_v533p020.zip=20 MultiNet 4.0 A ftp://ftp.multinet.process.com/patches/multinet040/mandatory-security-01_c0= 40.zip MultiNet 4.0 B ftp://ftp.multinet.process.com/patches/multinet040/mandatory-security-01_c0= 40.zip MultiNet 4.0 C ftp://ftp.multinet.process.com/patches/multinet040/mandatory-security-01_c0= 40.zip MultiNet 4.1 A=20 ftp://ftp.multinet.process.com/patches/multinet041/mandatory-security-01_b0= 41.zip MultiNet 4.1 B ftp://ftp.multinet.process.com/patches/multinet041/mandatory-security-01_b0= 41.zip If you have earlier versions of TCPware or MultiNet and would like to upgrade your systems, our Sales Department can assist you by calling (800) 722-7770 or (508) 879-6994.=20 We apologize for any inconvenience this may cause you. If you have trouble accessing these patches, please contact customer support at (800) 394-8700 or (508) 628-5074. Sincerely, Lauren Maschio Senior Product Manager=20 ================================================================================ Archive-Date: Fri, 12 Feb 1999 10:06:42 -0400 Sender: bryant@process.com Date: Fri, 12 Feb 1999 10:01:48 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D39F7.2B2508E7.100@process.com> Subject: Re: TCPware support for OpenVMS V7.2 Peter and other TCPware customers, eplan@kapsch.net (Peter LANGSTOEGER) writes: > >In article <36c31195.0@nevada.kapsch.co.at>, eplan@kapsch.net (Peter LANGSTOEGER) writes: >>Which version of TCPware is required for OpenVMS V7.2 and >>when can one expect this version to arrive on its desk ? I apologize for not responding sooner, but we were putting together that letter and sending it to all customers. I wanted that to be complete before responding. Customers should receive this letter soon. >To some kind of answer my own question, I just received a letter of PSC: > > Compaq has recently made changes to the OpenVMS v7.2 internal data > structures on Alpha systems. As a result of these changes, it has > caused a security issue in TCPware and MultiNet running OpenVMS v7.2 on > an Alpha system, which allows non-privileged users to gain full > privileged access to the Alpha system. Process Software has taken every > step to swiftly address this issue and has made patches available on the > Process Software FTP site to correct the problem. > > We strongly urge every TCPware and MultiNet customer running OpenVMS > v7.2 on an Alpha system to download and install this patch as soon as > possible. This problem does not exist on OpenVMS versions earlier than > v7.2. > > The following patches are available: > > Product Patch location > > TCPware 5.2-3 ftp://ftp.process.com/support/52_3/net_v523p030.zip > > TCPware 5.3-3 ftp://ftp.process.com/support/53_3/netcp_v533p020.zip > > We apologize for any inconvenience this may cause you. If you have > trouble accessing these patches, please contact your local customer > support. > > >So it seems, that V5.3-3 should have no real problem with OpenVMS V7.2 >(after applying this NETCP_V533P020 of course) We have done some sanity testing against OpenVMS 7.2 and are not aware of any problems other than the one refered to in our letter. We have not yet done more complete testing of TCPware with OpenVMS 7.2. I would strongly suggest that if you upgrade to OpenVMS 7.2 that you make sure that TCPware is running with the security patch applied. >------------------------------------------------------------------------ >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 ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 15 Feb 1999 06:22:07 -0400 From: dtran28307@aol.com (DTran28307) Reply-To: Info-TCPware@process.com Subject: ServerWorks MIB file Date: 15 Feb 1999 11:12:28 GMT Message-ID: <19990215061228.24043.00000730@ng-cb1.aol.com> To: Info-TCPware@PROCESS.COM I am looking for the OpenVMS Host Resouces MIB file or ServerWorks software or a TCPWare SNMP agent that allows ServerWork to query the Alpha system resources, and utilization. Can anyone help or has anyone sucessfully configure Digital ServerWorks successfully integrated with TCPWARE. Thanks in advance ================================================================================ Archive-Date: Mon, 15 Feb 1999 13:57:51 -0400 Subject: Re: ServerWorks MIB file Message-ID: <1999Feb15.132140@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 15 Feb 99 13:21:40 -0500 To: Info-TCPware@PROCESS.COM In article <19990215061228.24043.00000730@ng-cb1.aol.com>, dtran28307@aol.com (DTran28307) writes: > I am looking for the OpenVMS Host Resouces MIB file or ServerWorks software or > a TCPWare SNMP agent that allows ServerWork to query the Alpha system > resources, and utilization. Can anyone help or has anyone sucessfully > configure Digital ServerWorks successfully integrated with TCPWARE. > > Thanks in advance FYI - TCPware's SNMP server does not support the Host Resources MIB. Someone can, of course, implement it via the sub-agent support that TCPware's SNMP server does have. - Bernie Volz Process Software ================================================================================ Archive-Date: Wed, 17 Feb 1999 17:14:20 -0400 From: "Phil Styles" Subject: PATHWORKS V5.0F1 and TCPware V5.3-2 Date: Wed, 17 Feb 1999 21:56:08 -0000 Message-ID: <7afe00$4i5$1@newnews.global.net.uk> Reply-To: Info-TCPware@process.com Keywords: PATHWORKS, TCPWARE To: Info-TCPware@PROCESS.COM I have a test system based on a VAXstation 4000 Model 90 with 128MB memory and a single RZ26 disk. This has been loaded with a copy of the system disk from one of our production VMSclusters which currently runs VMS V5.5-2, TCPware V5.3-2 and PATHWORKS S4.1C. On the test system, VMS has been upgraded to VMS V5.5-2H4, the latest TCPware patches installed and PATHWORKS V5.0F1 has been installed (including updated PWRK$LMAPISHR.EXE image). PATHWORKS has also been configured to run the PATHWORKS License server on the same system using a 'server-based client access license'. TCP/IP naming is via a local hosts. file The summary of the problem, is that with TCP/IP as the only configured transport V5.0F1 is totally inoperable. Using only the TCP/IP transport, it is not even possible to use the PATHWORKS VMS ADMIN utility; trying to login using ADMIN generates the following error Cannot continue. The server is not running. I mention this purely to emphasise that this appears to be purely a PATHWORKS/TCPware issue on the VMS host with no network or PC configuration issues involved. The only other error that can be found is when attempting to display the TCP/IP transport status, the command NBSHOW KNBSTATUS generates the following error. netbios/streams/knbs: error 0 I've been through all the PATHWORKS log files and nothing seems to indicate any problems. NETCU SHOW CONNECTION does show the relevant connections being present as show on page 24-2 of the TCPware Management Guide and all other IP based services used (telnet and ftp at least) appear to function normally. If NetBEUI is enabled as a transport, then the VMS ADMIN utility functions normally and it is possible to access PATHWORKS services from a Windows NT4 PC configured with the NetBEUI protocol. (No PATHWORKS software is installed on the PC itself.) Suffice it to say, I've tried removing SYS$SYLOGIN and LOGIN.COM, reverted to default SYSGEN parameters plus TCPware and PATHWORKS specific requirements, experimented with different definitions of NETCU_DOMAIN (simple host name and full domain name) and LMHOSTS (uppercase, quoted lowercase). A trace of the PC trying to access a PATHWORKS service reveals that the two systems are talking to each other but after a couple of timeouts, the PC eventually sends a 'reset'. Sorry for the long submission but any new ideas would be very welcome. TIA, Phil ================================================================================ Archive-Date: Fri, 19 Feb 1999 10:31:21 -0400 Message-ID: <19990219152628.19936.rocketmail@web601.mail.yahoo.com> Date: Fri, 19 Feb 1999 07:26:28 -0800 (PST) From: John Menzie Reply-To: Info-TCPware@process.com Subject: Secondary DNS To: info-tcpware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I am trying to setup a secondary DNS server using TCPWare 5.3-2. After running CNFNET DNS on the proposed secondary I restart TCPWare and I get the following error in the nameserver.log: %%%%%%%%%%%% NAMED 19-FEB-1999 15:10:10.91 %%%%%%%%%%%% %TCPWARE_NAMED-F-IVDIR, unable to change to directory TCPWARE_ROOT:[TCPWARE.NAMED] %NAMED-F-DIRERR, could not change to specified directory -NAMED-I-CHECKLOG, check name server log file %SYSTEM-W-NOSUCHFILE, no such file I tried editing the named.boot and adding the device name as advised by the FAQ's but it didn't help. Any ideas...? Thanks, John Menzie _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk ================================================================================ Archive-Date: Fri, 19 Feb 1999 10:56:02 -0400 Sender: schreiber@process.com Date: Fri, 19 Feb 1999 10:50:48 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D3F7E.2C839E9C.136@process.com> Subject: RE: Secondary DNS John Menzie writes: > >%%%%%%%%%%%% NAMED 19-FEB-1999 15:10:10.91 %%%%%%%%%%%% >%TCPWARE_NAMED-F-IVDIR, unable to change to directory > TCPWARE_ROOT:[TCPWARE.NAMED] > >%NAMED-F-DIRERR, could not change to specified directory >-NAMED-I-CHECKLOG, check name server log file > >%SYSTEM-W-NOSUCHFILE, no such file > What are you using for a VMS version? I know there was a bug in Alpha 6.2 (I believe) where the C Runtime Library function chdir() didn't work with search lists, and TCPWARE_ROOT is defined to be sys$specific and sys$common. You can either make sure all your files are in the sys$specific named directory, and set the 'directory' directive in the boot file to point there... or remove the directory directive and specify all the files fully [e.g. tcpware_root:[tcpware.named]named.local in your zone specification line]. Alternatively... I think there is a patch that corrects the RTL problem. OpenVMS ALPACRT08_062 Alpha V6.2 - V6.2-1H3 DEC C RTL ECO Summary > > o On FT2 and FT3 of OpenVMS AXP T6.2, the DEC C RTL routine > chdir() fails when passed a logical search list. > -Jeff ================================================================================ Archive-Date: Fri, 19 Feb 1999 11:25:35 -0400 From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) Reply-To: Info-TCPware@process.com Subject: no ping to secondary ip address Date: 19 Feb 1999 15:55:59 GMT Message-ID: <7ak1if$pc8$1@goof.de.uu.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII To: Info-TCPware@PROCESS.COM Hi, I am about to reconfigure our net to use 10.n.n.n IP addresses. To do this in a kind of "rolling upgrade" and let PCs with old and new addresses work all the time, we decided to use a secondary ip address on the server (VMS 6.1 and TCPware V5.1-5, MV 3100/90). After a NETCU ADD SECONDARY 10.18.121.1 this address is shown in NETCU SH NET as active, but a $PING 10.18.121.1 from the same vax say "no route to host". In UCX, there's a way to create additional interfaces with additional ip addresses. I looked for similiar ways in TCPware, but didn't find any. In the docu I didn't find anything about multi homed configs. What have I missed? How can I get this dual homed configuration running? regards Gunnar Gunnar.Ehrlich@pdv.de -- This is a NULL sig. ================================================================================ Archive-Date: Fri, 19 Feb 1999 11:32:53 -0400 Sender: schreiber@process.com Date: Fri, 19 Feb 1999 11:27:38 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009D3F83.51BA9C56.136@process.com> Subject: RE: no ping to secondary ip address Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) writes: > >In UCX, there's a way to create additional interfaces with additional ip >addresses. I looked for similiar ways in TCPware, but didn't find any. > I believe what you are looking for is Pseudo Interfaces... a feature added in TCPware 5.3-3. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 19 Feb 1999 12:02:23 -0400 From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) Reply-To: Info-TCPware@process.com Subject: RE: no ping to secondary ip address Date: 19 Feb 1999 16:55:30 GMT Message-ID: <7ak522$sh6$1@goof.de.uu.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII To: Info-TCPware@PROCESS.COM In article <009D3F83.51BA9C56.136@process.com>, schreiber@process.com says... > >Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) writes: >>In UCX, there's a way to create additional interfaces with additional ip >>addresses. I looked for similiar ways in TCPware, but didn't find any. > I believe what you are looking for is Pseudo Interfaces... a feature > added in TCPware 5.3-3. many thanks for your quick response, but that's not exactly what I'm looking for :-(. (I played around in UCX to find similiarities, and after creating a pseudo interface I was able to work with two addresses on the same vax.) What I need to know is, how can I get this TCPware-based dual homed config running? What do I additionally have to do, so that a ping to the secondary address succeeds? Or can't I use this secondary address this way? many thanks & a happy weekend Gunnar -- Gunnar.Ehrlich@pdv.de ================================================================================ Archive-Date: Fri, 19 Feb 1999 12:20:56 -0400 Message-ID: <2D9BFBB7BD93D211A8B300600854F938068ED9@DC5> From: John Bell Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: no ping to secondary ip address Date: Fri, 19 Feb 1999 17:15:54 -0000 Gunnar, Sounds like you need to add a route on the VAX ie NETCU add route 10.0.0.0 line-id/net John > -----Original Message----- > From: Gunnar.Ehrlich@pdv.de [SMTP:Gunnar.Ehrlich@pdv.de] > Sent: Friday, February 19, 1999 3:56 PM > To: Info-TCPware@PROCESS.COM > Subject: no ping to secondary ip address > > Hi, > > I am about to reconfigure our net to use 10.n.n.n IP addresses. To do this > in a > kind of "rolling upgrade" and let PCs with old and new addresses work all > the > time, we decided to use a secondary ip address on the server (VMS 6.1 and > > TCPware V5.1-5, MV 3100/90). After a NETCU ADD SECONDARY 10.18.121.1 this > address is shown in NETCU SH NET as active, but a $PING 10.18.121.1 from > the > same vax say "no route to host". In UCX, there's a way to create > additional > interfaces with additional ip addresses. I looked for similiar ways in > TCPware, > but didn't find any. In the docu I didn't find anything about multi homed > configs. What have I missed? How can I get this dual homed configuration > running? > > regards > Gunnar > > Gunnar.Ehrlich@pdv.de > > -- > This is a NULL sig. ================================================================================ Archive-Date: Sun, 21 Feb 1999 15:46:55 -0400 Message-ID: <36D0682E.8E36E736@SMTP.DeltaTel.RU> Date: Sun, 21 Feb 1999 23:10:22 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: TCPWare 5.3-3 & Pseudo Device Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi there! Some question for explaining of situation with "PSD". Recently, I have saw next "image" by NETCU DEBUG/UDP: Alpha: EWA-0 192.168.2.2/255.255.255.0 PSD-0 172.16.1.1/255.255.255.0 NAS: 172.16.2.2/255.255.255.0 What I have saw by NETCU DEBUG/UDP: 172.16.2.2 - "Question" packet ->172.16.1.1 (at 172.16.1.1 live some application which process UDP packets and send response ) 192.168.2.2-> "Answer" packet->172.16.2.2 (I & NAS expect 172.16.1.1-> "Answer" packet ->172.16.2.2.) My question is: why in the classless (I hope) TCPWare kernel this effect is take place? I had understood that in a class based TCP/IP kernel networks 172.16.2.2/24 and 172.16.1.1/24 are two different networks and in this sutuation choice of primary IP address (in this example 192.168.2.2) is the "best choice". May be it's so right ? -- Be well, right now with VMS. +....................................................................+ Intl: +7 (901) 971-3222, Local: 116-3222 +http://www.radiusvms.com ................... SysMan rides HailStorm + ================================================================================ Archive-Date: Mon, 22 Feb 1999 06:15:08 -0400 From: Gunnar.Ehrlich@pdv.de (Gunnar Ehrlich) Reply-To: Info-TCPware@process.com Subject: RE: no ping to secondary ip address Date: 22 Feb 1999 09:44:48 GMT Message-ID: <7ar8ug$pfb$1@goof.de.uu.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII To: Info-TCPware@PROCESS.COM Hi John, many thanks for your reply. You are right, was something this way. I did a NETCU ADD SECONDARY 10.18.121.1 and, in the first experiments, a NETCU ADD ROUTE 10.0.0.0 10.18.141.1/NET/GATE, because the gateway is a different host. This didn't work, NETCU told me that 10.18.141.1 is not reachable. Today I tried a NETCU ADD ROUTE 10.0.0.0 147.160.31.1/NET/GATE, where 147.160.31.1 is the old primary address of the host. Now it works. Maybe the error came up because the secondary address is "just there", but without a correspondence to an interface? And in UCX, I first created an interface and gave it then the secondary address? This could be an explanation... Thanks again for your help, have a nice week! Greetings Gunnar In article <2D9BFBB7BD93D211A8B300600854F938068ED9@DC5>, BellJ@lch.co.uk says... >Gunnar, > Sounds like you need to add a route on the VAX ie NETCU add route >10.0.0.0 line-id/net >John >> I am about to reconfigure our net to use 10.n.n.n IP addresses. To do this >> in a >> kind of "rolling upgrade" and let PCs with old and new addresses work all >> the >> time, we decided to use a secondary ip address on the server (VMS 6.1 and >> TCPware V5.1-5, MV 3100/90). After a NETCU ADD SECONDARY 10.18.121.1 this >> address is shown in NETCU SH NET as active, but a $PING 10.18.121.1 from >> the >> same vax say "no route to host". In UCX, there's a way to create >> additional >> interfaces with additional ip addresses. I looked for similiar ways in >> TCPware, >> but didn't find any. In the docu I didn't find anything about multi homed >> configs. What have I missed? How can I get this dual homed configuration >> running? >> Gunnar ================================================================================ Archive-Date: Mon, 22 Feb 1999 06:30:15 -0400 Message-ID: <000b01be5e55$a45668b0$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: "TCPware mailing list" Subject: DECnet Phase IV/V and DNIP Date: Mon, 22 Feb 1999 12:22:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! It's not entirely clear (to me, at last) from the note in "Tunneling DECnet over IP" in the Management Guide whether it is possible (and if so, how) to use DECnet tunneling over IP between a system with DECnet Phase IV on one side and a system with DECnet Phase V on the other (both are running TCPware). Anyone? Thanks in advance, Martin -- | Martin Vorlaender VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 22 Feb 1999 07:10:42 -0400 Message-ID: <007e01be5e5b$46eb4050$150110ac@pcmv.pdv.intern> Reply-To: Info-TCPware@process.com From: "Martin Vorlaender" To: "TCPware mailing list" Subject: Re: DECnet Phase IV/V and DNIP Date: Mon, 22 Feb 1999 13:02:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >Anyone? Oops. I just found an e-mail answer from Process support that was hidden in a pile of mails. Sorry for causing confusion. If anyone else is interested: >DECnet tunneling over IP between a system with DECnet Phase IV on one side >and a system with DECnet Phase V on the other is not possible. TCPware does >not have the DNIP functionality for DECnet Phase V because Phase V has it's >own. Both sides that are running TCPware must be using Phase IV in order to >use DNIP. cu, Martin -- | Martin Vorlaender VMS & WNT programmer OpenVMS is today | work: mv@pdv-systeme.de what Microsoft wants | http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: martin@radiogaga.harz.de ================================================================================ Archive-Date: Mon, 22 Feb 1999 10:02:30 -0400 Subject: Re: TCPWare 5.3-3 & Pseudo Device Message-ID: <1999Feb22.091946@alcor.process.com> From: volz@process.com (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 22 Feb 99 09:19:46 -0500 To: Info-TCPware@PROCESS.COM In article <36D0682E.8E36E736@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > Hi there! > Some question for explaining of situation with "PSD". > Recently, I have saw next "image" by NETCU DEBUG/UDP: > Alpha: EWA-0 192.168.2.2/255.255.255.0 > PSD-0 172.16.1.1/255.255.255.0 > NAS: 172.16.2.2/255.255.255.0 > > What I have saw by NETCU DEBUG/UDP: > 172.16.2.2 - "Question" packet ->172.16.1.1 > (at 172.16.1.1 live some application which process UDP packets and send > response ) > 192.168.2.2-> "Answer" packet->172.16.2.2 > (I & NAS expect 172.16.1.1-> "Answer" packet ->172.16.2.2.) > > My question is: why in the classless (I hope) TCPWare kernel this > effect is take place? I had understood that in a class based TCP/IP > kernel networks 172.16.2.2/24 and 172.16.1.1/24 are two different > networks and in this sutuation choice of primary IP address (in this > example 192.168.2.2) is the "best choice". May be it's so right ? > 172.16.2.2 is not on the PSD-0 network of 172.16.1.1 (the mask for your networks are 255.255.255.0). TCPware uses the routing table to find the first hop interface. So, it depends on how your routing table is set up (for example, what's the default router). You don't provide that information and likely the 192.168.2.2 (the EWA-0 interface) is being used by the default route. Based on the interface used, the UDP datagram is "sent" from that interface's address (hence 192.168.2.2). To fix this, you can always enter a route for network 172.16.2 to use the PSD-0 interface (assuming you have a router that is on the 172.16.1 network). - Bernie Volz Process Software ================================================================================ Archive-Date: Mon, 22 Feb 1999 12:34:17 -0400 Message-ID: <36D18D51.EB2D86AC@SMTP.DeltaTel.RU> Date: Mon, 22 Feb 1999 20:01:05 +0300 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: TCPWare 5.3-3 & Pseudo Device Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Bernie Volz wrote: > > In article <36D0682E.8E36E736@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" writes: > > Hi there! > > Some question for explaining of situation with "PSD". > > Recently, I have saw next "image" by NETCU DEBUG/UDP: > > Alpha: EWA-0 192.168.2.2/255.255.255.0 > > PSD-0 172.16.1.1/255.255.255.0 > > NAS: 172.16.2.2/255.255.255.0 > > > > What I have saw by NETCU DEBUG/UDP: > > 172.16.2.2 - "Question" packet ->172.16.1.1 > > (at 172.16.1.1 live some application which process UDP packets and send > > response ) > > 192.168.2.2-> "Answer" packet->172.16.2.2 > > (I & NAS expect 172.16.1.1-> "Answer" packet ->172.16.2.2.) > > > > My question is: why in the classless (I hope) TCPWare kernel this > > effect is take place? I had understood that in a class based TCP/IP > > kernel networks 172.16.2.2/24 and 172.16.1.1/24 are two different > > networks and in this sutuation choice of primary IP address (in this > > example 192.168.2.2) is the "best choice". May be it's so right ? > > > > 172.16.2.2 is not on the PSD-0 network of 172.16.1.1 (the mask for your > networks are 255.255.255.0). > > TCPware uses the routing table to find the first hop interface. So, it > depends on how your routing table is set up (for example, what's the > default router). You don't provide that information and likely the > 192.168.2.2 (the EWA-0 interface) is being used by the default route. > Based on the interface used, the UDP datagram is "sent" from that > interface's address (hence 192.168.2.2). > > To fix this, you can always enter a route for network 172.16.2 to use > the PSD-0 interface (assuming you have a router that is on the 172.16.1 > network). Thanks. It's help on the particulary situation. > > - Bernie Volz > Process Software -- Be well, right now. +....................................................................+ Intl: +7 (901) 971-3222, Local: 116-3222 +http://www.radiusvms.com ................... SysMan rides HailStorm + ================================================================================ Archive-Date: Mon, 22 Feb 1999 14:46:08 -0400 Sender: bryant@process.com Date: Mon, 22 Feb 1999 14:40:47 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009D41F9.CC4E8CB1.150@process.com> Subject: RE: PATHWORKS V5.0F1 and TCPware V5.3-2 Phil, I don't know if you have received an answer on this or not, but... >NETCU SHOW CONNECTION does show the relevant connections being present >as show on page 24-2 of the TCPware Management Guide and all other IP based >services used (telnet and ftp at least) appear to function normally. If >NetBEUI is >enabled as a transport, then the VMS ADMIN utility functions normally and it >is possible to access PATHWORKS services from a Windows NT4 PC configured >with the >NetBEUI protocol. (No PATHWORKS software is installed on the PC itself.) would seem to point at Pathworks as the place to isolate the problem as opposed to the stack. Other than ensuring that the base stack is working and that the PWIP device is configured, there is little to do with TCPware itself. Since you see the connections, I would rule out TCPware. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA -------------------------------------------------------------------------------- "Phil Styles" writes: > >I have a test system based on a VAXstation 4000 Model 90 with 128MB memory >and a single RZ26 disk. This has been loaded with a copy of the system disk >from >one of our production VMSclusters which currently runs VMS V5.5-2, TCPware >V5.3-2 and PATHWORKS S4.1C. On the test system, VMS has been upgraded >to VMS V5.5-2H4, the latest TCPware patches installed and PATHWORKS >V5.0F1 has been installed (including updated PWRK$LMAPISHR.EXE image). >PATHWORKS has also been configured to run the PATHWORKS License server >on the same system using a 'server-based client access license'. TCP/IP >naming is via a local hosts. file > >The summary of the problem, is that with TCP/IP as the only configured >transport >V5.0F1 is totally inoperable. Using only the TCP/IP transport, it is not >even possible >to use the PATHWORKS VMS ADMIN utility; trying to login using ADMIN >generates the following error > >Cannot continue. The server is not running. > >I mention this purely to emphasise that this appears to be purely a >PATHWORKS/TCPware issue on the VMS host with no network or PC >configuration issues involved. > >The only other error that can be found is when attempting to display the >TCP/IP >transport status, the command NBSHOW KNBSTATUS generates the following >error. > >netbios/streams/knbs: error 0 > >I've been through all the PATHWORKS log files and nothing seems to indicate >any problems. > >NETCU SHOW CONNECTION does show the relevant connections being present >as show on page 24-2 of the TCPware Management Guide and all other IP based >services used (telnet and ftp at least) appear to function normally. If >NetBEUI is >enabled as a transport, then the VMS ADMIN utility functions normally and it >is possible to access PATHWORKS services from a Windows NT4 PC configured >with the >NetBEUI protocol. (No PATHWORKS software is installed on the PC itself.) > >Suffice it to say, I've tried removing SYS$SYLOGIN and LOGIN.COM, reverted >to >default SYSGEN parameters plus TCPware and PATHWORKS specific requirements, >experimented with different definitions of NETCU_DOMAIN (simple host name >and full >domain name) and LMHOSTS (uppercase, quoted lowercase). A trace of the PC >trying to access a PATHWORKS service reveals that the two systems are >talking to each >other but after a couple of timeouts, the PC eventually sends a 'reset'. > >Sorry for the long submission but any new ideas would be very welcome. > >TIA, Phil > ================================================================================ Archive-Date: Wed, 24 Feb 1999 14:26:30 -0400 From: "Pete Jacob" Reply-To: Info-TCPware@process.com To: Subject: telnet Date: Wed, 24 Feb 1999 14:28:34 -0500 Message-ID: <000001be602b$dec27a20$3d011d87@Pete1.ftmc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <63D30D6E10CFD11190A90000F805FE86A7F0D6@lespaul.process.com> hi! we have been having a strange problem with TCPware, we are a VMS cluster with node 1 running openvms v7.1 and TCPware v5.3.3 and node 2 running openvms v7.1 and UCX... every once in a while users call and are not able to telnet to the TCPware box... it looks like they connect but they get no username prompt... but after 2 minutes or so the prompt comes up and they can work fine... I tried bringing TCPware up and down a number of times... but no luck... I called TCPware support and they had me add something to my TCPware:TCPWARE_CONFIGURE.COM it is $! *** TELNET-OpenVMS parameters *** $ TELNETD_FLAGS == 256 does anyone know what this TELNETD_FLAGS mean in laymens terms? I did look in the management guide to see what it says, and gave a good description... but still don't really know what it is saying when I changed the parameter to 256 I think the defaut is 1 also when should I look into changing the number of telnet servers? how much to too much telnet traffic? default is 1 thanks Pete. ================================================================================ Archive-Date: Wed, 24 Feb 1999 15:09:32 -0400 Sender: DLUTES@textron.com Message-ID: <36D40698.54BBAD7E@cessna.textron.com> Date: Wed, 24 Feb 1999 14:03:04 -0600 From: Dale Lutes Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: telnet References: <000001be602b$dec27a20$3d011d87@Pete1.ftmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pete Jacob wrote: > we have been having a strange problem with TCPware, we are a VMS cluster > with node 1 running openvms v7.1 and TCPware v5.3.3 > and node 2 running openvms v7.1 and UCX... every once in a while > users call and are not able to telnet to the TCPware box... it looks like > they > connect but they get no username prompt... but after 2 minutes or so the > prompt > comes up and they can work fine... My system suffered from this exact same problem and Process SW gave me the same solution: > I called TCPware support and they had me add something to my > TCPware:TCPWARE_CONFIGURE.COM > > $ TELNETD_FLAGS == 256 > > does anyone know what this TELNETD_FLAGS mean in laymens terms? What this controls is how the Telnet server sets up the terminal's TT_ACCPORNAM field. What is TT_ACCPORNAM? The simple answer is that it is the terminal name you get back when you do a SHOW USERS/FULL. When bit 8 (mask 256) of TELNETD_FLAGS is off, Telnet tries to get the name of the system the user is logging in from. When bit 8 is on, Telnet doesn't bother to resolve the name and SHOW USERS gives the system IP address instead of a node name. While it is nice to have the name provided, it does cost you a lookup. In my case, our company's DNS server was as slow as molasses, hence the long wait to get connected. I hope this explanation hasn't made it all more confusing. Dale ================================================================================ Archive-Date: Fri, 26 Feb 1999 17:31:14 -0400 From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: [TCPware V5.3-3] ARP Problem with PSEUDO Ifc Date: 26 Feb 99 22:23:24 GMT Message-ID: <36d71edc.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM We've two IP networks on one physical LAN. So I added my TCPware system with an Pseudo Ifc for the second network to the LAN. (TCPware V5.3-3 on V7.1) All works, except: Pinging a Novell-Server (other nodes seems to be not so restrictive) showed that the TCPware node is using the Prim Ifc Add to ARP Requesting the node in the other IP network - and the NOVELL Server is not sending the ARP Response. Adding the Mac.Add to the ARP cache with NETCU ADD ARP gives then perfect communication. Even Pinging is possible (ICMP vs IP). There is no difference between a VAX and an Alpha. So what do you think, is this normal for Pseudo Ifc (means I've to live with it) or is it a bug (PSC has to fix it) ? I think it is a bug, and UCX (V4.2 in this case) does not have it... TIA ------------------------------------------------------------------------ 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