Archive-Date: Thu, 2 Jul 1998 11:20:15 -0400 From: "Jim Lahman" Reply-To: Info-TCPware@process.com Subject: TCPdriver & two ethernet lines Message-ID: <01bda5c9$bd5621b0$1ca112ac@clecaljaz001> Date: Thu, 02 Jul 1998 14:57:52 GMT To: Info-TCPware@PROCESS.COM Hi: I'm writing a TCP server using the $QIO interface. However, our alpha/VMS systems have two ethernet cards since they are connected to two subnets. I only want the TCP server to listen on one of the lines. I tries setting one of the ECB PIDs to 0 (Local internet address). However, the client receives a virtual circuit closed error. Do you have any hints? Jim Lahman jlahman@cyberdrive.net ================================================================================ Archive-Date: Thu, 2 Jul 1998 11:36:05 -0400 Sender: bryant@process.com Date: Thu, 2 Jul 1998 11:32:26 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: JLAHMAN@CYBERDRIVE.NET, bryant@process.com Message-ID: <009C8935.8D228227.123@process.com> Subject: RE: TCPdriver & two ethernet lines "Jim Lahman" writes: > >Hi: > >I'm writing a TCP server using the $QIO interface. However, our alpha/VMS >systems have two ethernet cards since they are connected to two subnets. I >only want the TCP server to listen on one of the lines. I tries setting >one of the ECB PIDs to 0 (Local internet address). However, the client >receives a virtual circuit closed error. > >Do you have any hints? > >Jim Lahman >jlahman@cyberdrive.net > Are you saying that you specified an ECB with a PID of 0 and the local address of the interface you want to listen on, or with a local address of 0? A local address of 0 would mean all interfaces. Assuming that you specified the local address of the interface you want to listen on, are you sure that the address was specified in network byte order? Does it work with a local address of 0? You may want to try NETCU DEBUG/TCP/LIA=interface_of_interest and watch for incoming packets from the client and make sure all is well there and see what is happening with the 3 way handshake for establishing the connection. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Thu, 2 Jul 1998 22:12:44 -0400 From: Peter.Burnett@tnx.neverlnd.org.uk (Peter Burnett) Reply-To: Info-TCPware@process.com Subject: DHCP Example please Date: 02 Jul 98 21:02:55 GMT Message-ID: <046_9807022300@neverlnd.org.uk> To: Info-TCPware@PROCESS.COM Read the manuals for v5.3 and looked at the example DHCPTAB.TEMPLATE and I am still a little confused. Could someone please post an example of an entry in the DHCPTAB. file of where a machine of an unknown hardware MAC address (ha) can be assigned an IP address from within a range. These machines will all use the Gateway Address (gw), Will have the same IP Address (ar) to be allocated from, same subnet mask (sm) and same DNS servers (ds)... for example.... # # Address Range 192.168.1.1 thru to 192.168.1.100 - Static # 192.168.1.101 thru to 192.168.1.150 - Dynamic (MAC Known) # 192.168.1.151 thru to 192.168.1.200 - Dynamic (MAC Unknown) # global.dummy:\ :sm=255.255.255.0: ds=192.168.1.3 192.168.1.4:\ :ns=192.168.1.3: ts=192.168.1.3:\ :cs=192.168.1.2: lg=192.168.1.3:\ :hn: bs=auto: vm=auto: to=0: # laptop.lease: ar=192.168.1.101 192.168.1.150: lt=3600:\ sm=255.255.255.0: ds=192.168.1.3 192.168.1.4:\ dn="neverlnd.org.uk": gw=192.168.1.3: # # This laptop has a known MAC address - 3Com EL III PCMCIA Card # pdb2: ht=ether: ha=00-60-97-EF-01-6E: tc=laptop.lease: # # These ones we do not know the MAC address ?????????? # Will be in the address range of 192.168.1.151 thru to 192.168.1.200 # Thanks in advance... Peter - pdb@post.neverlnd.org.uk - http://www.neverlnd.demon.co.uk ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Data: 44-(0)1424-853361 Fax: 44-(0)1424-853364 Hastings Voice: 44-(0)468-817347 SysAdmin@tnx.neverlnd.org.uk UK Http://www.neverlnd.demon.co.uk TN38 9QT/10 ================================================================================ Archive-Date: Tue, 7 Jul 1998 09:37:10 -0400 Sender: goatley@triton.process.com Date: Tue, 7 Jul 1998 09:37:07 -0400 From: goathunter@PROCESS.COM Reply-To: Info-TCPware@process.com From: "David A. Massaro, ITEC systems and networking" Subject: DNIP questions To: Info-TCPware@PROCESS.COM Message-ID: <01IZ438WTHEA9YDMJ8@mail.suny.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello, We're experimenting with DECnet over IP. A few questions have come up. We're running a large DECnet WAN. After configuring DNIP, how do we use DNIP as opposed to straight DECnet? How do we know which protocol is being used? Our routers give priority to straight DECnet connections. This was done quite a while ago because IP traffic was killing our DECnet connections. What is the priority now using DECnet over IP? Thanks! -Dave ,---------------------------------------------------------. | David A. Massaro | | Sr. Systems Programmer - SUNY ITEC | | Computing Services - Twin Rise 208 | | State University of New York College at Buffalo | | 1300 Elmwood Avenue | | Buffalo, New York, 14222 | | U.S.A., Planet Earth | | | | Internet: MassarDA@ITEC.SUNY.EDU | | SUNY DECnet: sbscVC::MassarDA | | Pager-mail: 7166332568.6191954@pagenet.net | | | | VOICE: 716-878-ITEC | | FAX: 716-878-4235 | | URL: h-d.itec.suny.edu | `---------------------------------------------------------' 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: Wed, 8 Jul 1998 15:45:32 -0400 From: "Ruslan R. Laishev" Reply-To: Info-TCPware@process.com Subject: Re: DNIP questions Date: Wed, 08 Jul 1998 23:24:54 +0400 Message-ID: <35A3C786.E504C73C@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Hi ! David A. Massaro, ITEC systems and networking wrote: > > Hello, > > We're experimenting with DECnet over IP. A few questions have come up. > > We're running a large DECnet WAN. After configuring DNIP, how do we > use DNIP as opposed to straight DECnet? How do we know which protocol > is being used? > > Our routers give priority to straight DECnet connections. This was done > quite a while ago because IP traffic was killing our DECnet connections. Probably You has quit serious reasons for using of two networks' protocols ? -- Cheers... +----------------------------------------------Pure personal oppinion+ OpenVMS System/Network HardWorker Cel: 7+ (901) 971-3222 RSA/FngrPnt:D1C7F4D1912325A81C122F468A83293A Fido: 2:5030/279 +http://www.levitte.org/~rlaishev/ ----------------------------------+ ================================================================================ Archive-Date: Thu, 9 Jul 1998 11:46:24 -0400 From: "Laurence Fossey" Reply-To: Info-TCPware@process.com Subject: Problems with the Telnet Server Date: Thu, 9 Jul 1998 09:47:09 +0100 Message-ID: <899974014.18922.0.nnrp-07.9e98f233@news.demon.co.uk> To: Info-TCPware@PROCESS.COM Hi, We have are currently using the TCPware V5.3 we have also had this problem on TCPware V5.1. The problem has been seen on both VAX & Alpha hardware. We use TCPware DNS and the network has no connection to the Internet. If we enable the TELnet server to do reverse translation of IP address so we get the host name in the Physical Terminal Name and not the IP address. The TELnet server drops a lot of connections and we Invalid Buffer length errors in the Log file (see below) The work around is to define TCPWARE_TELNETD_FLAGS to 257 but we would prefer host names in the terminal string. Can you help Regards Laurence Fossey NETCP.LOG TCPware(R) for OpenVMS V5.3-2 Copyright (c) 1997 Process Software Corporation ** 29-APR-1998 20:18:13 NETCP logging started. ** 29-APR-1998 20:18:17 Line LPB-0 (127.0.0.1) started by SYSTEM (21000204). ** 29-APR-1998 20:18:17 Line ISA-0 (194.130.78.15) started by SYSTEM (21000204). Line ISA-0 is using _EZA6:. ** 29-APR-1998 20:18:17 Updating multicast address list for line ISA-0: Adding address 01-00-5E-00-00-01 ** 29-APR-1998 20:18:18 TCP started (or restarted) by SYSTEM (21000204). ** 29-APR-1998 20:18:19 UDP started (or restarted) by SYSTEM (21000204). ** 29-APR-1998 20:18:19 INET started (or restarted) by SYSTEM (21000204). ** 29-APR-1998 20:18:20 UCX started (or restarted) by SYSTEM (21000204). ** 29-APR-1998 20:47:54 TCP connection established on _INET27: from 194.130.78.14,1043 to 194.130.78.15,23. Created terminal _NTA1: for interactive session. ** 29-APR-1998 20:48:05 TCP connection established on _INET28: from 194.130.78.14,1044 to 194.130.78.15,23. Created terminal _NTA1: for interactive session. ** 30-APR-1998 11:16:11 TCP connection established on _INET29: from 194.130.78.242,1057 to 194.130.78.15,23. Created terminal _NTA1: for interactive session. ** 30-APR-1998 12:37:32 TCP connection established on _INET30: from 194.130.78.14,1051 to 194.130.78.15,23. Created terminal _NTA2: for interactive session. ** 30-APR-1998 12:37:48 TCP connection established on _INET31: from 194.130.78.14,1054 to 194.130.78.15,23. Created terminal _NTA2: for interactive session. ** 30-APR-1998 12:37:59 TCP connection established on _INET32: from 194.130.78.15,1037 to 194.130.78.15,23. Failed to create terminal for interactive session. %SYSTEM-F-IVBUFLEN, invalid buffer length ** 30-APR-1998 12:38:44 TCP connection established on _INET33: from 194.130.78.15,1039 to 194.130.78.15,23. Failed to create terminal for interactive session. %SYSTEM-F-IVBUFLEN, invalid buffer length ================================================================================ Archive-Date: Thu, 9 Jul 1998 12:34:22 -0400 Subject: Re: Problems with the Telnet Server Message-ID: <1998Jul9.115111@alcor.process.com> From: VOLZ@PROCESS.COM (Bernie Volz) Reply-To: Info-TCPware@process.com Date: 9 Jul 98 11:51:11 -0400 To: Info-TCPware@PROCESS.COM In article <899974014.18922.0.nnrp-07.9e98f233@news.demon.co.uk>, "Laurence Fossey" writes: > Hi, > > We have are currently using the TCPware V5.3 we have also had this problem > on TCPware V5.1. The problem has been seen on both VAX & Alpha hardware. > > We use TCPware DNS and the network has no connection to the Internet. > > If we enable the TELnet server to do reverse translation of IP address so we > get the host name in the Physical Terminal Name and not the IP address. The > TELnet server drops a lot of connections and we Invalid Buffer length errors > in the Log file (see below) > > The work around is to define TCPWARE_TELNETD_FLAGS to 257 but we would > prefer host names in the terminal string. > > Can you help > > Regards > > Laurence Fossey This is a known problem and a fix is available - get the latest NETCP_V532P*.* patch kit available from ftp.tcpware.process.com - Bernie Volz Process Software Corporation ================================================================================ Archive-Date: Tue, 14 Jul 1998 13:32:59 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: PATHWORKS 5.0F License Server, TCP/IP Date: Tue, 14 Jul 1998 08:38:13 -0400 Message-ID: <6ofjcp$8t4$1@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Hi Everyone: What's the trick to getting the PATHWORKS 5.0F license server to use TCP/IP? I've used PWRK$CONFIG to set it to use TCP/IP and NOT DECnet or NetBEUI, and it refuses to respond to license requests via TCP/IP, and continues to respond to DECnet-based requests! I need to get it to respond to TCP/IP-based requests as we're removing DECnet and NetBEUI from the LAN. I'm using TCPware 5.2 on the PATHWORKS server and it's serving file services via TCP/IP so I think I've got TCPware configured correctly. Or have I? Regards, Brian Steele IS Manager C&W Grenada ================================================================================ Archive-Date: Tue, 14 Jul 1998 13:43:13 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: PATHWORKS 5.0F License Server, TCP/IP Date: Tue, 14 Jul 1998 08:21:57 -0400 Message-ID: <6ofie9$8nu$1@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Hi Everyone: What's the trick to getting the PATHWORKS 5.0F license server to use TCP/IP? I've used PWRK$CONFIG to set it to use TCP/IP and NOT DECnet or NetBEUI, and it refuses to respond to license requests via TCP/IP, and continues to respond to DECnet-based requests! I need to get it to respond to TCP/IP-based requests as we're removing DECnet and NetBEUI from the LAN. I'm using TCPware 5.2 on the PATHWORKS server and it's serving file services via TCP/IP so I think I've got TCPware configured correctly. Or have I? Regards, Brian Steele IS Manager C&W Grenada ================================================================================ Archive-Date: Tue, 14 Jul 1998 13:51:30 -0400 Sender: bryant@process.com Date: Tue, 14 Jul 1998 13:47:15 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009C92B6.5FE6C1FD.8@process.com> Subject: RE: PATHWORKS 5.0F License Server, TCP/IP >Hi Everyone: > >What's the trick to getting the PATHWORKS 5.0F license server to use TCP/IP? >I've used PWRK$CONFIG to set it to use TCP/IP and NOT DECnet or NetBEUI, and >it refuses to respond to license requests via TCP/IP, and continues to >respond to DECnet-based requests! > >I need to get it to respond to TCP/IP-based requests as we're removing >DECnet and NetBEUI from the LAN. I'm using TCPware 5.2 on the PATHWORKS >server and it's serving file services via TCP/IP so I think I've got TCPware >configured correctly. Or have I? Well, make sure you have configured PWIPDRIVER. A quick SHOW DEV PWIP should show a PWIP0: device. Then you can do a quick tcpdump watching a connection to a system of interest and look for packets on the netbios ports: $ TCPDUMP:==$TCPWARE:TCPDUMP $ tcpdump host marge.process.com warning: reducing packet buffers from 255 to 116 Getting stats. Tcpdump: listening on ESA0: 13:41:19.874313 marge.process.com.1024 > lear.process.com.netbios-ssn: P 1191489 223:1191489324(101) ack 683736396 win 6144 (DF) 13:41:20.044313 marge.process.com.1024 > lear.process.com.netbios-ssn: P 101:183 (82) ack 138 win 6144 (DF) 13:41:20.084313 marge.process.com.1024 > lear.process.com.netbios-ssn: P 183:266 (83) ack 207 win 6144 (DF) as an example. > >Regards, >Brian Steele >IS Manager >C&W Grenada ================================================================================ Archive-Date: Wed, 15 Jul 1998 13:54:21 -0400 From: royalef@aol.com (Royal E. Frazier Jr.) Subject: Re: PATHWORKS 5.0F License Server, TCP/IP Date: Wed, 15 Jul 1998 17:39:07 GMT Sender: royalef@aol.com (Royal E. Frazier Jr.) Message-ID: <35b0e736.11537210@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Keywords: GIF animations, genealogy To: Info-TCPware@PROCESS.COM "Brian Steele" wrote: >Hi Everyone: > >What's the trick to getting the PATHWORKS 5.0F license server to use TCP/IP? >I've used PWRK$CONFIG to set it to use TCP/IP and NOT DECnet or NetBEUI, and >it refuses to respond to license requests via TCP/IP, and continues to >respond to DECnet-based requests! > >I need to get it to respond to TCP/IP-based requests as we're removing >DECnet and NetBEUI from the LAN. I'm using TCPware 5.2 on the PATHWORKS >server and it's serving file services via TCP/IP so I think I've got TCPware >configured correctly. Or have I? This has nothing to do with TCPWARE. Pathworks under IP licenses completely different. I don't have it in front of me but under IP the Pathworks License server ha a DIFFERNET NODE NAME!! Brilliant ain't that! SERVER becomes something like SERVER$LWRKS (it may be related to the NETBIOS browser-PDC-domain name-i've seen it on our Fluke). On two of our servers it shows up with additional spaces and "L 01" tacked on the end. If you have a licensed PC that connects to the server, you will often see it in the Event Logger, but only if using TCP/IP. When the Pathworks client communicates across IP it looks, not for SERVER but for the SERVER$LWKRKS. Which your HOSTS. LMHOSTS. or DNS must properly resolve. I belive LMHOSTS. require some kind of PRELOAD statement. Ading it to our DNS got rid of the problem. It is a brilliant piece of idiocy for unknown reason. Basically you can't license from your servers because your clients are looking for servers that aren't defined. I'm not at work till friday, but if I find format I'm post/email. DEC/compaq gave us this answer. Royal Frazier ======================================== royalef@aol.com http://members.aol.com/royalef/royal.htm ======================================== Family Genealogy and GIF Animation ======================================== ================================================================================ Archive-Date: Thu, 16 Jul 1998 07:29:28 -0400 From: "Laurence Fossey" Reply-To: Info-TCPware@process.com Subject: RESTART of TCPware stops incoming DECNET over IP connections Date: Thu, 16 Jul 1998 10:29:52 +0100 Message-ID: <900581170.8416.0.nnrp-11.9e98f233@news.demon.co.uk> To: Info-TCPware@PROCESS.COM Hi, I was applying a TCPWARE patch which needed a restart TCPWARE, however after the restart I could no longer make Decnet connections to the system specifying a TCP/IP host name until I rebooted the whole server. Outgoing connections remained OK. As I recall DEC's UCX product does not have this problem, is this a problem with TCPWARE PWIO driver ?? Regards, Laurence Fossey ================================================================================ Archive-Date: Thu, 16 Jul 1998 08:00:00 -0400 Sender: gleason@process.com Date: Thu, 16 Jul 1998 07:55:44 -0400 From: "Kristy, Technical Support Specialist" Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: gleason@process.com Message-ID: <009C9417.99910721.16@process.com> Subject: RE: RESTART of TCPware stops incoming DECNET over IP connections >From: "Laurence Fossey" > >Hi, > >I was applying a TCPWARE patch which needed a restart TCPWARE, however after >the restart I could no longer make Decnet connections to the system >specifying a TCP/IP host name until I rebooted the whole server. > >Outgoing connections remained OK. > >As I recall DEC's UCX product does not have this problem, is this a problem >with TCPWARE PWIO driver ?? > >Regards, > >Laurence Fossey What version of TCPware and what patch did you install? That might give us a better understanding of what might have gone wrong and where. Thanks. -- Kristy Gleason Technical Support Process Software Corporation ================================================================================ Archive-Date: Thu, 16 Jul 1998 09:33:01 -0400 From: "Laurence Fossey" Reply-To: Info-TCPware@process.com Subject: Re: RESTART of TCPware stops incoming DECNET over IP connections Date: Thu, 16 Jul 1998 14:15:56 +0100 Message-ID: <900594634.29668.0.nnrp-01.9e98f233@news.demon.co.uk> To: Info-TCPware@PROCESS.COM We are running TCPWARE V5.3-2 on VMS V7.1 (VAX) The patch was the NETCP in for the Telnet Wrong Buffer Size patch Regards Laurence ================================================================================ Archive-Date: Thu, 16 Jul 1998 09:40:35 -0400 Sender: bryant@process.com Date: Thu, 16 Jul 1998 09:36:06 -0400 From: Geoff Bryant Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: bryant@process.com Message-ID: <009C9425.9EB7B480.150@process.com> Subject: RE: RESTART of TCPware stops incoming DECNET over IP connections >From: "Laurence Fossey" > >Hi, > >I was applying a TCPWARE patch which needed a restart TCPWARE, however after >the restart I could no longer make Decnet connections to the system >specifying a TCP/IP host name until I rebooted the whole server. > >Outgoing connections remained OK. > >As I recall DEC's UCX product does not have this problem, is this a problem >with TCPWARE PWIO driver ?? This should have worked. The TCPware restart should re-issue the NETCU START/PWIP command that re-establishes the link between INETDRIVER and PWIPDRIVER. Were there errors in the startup? > >Regards, > >Laurence Fossey ================================================================================ Archive-Date: Thu, 16 Jul 1998 11:16:16 -0400 From: IAMsteven.vore@digital.com (Steven Vore) Reply-To: Info-TCPware@process.com Subject: Re: PATHWORKS 5.0F License Server, TCP/IP Date: Thu, 16 Jul 1998 09:41:05 -0400 Message-ID: To: Info-TCPware@PROCESS.COM What's my License Server name? It's discussed in The Guide To Managing PATHWORKS Licenses, in the section on Configuring for WANs. A name is prepended with PWRK$L - which name is the potentially confusing part, when you're in a cluster. If it's just a standalone system (let's say the file server's got a NetBIOS name of MICKEY) then it's that system's NetBIOS name prepended by PWRK$L (PWRK$LMICKEY) that the license server uses. If it's a cluster, the rules are a little more complex so the easies thing to say is "look at the top of the license server log file." In a cluster of MICKEY, MINNIE, and PLUTO where the cluster alias is FRIENDS, it can end up being PWRK$LMICKEY, PWRK$LMINNIE, PWRK$LPLUTO, or PWRK$LFRIENDS -- but it will ALWAYS be the same name no matter which of the systems is currently doing the license serving. Go look in the top of the license server log file (in the PWRK$LOGS directory). -- ºoº Steven Vore, MCSE|steven.vore at digital.com | Just an Earthbound Misfit "Smile, Mickey's Watching" Remove UPPER CASE characters to reply ================================================================================ Archive-Date: Thu, 16 Jul 1998 13:04:33 -0400 From: "Brian Steele" Reply-To: Info-TCPware@process.com Subject: Re: PATHWORKS 5.0F License Server, TCP/IP Date: Thu, 16 Jul 1998 08:28:35 -0400 Message-ID: <6okril$683$1@col3.caribsurf.com> To: Info-TCPware@PROCESS.COM Royal E. Frazier Jr. wrote in message <35b0e736.11537210@nntp.ix.netcom.com>... >"Brian Steele" wrote: > >>Hi Everyone: >> >>What's the trick to getting the PATHWORKS 5.0F license server to use >> TCP/IP? > >When the Pathworks client communicates across IP it looks, not for >SERVER but for the SERVER$LWKRKS. Which your HOSTS. LMHOSTS. or >DNS must properly resolve. I belive LMHOSTS. require some kind of PRELOAD >statement. Ading it to our DNS got rid of the problem. I checked the license config on my PC, and it seems to be looking for PWRK$GNDL00 (my server's name is GNDL00). I added an entry in the DNS for PWRK$GNDL00 mapped to my server's IP address, but I'm still getting the same error. >I'm not at work till friday, but if I find format I'm post/email. >DEC/compaq gave us this answer. Thanks - I really need to get this sorted out! Regards, Brian Steele ================================================================================ Archive-Date: Thu, 16 Jul 1998 18:01:36 -0400 From: "Laurence Fossey" Reply-To: Info-TCPware@process.com Subject: Re: RESTART of TCPware stops incoming DECNET over IP connections Date: Thu, 16 Jul 1998 22:52:45 +0100 Message-ID: <900625744.6203.0.nnrp-09.9e98f233@news.demon.co.uk> To: Info-TCPware@PROCESS.COM Geoff Bryant wrote in message <009C9425.9EB7B480.150@process.com>... >>From: "Laurence Fossey" >> >>Hi, >> >>I was applying a TCPWARE patch which needed a restart TCPWARE, however after >>the restart I could no longer make Decnet connections to the system >>specifying a TCP/IP host name until I rebooted the whole server. >> >>Outgoing connections remained OK. >> >>As I recall DEC's UCX product does not have this problem, is this a problem >>with TCPWARE PWIO driver ?? > >This should have worked. The TCPware restart should re-issue the >NETCU START/PWIP command that re-establishes the link between INETDRIVER >and PWIPDRIVER. Were there errors in the startup? > There were no startup errors, I still have two systems with this problem. I've just issued a STOP /PWIP and a START /PWIP. Incoming connections were always disabled and while PWIP was stopped the outgoing connection could not be made. >> >>Regards, >> >>Laurence Fossey ================================================================================ Archive-Date: Fri, 17 Jul 1998 04:06:55 -0400 MIME-Version: 1.0 Date: Fri, 17 Jul 1998 09:39:50 +0100 Message-ID: <0007A6D1.3045@cpr.fr> From: pclairembault@cpr.fr (Pierre CLAIREMBAULT) Reply-To: Info-TCPware@process.com Subject: Re[2]: RESTART of TCPware stops incoming DECNET over IP conn To: Info-TCPware@PROCESS.COM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: cc:Mail note part You could try something like that : = MC ncl Disable Osi transport ! It stops all Osi active connections Netcu Stop/PWIP netcu Start/PWIP MC ncl Enable osi Transport = Pierre Clairembault ____________________________ S=E9parateur R=E9ponse _____________________= ___________ Objet : Re: RESTART of TCPware stops incoming DECNET over IP connect Auteur : Info-TCPware@process.com =E0 INTERNET Date : 16/07/98 22:52 = Geoff Bryant wrote in message <009C9425.9EB7B480.150@process.com>... = >>From: "Laurence Fossey" >> >>Hi, >> >>I was applying a TCPWARE patch which needed a restart TCPWARE, however = after >>the restart I could no longer make Decnet connections to the system = >>specifying a TCP/IP host name until I rebooted the whole server. >> >>Outgoing connections remained OK. >> >>As I recall DEC's UCX product does not have this problem, is this a = problem >>with TCPWARE PWIO driver ?? > >This should have worked. The TCPware restart should re-issue the = >NETCU START/PWIP command that re-establishes the link between INETDRIVER= = >and PWIPDRIVER. Were there errors in the startup? > There were no startup errors, I still have two systems with this problem.= = I've just issued a STOP /PWIP and a START /PWIP. = Incoming connections were always disabled and while PWIP was stopped the = outgoing connection could not be made. = >> >>Regards, >> >>Laurence Fossey = = ================================================================================ Archive-Date: Fri, 17 Jul 1998 13:54:18 -0400 MIME-Version: 1.0 Date: Fri, 17 Jul 1998 19:45:21 +0100 Message-ID: <0007AD63.3045@cpr.fr> From: pclairembault@cpr.fr (Pierre CLAIREMBAULT) Reply-To: Info-TCPware@process.com Subject: Transfer zone problem DNS TCPware V5.1-3 To: Info-TCPware@process.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Hello, I have a DNS server TCPware V5.3 named eco1 on VMS AXP V7.1-1H1. I have a public DNS Bind slave 8.1.2 on Sun Solaris 2.5.1. The zone transfer stops with error message : Err/TO getting serial# for "testfutuna.cpr.fr" testfutuna.cpr.fr is the zone to transfer. With an secondary bind 4 name server there is no problem. Is there a known problem of interoperability between bind 8 and TCPware? What is the bind version of TCPware 5.3-2? Regards, Pierre Clairembault ================================================================================ Archive-Date: Fri, 17 Jul 1998 20:39:54 -0400 From: royalef@aol.com (Royal E. Frazier Jr.) Subject: Re: PATHWORKS 5.0F License Server, TCP/IP Date: Sat, 18 Jul 1998 00:30:39 GMT Sender: royalef@aol.com (Royal E. Frazier Jr.) Message-ID: <35afebb8.1047565@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Keywords: GIF animations, genealogy To: Info-TCPware@PROCESS.COM "Brian Steele" wrote: > >Royal E. Frazier Jr. wrote in message ><35b0e736.11537210@nntp.ix.netcom.com>... >>"Brian Steele" wrote: >> >>>Hi Everyone: >>> >>>What's the trick to getting the PATHWORKS 5.0F license server to use >>> TCP/IP? >> >>When the Pathworks client communicates across IP it looks, not for >>SERVER but for the SERVER$LWKRKS. Which your HOSTS. LMHOSTS. or >>DNS must properly resolve. I belive LMHOSTS. require some kind of PRELOAD >>statement. Ading it to our DNS got rid of the problem. > >I checked the license config on my PC, and it seems to be looking for >PWRK$GNDL00 (my server's name is GNDL00). I added an entry in the DNS for >PWRK$GNDL00 mapped to my server's IP address, but I'm still getting the same >error. That's interesting because all of ours are in the format "PWRK$L"+server-node-name. Sure there wasn't supposed to be an L in there? I can't imagine why mine would be different from yours. We are running 5.0d+E on servers, licensing with PW1.0, 1.0a, 1.0Aeco2, and PW32(7.0&7.0a) on the clients. Of course, verify that the DNS entry is operational. DOS PROMPT, PING PWRK$GNDL00 is the best verification. If your stack requires a setting for resolving NETBIOS names using DNS that should be probably be on. Royal Frazier ======================================== royalef@aol.com http://members.aol.com/royalef/royal.htm ======================================== Family Genealogy and GIF Animation ======================================== ================================================================================ Archive-Date: Fri, 17 Jul 1998 22:06:44 -0400 Sender: schreiber@process.com Date: Fri, 17 Jul 1998 22:02:24 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009C9557.0B257328.27@process.com> Subject: RE: Transfer zone problem DNS TCPware V5.1-3 pclairembault@cpr.fr (Pierre CLAIREMBAULT) writes: > > The zone transfer stops with error message : > Err/TO getting serial# for "testfutuna.cpr.fr" > > testfutuna.cpr.fr is the zone to transfer. > > With an secondary bind 4 name server there is no problem. > That informational message is fairly new, and in many BIND 4 versions, it's not compiled in, so not seeing it doesn't nessessarily mean that the problem didn't exist. However, it indicates that there was some problem getting the serial, or that the query timed out. It would be useful to see a TCPdump trace of the traffic from and to the secondary server, and also you may want to check the result of: nslookup -d2 -type=soa testfutuna.cpr.fr from your Solaris system [of course replace with the actual IP addr or hostname of the primary server]. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Sat, 18 Jul 1998 16:36:36 -0400 From: "news.gov.on.ca" Reply-To: Info-TCPware@process.com Subject: Re: PATHWORKS 5.0F License Server, TCP/IP Date: Sat, 18 Jul 1998 15:48:39 -0400 Message-ID: <6oqu6v$96$1@news.gov.on.ca> To: Info-TCPware@PROCESS.COM Are you sure its not looking for PWRK$LGNDL00? (Note the L following the $) ------------------------------------------------------- Brian Steele wrote in message <6okril$683$1@col3.caribsurf.com>... I checked the license config on my PC, and it seems to be looking for PWRK$GNDL00 (my server's name is GNDL00). I added an entry in the DNS for PWRK$GNDL00 mapped to my server's IP address, but I'm still getting the same error. >I'm not at work till friday, but if I find format I'm post/email. >DEC/compaq gave us this answer. Thanks - I really need to get this sorted out! Regards, Brian Steele ================================================================================ Archive-Date: Mon, 20 Jul 1998 14:59:35 -0400 From: R_Frazier@transammonia.com (Royal E. Frazier, Jr.) Subject: secondary fails to update rev but does update hosts. Date: Mon, 20 Jul 1998 18:46:41 GMT Message-ID: <35b38f73.253625355@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM I'm having trouble getting reverse DNS listing to sync between VAX hosts. The error messages seems to indicate they are failing. TCPWARE ver 5.2-3 on primary TCPWARE ver 5.1-5 on secondary I'm looking to better understand what our DNS is doing. We have a PRIMARY and multiple SECONDARIES. I'm working on getting a smooth functional model on two servers which are 3 ft from eachother and are full production machines with no real others problems. The log on the secondary is filled with %%%%%%%%%%%% NAMED 20-JUL-1998 11:30:55.40 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 0000F2A5 to transfer zone 80.195.in-addr.arpa %SYSTEM-F-TIMEOUT, device timeout %%%%%%%%%%%% NAMED 20-JUL-1998 11:36:29.55 %%%%%%%%%%%% %%TCPWARE_NAMED-I-secondary zone "80.195.in-addr.arpa" expired %%%%%%%%%%%% NAMED 20-JUL-1998 11:45:58.72 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6C2 to transfer zone 80.195.in-addr.arpa %SYSTEM-F-TIMEOUT, device timeout %%%%%%%%%%%% NAMED 20-JUL-1998 12:00:57.99 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6D5 to transfer zone transammonia.com %%%%%%%%%%%% NAMED 20-JUL-1998 12:00:58.48 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6D6 to transfer zone 80.195.in-addr.arpa %SYSTEM-F-TIMEOUT, device timeout Despite setting a 20 minute retry...it seems to retry every fifteen... OBIWAN::REF>type named.local @ IN SOA srv01.transammonia.com. frazier.obiwan.transammonia.com. ( 199711040 ; Serial 3600 ; Refresh 1200 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS srv01.transammonia.com. 1 IN PTR localhost I have just updated and I have one success... %%%%%%%%%%%% NAMED 20-JUL-1998 12:01:03.10 %%%%%%%%%%%% %%TCPWARE_NAMED-I-XFERSUCCESS, zone transammonia.com transferred successfully %%%%%%%%%%%% NAMED 20-JUL-1998 12:01:06.38 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "transammonia.com" loaded (serial 199807200) After a restart I see this... OBIWAN::REF>type nameserver.log $EXIT $! Copyright (c) 1989-1996, Process Software Corporation $ SET NOON $! SET PROCESS/DUMP $ NAMED_ZXFR:==$TCPWARE:NAMED_ZXFR.EXE $START: $ RUN TCPWARE:NAMED.EXE NAMED TCPware(R) for OpenVMS V5.1-5 Copyright (c) 1996 Process Software Corpor ation %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.44 %%%%%%%%%%%% %%%%%%%%%%%% NAMED Process ID = 0000F6F3 %%%%%%%%%%%% %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.50 %%%%%%%%%%%% %%TCPWARE_NAMED-I-STARTUP, domain name server started %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.60 %%%%%%%%%%%% %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:18.79 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "transammonia.com" loaded (serial 199807200) %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:25.41 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "80.195.in-addr.arpa" loaded (serial 16) %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:25.71 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, primary zone "0.0.127.in-addr.arpa" loaded (serial 199711040) %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:26.48 %%%%%%%%%%%% %%TCPWARE_NAMED-I-ZONEINFO, cache zone "" loaded (serial 0) %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:26.53 %%%%%%%%%%%% %%TCPWARE_NAMED-I-MAIN, Ready to answer queries. %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:28.25 %%%%%%%%%%%% %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6F4 to transfer zone 80.195.in-addr.arpa %SYSTEM-F-TIMEOUT, device timeout %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:32.04 %%%%%%%%%%%% %%TCPWARE_NAMED-I-TIMEOUT, zoneref: Masters for secondary zone "80.195.in-addr.arpa" unreachable Why would the rev not be reachable but the named.hosts reachable? Royal Frazier r_frazier@transammonia.com ================================================================================ Archive-Date: Mon, 20 Jul 1998 15:12:43 -0400 Sender: schreiber@process.com Date: Mon, 20 Jul 1998 15:08:17 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009C9778.B04BA48A.11@process.com> Subject: RE: secondary fails to update rev but does update hosts. R_Frazier@transammonia.com (Royal E. Frazier, Jr.) writes: > >Despite setting a 20 minute retry...it seems to retry every fifteen... > I'd need to see your bootfile for sure, but the file you showed seems to be the file for the localhost domain, rather than the 80.195.in-addr.arpa domain. >OBIWAN::REF>type named.local >%%TCPWARE_NAMED-I-SUBPROC, created process 0000F6F4 to transfer zone > 80.195.in-addr.arpa >%SYSTEM-F-TIMEOUT, device timeout > >Why would the rev not be reachable but the named.hosts reachable? > 1) Check your boot file, are you sure that you didn't typo the IP addr of the master for the in-addr.arpa zone [e.g. is it really asking your other system or is it asking someone else]. 2) Check your master server... it is really authoritive for the in-addr.arpa zone? Try pointing nslookup at the primary server from the secondary. $ nslookup > set server [xxxx] > set d2 > set type=soa > 80.195.in-addr.arpa. > ls 80.195.in-addr.arpa. see if those two queries generate anything strange. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 20 Jul 1998 15:13:20 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE860D327C@lespaul.process.com> From: Mike Corbett Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: RE: secondary fails to update rev but does update hosts. Date: Mon, 20 Jul 1998 15:13:46 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDB412.85367D96" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDB412.85367D96 Content-Type: text/plain; charset="iso-8859-1" > I'm having trouble getting reverse DNS listing to sync between VAX > hosts. The error messages seems to indicate they are failing. > TCPWARE ver 5.2-3 on primary > TCPWARE ver 5.1-5 on secondary > > I'm looking to better understand what our DNS is doing. We have a > PRIMARY and multiple SECONDARIES. I'm working on getting a smooth > functional model on two servers which are 3 ft from eachother and are > full production machines with no real others problems. > > The log on the secondary is filled with > %%%%%%%%%%%% NAMED 20-JUL-1998 11:30:55.40 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-SUBPROC, created process 0000F2A5 to transfer zone > 80.195.in-addr.arpa > %SYSTEM-F-TIMEOUT, device timeout > %%%%%%%%%%%% NAMED 20-JUL-1998 11:36:29.55 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-secondary zone "80.195.in-addr.arpa" expired > %%%%%%%%%%%% NAMED 20-JUL-1998 11:45:58.72 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6C2 to transfer zone > 80.195.in-addr.arpa > %SYSTEM-F-TIMEOUT, device timeout > %%%%%%%%%%%% NAMED 20-JUL-1998 12:00:57.99 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6D5 to transfer zone > transammonia.com > %%%%%%%%%%%% NAMED 20-JUL-1998 12:00:58.48 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6D6 to transfer zone > 80.195.in-addr.arpa > %SYSTEM-F-TIMEOUT, device timeout > Despite setting a 20 minute retry...it seems to retry every fifteen... > > OBIWAN::REF>type named.local > @ IN SOA srv01.transammonia.com. > frazier.obiwan.transammonia.com. > ( > 199711040 ; Serial > 3600 ; Refresh > 1200 ; Retry > 3600000 ; Expire > 86400 ) ; Minimum > IN NS srv01.transammonia.com. > 1 IN PTR localhost > > > I have just updated and I have one success... > %%%%%%%%%%%% NAMED 20-JUL-1998 12:01:03.10 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-XFERSUCCESS, zone transammonia.com transferred > successfully > %%%%%%%%%%%% NAMED 20-JUL-1998 12:01:06.38 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "transammonia.com" loaded > (serial > 199807200) > > After a restart I see this... > OBIWAN::REF>type nameserver.log > $EXIT > $! Copyright (c) 1989-1996, Process Software Corporation > $ SET NOON > $! SET PROCESS/DUMP > $ NAMED_ZXFR:==$TCPWARE:NAMED_ZXFR.EXE > $START: > $ RUN TCPWARE:NAMED.EXE > NAMED TCPware(R) for OpenVMS V5.1-5 Copyright (c) 1996 Process > Software Corpor > ation > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.44 %%%%%%%%%%%% > %%%%%%%%%%%% NAMED Process ID = 0000F6F3 %%%%%%%%%%%% > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.50 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-STARTUP, domain name server started > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:14.60 %%%%%%%%%%%% > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:18.79 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "transammonia.com" loaded > (serial 199807200) > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:25.41 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-ZONEINFO, secondary zone "80.195.in-addr.arpa" > loaded (serial 16) > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:25.71 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-ZONEINFO, primary zone "0.0.127.in-addr.arpa" loaded > (serial 199711040) > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:26.48 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-ZONEINFO, cache zone "" loaded (serial 0) > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:26.53 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-MAIN, Ready to answer queries. > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:28.25 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-SUBPROC, created process 0000F6F4 to transfer zone > 80.195.in-addr.arpa > %SYSTEM-F-TIMEOUT, device timeout > %%%%%%%%%%%% NAMED 20-JUL-1998 12:23:32.04 %%%%%%%%%%%% > %%TCPWARE_NAMED-I-TIMEOUT, zoneref: Masters for secondary zone > "80.195.in-addr.arpa" unreachable > > Why would the rev not be reachable but the named.hosts reachable? > Royal, There were problems with named and zone transfers in version 5.1-5 of TCPware. I'd recommend getting the following patch and see if it corrects the problem - http://vms.process.com/support/51_5/NAMED_V515P050.A regards Michael ------ =_NextPart_000_01BDB412.85367D96 Content-Type: application/octet-stream; name="NAMED_V515P050.A.url" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="NAMED_V515P050.A.url" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9aHR0cDovL3Ztcy5wcm9jZXNzLmNvbS9zdXBwb3J0LzUx XzUvTkFNRURfVjUxNVAwNTAuQQ0KAA== ------ =_NextPart_000_01BDB412.85367D96-- ================================================================================ Archive-Date: Wed, 22 Jul 1998 11:07:36 -0400 From: R_Frazier@transammonia.com (Royal E. Frazier, Jr.) Subject: Re: secondary fails to update rev but does update hosts. Date: Wed, 22 Jul 1998 15:01:26 GMT Message-ID: <35b5fb5d.412346476@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM Jeff Schreiber wrote: >R_Frazier@transammonia.com (Royal E. Frazier, Jr.) writes: >> >>Despite setting a 20 minute retry...it seems to retry every fifteen... > > I'd need to see your bootfile for sure, but the file you showed seems > to be the file for the localhost domain, rather than the > 80.195.in-addr.arpa domain. I use $includes a lot. My actual hosts and reverse entries are generated out of my network database. This allows me to create a basic text files from another app and drop the text file into the TCPWARE.NAMED directory and restart. Server: NAMED.BOOT ; Data file to boot a primary name server. ; ; directory where all the data files are stored directory TCPWARE_ROOT:[TCPWARE.NAMED] ; ; type domain source host/file primary transammonia.com. NAMED.HOSTS ; primary 40.80.195.in-addr.arpa. NAMED.REV ; primary 0.0.127.in-addr.arpa. NAMED.LOCAL ; ; load the cache data last cache . NAMED.CA Server: NAMED.LOCAL ; @(#)named.local (VMS) 11/1/89 ; ; Data file for local loopback interface. ; (Uncomment ;; and modify) ; $include named.soa Server: NAMED.SOA ; @(#)named.soa (VMS) 11/1/89 ; ; Data file for local loopback interface. ; (Uncomment ;; and modify) ; @ IN SOA srv01.transammonia.com. frazier.obiwan.transammonia.com. ( 199807200 ; Serial 3600 ; Refresh 600 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS srv01.transammonia.com. Server: NAMED.SOA ; @(#)named.hosts (VMS) 2/27/96 ; $include named.soa ; localhost IN A 127.0.0.1 ; ;srv01 IN A 195.80.30.3 $include named.txt $include nameddhcp.txt Server: NAMED.REV ; @(#) named.rev (VMS) 2/27/96 ; (Uncomment ;; and modify) ; $include named.soa ; ; This document is outputted from NCPLISTS.XLS ; any direct modifications to it will be regularly overwritten ; $include namedrev.txt $include namedrevdhcp.txt ====================== Now the Secondary's files: (195.80.30.3 is the server above) Secondary: NAMED.BOOT ; Data file to boot a secondary name server. ; ; directory where all the data files are stored directory TCPWARE_ROOT:[TCPWARE.NAMED] ; ; type domain source host/file secondary transammonia.com 195.80.30.3 NAMED.HOSTS ; secondary 80.195.in-addr.arpa 195.80.30.3 NAMED.REV ; primary 0.0.127.in-addr.arpa NAMED.LOCAL ; ; load the cache data last cache . NAMED.CA Secondary: NAMED.LOCAL ; @(#)named.local (VMS) 11/1/89 ; ; Data file for local loopback interface. ; (Uncomment ;; and modify) ; @ IN SOA srv01.transammonia.com. frazier.obiwan.transammonia.com. ( 199711040 ; Serial 3600 ; Refresh 1200 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS srv01.transammonia.com. 1 IN PTR localhost Secondary: NAMED.HOSTS looks like.... ; zone 'transammonia.com' last serial 199712020 ; from 195.80.30.3 at Mon Jul 20 12:00:59 1998 $ORIGIN com. transammonia IN SOA srv01.transammonia.com. frazier.obiwan.transammo nia.com. ( 199807200 3600 600 3600000 86400 ) IN NS srv01.transammonia.com. $ORIGIN transammonia.com. with lots of entries following... Secondary: NAMED.REV looks like.... ; zone '80.195.in-addr.arpa' last serial 15 ; from 195.80.20.4 at Wed Oct 1 12:20:24 1997 $ORIGIN 195.in-addr.arpa. 80 IN SOA tampa.transammonia.com. frazier.tampa.transammon ia.com. ( 16 3600 600 3600000 86400 ) IN NS tampa.transammonia.com. $ORIGIN 6.80.195.in-addr.arpa. followed by lots of entries... (195.80.20.4)TAMPA.TRansammonia.com hasn't existed for 7 months. I know this is the problem, but I don'tsee where I'm directing it to T20.4/Tampa?!? ================================================================================ Archive-Date: Wed, 22 Jul 1998 12:01:06 -0400 From: R_Frazier@transammonia.com (Royal E. Frazier, Jr.) Subject: Re: secondary fails to update rev but does update hosts. Date: Wed, 22 Jul 1998 15:57:08 GMT Message-ID: <35b60b64.416450647@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM I must have looked at this ten times and only after I posted it and read it on line did I see the obvious error... R_Frazier@transammonia.com (Royal E. Frazier, Jr.) wrote: >Server: NAMED.BOOT >; Data file to boot a primary name server. >; >; directory where all the data files are stored >directory TCPWARE_ROOT:[TCPWARE.NAMED] >; >; type domain source host/file >primary transammonia.com. NAMED.HOSTS >; >primary 40.80.195.in-addr.arpa. NAMED.REV should be 80.195.in-addr.arpa. I have no idea where the 40 came form since that is not seven this server's subnet. ================================================================================ Archive-Date: Wed, 22 Jul 1998 12:05:57 -0400 Sender: schreiber@process.com Date: Wed, 22 Jul 1998 12:05:48 -0400 From: Jeff Schreiber Reply-To: Info-TCPware@process.com To: Info-TCPware@process.com CC: schreiber@process.com Message-ID: <009C98F1.8704DF36.54@process.com> Subject: Re: secondary fails to update rev but does update hosts. R_Frazier@transammonia.com (Royal E. Frazier, Jr.) writes: > [...] >primary 40.80.195.in-addr.arpa. NAMED.REV [...] >Now the Secondary's files: (195.80.30.3 is the server above) [...] >secondary 80.195.in-addr.arpa 195.80.30.3 NAMED.REV [...] >Secondary: NAMED.REV looks like.... >; zone '80.195.in-addr.arpa' last serial 15 >; from 195.80.20.4 at Wed Oct 1 12:20:24 1997 [...] > > (195.80.20.4)TAMPA.TRansammonia.com hasn't existed for 7 months. > >I know this is the problem, but I don'tsee where I'm directing it to >T20.4/Tampa?!? Looking at the transfer date in the Named.Rev file, that file is 9 months old, which would put it back to when tampa was around. I'm guessing this server was originally secondary to tampa for the 80.195.in-addr.arpa zone and what your looking at is the last time you had a successful zone transfer from 'tampa'. The problem is that your secondary is configured to be secondary for the 80.195.in-addr.arpa domain, and it's pointing to your primary, but your primary _isn't_ authoritive for 80.195.in-addr.arpa... it's authoritive for 40.80.195.in-addr.arpa. So your secondary is trying to transfer a zone from your primary that your primary isn't authoritative for. - Jeff ================================================================================ Archive-Date: Fri, 24 Jul 1998 17:10:44 -0400 Sender: goatley@triton.process.com Return-Path: From: R_Frazier@transammonia.com (Royal E. Frazier, Jr.) Subject: DHCP Identifier??: 01 52 41 53 20 40 F8 9C 60 46 *.RAS @ø.`F* Date: Fri, 24 Jul 1998 20:52:04 GMT Message-ID: <35b8f2df.18496634@nntp.ix.netcom.com> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm having trouble figuring out what devices our requesting certain DHCP licenses. In the example below there are a number that are represented by a 17-byte signature beginning with =22.RAS =40=22. Is this supposed to be meaningful. At first I though it was related to NT RAS services, but now I don't it, since this location has no NT boxes. Is this a sign of an aborted offering? the manuals give no clue (alow I'm still using 5.0 manual for 5.2-3. NETCU> sh dhcp TCPware(R) for OpenVMS DHCP Address Leases Address Expires Client Address/Identifier ------- ------- ------------------------- 195.80.50.122 01 52 41 53 20 40 F8 9C 60 46 *.RAS =40=F8.=60F* B5 BD 01 01 00 00 00 *=B5=BD.....* 195.80.50.123 01 AA 00 04 00 A7 04 *.=AA...=A7.* 195.80.50.124 01 AA 00 04 00 9A 04 *.=AA.....* 195.80.50.125 01 AA 00 04 00 29 07 *.=AA...).* 195.80.50.126 01 00 A0 24 63 C0 48 *.. =24c=C0H* 195.80.50.127 01 52 41 53 20 70 88 34 A4 D9 *.RAS p.4 =D9* 95 BD 01 01 00 00 00 *.=BD.....* 195.80.50.128 01 52 41 53 20 E0 55 BE 0C 5A *.RAS =E0U .Z* 31 BD 01 01 00 00 00 *1=BD.....* Royal Frazier ================================================================================ Archive-Date: Wed, 29 Jul 1998 09:24:15 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE860D32A9@lespaul.process.com> From: Mike Corbett Reply-To: Info-TCPware@process.com To: "'Info-TCPware@process.com'" Subject: =?iso-8859-1?Q?RE=3A_DHCP_Identifier=3F=3F=3A_01_52_41_53_20_4?= =?iso-8859-1?Q?0_F8_9C_60_46_=2A=2ERAS_=40=F8=2E=60F=2A?= Date: Wed, 29 Jul 1998 09:28:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=20 > I'm having trouble figuring out what devices our requesting certain > DHCP licenses. In the example below there are a number that are > represented by a 17-byte signature beginning with ".RAS @". Is this > supposed to be meaningful. At first I though it was related to NT RAS > services, but now I don't it, since this location has no NT boxes. Is > this a sign of an aborted offering? the manuals give no clue (alow = I'm > still using 5.0 manual for 5.2-3. >=20 > NETCU> sh dhcp > TCPware(R) for OpenVMS DHCP Address Leases >=20 > Address Expires Client Address/Identifier > ------- ------- ------------------------- > 195.80.50.122 01 52 41 53 20 40 F8 9C 60 46 *.RAS @=F8.`F* > B5 BD 01 01 00 00 00 *=B5=BD.....* > 195.80.50.123 01 AA 00 04 00 A7 04 *.=AA...=A7.* > 195.80.50.124 01 AA 00 04 00 9A 04 *.=AA.....* > 195.80.50.125 01 AA 00 04 00 29 07 *.=AA...).* > 195.80.50.126 01 00 A0 24 63 C0 48 *.. $c=C0H* > 195.80.50.127 01 52 41 53 20 70 88 34 A4 D9 *.RAS p.4 =D9* > 95 BD 01 01 00 00 00 *.=BD.....* > 195.80.50.128 01 52 41 53 20 E0 55 BE 0C 5A *.RAS =E0U .Z* > 31 BD 01 01 00 00 00 *1=BD.....* > Royal, The CLIENT ID is sent by the client in the DHCP request. Here is the relevant section from RFC1533 - 9.12. Client-identifier This option is used by DHCP clients to specify their unique identifier. DHCP servers use this value to index their database of address bindings. This value is expected to be unique for all clients in an administrative domain. Identifiers consist of a type-value pair, similar to the It is expected that this field will typically contain a hardware = type and hardware address, but this is not required. Current legal = values for hardware types are defined in [22]. The code for this option is 61, and its minimum length is 2. Code Len Type Client-Identifier=20 +-----+-----+-----+-----+-----+--- | 61 | n | t1 | i1 | i2 | ...=20 +-----+-----+-----+-----+-----+--- regards Michael ================================================================================ Archive-Date: Fri, 31 Jul 1998 15:18:49 -0400 Sender: goatley@triton.process.com Return-Path: From: mwd$1001@leica.co.uk (Mike Wilmot-Dear) Reply-To: Info-TCPware@process.com Subject: Re: DHCP Identifier??: 01 52 41 53 20 40 F8 9C 60 46 *.RAS @ø.`F* Message-ID: Sender: mwd$1001@leica.co.uk Date: Fri, 31 Jul 1998 14:58:30 GMT To: Info-TCPware@PROCESS.COM Royal E. Frazier, Jr. (R_Frazier@transammonia.com) wrote: > I'm having trouble figuring out what devices our requesting certain > DHCP licenses. In the example below there are a number that are > represented by a 17-byte signature beginning with ".RAS @". Is this > supposed to be meaningful. At first I though it was related to NT RAS That is certainly the form of client ID I've seen from NT RAS boxes requesting ID's for dialup clients. (I don't know whether the ID is generated by the RAS server or comes from the remote client). > services, but now I don't it, since this location has no NT boxes. Is Well it's possible that other things may provide support for NT RAS clients and request using ID's of this form. Possible candidates would be things like Access Servers (Cisco's Annexxes etc.) or maybe some routers (Also it's possible that Win95 dialup stuff may do something similar although I've never played with it so don't know). I guess the other possibility is that somebody sneaked in an NT box whilst you weren't loooking. ;-) Cheers, Mike -- +*I'm not paid to make official comments for Leica, so the above isn't one.*+ Mike Wilmot-Dear (MW342)