Archive-Date: Mon, 5 Jan 1998 09:03:40 -0400 From: "Peter Burnett" Reply-To: Info-TCPware@process.com Subject: Lan Manager Interface Date: Mon, 5 Jan 1998 13:59:12 -0000 Message-ID: <884008664.19691.0.nnrp-03.c1c3d261@news.demon.co.uk> To: Info-TCPware@PROCESS.COM We have a 4 node VAX cluster 1 off Vax 4100-100, 1 off VAX 4100-106a and 2 off 4000-200 machines with the nodes running OpenVMS 6.1 with TCPWare 5.1-4 installed. What we would like to be able to is export the DSSI disk farm (about 34GB shared across about 12 disks) we have to systems running NT, Win95 and Win31. On the NT and 95 based platforms, we want to be able to support Long Filenames. The best way I think (but correct me if I am wrong) is to use a Lan Manager protocol hosted on the nodes themselves. I have had a brief flirtation with the freeware SAMBA server, sort of works, other problems are involved, user id's on the 95/NT/31 platforms are different to that on the VAXen etc etc. We did have Pathworks here but our experiences with that have been so bad in the past and my predecesser could not get any of it to work reliably.. Currently, we export all the disks as NFS volumes to a NFS<>Novell Netware gateway but this has permission problems that we seem not to be able to resolve (2 files in the same directory, one can be eddited, the other not) and also does not support long filenames when Win95 and NT is involved. These disks when exported as NFS to a Sun/Solaris based system does seem to work all OK so the weak link seems to be the NFS<>Netware conversion, this bit of the chain we would like to replace. What I would like to know is that amoungst you collective geniuses, do you know of any products, commercial or otherwise that either (a) will make my vax disks look like Netware server disks or (b) will make my vax disks look like a MS Workgroup etc or even (c) both a and b. If any commercial vendors are out there reading this, feel free to contact me (initialty via email) with your offerings. All suggestions for products or any other ways of doing this from the group are welcomed. ================================================================================ Archive-Date: Tue, 6 Jan 1998 13:20:40 -0400 From: "Paul Roberts" Reply-To: Info-TCPware@process.com Subject: Application doesn't recognise NTY devices Date: Tue, 6 Jan 1998 18:11:51 -0000 Message-ID: <884110312.4553.0.nnrp-07.c29f9d9a@news.demon.co.uk> To: Info-TCPware@PROCESS.COM I vaguely remember hearing about some special "feature" that allowed NTY devices to appear as LTA devices to applications that didn't recognise NTY devices, but I can't remember if it was Multinet or TCPware, or even if it was related to NTY devices. Does anyone in the Multinet or TCPware camp recognise this facility? One of our customers has a third party application that runs fine over LAT and TXA devices but not NTY. He gets an "invalid terminal device" message when he tries to run it over an NTY so I am wondering if we can use a fake LAT device to fool the app into working. Any ideas? Paul -- Paul Roberts, Internet & Intranet Solutions Ltd., e-mail: spam-filter@intranet-solutions.com Replace spam-filter with paul.roberts to reply. Antispam address for local postmaster: postmaster@localhost ================================================================================ Archive-Date: Thu, 8 Jan 1998 10:24:52 -0400 From: "Al Batsman" Reply-To: Info-TCPware@process.com Subject: DNS - NT vs. VMS Date: Thu, 8 Jan 1998 15:16:08 -0000 Message-ID: <692qm6$4db$1@plutonium.btinternet.com> To: Info-TCPware@PROCESS.COM I am currently running DNS on two Vax servers (VMS 5.5). We currently have several NT4 Servers and are in the process of installing NT4 Workstation to all the users desks. I was wondering whether it is worth my while moving DNS away from VMS and onto the NT4 Servers? Has anyone got any opinions/information on the benefits of using either NOS for DNS? Any help will be grateful, Cheers, Dan Barry Comms Analyst ================================================================================ Archive-Date: Thu, 8 Jan 1998 16:52:59 -0400 Message-ID: <34B54A23.69A0@cableinet.co.uk> Date: Thu, 08 Jan 1998 21:50:27 +0000 From: Tim Llewellyn Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Subject: Re: DNS - NT vs. VMS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Al Batsman wrote: > > I am currently running DNS on two Vax servers (VMS 5.5). > > We currently have several NT4 Servers and are in the process of installing > NT4 Workstation to all the users desks. > > I was wondering whether it is worth my while moving DNS away from VMS and > onto the NT4 Servers? > > Has anyone got any opinions/information on the benefits of using either NOS > for DNS? > > Any help will be grateful, > Whatever you do, just say NO to DHCP, expecially if you are using X-Windows on the PC's. HTH -- Tim Llewellyn at home trying out cableinet. Yes, I am also tim.llewellyn at bbc.co.uk and tjl at siva.bris.ac.uk. Standard disclaimer applies. My views in no way represent those of my employers or service provider. ================================================================================ Archive-Date: Fri, 9 Jan 1998 06:19:10 -0400 From: "Bernhard Fabricius" Reply-To: Info-TCPware@process.com Subject: Re: DNS - NT vs. VMS Date: 9 Jan 1998 11:07:00 GMT Message-ID: <01bd1cee$a7cd84a0$79811aac@bfpc.dmu.dk> To: Info-TCPware@PROCESS.COM Warning: People with weak hearts should read no further, or at least have a replacemnet battery for their pacemakers handy: I'm about to say something in favour of NT! > Al Batsman wrote: > > Has anyone got any opinions/information on the benefits of using either NOS > > [NT or VMS] for DNS? Tim Llewellyn replied: > Whatever you do, just say NO to DHCP, expecially if you are using > X-Windows > on the PC's. No. Not true. The DNS server under Windows NT 4 (with SP 3 and "DNS-FIX") does an excellent job in integrating DNS and DHCP-supplied addresses via the WINS and WINS-R additions to the NT-DNS server. It works like a charm (as long as your NetBEUI names are unique, as they should be anyway). We run NT-DNS here in a LARGE orginistaion with MANY domains and SCORES of DHCP scopes. The graphical interface to NT-DNS is superb. Eg, when adding an A-record, you have the option of automatic addition of the PTR record in the reverse zone. (You CAN hand-edit the files too if you like). The original NT-DNS, which was a simple re-compile of the PD source code, was a major disaster. Someone in Microsoft then rewrote the entire code in an NT context, and the result is outstanding. The DNS server does not put any significant load on the hosting NT server - in fact we have WINS, DHCP, DNS and InterCheck services running on our 83 MHz/32 MB PDC, and even when a bug in SGI's unspeakable IRIX software made an Octane make 1.500.000 DNS (1˝ million!) request per hour, the services continued to work. Replies were given. Users noted nothing.. OK, the the file-manager was sloppy, but the box didn't crash! So, one up for NT for once! Cheers Bear™ ================================================================================ Archive-Date: Sat, 10 Jan 1998 09:07:08 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: Re: DNS - NT vs. VMS Date: 10 Jan 98 14:01:18 GMT Message-ID: <34b77f2e.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <01bd1cee$a7cd84a0$79811aac@bfpc.dmu.dk>, "Bernhard Fabricius" writes: >Warning: People with weak hearts should read no further, or at least have a >replacemnet battery for their pacemakers handy: I'm about to say something >in favour of NT! Are you sure, you understood the situation ? >> Al Batsman wrote: >> > Has anyone got any opinions/information on the benefits of using either >NOS >> > [NT or VMS] for DNS? > > Tim Llewellyn replied: >> Whatever you do, just say NO to DHCP, expecially if you are using >> X-Windows >> on the PC's. > >No. Not true. The DNS server under Windows NT 4 (with SP 3 and "DNS-FIX") >does an excellent job in integrating DNS and DHCP-supplied addresses via >the WINS and WINS-R additions to the NT-DNS server. Excellent job ? A non-WINS BIND/DNS server (as U**X, OpenVMS, ... DNS Servers are) cannot do zone-transfer DHCP names/address from the NT DNS server. And a WINS capable BIND/DNS Server (can't do it either) do the DHCP resolution on its own. So, a U**X or OpenVMS BIND/DNS server cannot resolve a request for a DHCP name (except you find a proprietary software, which could do this, but only if DHCP server and BIND/DNS server is on the same machine. And then you still have the problems with the secondary nameservers...) So, a U**X or OpenVMS system (or do you need X11 on a NT platform) which want to send the display to a DHCP system must contact a WINS (one of the above mentioned proprietary solutions) capable BIND/DNS server. So, DHCP forces you to use NT BIND/DNS Servers and NT DHCP Servers only. >It works like a charm (as long as your NetBEUI names are unique, as they >should be anyway). We run NT-DNS here in a LARGE orginistaion with MANY >domains and SCORES of DHCP scopes. The graphical interface to NT-DNS is >superb. Eg, when adding an A-record, you have the option of automatic >addition of the PTR record in the reverse zone. (You CAN hand-edit the >files too if you like). And you SHOULD do it. If you don't, you can't control the version number. The M$ DNS server change it (or even worse don't change it) what it likes, and not when you wants to do it... The version number is important to detect, if a zone transfer is required. >The original NT-DNS, which was a simple re-compile of the PD source code, >was a major disaster. Someone in Microsoft then rewrote the entire code in >an NT context, and the result is outstanding. What is outstanding? If you mean zone transfer requests of the M$ DNS Server over a Dial-On-Demand Connection to the primary BIND/DNS Server almost never go through (and therefore a ZONE transfer request is never completed), then this matches our observations... We had to replace the M$ NT BIND/DNS Server Software by another product, which was also crap (this seems usual on PCs) but at least was faster fixed... >The DNS server does not put any significant load on the hosting NT server - >in fact we have WINS, DHCP, DNS and InterCheck services running on our 83 >MHz/32 MB PDC, and even when a bug in SGI's unspeakable IRIX software made >an Octane make 1.500.000 DNS (1˝ million!) request per hour, the services >continued to work. Replies were given. Users noted nothing.. OK, the the >file-manager was sloppy, but the box didn't crash! > >So, one up for NT for once! But not for M$ in our case... ------------------------------------------------------------------------ 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: Wed, 14 Jan 1998 22:49:55 -0400 From: Allen Sparks Subject: Services in TCPWARE Date: Wed, 14 Jan 1998 18:37:19 -0900 Message-ID: <34BD846F.6B3D@yahoo.com> Reply-To: Info-TCPware@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM I've got documentation from someone who is running a program he's trying to port from DECNet to TCP/IP. One of the things you have to do to configure this program for TCP/IP is, place an entry in the services file (I fouund that no problem). The documentation for this product give instructions on what changes are made to Wollongong TCP/IP software. The addtional file that is mentioned is called "SERVERS.DAT", and it has entries in it that give an executable path of the program, socket-type, etc. From what I can gather, the "SERVERS.DAT" file has entries that are pointed to by the "SERVICES." file by service name. "SERVERS.DAT" may be the equivalent of a standard unix "inetd.conf" file. Does TCPWARE have something equivalent? Anyone out there knowledgable with both TCPWARE and Wollongong that may be able to give me hints? I run TCPWARE Version 5.2 on OpenVMS 6.1. === Al ================================================================================ Archive-Date: Thu, 15 Jan 1998 09:13:36 -0400 Message-ID: <34BE18A9.356D0AD8@process.com> Date: Thu, 15 Jan 1998 09:09:45 -0500 From: Michael Corbett Reply-To: Info-TCPware@process.com MIME-Version: 1.0 To: Info-TCPware@process.com Subject: Re: Services in TCPWARE References: <34BD846F.6B3D@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Allen Sparks wrote: > > I've got documentation from someone who is running a program he's > trying to port from DECNet to TCP/IP. One of the things you have to > do to configure this program for TCP/IP is, place an entry in the > services file (I fouund that no problem). The documentation for this > product give instructions on what changes are made to Wollongong TCP/IP > software. > > The addtional file that is mentioned is called "SERVERS.DAT", and it has > entries in it that give an executable path of the program, socket-type, > etc. > > >From what I can gather, the "SERVERS.DAT" file has entries that are > pointed to by the "SERVICES." file by service name. > > "SERVERS.DAT" may be the equivalent of a standard unix "inetd.conf" > file. Does TCPWARE have something equivalent? > With TCPware you add services with the NETCU ADD SERVICE command. To have the services added every time TCPware is started you can add the commands to the TCPWARE:SERVERS.COM file. regards Michael -- +-----------------------------------------------------------------+ 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: Thu, 15 Jan 1998 09:13:44 -0400 Date: Thu, 15 Jan 1998 09:11 -0500 From: BRYANT@PROCESS.COM (Geoff Bryant) Reply-To: Info-TCPware@process.com Message-ID: <009C051DFAE0F980.08B2@PROCESS.COM> To: Info-TCPware@process.com Subject: RE: Services in TCPWARE Allen Sparks writes: > >I've got documentation from someone who is running a program he's >trying to port from DECNet to TCP/IP. One of the things you have to >do to configure this program for TCP/IP is, place an entry in the >services file (I fouund that no problem). The documentation for this >product give instructions on what changes are made to Wollongong TCP/IP >software. > >The addtional file that is mentioned is called "SERVERS.DAT", and it has >entries in it that give an executable path of the program, socket-type, >etc. > >From what I can gather, the "SERVERS.DAT" file has entries that are >pointed to by the "SERVICES." file by service name. > >"SERVERS.DAT" may be the equivalent of a standard unix "inetd.conf" >file. Does TCPWARE have something equivalent? > >Anyone out there knowledgable with both TCPWARE and Wollongong that may >be able to give me hints? > >I run TCPWARE Version 5.2 on OpenVMS 6.1. > === Al You can edit/create a file in the TCPWARE: driectory called SERVERS.COM which will be executed by the TCPware startup procedure to add customer services. You simply place your NETCU ADD SERVICE commands into the SERVERS.COM file. Check the documentation on the NETCU ADD SERVICE command for full info on what you need there. It depends a bit on what API the program was written against. The SERVICES. is for providing info that programs can read with the getservbyx routines. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Fri, 23 Jan 1998 08:53:54 -0400 Subject: DDNS Message-ID: <34C8A0DF.7DB1@process.com> From: James Gildea Reply-To: Info-TCPware@process.com Date: Fri, 23 Jan 1998 08:53:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Info-TCPware@PROCESS.COM Lately I've been getting some requests to add Dynamic DNS to TCPware. I've been trying to assess the actual user demand for DDNS on OpenVMS. Would any readers of this group deploy a TCPware-based DDNS server, along with a modified TCPware DHCP server? In other words, is there enough interest among users for this enhancement? Comments back to this newsgroup or to me directly (gildea@process.com) will be appreciated. Jim Gildea Product Marketing Manager Process Software Corp. ================================================================================ Archive-Date: Sun, 25 Jan 1998 18:40:20 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: Re: DDNS Date: 25 Jan 98 23:32:36 GMT Message-ID: <34cbcb94.0@nevada.kapsch.co.at> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <34C8A0DF.7DB1@process.com>, James Gildea writes: >Lately I've been getting some requests to add Dynamic DNS to TCPware. >I've been trying to assess the actual user demand for DDNS on OpenVMS. >Would any readers of this group deploy a TCPware-based DDNS server, >along with a modified TCPware DHCP server? In other words, is there >enough interest among users for this enhancement? > >Comments back to this newsgroup or to me directly (gildea@process.com) >will be appreciated. For us, it is years too late. M$ won the rat race. It is not a problem of coupling DNS and DHCP alone. It is also a problem of replicate a DHCP Config for an area via a DHCP server in another area (one server per area). Is TCPware finally able to support this ? And WINS is then the next problem... I'd be lucky, if I had a choice. But our managers are narrow (aka M$) minded. Fight M$ and try it. Good luck ------------------------------------------------------------------------ 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: Mon, 26 Jan 1998 13:51:11 -0400 From: "Paul Roberts" Reply-To: Info-TCPware@process.com Subject: Re: DDNS Date: Mon, 26 Jan 1998 18:42:46 -0000 Message-ID: <885840168.9920.0.nnrp-07.c29f9d9a@news.demon.co.uk> To: Info-TCPware@PROCESS.COM >It is not a problem of coupling DNS and DHCP alone. It is also a problem >of replicate a DHCP Config for an area via a DHCP server in another area >(one server per area). Is TCPware finally able to support this ? If you are talking about over-lapping scopes to provide redundancy and resilience, there are two internet drafts which discuss different ways of doing this. >And WINS is then the next problem... Forget WINS. It won't be needed if you use DDNS, and Microsoft are ditching it in NT5 anyway. Paul Roberts, Internet & Intranet Solutions Ltd., e-mail: spam-filter@intranet-solutions.com Replace spam-filter with paul.roberts to reply. Antispam address for local postmaster: postmaster@localhost ================================================================================ Archive-Date: Mon, 26 Jan 1998 14:35:31 -0400 From: eplan@kapsch.co.at (Peter LANGSTOEGER) Subject: Re: DDNS Date: 26 Jan 1998 19:30:05 GMT Message-ID: <6aio7t$hf0$1@news.Austria.EU.net> Reply-To: Info-TCPware@process.com To: Info-TCPware@PROCESS.COM In article <885840168.9920.0.nnrp-07.c29f9d9a@news.demon.co.uk>, "Paul Roberts" writes: >>It is not a problem of coupling DNS and DHCP alone. It is also a problem >>of replicate a DHCP Config for an area via a DHCP server in another area >>(one server per area). Is TCPware finally able to support this ? > > >If you are talking about over-lapping scopes to provide redundancy and >resilience, there are two internet drafts which discuss different ways of >doing this. I was talking about replication and IP-HELPER-ADDRESS in a CISCO router. I don't know how M$ solved the problem but apparently they did. When the RFCs are complete, then there is a "standard" solution (which I prefer) but what was the situation say two years ago ? If PC clients, then M$ WINS/DNS/DHCP... And how could you avoid PC clients ? >>And WINS is then the next problem... > >Forget WINS. It won't be needed if you use DDNS, and Microsoft are ditching >it in NT5 anyway. Yes, I heard/read this, too. But we are still WFW and W95 (migrating to NT4 and W95 for over a year now)... NT5 is years away (at least for us). btw: all OpenVMS upgrade at our site has been solved in a couple of days/weeks. Mass management is still a problem with these Personal Crap. With over 1500 PCs and upgrading 2-4 PCs per day the WINS problem will stay here for some more time. Even M$ couldn't believe that WFW will live so long. (But we must be finished before 2000, since WFW is not Y2K compliant). 'nuff said ------------------------------------------------------------------------ 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: Sat, 31 Jan 1998 17:00:40 -0400 From: "Veli Körkkö" Reply-To: Info-TCPware@process.com Subject: Interoparability of UCX FTP and TCPware FTP Date: Wed, 28 Jan 1998 13:41:34 +0200 Message-ID: <6an675$r7c$1@hiisi.inet.fi> To: Info-TCPware@PROCESS.COM Observed on my customer system: System1: OpenVMS V7.1 Alpha, UCX V4.1 ECO 8 System2: OpenVMS V6.1 Alpha, TCPware V5.1-4 When doing FTP GET, the FTP client on the UCX system hangs at the next operation if VMSplus mode is enabled between UCX FTP client and TCPware FTP server. UCXsystem$ FTP/USER=xxx/pass=xx tcpwaresystem FTP> get xx.xx FTP> QUIT ! and here we stay until I press control-Y UCXsystem$ FTP/USER=xxx/pass=xx tcpwaresystem FTP> disable vms FTP> get xx.xx FTP> quit !works just fine The UCX system has latest DEC ECO. I did these tests also against TCpware V5.2 system and same behaviour. Originally the UCX version was V4.1 base btw. Below is trace using UCX $TCPIPTRACE from both cases showing packets exchanged at the moment of QUIT command. _veli ---------------------------------------------------------------------------- ---- TCPIPtrace XMT packet 72 at 27-JAN-1998 15:37:29.92 IP Address Port Seq # Ack # Source 157.129.160.12 1114 72128101 257957067 Destination 193.64.26.4 21 Packet Length 46 TCP flags PSH ACK window 4096 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 0CA0819D 7FA80680 00007879 2E000045 0000 E...yx.......... CB1C600F 65964C04 15005A04 | 041A40C1 0010 .@...Z...L.e.`.. 0A0D 54495551 | 0000F513 00101850 0020 P.......QUIT.. ---------------------------------------------------------------------------- ---- TCPIPtrace RCV packet 73 at 27-JAN-1998 15:37:30.12 IP Address Port Seq # Ack # Source 193.64.26.4 21 257957067 72128107 Destination 157.129.160.12 1114 Packet Length 40 TCP flags ACK window 24570 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 041A40C1 05E80637 0040F842 28000045 0000 E..(B.@.7....@.. 6B964C04 CB1C600F 5A041500 | 0CA0819D 0010 .......Z.`...L.k 0000 00000000 | 0000B66B FA5F1050 0020 P._.k......... ----------- Above QUIT and after that hanging. Below QUIT and normal completion when VMSplus disabled. ----------- ---------------------------------------------------------------------------- ---- TCPIPtrace XMT packet 89 at 27-JAN-1998 15:38:45.95 IP Address Port Seq # Ack # Source 157.129.160.12 1116 81152104 279763389 Destination 193.64.26.4 21 Packet Length 46 TCP flags PSH ACK window 4096 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 0CA0819D 40A80680 0000B779 2E000045 0000 E...y......@.... BDD9AC10 6848D604 15005C04 | 041A40C1 0010 .@...\....Hh.... 0A0D 54495551 | 000027A3 00101850 0020 P....'..QUIT.. ---------------------------------------------------------------------------- ---- TCPIPtrace RCV packet 90 at 27-JAN-1998 15:38:45.98 IP Address Port Seq # Ack # Source 193.64.26.4 21 279763389 81152110 Destination 157.129.160.12 1116 Packet Length 73 TCP flags PSH ACK window 24576 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 041A40C1 E4CE0637 0040F85B 49000045 0000 E..I[.@.7....@.. 6E48D604 BDD9AC10 5C041500 | 0CA0819D 0010 .......\......Hn 76726553 20313232 | 0000730C 00601850 0020 P.`..s..221 Serv 6E6E6F63 20676E69 736F6C63 20656369 0030 ice closing conn 0A 0D2E6E6F 69746365 0040 ection... ---------------------------------------------------------------------------- ---- TCPIPtrace XMT packet 91 at 27-JAN-1998 15:38:45.98 IP Address Port Seq # Ack # Source 157.129.160.12 1116 81152110 279763422 Destination 193.64.26.4 21 Packet Length 40 TCP flags FIN ACK window 4096 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 0CA0819D 45A80680 0000B879 28000045 0000 E..(y......E.... DED9AC10 6E48D604 15005C04 | 041A40C1 0010 .@...\....Hn.... | 0000C14A 00101150 0020 P...J... ---------------------------------------------------------------------------- ---- TCPIPtrace RCV packet 93 at 27-JAN-1998 15:38:46.10 IP Address Port Seq # Ack # Source 193.64.26.4 21 279763422 81152111 Destination 157.129.160.12 1116 Packet Length 40 TCP flags FIN PSH ACK window 24576 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 041A40C1 05CE0637 0040F85C 28000045 0000 E..(\.@.7....@.. 6F48D604 DED9AC10 5C041500 | 0CA0819D 0010 .......\......Ho 0000 00000000 | 0000B7FA 00601950 0020 P.`........... ---------------------------------------------------------------------------- ---- TCPIPtrace XMT packet 94 at 27-JAN-1998 15:38:46.10 IP Address Port Seq # Ack # Source 157.129.160.12 1116 81152111 279763423 Destination 193.64.26.4 21 Packet Length 40 TCP flags ACK window 4096 Hex Count Ascii -------- -------- -------- -------- ---- ---------------- 0CA0819D 44A80680 0000B979 28000045 0000 E..(y......D.... DFD9AC10 6F48D604 15005C04 | 041A40C1 0010 .@...\....Ho.... | 0000C04A 00101050 0020 P...J...