Archive-Date: XXX, 3 Jul 1997 13:51:10 EDT Subject: DHCP Error Explanation Message-ID: <1997Jul3.135110.17906@giant> From: joneil@giant.intranet.com (John O'Neil........Ext 562) Date: 3 Jul 97 13:51:10 EDT Can anyone assist with this error message, and point me in the direction as to what might be causing this? Thanks, John O'Neil IntraNet, Inc. %%%%%%%%%%% OPCOM 3-JUL-1997 10:39:04.73 %%%%%%%%%%% Message from user SYSTEM on INET2 %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B %%%%%%%%%%% OPCOM 3-JUL-1997 11:44:04.86 %%%%%%%%%%% Message from user SYSTEM on INET2 %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B %%%%%%%%%%% OPCOM 3-JUL-1997 11:56:04.89 %%%%%%%%%%% Message from user SYSTEM on INET2 %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B %%%%%%%%%%% OPCOM 3-JUL-1997 13:14:59.24 %%%%%%%%%%% Message from user SYSTEM on INET2 %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106A5A5 %%%%%%%%%%% OPCOM 3-JUL-1997 13:15:05.31 %%%%%%%%%%% Message from user SYSTEM on INET2 %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B ================================================================================ Archive-Date: Mon, 07 Jul 1997 16:52:51 -0400 Subject: Re: DHCP Error Explanation Message-ID: <33C15722.4C89@process.com> From: Hiroto Shibuya Date: Mon, 07 Jul 1997 16:52:51 -0400 References: <1997Jul3.135110.17906@giant> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John O'Neil........Ext 562 wrote: > ... > > %%%%%%%%%%% OPCOM 3-JUL-1997 10:39:04.73 %%%%%%%%%%% > Message from user SYSTEM on INET2 > %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B > DHCP message type 5 is DHCPACK, which is a server to client message. It should have the packet marked as "reply" packet which should be dropped by the server at the pretty ealier stage. The fact the above message is printed out means that there was a packet claiming to be request packet although has DHCP message type of DHCPACK which should not appear in the request packet, thus the anomaly was reported. > %DHCPD-W-BADDHCPMSG, unknown DHCP message 5 from 00008106EC2B ^^^^^^^^^^^^ Can you identify your offending client from this MAC address? ================================================================================ Archive-Date: XXX, 10 Jul 1997 15:55:12 GMT Subject: telnet behavior with TCPWARE 5.2 Message-ID: From: byrd@mscf.med.upenn.edu (Karen Byrd) Date: 10 Jul 1997 15:55:12 GMT I recently switched from Attachmate(Wollongong) Pathway to TCPWare 5.2. Everything seems fine except that starting a telnet session seems slow. Or rather a few seconds slower than it did using Pathway. Any ideas? -- Karen Byrd School of Medicine Univ. of Pennsylvania Phila., PA ================================================================================ Archive-Date: Thu, 10 Jul 1997 15:16:20 -0400 Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <33C53504.12D7@process.com> From: Kristy Gleason Date: Thu, 10 Jul 1997 15:16:20 -0400 Reply-To: gleason@process.com References: MIME-Version: 1.0 To: Karen Byrd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karen Byrd wrote: > > I recently switched from Attachmate(Wollongong) Pathway to > TCPWare 5.2. Everything seems fine except that starting a telnet session > seems slow. Or rather a few seconds slower than it did using Pathway. > > Any ideas? > > -- > Karen Byrd > School of Medicine > Univ. of Pennsylvania > Phila., PA This is probably happening because by default the TELNET server will attempt try to find the host name of the client and use it when setting the remote port information (ACCPORNAM) for the process. (This shows up when you do a SHOW SYSTEM and in the accounting file.) Looking up the host name could take some time especially if there are network problems, problems with name servers, or if DNS is improperly configured. You can disable the lookup and have the TELNET server use the client IP address for the remote port information by setting bit 8 of the TELNETD_FLAGS logical. You can add the following line to your TCPWARE_CONFIGURE.COM to set this. $ TELNETD_FLAGS == 256 For more information on the TCPWARE_TELNETD_FLAGS logical refer to the "Telnet - OpenVMS Management" chapter of the TCPware Management Guide. If this doesn't solve the problem, please send an email to support@process.com and we will work further on this. Thanks! -- Kristy Gleason Process Software Corporation Technical Support Specialist ================================================================================ Archive-Date: Wed, 16 Jul 1997 18:53:33 -0400 Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <33CD18AD.174EE87F@eco.twg.com> From: Larry Henry Date: Wed, 16 Jul 1997 18:53:33 -0400 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karen Byrd wrote: > > I recently switched from Attachmate(Wollongong) Pathway to > TCPWare 5.2. Everything seems fine except that starting a telnet session > seems slow. Or rather a few seconds slower than it did using Pathway. > > Any ideas? > > -- > Karen Byrd > School of Medicine > Univ. of Pennsylvania > Phila., PA Glibbly I'd say, "sounds like you made the wrong choice..." but more technically I'd say Process probably doesn't implement their telnet solution in an optimal fashion... Ready to switch back ? -Larry. Director, McLean Development Attachmate, Open Systems Group ================================================================================ Archive-Date: XXX, 17 Jul 1997 05:58:20 GMT Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <01bc9275$dc61b0f0$8510ac8f@home> From: "Larry Henry" Date: 17 Jul 1997 05:58:20 GMT References: Just as an FYI, I got a note from a CISCO support rep that this problem was related to reverse hostname lookups. -Larry. Larry Henry wrote in article <33CD18AD.174EE87F@eco.twg.com>... > Karen Byrd wrote: > > > > I recently switched from Attachmate(Wollongong) Pathway to > > TCPWare 5.2. Everything seems fine except that starting a telnet session > > seems slow. Or rather a few seconds slower than it did using Pathway. > > > > Any ideas? > > > > -- > > Karen Byrd > > School of Medicine > > Univ. of Pennsylvania > > Phila., PA > > Glibbly I'd say, "sounds like you made the wrong choice..." but more > technically I'd say Process probably doesn't implement their telnet > solution in an optimal fashion... > > Ready to switch back ? > > -Larry. > Director, McLean Development > Attachmate, Open Systems Group > ================================================================================ Archive-Date: XXX, 17 Jul 1997 08:23:45 GMT Subject: printing problem Message-ID: <5qkkqh$ahs$1@tst.hk.super.net> From: silee@news.hk.super.net (Mr Simon Lee) Date: 17 Jul 1997 08:23:45 GMT Hello, Our system information: Product name : TCPware 5.1 OS : OpenVMS 6.2 Problem description: After upgraded TCPware from 4.x to 5.1, we have printing problem that the print jobs of the TCPware queue are all staying in the print queue with 'retain on error' status. We then applied the patch TSSYM_v514010 last week, which should resolve this timeout problem, but we still have the same error. We have not defined the logical TCPWARE_TSSYM_*_RETRY_INTERVAL after we applied the patch. We use the following command line to create the print queue which have this problem: init/que/process=tcpware_tssym/on="man_lpr,9100,keep,noopcom" /library=man_lpr/default=(feed,flag=one,form=default) hpv302$man_lpr/retain=error Please advice. Thanks very much in advance, Simon ================================================================================ Archive-Date: XXX, 17 Jul 1997 15:43:34 GMT Subject: Hmmmmm Message-ID: <5qlej6$f55$825@falcon.ns.net> From: rich@aardvark.greystoneapts.com Date: 17 Jul 1997 15:43:34 GMT Hmmmmm. ================================================================================ Archive-Date: Thu, 17 Jul 1997 17:55:58 -0400 Subject: Re: printing problem Message-ID: <33CE94EE.7E46@process.com> From: Kristy Gleason Date: Thu, 17 Jul 1997 17:55:58 -0400 Reply-To: gleason@process.com References: <5qkkqh$ahs$1@tst.hk.super.net> MIME-Version: 1.0 To: Mr Simon Lee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mr Simon Lee wrote: > > Hello, > > Our system information: > > Product name : TCPware 5.1 > OS : OpenVMS 6.2 > > Problem description: > > After upgraded TCPware from 4.x to 5.1, we have printing problem that > the print jobs of the TCPware queue are all staying in the print queue > with 'retain on error' status. We then applied the patch TSSYM_v514010 > last week, which should resolve this timeout problem, but we still have > the same error. > > We have not defined the logical TCPWARE_TSSYM_*_RETRY_INTERVAL after > we applied the patch. > > We use the following command line to create the print queue which have > this problem: > > init/que/process=tcpware_tssym/on="man_lpr,9100,keep,noopcom" > /library=man_lpr/default=(feed,flag=one,form=default) > hpv302$man_lpr/retain=error > > > > Please advice. > > Thanks very much in advance, > Simon Hiya Simon, Did you stop (not pause) and restart the TSSYM-based queue(s) after you applied the patch? -- Kristy Technical Support Specialist Process Software Corporation ================================================================================ Archive-Date: XXX, 18 Jul 1997 17:00:38 GMT Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <5qo7fm$bfn$1@news.Austria.EU.net> From: eplan@kapsch.co.at (Peter LANGSTOEGER) Date: 18 Jul 1997 17:00:38 GMT Reply-To: eplan@kapsch.co.at References: In article <01bc9275$dc61b0f0$8510ac8f@home>, "Larry Henry" writes: >Just as an FYI, I got a note from a CISCO support rep that this problem was >related to reverse >hostname lookups. But nevertheless, there are problems with TCPware V5.2 TELNET(ing to an AS/400) We "fixed" it (temporary) by restoring the TCPware V5.1 TELNET.EXE Just the same, what we did with the TFTP server (files are now stored in Fixed-512 format and truncated (!!) was Stream-LF before). And we are still looking why the RSH Proxy broke with the V5.2 upgrade. Every new version of TCPware (Note: I still like TCPware) breaks a utility which worked for years (eg. FTP client crashes with ERRDURWRI in V5.0-x, PWIPdriver machine crashes in V5.0-4, or BIND server did not do zone transfers in V5.0-4, ...) But we have also long standing problems with TCPware, (eg. reverse TELNET, DNS Client gives "%DNS-E-DUPSERVDEF, duplicate service definition", FTP ACCVIO with Novell V4.1 server, Timeserver operates in slave mode though configured as FIXED_MASTER, and so on). just my 0.02 ------------------------------------------------------------------------ Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 Network and OpenVMS system manager Fax. +43 1 81111-888 Technical Computer Center (ADV) 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" ================================================================================ Archive-Date: Sun, 20 Jul 1997 15:11:16 GMT Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <5qta51$htm@sjx-ixn3.ix.netcom.com> From: royalef@aol.com (Royal E. Frazier Jr.) Date: Sun, 20 Jul 1997 15:11:16 GMT Reply-To: royalef@aol.com Sender: royalef@aol.com (Royal E. Frazier Jr.) References: Keywords: GIF animations, genealogy Kristy Gleason wrote: >You can disable the lookup and have the TELNET server use the client >IP address for the remote port information by setting bit 8 of the >TELNETD_FLAGS logical. You can add the following line to your >TCPWARE_CONFIGURE.COM to set this. >$ TELNETD_FLAGS == 256 We've DEFINEd this on all of our vaxes, but the value reverts to 129 occasionally. It doesn't do it on all of our vaxes, or reliably. Any ideas what would cause the flags to change? Royal Frazier Transammonia, Inc. ================================================================================ Archive-Date: Sun, 20 Jul 1997 15:13:13 GMT Subject: Terminal IP Queues on OPENVMS Message-ID: <5qta8l$e87@sjx-ixn8.ix.netcom.com> From: royalef@aol.com (Royal E. Frazier Jr.) Date: Sun, 20 Jul 1997 15:13:13 GMT Reply-To: royalef@aol.com Sender: royalef@aol.com (Royal E. Frazier Jr.) Keywords: GIF animations, genealogy We have several IP queues setup by a previous employee using TCPWARE. All of them are server queues, none are terminal. Is there any restriction that prevents a TCPWARE queue from being a TERMINAL DQS queues? Having all server IP queus prevents us from assigning them to eachother during outages. Royal Frazier ================================================================================ Archive-Date: XXX, 20 Jul 1997 23:50:01 -0400 Subject: Re: telnet behavior with TCPWARE 5.2 Message-ID: <1997Jul20.235001@process.com> From: volz@process.com (Bernie Volz) Date: 20 Jul 97 23:50:01 -0400 References: <5qta51$htm@sjx-ixn3.ix.netcom.com> In article <5qta51$htm@sjx-ixn3.ix.netcom.com>, royalef@aol.com (Royal E. Frazier Jr.) writes: > Kristy Gleason wrote: > >>You can disable the lookup and have the TELNET server use the client >>IP address for the remote port information by setting bit 8 of the >>TELNETD_FLAGS logical. You can add the following line to your >>TCPWARE_CONFIGURE.COM to set this. > >>$ TELNETD_FLAGS == 256 > > We've DEFINEd this on all of our vaxes, but the value reverts to 129 > occasionally. It doesn't do it on all of our vaxes, or reliably. > > Any ideas what would cause the flags to change? > > Royal Frazier > Transammonia, Inc. > Make sure you've editted the file in TCPWARE_COMMON:[TCPWARE], not the TCPWARE_SPECIFIC (SYS$SPECIFIC) directory. If you just do the specific directory, it will only take affect on that one node. And, it may cause some strange results if you have a TELNET_CONTROL.COM in both the specific and common directory. If you did put any in the specific directory, make sure you get rid of them. Also, TELNET_CONTROL.COM (as all *_CONTROL.COM) are "replaced" each time you (re)install TCPware. The install doesn't purge the old versions, so you can check what the changes are. I also assume that by stating that the flag changes, you are referring to the logical that is defined based on the value, TCPWARE_TELNETD_FLAGS? - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Mon, 21 Jul 1997 09:32:42 -0500 Subject: Re: printing problem Message-ID: <33D37309.5C2D@process.com> From: Michael Corbett Date: Mon, 21 Jul 1997 09:32:42 -0500 References: <5qkkqh$ahs$1@tst.hk.super.net> MIME-Version: 1.0 To: Mr Simon Lee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mr Simon Lee wrote: [Snip] > Problem description: > > After upgraded TCPware from 4.x to 5.1, we have printing problem that > the print jobs of the TCPware queue are all staying in the print queue > with 'retain on error' status. We then applied the patch TSSYM_v514010 > last week, which should resolve this timeout problem, but we still have > the same error. > > We have not defined the logical TCPWARE_TSSYM_*_RETRY_INTERVAL after > we applied the patch. > Simon, You have to make sure that all the TSSYM queues are stopped and then started. You should do a STOP/QUEUE/RESET on all the TSSYM queues and then start them. The TSSYM symbiont will handle up to 16 queues each so if you just stop and start one queue the symbiont does not stop and the new version of the symbiont is not run. regards Mike -- +-----------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Corporation Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: XXX, 22 Jul 1997 17:11:08 -0400 Subject: MadGoat: Updated MGFTP and NETLIB Message-ID: <1997Jul22.171108@process.com> From: goatley@process.com (Hunter Goatley) Date: 22 Jul 97 17:11:08 -0400 MadGoat Software announces the following updates: - MadGoat FTP V2.2-2 - NETLIB V2.1B MGFTP is an FTP client and server for VMS that runs with all the major TCP/IP implementations for VMS (TCPware, MultiNet, CMU, UCX, and Pathway). It implements STRU VMS support and has many features not offered by any any of the vendors' FTP clients and servers. NETLIB is MadGoat's library of generic TCP/IP routines. Software that uses NETLIB will run under any of the VMS TCP/IP implementations without modification. Note: the MGFTP kit includes NETLIB V2.1B. You can get the updates from: WWW http://www.madgoat.com/ http://www2.wku.edu/www/fileserv/ ftp://ftp.madgoat.com/madgoat/mgftp.zip ftp://ftp.madgoat.com/madgoat/netlib021.zip FTP ftp.madgoat.com [.MADGOAT]MGFTP.ZIP [.MADGOAT]NETLIB021.ZIP ftp.process.com [.MADGOAT]MGFTP.ZIP [.MADGOAT]NETLIB021.ZIP ftp.spc.edu [.MACRO32.SAVESETS]MGFTP.ZIP [.MACRO32.SAVESETS]NETLIB021.ZIP Other mirrors E-mail Send the following commands in the body of a mail message to : SEND MGFTP SEND NETLIB021 Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html