Archive-Date: Tue, 1 Feb 2000 10:42:18 -0400 Date: Tue, 01 Feb 2000 10:35:32 -0500 From: "John Buzard" Reply-To: Info-MultiNet@process.com To: Subject: Steps from pathway to multinet MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII I finally am getting around to having time to replace my Attachmate Pathway software with Multinet 4.2. Does anyone have any tips on files that I could reuse or just general shortcuts to help me make this as painless as possible. I have been watching this email group and am a little worried about the number of issues that pop up with the Multinet product. I worry I might not get all the patches loaded and I might get a failure over something very minor. I will be putting this on an Alpha 2100, openvms 7.1-1h2. John Buzard Michael Baker Jr Inc 410 Rouser Rd Coraopolis, PA 15108 412-269-7132 email - jbuzard@mbakercorp.com ================================================================================ Archive-Date: Wed, 2 Feb 2000 10:29:10 -0400 Sender: goatley@triton.process.com Return-Path: Date: Tue, 1 Feb 2000 17:31:22 -0800 From: SEF@chives.jpl.nasa.gov Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: SEF@chives.jpl.nasa.gov Subject: UDP Packet Stats What is the best way to count the daily influx of UDP packets from a particular host? Thanks In Advance, Scott ================================================================================ Archive-Date: Wed, 2 Feb 2000 12:22:44 -0400 Date: Wed, 2 Feb 2000 11:18:28 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: SEF@CHIVES.JPL.NASA.GOV Subject: RE: UDP Packet Stats SEF@chives.jpl.nasa.gov writes: > >What is the best way to count the daily influx of UDP packets >from a particular host? > You can use MultiNet's packet filtering to get a count of UDP traffic (thanks, Geoff!). You basically would set up a filter that looked like this: permit udp 10.1.1.1 255.255.255.255 0 0 permit udp 0 0 0 0 permit icmp 0 0 0 0 permit tcp 0 0 0 0 where "10.1.1.1" is the host to watch. There is an implicit DENY at the end of the list, so if you set up filtering, you must add the additional "permit" lines to allow all other traffic in. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 2 Feb 2000 15:17:07 -0400 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Wed, 2 Feb 2000 15:16:34 -0400 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: LPDSMB-030_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: LPDSMB-030_A042 Description: Updated MultiNet LPD symbiont Release date: 2-FEB-2000 Versions: V4.2A, V4.1B, V4.1A, V4.0C ftp://ftp.multinet.process.com/patches/multinet042/lpdsmb-030_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- This kit updates MultiNet V4.0 Rev C through V4.2 Rev A with a new version of the LPD symbiont, which includes the following changes : - Fix the problem of symbiont process termination due to accvio. - When literal form feeds are encountered in the input file, these are no longer prefixed with a line feed in the output stream. This prevents the printing of superfluous blank pages which occured in some circumstances. The legacy behaviour of prefixing form feeds with line feeds can be invoked if needed by redefining the /system/exec logical MULTINET_NLPx_REMOTE_PRINTER to include the option "DOLFFF=Y". [D/E 926] - Adds debugging information that can be enabled by defining the following logical *before* starting the LPD queues: $ define/system/exec multinet_lpd_symbiont_debug true When the symbiont process is created with that logical defined, a log file will be created in MULTINET_SPOOL: for that symbiont. - Restores timer retries to queues that are not set up to allow user-specified printer destinations. For the other queues, jobs are requeued to be retried. The advantage to the timer retries is that the symbiont won't immediately try to print a job when the previous job failed because the printer was inaccessible. (D/E 393, 2201) The timer retry intervals can be controlled by the logical MULTINET_LPD_SYMBIONT_CONNECT_TIMERS. Its equivalence string should be two numbers, separated by a space, that specify the retry interval and maximum retry time in seconds. By default, the interval starts at 10 minutes; for each retry, that value is doubled to the maximum retry time, which defaults to 2 hours. The default would be represented by the following logical definition: $ define/system/exec MULTINET_LPD_SYMBIONT_CONNECT_TIMERS - "600 7200" - OPCOM messages from the LPD symbiont now include the queue name and entry number associated with the message. - OPCOM messages from the LPD symbiont can be disabled by defining the following logical: $ define/system/exec multinet_printer_no_opcom true It is not recommended that the OPCOM messages be disabled, as they may block legitimate problem messages, in addition to informational messages about trying connections. - Support has been added for the new MULTINET_LPD_MAXSTREAMS logical, allowing restriction of the number of queues handled per symbiont image without editing and compiling a new "User Exit". - Support has been added for socket keepalive timers. This can be enabled globally by defining the following logical : $ define/system/executive MULTINET_LPD_KEEPALIVE "Y" This can also be refined on a per-printer basis using the MULTINET_NLPx_REMOTE_PRINTER option "KEEPALIVE=Y" or "KEEPALIVE=N". If none of the above logicals is used, the symbiont will behave as in older versions, without keepalive timers enabled. [D/E 2705] - Support has been added for options which will enable the legacy behaviour of forcing a linefeed at the end of each print job, rather than the carriage return which is used by default in more recent product versions. This feature is useful for environments where continuous feed stock is being used in conjunction with /NOFEED options. Without this option, existing applications may exhibit output "creep" unless modified. To set this option as the global default, use the following command : $define/system/executive MULTINET_LPD_SYMBIONT_LFTAIL "Y" This can also be refined on a per-printer basis using the MULTINET_NLPx_REMOTE_PRINTER option "LFTAIL=Y" or "LFTAIL=N". [D/E 3525] - Previously, when the destination was specified by name rather than IP address, the lookup was being performed synchronously. When problems were encountered during the lookup, this would cause the queues being serviced by the symbiont instance to become busy. This functionality has been changed, and host name lookups are now performed asynchronously. Note that it is still advised to use a local caching nameserver. [D/E 2705] - Changed to support wildcard ("*") for the queue name with the RETAIN_CR configuration logical, i.e : $ define/executive/table=multinet_printer_table - $_ MULTINET_PRINTER_*_RETAIN_CR_DEFAULT "Y" [D/E 4903] To have these new images take effect, stop _all_ LPD and client queues on your system with STOP/QUEUE/RESET, then start them again with: @MULTINET:REMOTE-PRINTER-QUEUES You do not have to reboot after installing this kit. [End of ECO announcement] ================================================================================ Archive-Date: Wed, 2 Feb 2000 15:45:30 -0400 From: "Brian Tillman" Reply-To: Info-MultiNet@process.com Subject: Re: Steps from pathway to multinet Date: Wed, 2 Feb 2000 15:30:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" To: INFO-MULTINET@PROCESS.COM >I finally am getting around to having time to replace my Attachmate Pathway software with Multinet 4.2. I, too, am in the process of doing exactly this. Right now I have one node in the cluster running Multinet V4.2 and the other still running Pathway. I just read all the Multinet Admin docs and set up the configuration to match the Pathway configuration. I have some issues with Multinet and how it creates the START_MULTINET.COM file. In particular, I DON'T want it to translate my CONCEALED logical names down to the device level; I want it to honor the CONCEALED attribute. It still works. I know because I modified the server configuration program to not put the NO_CONCEAL attribute in the F$PARSE call for the installation device. That is, instead of: $ Directory = F$Parse(Startup_File1,,,"DEVICE","NO_CONCEAL") - + F$Parse(Startup_File1,,,"DIRECTORY","NO_CONCEAL") - "][" - "][" ... $ Define/System/Exec/NoLog MultiNet_Root 'Directory']/Tran=(CONC,TERM) $ Define/System/Exec/NoLog MultiNet_Specific_Root 'Directory']/Tran=(CONC,TERM) $ Define/System/Exec/NoLog MultiNet_Common_Root 'Directory']/Tran=(CONC,TERM) $ Goto LogDone $CommonDir: $ Define/System/Exec/NoLog MultiNet_Root 'Directory']/Tran=(CONC,TERM),MultiNet_Common_Root: $ Define/System/Exec/NoLog MultiNet_Specific_Root 'Directory']/Tran=(CONC,TERM) $ Define/System/Exec/NoLog MultiNet_Common_Root 'Directory'SYSCOMMON.]/Tran=(CONC,TERM) I now have: $ Directory = F$Parse(Startup_File1,,,"DEVICE") - + F$Parse(Startup_File1,,,"DIRECTORY","NO_CONCEAL") - "][" - "][" ... $ Define/System/Exec/NoLog MultiNet_Root 'Directory']/Tran=CONC $ Define/System/Exec/NoLog MultiNet_Specific_Root 'Directory']/Tran=CONC $ Define/System/Exec/NoLog MultiNet_Common_Root 'Directory']/Tran=CONC $ Goto LogDone $CommonDir: $ Define/System/Exec/NoLog MultiNet_Root 'Directory']/Tran=CONC,MultiNet_Common_Root: $ Define/System/Exec/NoLog MultiNet_Specific_Root 'Directory']/Tran=CONC $ Define/System/Exec/NoLog MultiNet_Common_Root 'Directory'SYSCOMMON.]/Tran=CONC Everything works perfectly and allows me to have the MULTINET* logicals defined in terms of my terminal, concealed disk logical names, instead of the physical device. This allows me the flexibility to move Multinet from one disk to another without changing anything. The one drawback is that, when I apply a patch, I have to extract KITINSTAL.COM, edit it to take out the ",TERM" on one of its DEFINE statements, and rebuild the kit with the modified KITINSTAL.COM before applying the patch. It would be nice if I didn't have to hack the distribution in this way, seeing how one CAN define one concealed logical name in terms of another with no ill effects. I also have some issues with when Multinet's FTP client tries to do its structure negotiation. Pathway's FTP client doesn't send the STRU O VMS until a login to the FTP server has occurred. Thus, it will negotiate even through a firewall. Multinet, on the other hand, sends the STRU O VMS prior to any USER command, so that the automatic structure negotiation gets thrown away for most FTP servers but its own. Pathway's FTP client, also, when prompting for the username, assumes the currect username as the default. Multinet has no default. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 2 Feb 2000 16:19:39 -0500 Date: Wed, 2 Feb 2000 15:15:21 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Steps from pathway to multinet "Brian Tillman" writes: > >It would be nice if I didn't have to hack the distribution in this way, >seeing how one CAN define one concealed logical name in terms of another >with no ill effects. > I'm not sure what the historical reasoning for this is, but we'll look into it. >I also have some issues with when Multinet's FTP client tries to do its >structure negotiation. Pathway's FTP client doesn't send the STRU O VMS >until a login to the FTP server has occurred. Thus, it will negotiate even >through a firewall. Multinet, on the other hand, sends the STRU O VMS prior >to any USER command, so that the automatic structure negotiation gets thrown >away for most FTP servers but its own. ??? It works OK with MultiNet, TCPware, CMU/IP, and MGFTP servers. They're the only ones that support STRU O VMS, so I'm not sure what you're saying (and Pathway, too, of course). FWIW, the MGFTP client also sends the STRU O VMS negotiation through before the login occurs. Having never dealt with a firewall, is it the firewall that throws away the STRU negotiation? I've never had a problem with the STRU O VMS command going out first. >Pathway's FTP client, also, when >prompting for the username, assumes the currect username as the default. >Multinet has no default. > Actually, it does if you have PROMPT-ON-CONNECT enabled, even though it doesn't show the default. If you just hit RETURN at the Username: prompt, it sends the current username: FTP>prompt-on-connect [Will automatically prompt for username and password] FTP>goat Connection opened (Assuming 8-bit connections) http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 2 Feb 2000 16:22:33 -0500 From: Javier Henderson Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 2 Feb 2000 13:18:15 -0800 (PST) To: Info-MultiNet@process.com Subject: Re: Steps from pathway to multinet References: <38989414@news.si.com> Brian Tillman writes: > Everything works perfectly and allows me to have the MULTINET* logicals > defined in terms of my terminal, concealed disk logical names, instead of > the physical device. This allows me the flexibility to move Multinet from > one disk to another without changing anything. The MULTINET logical names are created on the fly as you run START_MULTINET.COM, based on where that file is running from, so you can move the entire directory tree to another disk drive without having to change anything. Or maybe I'm missing something, or maybe Process changed the way things used to be. -jav ================================================================================ Archive-Date: Wed, 2 Feb 2000 16:30:47 -0500 Date: Wed, 02 Feb 2000 14:26:42 -0700 To: Info-MultiNet@process.com From: Jim Mehlhop Reply-To: Info-MultiNet@process.com Subject: Re: Steps from pathway to multinet References: <38989414@news.si.com> <38989414@news.si.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:18 PM 2/2/00 -0800, you wrote: >Brian Tillman writes: > > > Everything works perfectly and allows me to have the MULTINET* logicals > > defined in terms of my terminal, concealed disk logical names, instead of > > the physical device. This allows me the flexibility to move Multinet from > > one disk to another without changing anything. > > The MULTINET logical names are created on the fly as you run >START_MULTINET.COM, based on where that file is running from, so you >can move the entire directory tree to another disk drive without >having to change anything. > > Or maybe I'm missing something, or maybe Process changed >the way things used to be. Nope still works that way Jim >-jav ================================================================================ Archive-Date: Wed, 2 Feb 2000 16:45:59 -0500 Date: Wed, 2 Feb 2000 15:41:45 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Steps from pathway to multinet "Brian Tillman" writes: > >Everything works perfectly and allows me to have the MULTINET* logicals >defined in terms of my terminal, concealed disk logical names, instead of >the physical device. This allows me the flexibility to move Multinet from >one disk to another without changing anything. > As Javier pointed out, this is really a non-issue, other than what you see when you do SHOW LOG MULTINET*. By defining the logicals at startup time, no matter what disk MultiNet resides on, your logicals are OK, except for what you might see. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 4 Feb 2000 11:04:27 -0500 From: mdixon2@csc.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@Process.Com Date: Fri, 4 Feb 2000 10:47:20 -0500 Subject: Problem with RCP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have logged this with Process, but have yet to hear back on a cause (PSC Case # 78636) Perhaps you all can assist. I have a VAX running Multinet 4.1 Rev A on V 6.2 VMS with a handfull of patches about equivalent to REV B. I try to RCP to an Alpha UCX V 4.1 ECO 10 System and it fails. If I RCP to another MultiNet system all is OK If I RCP from Alpha UCX V 4.1 ECO 10 to MultiNet it works. If I RCP from another UCX to the first UCX box, that works (both V 4.1 different ECO's). Only RCP from MultiNet to UCX fails. Here is an example of the output, nodenames & usernames have been replaced with ### & XXX. The TCPDump looks like MultiNet is sending the command VMS_RCP to UCX and it chokes. I cannot figure out why and where this is really coming from. Any assistance would be appreciated Michael Dixon OpenVMS Systems Consultant On the MultiNet system: NDCVX1>> rcp login.com ndcal1::x.x/log/user=XXXXX %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling On the UCX system UCX creates the log file and displays an OPCOM message. NDCAL1>> %%%%%%%%%%% OPCOM 3-FEB-2000 16:39:56.53 %%%%%%%%%%% Message from user INTERnet on NDCAL1 INTERnet ACP RSH Accept Request from Host: ##.##.##.## Port: 1023 NDCAL1>> ty UCX$RSHD_STARTUP.LOG;1 %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling \VMS_RCP\ XXXXXX job terminated at 3-FEB-2000 16:39:56.76 Accounting information: Buffered I/O count: 30 Peak working set size: 1632 Direct I/O count: 5 Peak page file size: 38512 Page faults: 168 Mounted volumes: 0 Charged CPU time: 0 00:00:00.11 Elapsed time: 0 00:00:00.24 And a TCP DUMP during this exchange... NDCVX1>> mu tcpdump/hex/snap=1500 host ndcal1.de-wil.csc.com 16:22:49.14 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: S 0:0(0) a ck 1 win 4096 4500 002c fa9c 0000 8006 1516 1406 0188 E..,............ 1406 0186 0202 03fe 66da 1400 3351 3292 ........f...3Q2. 6012 1000 7643 0000 0204 05b0 0000 `...vC........ 16:22:49.14 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: . ack 1 wi n 6144 (DF) 4500 0028 8e19 4000 4006 819d 1406 0186 E..(..@.@....... 1406 0188 03fe 0202 3351 3292 66da 1401 ........3Q2.f... 5010 1800 85fc 0000 P....... 16:22:49.14 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: P 1:2(1) a ck 1 win 6144 (DF) 4500 0029 8e1c 4000 4006 8199 1406 0186 E..)..@.@....... 1406 0188 03fe 0202 3351 3292 66da 1401 ........3Q2.f... 5018 1800 85f3 0000 00 P........ 16:22:49.30 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: . ack 2 wi n 4095 4500 0028 fa9d 0000 8006 1519 1406 0188 E..(............ 1406 0186 0202 03fe 66da 1401 3351 3293 ........f...3Q2. 5010 0fff 8dfc 0000 0000 0000 0000 P............. 16:22:49.30 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: P 2:45(43) ack 1 win 6144 (DF) 4500 0053 8e46 4000 4006 8145 1406 0186 E..S.F@.@..E.... 1406 0188 03fe 0202 3351 3293 66da 1401 ........3Q2.f... 5018 1800 3817 0000 6469 786f 6e6d 0064 P...8...dixonm.d 6978 6f6e 6d00 7365 7420 766d 735f 7263 ixonm.set vms_rc 7020 3d20 3120 3b20 7263 7020 2d74 2078 p = 1 ; rcp -t x 2e78 00 .x. 16:22:49.49 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: . ack 45 w in 4052 4500 0028 faa0 0000 8006 1516 1406 0188 E..(............ 1406 0186 0202 03fe 66da 1401 3351 32be ........f...3Q2. 5010 0fd4 8dfc 0000 0000 0000 0000 P............. 16:22:49.51 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: P 1:2(1) a ck 45 win 4052 4500 0029 faa2 0000 8006 1513 1406 0188 E..)............ 1406 0186 0202 03fe 66da 1401 3351 32be ........f...3Q2. 5018 0fd4 8df3 0000 0000 0000 0000 P............. 16:22:49.60 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: . ack 2 wi n 32768 (DF) 4500 0028 8e81 4000 4006 8135 1406 0186 E..(..@.@..5.... 1406 0188 03fe 0202 3351 32be 66da 1402 ........3Q2.f... 5010 8000 1dcf 0000 P....... 16:22:49.60 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: P 2:83(81) ack 45 win 4052 4500 0079 faa3 0000 8006 14c2 1406 0188 E..y............ 1406 0186 0202 03fe 66da 1402 3351 32be ........f...3Q2. 5018 0fd4 a94d 0000 0a25 4443 4c2d 572d P....M...%DCL-W- 4956 4b45 5957 2c20 756e 7265 636f 676e IVKEYW, unrecogn 697a 6564 206b 6579 776f 7264 202d 2063 ized keyword - c 6865 636b 2076 616c 6964 6974 7920 616e heck validity an 6420 7370 656c 6c69 6e67 0d0a 205c 564d d spelling.. \VM 535f 5243 505c 0d0a 0d S_RCP\... 16:22:49.60 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: F 45:45(0) ack 83 win 32768 (DF) 4500 0028 8e83 4000 4006 8133 1406 0186 E..(..@.@..3.... 1406 0188 03fe 0202 3351 32be 66da 1453 ........3Q2.f..S 5011 8000 1d7d 0000 P....}.. 16:22:49.61 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: . ack 46 w in 4052 4500 0028 faa4 0000 8006 1512 1406 0188 E..(............ 1406 0186 0202 03fe 66da 1453 3351 32bf ........f..S3Q2. 5010 0fd4 8da9 0000 0000 0000 0000 P............. 16:22:49.61 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: F 83:83(0) ack 46 win 4096 4500 0028 faa5 0000 8006 1511 1406 0188 E..(............ 1406 0186 0202 03fe 66da 1453 3351 32bf ........f..S3Q2. 5011 1000 8d7c 0000 0000 0000 0000 P....|........ 16:22:49.61 ndcvx1.###.###.###.1022 > ndcal1.###.###.###.shell: . ack 84 w in 32768 (DF) 4500 0028 8e84 4000 4006 8132 1406 0186 E..(..@.@..2.... 1406 0188 03fe 0202 3351 32bf 66da 1454 ........3Q2.f..T 5010 8000 1d7c 0000 P....|.. ================================================================================ Archive-Date: Fri, 4 Feb 2000 12:00:08 -0500 Date: Fri, 04 Feb 2000 11:55:43 -0500 (EST) From: Dave Greenwood Reply-To: Info-MultiNet@process.com Subject: Re: Problem with RCP To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII mdixon2@csc.com wrote: > I have logged this with Process, but have yet to hear back on a cause (PSC Case > # 78636) Perhaps you all can assist. > > I have a VAX running Multinet 4.1 Rev A on V 6.2 VMS with a handfull of patches > about equivalent to REV B. > > I try to RCP to an Alpha UCX V 4.1 ECO 10 System and it fails. > If I RCP to another MultiNet system all is OK > If I RCP from Alpha UCX V 4.1 ECO 10 to MultiNet it works. > If I RCP from another UCX to the first UCX box, that works (both V 4.1 different > ECO's). > Only RCP from MultiNet to UCX fails. > > Here is an example of the output, nodenames & usernames have been replaced with > ### & XXX. The TCPDump looks like MultiNet is sending the command VMS_RCP to > UCX and it chokes. I cannot figure out why and where this is really coming > from. Any assistance would be appreciated [snip] Have you tried RCP/NOVMS from the MultiNet node? It's probably a pain to have to remember to do it but it might work. See HELP RCP/VMS_ATTRIBUTES for info. Dave -------------- Dave Greenwood Internet: Greenwoodde@ORNL.GOV Oak Ridge National Lab %STD-W-DISCLAIMER, I only speak for myself ================================================================================ Archive-Date: Fri, 4 Feb 2000 12:00:45 -0500 Date: Fri, 4 Feb 2000 08:56:25 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Problem with RCP Message-ID: <0002040850390.34-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Feb 2000 10:47 -0500, mdixon2@csc.com wrote: > On the MultiNet system: > NDCVX1>> rcp login.com ndcal1::x.x/log/user=XXXXX For grins, try "rcp/log/user=XXX login.com ndcal1::x.x" > %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling > > On the UCX system UCX creates the log file and displays an OPCOM message. > NDCAL1>> > %%%%%%%%%%% OPCOM 3-FEB-2000 16:39:56.53 %%%%%%%%%%% > Message from user INTERnet on NDCAL1 > INTERnet ACP RSH Accept Request from Host: ##.##.##.## Port: 1023 > NDCAL1>> ty UCX$RSHD_STARTUP.LOG;1 > %DCL-W-IVKEYW, unrecognized keyword - check validity and spelling > \VMS_RCP\ Try "rcp/novms_attributes/log/user=XXX login.com ndcal1::x.x" > XXXXXX job terminated at 3-FEB-2000 16:39:56.76 > > Accounting information: > Buffered I/O count: 30 Peak working set size: 1632 > Direct I/O count: 5 Peak page file size: 38512 > Page faults: 168 Mounted volumes: 0 > Charged CPU time: 0 00:00:00.11 Elapsed time: 0 00:00:00.24 > > And a TCP DUMP during this exchange... > > NDCVX1>> mu tcpdump/hex/snap=1500 host ndcal1.de-wil.csc.com > 16:22:49.14 ndcal1.###.###.###.shell > ndcvx1.###.###.###.1022: S 0:0(0) a > ck 1 win 4096 > 4500 002c fa9c 0000 8006 1516 1406 0188 E..,............ > 1406 0186 0202 03fe 66da 1400 3351 3292 ........f...3Q2. > 6012 1000 7643 0000 0204 05b0 0000 `...vC........ Occluding your IP address with ### isn't useful unless you also occlude the hex version of your IP address (14060186). -d ================================================================================ Archive-Date: Fri, 4 Feb 2000 12:26:42 -0500 From: mdixon2@csc.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Date: Fri, 4 Feb 2000 12:21:43 -0500 Subject: Re: Problem with RCP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Thanks to Dan and Dave for the answer! /noVMS did the trick! Also I must appologize to the PSC rep Dave Orth, I meant to say in my forst posting that I had not received an answer, I get get a response that someone would look into it. I was simply impatient due to an irritated user. Thanks again! Mike Dixon OpenVMS Systems Consultant ================================================================================ Archive-Date: Fri, 4 Feb 2000 13:55:13 -0500 Date: Fri, 4 Feb 2000 11:50:48 -0700 From: "WILLIAMS VIGIL, NIS-3/DEC MS-D440, 505-667-3587" Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Subject: print to que on remote VMS node? Multinet 4.2a, Alpha VMS 7.2-1 Anyone know how one can configure Multinet to print from one VMS system to another remote VMS system's locally attached HP1600CM printer connected to its parallel port? Ws +----------------------------------------------------------+ |Williams E. VIGIL "Y que mas?" LANL, Los Alamos, NM| |wevigil@lanl.gov 505-667-3587 Pager: 104-4728| |"... description is not explanation and when it comes to | | primary causes science explains nothing." D. Grinspoon | +----------------------------------------------------------+ ================================================================================ Archive-Date: Fri, 4 Feb 2000 14:20:38 -0500 Date: Fri, 04 Feb 2000 14:15:13 -0500 From: Michael Corbett Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 To: info-multinet@process.com Subject: RE: print to que on remote VMS node? Content-Type: text/plain; charset=us-ascii > > Multinet 4.2a, Alpha VMS 7.2-1 > > Anyone know how one can configure Multinet to print from > one VMS system to another remote VMS system's locally attached > HP1600CM printer connected to its parallel port? > Enable the LPD server on one system and on the other create a LPD queue that points to the other system. For example - On the system that has the locally attached printer you have to create a VMS queue that prints to that printer, lets call the queue LCOALQUEUE. You then have to enable the LPD server, set it up to accept connections from the other system, and then restart the Multinet server. For example - $ MU CONFIG/SER MultiNet Server Configuration Utility V4.1(42) [Reading in configuration from MULTINET:SERVICES.MASTER_SERVER] SERVER-CONFIG>ENABLE LPD SERVER-CONFIG>SELECT LPD [The Selected SERVER entry is now LPD] SERVER-CONFIG>SET ACCEPT-HOST Delete address "IP-127.0.0.1" ? [NO] You can now add new addresses for LPD. An empty line terminates. Add Address: 10.1.1.1 Add Address: SERVER-CONFIG>RESTART Configuration modified, do you want to save it first ? [YES] YES [Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER] On the other system you have to create a Multinet LPD queue that points to the queue on the first system. For example - $ MU CONFIG/PRINTER MultiNet Remote Printer Configuration Utility V4.1(25) [Reading in configuration from MULTINET:REMOTE-PRINTER-QUEUES.COM] PRINTER-CONFIG>ADD LPD_QUEUE [Adding new configuration entry for queue "LPD_QUEUE"] Remote Host Name: HOST.DOMAIN.COM Protocol Type: [LPD] Remote Queue Name: [lp] LOCALQUEUE [LPD_QUEUE => HOST.DOMAIN.COM, LOCALQUEUE] PRINTER-CONFIG>^Z [Writing configuration to MULTINET:REMOTE-PRINTER-QUEUES.COM] $ @MULTINET:REMOTE-PRINTER-QUEUES.COM You now have a queue called LPD_QUEUE that will print LPD to the queue called LOCALQUEUE on the other system. 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: Fri, 4 Feb 2000 15:32:27 -0500 Date: Fri, 04 Feb 2000 12:27:57 -0800 (PST) From: "Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515" Reply-To: Info-MultiNet@process.com Subject: [Q] Can a single interface support multiple IP addresses? To: INFO-MULTINET@PROCESS.COM MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII We're having various and sundry problems with a number of our hosts which are multi-homed, that is, have multiple IP addresses for a single domain name. Currently, each of the several IP addresses corresponds to a different network interface on a different network. I won't go into the details of our problems other than to say that only one of the multiple IP addresses is accessible from off-site, but any given domain-name -> IP address translation has a 75% chance of giving an _inaccessible_ address. In an attempt to solve this issue, I had our name server folks add a second set of domain names for these hosts with only the one, publicly accessible IP address for each in NAMED.HOSTS. This "works" for a lot of things, but not the one that I'm currently most worried about (DSNlink 2.2E over TCP/IP). If the remote end does a reverse lookup of the publicly accessible IP address, the multi- homed domain name is returned. If that domain-name is stored (as it apparently is for DSNlink) and used later, we run into the 75% failure rate problem again. Sigh... An alternative, _if_ it would work, would be to add another Multinet interface, e.g. se5, with a new IP address, but which uses the same VMS device, e.g. FWA0, as the existing public-side network interface, se0. The new IP address would be associated with the new domain-name that is already in the name server, but we'd be able to add the correct reverse lookup entries. Is this sort of thing supported? Are there any gotcha's I should know about before I go down this road? Thanks, Ken -- Kenneth H. Fairfield | Internet: Fairfield@SLC.Slac.Stanford.Edu SLAC, 2575 Sand Hill Rd, MS 46 | Voice: 650-926-2924 Menlo Park, CA 94025 | FAX: 650-926-3515 ----------------------------------------------------------------------------- These opinions are mine, not SLAC's, Stanford's, nor the DOE's... ================================================================================ Archive-Date: Fri, 4 Feb 2000 15:37:57 -0500 From: Javier Henderson Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 4 Feb 2000 12:33:31 -0800 (PST) To: Info-MultiNet@process.com Subject: [Q] Can a single interface support multiple IP addresses? References: <01JLICFO8EBMBQ13X0@SLC.SLAC.STANFORD.EDU> Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515 writes: > An alternative, _if_ it would work, would be to add another > Multinet interface, e.g. se5, with a new IP address, but which uses > the same VMS device, e.g. FWA0, as the existing public-side network > interface, se0. The new IP address would be associated with the new > domain-name that is already in the name server, but we'd be able to > add the correct reverse lookup entries. > > Is this sort of thing supported? Are there any gotcha's I > should know about before I go down this road? > Yes, it is supported. $ mu conf CONFIG> add pd0 The hardware device will be se0. You can have up to either 10 or 500 devices. When MultiNet was a TGV product, you needed a patch to add more than 10 virtual interfaces. I don't know if this patch was later rolled into the baseline product by Process. You will need to reboot the system for the pd interfaces to take effect. -jav ================================================================================ Archive-Date: Fri, 4 Feb 2000 15:38:19 -0500 Date: Fri, 4 Feb 2000 12:33:54 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: [Q] Can a single interface support multiple IP addresses? Message-ID: <0002041233250.4936-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Feb 2000 12:27 -0800, Ken Fairfield; SLAC: 650-926-2924; FAX:...: MultiNet has "pd" interfaces for just this sort of thing. I know they used to not be supported due to the added complexity in explaining how this works, but this may have changed since the TGV days. -Dan Wing > We're having various and sundry problems with a number of our > hosts which are multi-homed, that is, have multiple IP addresses for > a single domain name. Currently, each of the several IP addresses > corresponds to a different network interface on a different network. > > I won't go into the details of our problems other than to say > that only one of the multiple IP addresses is accessible from > off-site, but any given domain-name -> IP address translation has a > 75% chance of giving an _inaccessible_ address. > > In an attempt to solve this issue, I had our name server folks > add a second set of domain names for these hosts with only the one, > publicly accessible IP address for each in NAMED.HOSTS. This > "works" for a lot of things, but not the one that I'm currently most > worried about (DSNlink 2.2E over TCP/IP). If the remote end does a > reverse lookup of the publicly accessible IP address, the multi- > homed domain name is returned. If that domain-name is stored (as it > apparently is for DSNlink) and used later, we run into the 75% > failure rate problem again. Sigh... > > An alternative, _if_ it would work, would be to add another > Multinet interface, e.g. se5, with a new IP address, but which uses > the same VMS device, e.g. FWA0, as the existing public-side network > interface, se0. The new IP address would be associated with the new > domain-name that is already in the name server, but we'd be able to > add the correct reverse lookup entries. > > Is this sort of thing supported? Are there any gotcha's I > should know about before I go down this road? > > Thanks, Ken > -- > Kenneth H. Fairfield | Internet: Fairfield@SLC.Slac.Stanford.Edu > SLAC, 2575 Sand Hill Rd, MS 46 | Voice: 650-926-2924 > Menlo Park, CA 94025 | FAX: 650-926-3515 > ----------------------------------------------------------------------------- > These opinions are mine, not SLAC's, Stanford's, nor the DOE's... > ================================================================================ Archive-Date: Fri, 4 Feb 2000 15:55:57 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Fri, 4 Feb 2000 15:55:11 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: NAMED-060_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: NAMED-060_A042 Description: NAMED update (fixes zone transfer problems) Release date: 4-FEB-2000 Versions: V4.2A ftp://ftp.multinet.process.com/patches/multinet042/named-060_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- NAMED-060_A042 ECO kit revision 6.0 for Multinet Version 4.2 Rev A 25-Jan-2000 This kit updates MultiNet V4.2 Rev A with a new versions of LOADABLE_NAMED_CONTROL.EXE, NAMED-XFER.EXE, and NAMED.EXE and corrects the following problems: - NAMED-040_A042 and subsequent ECOs introduced a new timing window that could cause master servers to prematurely terminate large outgoing zone transfers. This problem has been corrected. (D/E 5478) - Secondary servers no longer create a new version of the backup zone file when it transfers the zone, it now replaces the old file with the new file. Customers are encouraged to check the directories where their backup zone files are stored, and purge the excess if desired. (D/E 5207) This kit also includes the following changes from previous ECO kits: NAMED-051_A042 -------------- - Master Server no longer access violates if you try to restart the nameserver if it's hung or not running. (D/E 5192) IP AddressWorks related changes: - Improved handling of errors trying to communicate with the Server Manager. NAMED-040_A042 -------------- - A timing issue has been corrected. With the right timing, the nameserver could hang intermittently until another tcp connection is received. (D/E 5175) IP AddressWorks related changes: - NameD no longer creates a crash dump if it is shutdown before it has a chance to fully start up. NAMED-030_A042 -------------- - Several problems have been corrected regarding logging files. - The log files are now flushed to disk periodically, so their contents can be viewed without restarting or reloading NameD. - The "versions" clause on the logging file statement will now cause NameD to create a new version of the file upon restart or reload, and the specified number of old versions will be kept. For example: logging { channel queries_log { file "multinet:queries.log" versions 3; severity info; } category queries { queries_log; }; } If "versions" is not specified, NameD performs the current behavior of appending to the same log file. NAMED-021_A042 -------------- - A problem has been corrected regarding logging files. One may now configure the logging {} statement to have multiple channels to the same log file. NAMED-010_A042 -------------- - BIND 8 creates glue records during zone transfers to secondaries when the zone being transferred contains delegation names that exist in subzones of the transferred zone (e.g. the zone has NS records for subzones that point to servers whose name is also in a subzone). This caused problems if the NS record was pointing to a cluster alias name as the authoritative server for that subzone. This patch prevents the glue from being created if the NS record points to a CSN. IP AddressWorks related changes: - NameD now cleanly terminates it's connection with the LDAP server when the nameserver is stopped via NETCONTROL DOMAIN STOP or RESTART) - NameD now informs the IPAW GUI and issues a warning if it has no configuration file to start up with, and can't export one from LDAP. You need to restart the Nameserver and the Master Server for these changes to take effect. The following is the recommended sequence: $ ! shut down the Nameserver $ MULTINET NETCONTROL DOMAINNAME STOP $ ! re-start the master server, which will automaticaly restart NAMED $ @MULTINET:START_SERVER.COM You do not have to reboot after installing this kit. [End of ECO announcement] ================================================================================ Archive-Date: Fri, 4 Feb 2000 16:07:34 -0500 Sender: goatley@triton.process.com Return-Path: Date: Fri, 04 Feb 2000 15:38:25 -0500 To: INFO-MULTINET@process.com From: Dan Sugalski Reply-To: Info-MultiNet@process.com Subject: Re: [Q] Can a single interface support multiple IP addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:27 PM 2/4/00 -0800, Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515 wrote: > Is this sort of thing supported? Are there any gotcha's I > should know about before I go down this road? Sure. You just set up a pseudo-interface for each IP address other than the primary. Works really nicely. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk ================================================================================ Archive-Date: Fri, 4 Feb 2000 16:42:12 -0500 From: Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515) Reply-To: Info-MultiNet@process.com Subject: Re: [Q] Can a single interface support multiple IP addresses? Date: 4 Feb 00 13:15:12 PST To: INFO-MULTINET@PROCESS.COM In article <14491.14235.548197.77877@argentum.network-alchemy.com>, Javier Henderson writes: [...] > Yes, it is supported. > > $ mu conf > CONFIG> add pd0 > > The hardware device will be se0. Ah ha, thanks! I suppose you could have just told me to RTFM since I've now looked and found the section titled, "Assigning Multiple Addresses to a Network Interface" in Ch.3 of the Multinet Administrator's Guide. :-) Looks like this is _exactly_ what I need. :-) :-) Thanks, Ken -- Kenneth H. Fairfield | Internet: Fairfield@SLC.Slac.Stanford.Edu SLAC, 2575 Sand Hill Rd, MS 46 | Voice: 650-926-2924 Menlo Park, CA 94025 | FAX: 650-926-3515 ----------------------------------------------------------------------------- These opinions are mine, not SLAC's, Stanford's, nor the DOE's... ================================================================================ Archive-Date: Mon, 7 Feb 2000 12:29:04 -0500 Date: Mon, 07 Feb 2000 10:51:53 -0600 From: "Brinker, Horst" Reply-To: Info-MultiNet@process.com Subject: How do I interpret the intrusion source? To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Hello all, I run Multinet v4.1B with patches on Vax VMS 7.1. Somewhere out on our network, I appear to have a babbling node. How can I track down the node from the intrusion record source field ( show intrusion command )? The format of the record I get is below. The source field is "TELNET::C0A82465" . NETWORK INTRUDER 11 8-FEB-2000 11:32:37.34 TELNET::C0A82465 Thanks, Horst Brinker ================================================================================ Archive-Date: Mon, 7 Feb 2000 12:36:36 -0500 Date: Mon, 07 Feb 2000 10:32:07 -0700 To: Info-MultiNet@process.com From: Jim Mehlhop Reply-To: Info-MultiNet@process.com Subject: Re: How do I interpret the intrusion source? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:51 AM 2/7/00 -0600, you wrote: >Hello all, > >I run Multinet v4.1B with patches on Vax VMS 7.1. Somewhere out on our >network, I appear to have a babbling node. How can I track down the node >from the intrusion record source field ( show intrusion command )? > >The format of the record I get is below. The source field is >"TELNET::C0A82465" . break the hex down to decimal 2 digits per . Ie C0 A8 24 65 192.168.36.101 Jim > NETWORK INTRUDER 11 8-FEB-2000 11:32:37.34 TELNET::C0A82465 > >Thanks, >Horst Brinker ================================================================================ Archive-Date: Mon, 7 Feb 2000 16:29:26 -0500 From: "Harms,Jon" Reply-To: Info-MultiNet@process.com To: "'info-multinet@process.com'" Subject: NFS Questions Date: Mon, 7 Feb 2000 15:24:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" As the subject says, I have some NFS questions and need some direction about where to go next in my trys to get this to work. Here is the scenario: Node1 (server VMS 7.2-1, Multinet 4.2a) Node2 (client VMS 7.1, Multinet 4.1b) I have Node1 set up for the correct mount point and I can mount the drive from Node2 but I get UICs of [200,200] (default) which doesn't allow me to do anything to the drives. Is there something special that needs to be done to get two VMS Multinet boxes to nfs mount each other? I can guarantee that the UICs are the same across the nodes due to the account creation scripts so I didn't know if that would help me, would it? Do I need to have a password file since I am using two VMS boxes? Is there a tutorial/example that I can look at to help with my configuration? Any help is appreciated. -- Jon Harms Tech Dev System Developer jharms@cerner.com - http://www.cerner.com/ ================================================================================ Archive-Date: Mon, 7 Feb 2000 17:02:25 -0500 Sender: lovejoy@process.com Date: Mon, 7 Feb 2000 16:57:53 -0500 From: lovejoy@process.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: NFS Questions Jon, You need to add uid entries using the mu conf/nfs utility. See the Admin Guide, Chapters, Configuring the MultiNet NFS Server and Using the NFS Client. -Steve Lovjoy, Process Software ================================================================================ Archive-Date: Mon, 7 Feb 2000 17:05:26 -0500 From: Mike Duffy Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: NFS Questions Date: Mon, 7 Feb 2000 17:00:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Jon, MultiNet NFS maps Unix-style UID/GID pairs to OpenVMS usernames. Things will be much simpler if each username has a unique UIC, which is usually a good idea anyway. Since you have V4.1 on at least one system, I'll refer to page numbers in that documentation set. From the server standpoint: Take a look in the Administrator's Guide beginning at section 19.1.3. Sections 19.4 through 19.6 (beginning at page 19-14) contain examples of showing, adding and deleting mappings. From the client standpoint: Sections 20.1.2 and 20.1.3.*, and sections 20.3.* contain examples of the same things, but from the client side. Mike Duffy Process Software Corp. -----Original Message----- From: Harms,Jon [mailto:JHARMS@cerner.com] Sent: Monday, February 07, 2000 4:25 PM To: 'info-multinet@process.com' Subject: NFS Questions As the subject says, I have some NFS questions and need some direction about where to go next in my trys to get this to work. Here is the scenario: Node1 (server VMS 7.2-1, Multinet 4.2a) Node2 (client VMS 7.1, Multinet 4.1b) I have Node1 set up for the correct mount point and I can mount the drive from Node2 but I get UICs of [200,200] (default) which doesn't allow me to do anything to the drives. Is there something special that needs to be done to get two VMS Multinet boxes to nfs mount each other? I can guarantee that the UICs are the same across the nodes due to the account creation scripts so I didn't know if that would help me, would it? Do I need to have a password file since I am using two VMS boxes? Is there a tutorial/example that I can look at to help with my configuration? Any help is appreciated. -- Jon Harms Tech Dev System Developer jharms@cerner.com - http://www.cerner.com/ ================================================================================ Archive-Date: Mon, 7 Feb 2000 18:46:00 -0500 From: galvas@merlin.arc.nasa.gov (Laura Holst) Subject: MU FTP Error - More Info? Date: 7 Feb 2000 23:05:50 GMT Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Hi --- We are receiving the following error from (I assume) Multinet FTP: ?Could not parse address from PASV reply. I couldn't find any more information on this in the manuals. We are FTPing from Multinet V4-2 Rev A-X on an Alphaserver 4100 running OpenVMS 7.1 to a MAC running (I assume!) Fetch. After connecting and successfully logging into the MAC, using DIR or PUT generates the error. Does anyone know what this error might mean, and what we can do to fix it? According to the user, this "worked before". :-) Thanks, Laura Galvas ================================================================================ Archive-Date: Mon, 7 Feb 2000 19:32:36 -0500 Date: Mon, 7 Feb 2000 18:28:05 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: MU FTP Error - More Info? galvas@merlin.arc.nasa.gov (Laura Holst) writes: > >We are receiving the following error from (I assume) Multinet FTP: > > ?Could not parse address from PASV reply. > >I couldn't find any more information on this in the manuals. > >We are FTPing from Multinet V4-2 Rev A-X on an Alphaserver 4100 running >OpenVMS 7.1 to a MAC running (I assume!) Fetch. > >After connecting and successfully logging into the MAC, using >DIR or PUT generates the error. > >Does anyone know what this error might mean, and what we can do to fix it? > >According to the user, this "worked before". :-) > The MultiNet FTP client uses passive mode by default. The way that works is that a PASV command is sent from the client to the server. The server responds with a string that includes an IP address and port number that it will be listening on for the data connection: > 7-FEB-2000 18:25:47.74 'PASV' Entering passive mode (205,241,220,114,57,23). If that reply isn't formatted correctly, you'll get the message you're seeing. Unless you have a firewall in between the systems, it should work to just disable passive mode (PASSIVE OFF at the FTP prompt or in SYS$LOGIN:FTP.INIT). Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 8 Feb 2000 03:55:41 -0500 From: "Parraco, Andy" Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: How do I interpret the intrusion source? Date: Tue, 8 Feb 2000 04:50:33 -0400 MIME-Version: 1.0 Content-Type: text/plain We built a DCL procedure to do this: $! Command procedure to translate the Hex IP address into the Multinet address $! and return the Name Server translation $! $! $! P1 should be the hex IP address e.g.: @whoisit C40C7AA6 $! $ a= f$integer("%x''f$extract(4,2,p1)'") $ b= f$integer("%x''f$extract(6,2,p1)'") $ multinet ns 196.12.'a.'b $exit Cheers. - Andy Parraco * Andrew C. Parraco * Senior Project Manager, Information Systems Division * The Bank of Bermuda Limited * E-Mail andy.parraco@bankofbermuda.com > ---------- > From: Jim Mehlhop[SMTP:mehlhop@process.com] > Reply To: Info-MultiNet@process.com > Sent: Monday, February 07, 2000 5:32 PM > To: Info-MultiNet@process.com > Subject: Re: How do I interpret the intrusion source? > > At 10:51 AM 2/7/00 -0600, you wrote: > >Hello all, > > > >I run Multinet v4.1B with patches on Vax VMS 7.1. Somewhere out on our > >network, I appear to have a babbling node. How can I track down the node > >from the intrusion record source field ( show intrusion command )? > > > >The format of the record I get is below. The source field is > >"TELNET::C0A82465" . > > break the hex down to decimal 2 digits per . Ie > > C0 A8 24 65 > 192.168.36.101 > > Jim > > > > NETWORK INTRUDER 11 8-FEB-2000 11:32:37.34 > TELNET::C0A82465 > > > >Thanks, > >Horst Brinker > ================================================================================ Archive-Date: Tue, 8 Feb 2000 14:54:41 -0500 From: Randy Neufeldt Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: Laser print forms... Date: Tue, 8 Feb 2000 13:50:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, this may not be the best place to send this question but I've received many good answers from this group on many different topics (other than Multinet) and this is sort of Multinet related ;-) Has anyone constructed OpenVMS device control libraries for HP laser printers. I would like to replace older DEC printers with lasers. If so, would someone be kind enough to respond directly to me? ====================================== Randall J. Neufeldt, VMS Systems Administrator DRA INFORMATION Inc. 500 Place d'Armes, suite 2420 Montral, ubec Canada H2Y 2W2 randyn@dra.com telephone : 1-800-884-9330 telephone : 1-514-350-4518 facsimile : 1-514-350-5299 http://www.dra.com ================================================================================ Archive-Date: Tue, 8 Feb 2000 15:51:20 -0500 From: mfleming@csub.edu Reply-To: Info-MultiNet@process.com Subject: Dynamic DNS Problems Date: Tue, 08 Feb 2000 12:25:36 -0800 To: INFO-MULTINET@PROCESS.COM Process Software MultiNet V4.2 Rev A-X, AlphaServer 2100 5/250, OpenVMS AXP V7.2-1 DHCPD.VUI DHCP-041_A042 20-SEP-1999 DHCP_CONVERSION_TOOL.VUI DHCP-041_A042 20-SEP-1999 LOADABLE_DHCP_CONTROL.VUI DHCP-041_A042 20-SEP-1999 LOADABLE_NAMED_CONTROL.VUI NAMED-060_A042 5-FEB-2000 NAMED-XFER.VUI NAMED-060_A042 5-FEB-2000 NAMED.VUI NAMED-060_A042 5-FEB-2000 I am running the above versions of MultiNet components and beginning to experiment with dynamic DNS. I have encountered some difficulties in the process and have a few questions. Below is an extract from my dhcpd.conf file. allow dynamic-update; allow update-A-record; option host-name "Host-%M"; use-host-decl-names on; option domain-name "csub.edu"; Below is a logging channel definition from named.conf that I set up with the intent to help with debugging ddns error messages. channel update_log { file "multinet:ddns_updates.log"; severity debug 15; print-severity yes; print-time yes; }; I get "error processing update packet" messages for a number of ddns updates. I turned on DHCP debug 15 to trace down what IP addresses were causing the errors (there should be some intermediate debug value that returns MAC and IP addresses that doesn't consume dozens and dozens of lines); however, I haven't been able to get named or dhcpd to tell me what the actual error is. I have tried various debug values in my named log channel definition above, but so far, no success. (Note: Having documentation showing what debug value does what would be VERY helpful.) How can I go about finding out what named is complaining about? I have both host-name "Host-%M" defined and use-host-decl-names on. My hope was that if a dhcp client did not have a host entry in dhcpd.conf that ddns would use "Host-%M" and that it would use the host-decl if there was an entry. It seems to use only "Host-%M". Is there any way to get the behaviour I want? I have some 1500 dhcp and bootp clients. I get hundreds of ddns updates a day. My named serial number is going through the roof and AXFR zone transfers are occurring every few minutes. I don't know what can be done about the runaway serial number problem (I can distribute the burden somewhat with zones but...); however, the traffic from the zone transfer can be reduced by orders of magnitude if IXFR zone transfers were supported. How soon before BIND 8.2.x.x and IXFR will be supported in MultiNet? Those of you using ddns, how are you managing the static named entries apart from the ddns entries? My pretty formated dns host entry files with comments and $includes gets automatically re-created on the fly with named dumps that are impossible to work with. This next question may not be possible... We have two domains (csub.edu and csubak.edu) that for historical reasons we want to be more or less aliases of each other--we want each machine to be listed in both domains forward and reverse. Can ddns do this and how? Thanks for all your help. Michael Fleming CSU, Bakersfield -- Michael W. Fleming, Network Analyst, California State University Voice/mail:(661)664-2118 (24hrs) Fax:(661)664-2099 (24hrs) Disclaimer: I directly represent only myself and my family; indirectly, I represent God and all His creation. ================================================================================ Archive-Date: Tue, 8 Feb 2000 16:56:36 -0500 Sender: schreiber@process.com Date: Tue, 8 Feb 2000 16:52:02 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: Dynamic DNS Problems mfleming@csub.edu writes: > >Below is a logging channel definition from named.conf that I set up with >the intent to help with debugging ddns error messages. > > channel update_log { > file "multinet:ddns_updates.log"; > severity debug 15; > print-severity yes; > print-time yes; > }; Do you have a category that points to that channel? You probably want: category update { update_log; }; In your logging section as well. And when your ready to do the tests that generate the errors, you'll want to use: $ MU NETC DOMAIN DEBUG 5 To set the debugging level to 5 [there isn't anything for dynamic updates below debug 5 at this point]. When your done, turn off debugging with: $ MU NETC DOMAIN DEBUG 0 >I have tried various debug values in my named >log channel definition above, but so far, no success. (Note: Having >documentation showing what debug value does what would be VERY helpful.) >How can I go about finding out what named is complaining about? Try setting the debugging level in the nameserver as described above. This should generate some "process_updates" messages in the log file. >AXFR zone transfers are occurring every few minutes. I don't know what can >be done about the runaway serial number problem (I can distribute the >burden somewhat with zones but...) The serial number growth is something you get when the zones change, there isn't much that can be done about that. There is work being done on the ISC nameserver to limit the serial growth somewhat. However it's not the serial number growth that is causing the zone transfers every few minutes. That is done because of the DNS Notify protocol. When the nameserver changes it's zone, it notifies the secondaries that the zone has changed. The secondary servers check the SOA and transfer the zone again if the Serial has changed. You can disable DNS Notify on a server or a zone by zone basis, by setting "notify no;" in the options {} section, or the individual zone section. With a dynamic zone, you might want to lower your refresh times in your SOA if you aren't using NOTIFY and the refresh is still setup as if the zone is relatively static. >How soon before BIND 8.2.x.x and IXFR will be supported in MultiNet? Should be next release. ISC had some problems with their IXFR implementation, but I think it's stabilizing. Don't hold me to that though, I've not yet been involved with the DNS stuff for 4.3. >Those of you using ddns, how are you managing the static named entries >apart from the ddns entries? My pretty formated dns host entry files >with comments and $includes gets automatically re-created on the fly >with named dumps that are impossible to work with. Making changes to your zone file on a dynamic zone is quite dangerous. As the nameserver runs, it builds up a log of the dynamic changes to date. When the zone goes through a maintenance cycle, it writes out a new version of the zone file, and clears out the log to that point. When you shut down the nameserver, it also will write out a new version of the zone file. If the nameserver stops 'less than cleanly', it doesn't write out a new zone file. When you then start the nameserver, if loads in the zone from the file, and then checks for a dynamic log. If it finds one, it opens it up, and processes the dynamic changes sequentially. However the serial number changes are part of the dynamic changes. So if the starting serial number in the zone file isn't the starting serial number in the dynamic log, it realizes something is out of wack, and it takes the zone file as it is, and doesn't apply any dynamic changes. So basically, if you change the zone file on a dynamic zone, those changes will be wiped out when it next writes the dynamic zone file. If you make changes and kill the running nameserver, then start it back up, any dynamic changes from the last time it wrote it will be lost. The best way to handle it is shut down the server cleanly [let your secondaries take over for a couple minutes]. This will write out the zone file. Edit it and add your static entries. Then start the server back up [remembering to increase the serial for your secondaries :]. [I guess I can put a shameless plug in here for our IPaddressWorks product which has some handshaking to allow changes to be made to a dynamic zone through the utility]. > >This next question may not be possible... We have two domains (csub.edu >and csubak.edu) that for historical reasons we want to be more or less >aliases of each other--we want each machine to be listed in both domains >forward and reverse. Can ddns do this and how? > Not that I can think of off the top of my head, no. There is an RFC (2672) that describes a Resource Record "DNAME" that is designed to rename whole domains. If I remember the proposal at all [it's been a while since I last read that, when it was a draft], you can redirect zones to different zones. In other words, having: CSUBAK.EDU IN DNAME CSUB.EDU Would cause www.csubak.edu to return the answer for www.csub.edu. I'd have to re-read the RFC to be sure, and I'm not sure if BIND 8.2 supports it yet. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Wed, 9 Feb 2000 11:06:17 -0500 Date: Wed, 9 Feb 2000 11:01:36 -0500 From: "Bryan R. Webb" Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Subject: any SMTP_SERVER_REJECT patch for Multinet V3.5A? Folks, I have been able to recall from my archived mail that Multinet V4.0C included support for the SMTP_SERVER_REJECT. file to control email relaying and that there was an ECO available for some earlier versions. I am not finding that ECO or any mention of what versions it covered. Did it cover V3.5A or V3.5B? If so, where might I find it now? I need to fix email relaying on a system currently running V3.5A. The owner of the system make heavy use of Multinet MM. I only now tracked down that V4.0A drops MM and includes it in the contributed software directory. I'd like to get the relaying fixed quickly and allow a little more time to work with MM, and this ECO appears to be what I need. Thanks a bunch for any pointers on this! --Bryan Webb VMS Systems Administrator Pittsburgh Supercomputing Center ================================================================================ Archive-Date: Wed, 9 Feb 2000 11:18:25 -0500 Date: Wed, 09 Feb 2000 11:13:03 -0500 From: Michael Corbett Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 To: info-multinet@process.com Subject: RE: any SMTP_SERVER_REJECT patch for Multinet V3.5A? Content-Type: text/plain; charset=us-ascii > > > I have been able to recall from my archived mail that Multinet V4.0C > included support for the SMTP_SERVER_REJECT. file to control email > relaying and that there was an ECO available for some earlier > versions. I am not finding that ECO or any mention of what versions > it covered. Did it cover V3.5A or V3.5B? If so, where might I find > it now? > > I need to fix email relaying on a system currently running V3.5A. The > owner of the system make heavy use of Multinet MM. I only now tracked > down that V4.0A drops MM and includes it in the contributed software > directory. I'd like to get the relaying fixed quickly and allow a > little more time to work with MM, and this ECO appears to be what I > need. > > Thanks a bunch for any pointers on this! No, there are no ECOs that add this ability for versions of Multinet prior to 4.1. 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: Wed, 9 Feb 2000 11:19:23 -0500 Sender: schreiber@process.com Date: Wed, 9 Feb 2000 11:14:41 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: any SMTP_SERVER_REJECT patch for Multinet V3.5A? "Bryan R. Webb" writes: > >I am not finding that ECO or any mention of what versions it covered. >Did it cover V3.5A or V3.5B? If so, where might I find it now? > There is an ECO-SMTP040.ZIP in the Multinet040 section of the patches directory on ftp.multinet.process.com, which I believe contains the change. However I don't know if it will install on 3.5, nor if you can pull the SMTP_SERVER.EXE out of the saveset and get that to run [you might have problems with socket library versions]. Likewise there is SMTP-03_B041 which contains some changes/fixes to the filter stuff. It won't install on anything prior to 4.1, and I'm not sure if that will work pulling it out of the saveset [I highly doubt it will]. But you might want to give it a try. -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 10 Feb 2000 11:58:45 -0500 From: "Harms,Jon" Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: NFS & Indexed Files Date: Thu, 10 Feb 2000 10:51:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I am trying to compile some code over NFS but I am having troubles because of a file that is marked as 'Indexed, Prolog: 3, Using 1 key' for the file organization but the only file that it appears I can create over NFS is indexed, without the prolog. Is there a problem creating a 'Indexed, Prolog: 3, Using 1 key' file over NFS? I did mount the server with the /vms parameter to nfsmount. Setup is: Node1 - 7.2-1 (Server) MU 4.2a Node2 - 7.1 (Client) MU 4.1b I have included a dcl command to demonstrate the following including the fdl that was being used to create the file. Any help that you can give would be appreciated. It is possible to copy the 'Indexed, Prolog: 3, Using 1 key' file to the nfs drive with the appropriate type but I can't create that type of file over nfs. Thanks Jon --------------------------------------------------------- MAKE_DIABLO$ create/fdl=cxx$demangler_db.fdl blah.dat MAKE_DIABLO$ dir/full blah.dat Directory DATA02:[CERNER.W_STANDARD.REV007_009.CODE.ENVDUMP] BLAH.DAT;1 File ID: (5309,2,0) Size: 0/0 Owner: [MAKE_JH3163] Created: 10-FEB-2000 10:06:03.04 Revised: 10-FEB-2000 10:06:03.19 (1) Expires: Backup: Effective: Recording: File organization: Indexed Shelved state: Online File attributes: Allocation: 0, Extend: 63, Maximum bucket size: 17, Global buffer count: 0, No version limit Record format: Variable length, maximum 8223 bytes, longest 0 bytes Record attributes: Carriage return carriage control RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:RWED, World:RE Access Cntrl List: None Total of 1 file, 0/0 blocks. MAKE_DIABLO$ copy cxx$demangler_db.fdl v5testc:[cerner.w_standard.testrev78.code.envdump] /log %COPY-S-COPIED, DATA02:[CERNER.W_STANDARD.REV007_009.CODE.ENVDUMP]CXX$DEMANGLER_DB.FDL;2 copied to V5TESTC:[CERNER.W_STANDARD.TESTRE V78.CODE.ENVDUMP]CXX$DEMANGLER_DB.FDL;2 (2 blocks) MAKE_DIABLO$ set def v5testc:[cerner.w_standard.testrev78.code.envdump] MAKE_DIABLO$ create/fdl=cxx$demangler_db.fdl blah.dat MAKE_DIABLO$ dir/full blah.dat Directory V5TESTC:[CERNER.W_STANDARD.TESTREV78.CODE.ENVDUMP] BLAH.DAT;1 File ID: (18820,3,0) Size: 252/252 Owner: [MAKE_JH3163] Created: 7-APR-2000 10:03:38.58 Revised: 7-APR-2000 10:03:38.65 (1) Expires: Backup: Effective: Recording: File organization: Indexed, Prolog: 3, Using 1 key Shelved state: Online File attributes: Allocation: 252, Extend: 63, Maximum bucket size: 17, Global buffer count: 0, No version limit Contiguous best try Record format: Variable length, maximum 8223 bytes, longest 0 bytes Record attributes: Carriage return carriage control RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:RWED, World:RE Access Cntrl List: None Total of 1 file, 252/252 blocks. MAKE_DIABLO$ type cxx$demangler_db.fdl IDENT " 7-APR-2000 10:01:42 OpenVMS FDL Editor" SYSTEM SOURCE "OpenVMS" FILE ALLOCATION 252 BEST_TRY_CONTIGUOUS yes BUCKET_SIZE 17 CLUSTER_SIZE 18 CONTIGUOUS no EXTENSION 63 FILE_MONITORING no GLOBAL_BUFFER_COUNT 0 NAME "" ORGANIZATION indexed OWNER [MAKE_JH3163] PROTECTION (system:RWED, owner:RWED, group:RWED, world:RE) RECORD BLOCK_SPAN yes CARRIAGE_CONTROL carriage_return FORMAT variable SIZE 8223 AREA 0 ALLOCATION 252 BEST_TRY_CONTIGUOUS yes BUCKET_SIZE 17 EXTENSION 63 KEY 0 CHANGES no DATA_AREA 0 DATA_FILL 50 DATA_KEY_COMPRESSION yes DATA_RECORD_COMPRESSION yes DUPLICATES no INDEX_AREA 0 INDEX_COMPRESSION yes INDEX_FILL 50 LEVEL1_INDEX_AREA 0 NAME "" NULL_KEY no PROLOG 3 SEG0_LENGTH 31 SEG0_POSITION 0 TYPE string MAKE_DIABLO$ -- Jon Harms Tech Dev System Developer jharms@cerner.com - http://www.cerner.com/ ================================================================================ Archive-Date: Thu, 10 Feb 2000 15:38:31 -0500 From: "EW" Reply-To: Info-MultiNet@process.com Subject: MultiNet V4.1B Setup Date: Thu, 10 Feb 2000 13:39:58 -0700 To: INFO-MULTINET@PROCESS.COM We are running MultiNet V4.1B on VMS 5.5-2. We are now basically a "closed" network with all Win95 PC inside it running a custom built telnet application to the VAX. This "closed" network also allow the PCs talk to the outside Mainframes through a NT PC running as Gateway router. This NT router will do all the IP filtering. The dafault gateway for the VAX is not pointing to this NT router but to another NT. So if any unauthorized PC from outside trying to ping to the VAX, it will not respond to the NT router. If I let access to an outside PC to the VAX, I now will allow its IP into the NT router; also I will set its IP into the static route table using MU SET/ROUTE command to point to the NT router. I have some questions here: 1. Is this primitive setup secure enough to stop normal users to come into the VAX. That NT router is going to be replaced with a Cisco switch pretty soon. Will that make any difference. 2. What can I do with the existing MultiNet V4.1B setup to improve the security ? 3. Will the UserName/PassWord combination on the VAX strong enough to deter potential users to come in and delete some files or access the VAX in anyway ? Please excuse my long question. I don't have the experience in the MultiNet V4.1 at all. Thanks. ew ================================================================================ Archive-Date: Thu, 10 Feb 2000 16:30:36 -0500 Date: Thu, 10 Feb 2000 13:25:58 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: MultiNet V4.1B Setup Message-ID: <0002101322310.25943-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Feb 2000 13:39 -0700, EW wrote: > We are running MultiNet V4.1B on VMS 5.5-2. We are now basically a "closed" > network with all Win95 PC inside it running a custom built telnet > application to the VAX. This "closed" network also allow the PCs talk to > the outside Mainframes through a NT PC running as Gateway router. This NT > router will do all the IP filtering. The dafault gateway for the VAX is not > pointing to this NT router but to another NT. So if any unauthorized PC > from outside trying to ping to the VAX, it will not respond to the NT > router. > > If I let access to an outside PC to the VAX, I now will allow its IP into > the NT router; also I will set its IP into the static route table using MU > SET/ROUTE command to point to the NT router. I have some questions here: > > 1. Is this primitive setup secure enough to stop normal users to come into > the VAX. That NT router is going to be replaced with a Cisco switch pretty > soon. Will that make any difference. Switches don't route unless they're the so-called "layer 3" switches (which are routers). > 2. What can I do with the existing MultiNet V4.1B setup to improve the > security ? Disable all services that aren't needed such as echo, time, daytime, and so on: $ MULTINET CONFIG/SERVER > SHOW > DISABLE blah > SAVE > RESTART > EXIT > 3. Will the UserName/PassWord combination on the VAX strong enough to deter > potential users to come in and delete some files or access the VAX in anyway > ? No. Username/password authentication is weak and easily circumvented. If you really care about security use one-time passwords. Much less convenient but can be designed to be more secure. MultiNet includes facilities to support one-time passwords ("Secure/IP"). > Please excuse my long question. I don't have the experience in the MultiNet > V4.1 at all. -Dan Wing ================================================================================ Archive-Date: Thu, 10 Feb 2000 16:40:24 -0500 Date: Thu, 10 Feb 2000 15:35:47 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: MultiNet V4.1B Setup Dan Wing writes: > >> 2. What can I do with the existing MultiNet V4.1B setup to improve the >> security ? > >Disable all services that aren't needed such as echo, time, daytime, and >so on: > > $ MULTINET CONFIG/SERVER > > SHOW > > DISABLE blah > > SAVE > > RESTART > > EXIT > You can also use packet filtering in MultiNet to block certain kinds of packets. See the V4.1B manual (and/or the release notes) for info on packet filtering. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Thu, 10 Feb 2000 17:33:45 -0500 Date: Thu, 10 Feb 2000 16:28:06 -0600 From: "Tom Lynch" Reply-To: Info-MultiNet@process.com To: Subject: NFS MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII I have two systems an 8400 and a 7630 both running identical versions of Multinet... Process Software MultiNet V4.2 Rev A-X, AlphaServer 8400 5/300, OpenVMS AXP V6.2 Process Software MultiNet V4.2 Rev A-X, DEC 7000 Model 630, OpenVMS AXP V6.2 I've exported a directory on both systems that are about the same size i.e. number of files and content. When I map a drive to the 8400 and open it up it takes about 5 seconds to show me the files. It takes about 5 - 10 minutes on the 7630. Looking at a tcpdump on both systems, I see thousands of netbios broadcasts when I try to open the 7630 mount point. I don't see any netbios broadcasts when I open the 8400 mount point. e.g. ... 15:51:05.00 10.2.0.10.netbios-ns > 10.2.255.255.netbios-ns: 8df4+ NBNS?[ INFO SE RVICES .] (50) 4500 004e 342a 0000 8011 f267 0a02 000a E..N4*.....g.... 0a02 ffff 0089 0089 003a d6e5 8df4 0110 .........:...... 0001 0000 0000 0000 2045 4a45 4f45 4745 ........ EJEOEGE 5043 4146 4445 4646 4346 4745 4a45 4445 PCAFDEFFCFGEJEDE 4646 4443 4143 4141 4100 0020 0001 FFDCACAAA.. .. 15:51:05.00 10.2.0.10.netbios-ns > 10.2.255.255.netbios-ns: 8df8+ NBNS?[ SYBASE .] (50) 4500 004e 352a 0000 8011 f167 0a02 000a E..N5*.....g.... 0a02 ffff 0089 0089 003a 0fef 8df8 0110 .........:...... 0001 0000 0000 0000 2046 4446 4a45 4345 ........ FDFJECE 4246 4445 4643 4143 4143 4143 4143 4143 BFDEFCACACACACAC 4143 4143 4143 4141 4100 0020 0001 ACACACAAA.. .. 15:51:05.00 10.2.0.10.netbios-dgm > 10.2.255.255.netbios-dgm: udp 358 4500 0182 362a 0000 8011 ef33 0a02 000a E...6*.....3.... 0a02 ffff 008a 008a 016e a383 1102 8df6 .........n...... ... Any help would be apprecaited. Thanks, Tom Thomas W. Lynch Senior Technical Engineer University of Wisconsin Medical Foundation ================================================================================ Archive-Date: Fri, 11 Feb 2000 08:51:33 -0500 From: gartmann@immunbio.mpg.de (Christoph Gartmann) Subject: 553 Mail to not allowed; forgoing mail address prohibited Date: 11 Feb 2000 12:26:42 GMT Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Hello, one of our users complained that a return receipt didn't get through. It was rejected by our SMTP-server running Multinet 4.2 plus patches with the following error message: 553 Mail to not allowed; forgoing mail address prohibited I dont't understand this message. What does it mean? Or why is the return receipt rejected? Regards, Christoph Gartmann -----------------------------------------------------------------------+ | Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 | | Immunbiologie | | Postfach 1169 Internet: gartmann@immunbio.mpg.de | | D-79011 Freiburg, FRG | +------------ http://www.immunbio.mpg.de/english/menue.html -----------+ ================================================================================ Archive-Date: Fri, 11 Feb 2000 08:56:40 -0500 Date: Fri, 11 Feb 2000 7:52:05 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: 553 Mail to not allowed; forgoing mail address prohibited gartmann@immunbio.mpg.de (Christoph Gartmann) writes: > >one of our users complained that a return receipt didn't get through. It was >rejected by our SMTP-server running Multinet 4.2 plus patches with the >following error message: > 553 Mail to not allowed; forgoing mail address prohibited >I dont't understand this message. What does it mean? Or why is the return >receipt rejected? > It matched one of your SMTP reject rules. The text "forgoing mail address prohibited" appears to be defined in your rejection rule file (MULTINET:SMTP_SERVER_REJECT.). Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 11 Feb 2000 10:53:46 -0500 From: gartmann@immunbio.mpg.de (Christoph Gartmann) Subject: RE: 553 Mail to not allowed; forgoing mail address prohibited Date: 11 Feb 2000 15:40:36 GMT Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM In article <000211075205.202000c1@process.com>, Hunter Goatley writes: >gartmann@immunbio.mpg.de (Christoph Gartmann) writes: >> >>one of our users complained that a return receipt didn't get through. It was >>rejected by our SMTP-server running Multinet 4.2 plus patches with the >>following error message: >> 553 Mail to not allowed; forgoing mail address prohibited >>I dont't understand this message. What does it mean? Or why is the return >>receipt rejected? >> >It matched one of your SMTP reject rules. The text "forgoing mail >address prohibited" appears to be defined in your rejection rule file >(MULTINET:SMTP_SERVER_REJECT.). This was my first guess as well. But there is no such text in my reject file... Regards, Christoph Gartmann -----------------------------------------------------------------------+ | Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 | | Immunbiologie | | Postfach 1169 Internet: gartmann@immunbio.mpg.de | | D-79011 Freiburg, FRG | +------------ http://www.immunbio.mpg.de/english/menue.html -----------+ ================================================================================ Archive-Date: Fri, 11 Feb 2000 11:04:10 -0500 Date: Fri, 11 Feb 2000 9:59:31 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: gartmann@immunbio.mpg.de Subject: RE: 553 Mail to not allowed; forgoing mail address prohibited gartmann@immunbio.mpg.de (Christoph Gartmann) writes: > >>It matched one of your SMTP reject rules. The text "forgoing mail >>address prohibited" appears to be defined in your rejection rule file >>(MULTINET:SMTP_SERVER_REJECT.). > >This was my first guess as well. But there is no such text in my reject file... > Hmmm.... Well, the code is definitely creating the message text using what was found in the reject file. I've also done a search on all the sources, and "forgoing" isn't in there (it's also misspelled). Do you have MULTINET_SMTP_SERVER_REJECT_FILE pointing to a different file, perhaps? Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 11 Feb 2000 16:37:54 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Fri, 11 Feb 2000 16:37:21 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: MASTER_SERVER-070_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: MASTER_SERVER-070_A042 Description: Various MultiNet master server fixes Release date: 11-FEB-2000 Versions: V4.2A,V4.1B,V4.1A,V4.0C ftp://ftp.multinet.process.com/patches/multinet042/master_server-070_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- The MASTER_SERVER-070_A042 kit updates MultiNet V4.2 Rev A, V4.0 Rev C, V4.1A and V4.1B with a new version of SERVER.EXE which include following changes: Changes since 4.2A 1) Go to AST level before checking the number of active servers and possibly setting the MAX_SERVERS_REACHED flag. This corrects a problem where the master server would get slightly off on whether or not a new request could be handled and cause a delay in handling the request. 2) A potential buffer overflow that could corrupt the master servers stack has been corrected. 3) Make certain that the number of active servers is only adjusted when at AST level to avoid possible synchronization problems that could let the master server get confused about whether or not more requests can be accepted. 4) Close the UDP socket if connect failed when doing DNS resolver queries. This prevents UDP connections from building up on heavily loaded systems and eventually causing the system to run out of available sockets. 5) Always issue a new read to the termination mailbox. This prevents the server count from erroneously getting stuck at the maximum and no new accepts for incoming requests being issued. This would cause a lot of connections to be left in Close Wait state. 6) Correct a possible denial of service attack. 7) Internal POP3 module will accept null as valid Application Protocol Version String to support new Eduroa Version 4. Changes since 4.1B 1) Change to the memory allocation routines to prevent corruption that was causing the MASTER_SERVER to crash. 2) Change to memory allocation routine to close a small timing window on AXP that was causing the MASTER_SERVER to crash. Changes since 4.1A 1) MASTER_SERVER were crashing without leaving process dump due to exhausted channels, at the same time, leaving large number of permanent mailboxes behind, which may eventually exhaust the available mailboxes on the system and hang the system. This regression in 4.0C for UCX service is corrected to properly reuse the permanent mailbox created by the master server. 2) Channel leak in the UCX service was fixed which was causing server crashing with exhausted channels. 3) Possible server ACCVIO on AXP was fixed 4) More problems with UCX service are fixed and channel count usage is reduced to one. Changes since 4.0C 1) The logical MULTINET_POP3_INPUT_WAIT can be defined as the amount of time the POP3 server should wait for input from the client before closing the connection. The value is a normal VMS time string. 2) Just to be more lenient, the MASTER_SERVER now automatically uppercases all program names when it reads the services configuration file. You do not have to reboot after installing this kit. After installing, execute: @MULTINET:START_SERVER to restart the new master server. [End of ECO announcement] ================================================================================ Archive-Date: Fri, 11 Feb 2000 16:39:27 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Fri, 11 Feb 2000 16:38:56 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: FTP-040_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: FTP-040_A042 Description: MultiNet FTP update Release date: 11-FEB-2000 Versions: V4.2A, V4.1B, V4.1A ftp://ftp.multinet.process.com/patches/multinet042/ftp-040_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- This ECO kit provides a new version of FTP and applies to Multinet V4.2 Rev A, V4.1 Rev A and V4.1 Rev B. This kit provides the following changes to V4.2A: DE 4545,5622 - Fix FTP_SERVER.EXE so that it doesn't crash when attempting to delete a file with MULTINET_FTP_UNIX_STYLE_BY_DEFAULT defined. Changed from SYS$ERASE & SYS$RENAME to LIB$DELETE_FILE and LIB$RENAME_FILE to let VMS take care of more of the details involved. DE 4643 - Correct a problem with RMDIR on OpenVMS 7.2 AXP that prevented directories from being deleted. DE 4774 - Correct a problem with transferring fixed length records in image mode when the record size is an odd number of bytes. New images for FTP.EXE and FTP_SERVER.EXE are supplied. You do not have to reboot after installing this kit. New FTP sessions will automatically use the new server or client image. [End of ECO announcement] ================================================================================ Archive-Date: Mon, 14 Feb 2000 11:16:40 -0500 Date: Mon, 14 Feb 2000 10:08:44 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Invitation to join MultiNet & TCPware Teleconference Process Software invites all MultiNet and TCPware customers to participate in: Online MultiNet and TCPware TCP/IP TeleConference February 17th 1-1:45pm EST Process Software's Senior Engineering and Product Marketing teams will bring you information on maximizing your TCP/IP for OpenVMS product and learning about upcoming technologies and product advancements. Teleconference will cover: - TCPware and MultiNet Product Roadmaps for 2000 - Optimizing the performance of Process Software's TCP/IP stacks - Introduction on Process Software's Paired Network Interface feature which increases your networks throughput and adds reliability - Performance testing results - Question and answer period for participants Register now for the conference at http://www.process.com/aspscripts/telebrief/ ================================================================================ Archive-Date: Mon, 14 Feb 2000 11:17:01 -0500 Date: Mon, 14 Feb 2000 10:08:44 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Invitation to join MultiNet & TCPware Teleconference Process Software invites all MultiNet and TCPware customers to participate in: Online MultiNet and TCPware TCP/IP TeleConference February 17th 1-1:45pm EST Process Software's Senior Engineering and Product Marketing teams will bring you information on maximizing your TCP/IP for OpenVMS product and learning about upcoming technologies and product advancements. Teleconference will cover: - TCPware and MultiNet Product Roadmaps for 2000 - Optimizing the performance of Process Software's TCP/IP stacks - Introduction on Process Software's Paired Network Interface feature which increases your networks throughput and adds reliability - Performance testing results - Question and answer period for participants Register now for the conference at http://www.process.com/aspscripts/telebrief/ ================================================================================ Archive-Date: Tue, 15 Feb 2000 19:14:58 -0500 From: "Paul Higgins" Reply-To: Info-MultiNet@process.com Subject: Can't get RSH to execute without prompting for a password Date: Sun, 13 Feb 2000 00:23:38 -0800 To: INFO-MULTINET@PROCESS.COM I am trying to issue a Remote Shell (rsh) on an NT box and have it execute on a Alpha box. The rsh command is working, however; I am getting prompted for the password of the login account on the Alpha box. I need to issue this command from a dos batch file so I do not want a password prompt and entry. I have tried setting up a proxy on the Alpha box and even eliminating the need for a password on the Alpha login account but it still prompts for a password. The basic NT rsh command does not seem to have any provision for including a password, only a username. Here is an example of the rsh command: rsh omega -l username dir I have another Alpha box running ucx and this command works fine without prompting for a password. Is this a limitation of multinet or am I missing something? Any suggestions would be appreciated. I am running OPENVMS 6.2 with multinet 4.0 (40). One large quirk. This machine is running under a Y2K rollback to 1972. ================================================================================ Archive-Date: Tue, 15 Feb 2000 20:17:01 -0500 Date: Tue, 15 Feb 2000 19:12:12 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: Can't get RSH to execute without prompting for a password "Paul Higgins" writes: > >I am trying to issue a Remote Shell (rsh) on an NT box and have it execute >on a Alpha box. The rsh command is working, however; I am getting prompted >for the password of the login account on the Alpha box. I assume you created the .RHOSTS file in the SYS$LOGIN directory of the target account? Or MULTINET:HOSTS.EQUIV? Did you follow the instructions on the MultiNet Admin Guide for "Configuring `R' Services"? Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Tue, 15 Feb 2000 22:54:37 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Tue, 15 Feb 2000 22:54:05 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: NFS_SERVER-020_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: NFS_SERVER-020_A042 Description: Fixes a file truncation problem. Release date: 15-FEB-2000 Versions: V4.2A ftp://ftp.multinet.process.com/patches/multinet042/nfs_server-020_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- NFS_SERVER-020_A042 This kit updates MultiNet V4.2 Rev A with a new version of the NFS_SERVER.EXE which corrects the following problems: SWL 30-JUN-1999 o The NFS_SERVER process will crash the system (while in KERNEL mode) if a request to access a file coincides with a concurrent access which is converting the file to stream, causing the second request to be waited.(d/e 4045) SWL 28-SEP-1999 o The NFS_SERVER process will sometimes incorrectly truncate files when it processes write requests out of sequence.(d/e 4246) If the NFS Server process is currently unresponsive and running in KERNEL mode a reboot will be necessary. Otherwise restarting the NFS Server is sufficient $ MULTINET NETCONTROL NFS RESTART [End of ECO announcement] ================================================================================ Archive-Date: Wed, 16 Feb 2000 12:40:45 -0500 Date: Wed, 16 Feb 2000 09:38:33 -0800 From: Diane Burns-Giles Reply-To: Info-MultiNet@process.com Subject: security questions/help To: info-multinet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" I have very little knowledge about security issues regarding the vms operating system. In particular it has been brought to my attention that I should turn off telnet and finger so that the Alpha's won't be so vulnerable from hackers. Can anybody shed some light on this matter and direct me to articles or third party software that has worked for your environment. Can you briefly explain why computers are more vulnerable and how you have addressed the same problem. thanks in advance, diane ================================================================================ Archive-Date: Wed, 16 Feb 2000 13:17:50 -0500 From: mdixon2@csc.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Date: Wed, 16 Feb 2000 13:12:31 -0500 Subject: Re: security questions/help MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Diane: I feel that blindly turning off Finger and Telnet is not the answer to securing your system. MultiNet comes with many services pre-defined and enabled by default. A significant number of these services can lead to problems for you from hackers. I have heard arguments that "Would a hacker know what to do once they got to the "$" prompt?", that does not matter, you don't want them to get that far. A safe bet is to understand what you really use on your system. Look at the IP services offered by default via MultiNet (MU CONFIG/SERVER) and disable any service you know that you do not require. Be sure you track what you turn off in case you later find that you needed it. IMHO, there is no simple answer. Michael Dixon OpenVMS Systems Consultant burns@salk.edu on 02/16/2000 12:38:33 PM Please respond to Info-MultiNet@process.com To: info-multinet@process.com cc: (bcc: Michael Dixon/COGG/SUBCONTRACTOR/CSC) Subject: security questions/help I have very little knowledge about security issues regarding the vms operating system. In particular it has been brought to my attention that I should turn off telnet and finger so that the Alpha's won't be so vulnerable from hackers. Can anybody shed some light on this matter and direct me to articles or third party software that has worked for your environment. Can you briefly explain why computers are more vulnerable and how you have addressed the same problem. thanks in advance, diane ================================================================================ Archive-Date: Wed, 16 Feb 2000 13:41:45 -0500 From: Alan Reply-To: Info-MultiNet@process.com Subject: How does multinet redirect to SYS$INPUT ? Date: Wed, 16 Feb 2000 17:22:13 GMT To: INFO-MULTINET@PROCESS.COM I have just written an application that is launched by multinet when it receives a connection on a port. The application then reads from SYS$INPUT to find out what data has been send and sends an appropriate response. I was wondering how multinet sets up SYS$INPUT of the process that it is creating (using SYS$CREPRC) to be the port that it has just opened. Anyone know ? --- Alan Campbell alanc@mullen.demon.co.uk Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Wed, 16 Feb 2000 14:01:33 -0500 Date: Wed, 16 Feb 2000 12:56:34 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: How does multinet redirect to SYS$INPUT ? Alan writes: > >I was wondering how multinet sets up SYS$INPUT of the process that it >is creating (using SYS$CREPRC) to be the port that it has just opened. > In the call to $CREPRC, is simply specifies the INETx: or BG: device associated with the port as the input for the process. Hunter ------ Hunter Goatley, Process Software, http://www.process.com http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 16 Feb 2000 15:25:56 -0500 Sender: goathunter@PROCESS.COM From: Tom Ricci Reply-To: Info-MultiNet@process.com To: Info-MultiNet Subject: DNSworks Beta 2 Now Available Date: Wed, 16 Feb 2000 09:28:45 -0500 DNSworks Beta 2 Now Available Many thanks to those of you have registered for Process Software's DNSworks free online Domain analysis and optimization service beta program. With your help, we have fixed the reported bugs and been able to enhance the service. Hopefully you have benefited from the DNS analysis reporting and solutions online service. In Beta 2, we have made the scheduling service fully functional. You can now enter the domains to be analyzed once, schedule analyses to be run in the background, and receive HTML reports daily, weekly, or monthly, as you prefer, via email. No other interaction is required. If you have already registered for the service, simply return to your Service profile and select the frequency to run reports. If you haven't tried the service yet, go to http://www.dnsworks.com and register as a first time user, follow the menu, and you'll be up and running in minutes. Thank you again for your participation. All participants who return the Beta feedback form will receive a gift and entered into a drawing for a Palm Pilot. The beta program will end by the end of the month. Tom Ricci ======================================= Tom Ricci, Director of Marketing Communications Process Software Corporation 959 Concord St., Framingham, MA 01701 (508) 626-7546/FAX: (508) 879-0042 ricci@process.com / www.process.com ======================================= ================================================================================ Archive-Date: Wed, 16 Feb 2000 16:34:31 -0500 From: "Kattalia, Mark" Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Subject: How SMTP percieves addresses(DNS question) Date: Wed, 16 Feb 2000 13:28:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I Have a question about how the SMTP service percieves and translates addressing. I notice that some companies only register their domain name portion of an address as an MX record instead of an A record. I have our domain name registered as a MX record and an A record. This works well for us. It stops people from getting to our website by just typing callan.com, but that's okay with me. I notice that SMTP sometimes has trouble translating an MX-only domain name retrying to send to that particular address multiple times. It has always delivered to this type of address, but it sometimes takes a while. Which is the correct usage? Should the domain name be registered as only MX or A or both? What are the liabilities with either method? Mark Kattalia CALLAN ASSOCIATES Inc. kattalia@callan.com (415) 978-3099 ================================================================================ Archive-Date: Wed, 16 Feb 2000 16:38:16 -0500 Date: Wed, 16 Feb 2000 15:33:30 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: How SMTP percieves addresses(DNS question) "Kattalia, Mark" writes: > >I Have a question about how the SMTP service percieves and translates >addressing. > >I notice that some companies only register their domain name portion of an >address as an MX record instead of an A record. > >I have our domain name registered as a MX record and an A record. This works >well for us. It stops people from getting to our website by just typing >callan.com, but that's okay with me. > >I notice that SMTP sometimes has trouble translating an MX-only domain name >retrying to send to that particular address multiple times. It has always >delivered to this type of address, but it sometimes takes a while. > Unless there are DNS problems or the target node is not reachable, it shouldn't make a difference. >Which is the correct usage? Should the domain name be registered as only MX >or A or both? What are the liabilities with either method? > It doesn't matter, unless you want to have multiple nodes that are capable of handling mail for your domain name, which is the whole point to MX records. Note that some domain names are MX records simply because they are "virtual domains" (my term), without any corresponding ftp site, web site, etc. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Wed, 16 Feb 2000 16:43:00 -0500 From: Javier Henderson Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Feb 2000 13:38:04 -0800 (PST) To: Info-MultiNet@process.com Subject: How SMTP percieves addresses(DNS question) References: <59B5722E861AD211AC26AA0004002804FB43F7@poster.callan.com> Kattalia, Mark writes: > I Have a question about how the SMTP service percieves and translates > addressing. > > I notice that some companies only register their domain name portion of an > address as an MX record instead of an A record. > > I have our domain name registered as a MX record and an A record. This works > well for us. It stops people from getting to our website by just typing > callan.com, but that's okay with me. > > I notice that SMTP sometimes has trouble translating an MX-only domain name > retrying to send to that particular address multiple times. It has always > delivered to this type of address, but it sometimes takes a while. > > Which is the correct usage? Should the domain name be registered as only MX > or A or both? What are the liabilities with either method? I think there's a nomenclature confusion here, but I could be wrong, the usage of "registering" above seems a bit off. Whatever address you tell people to use for email (ie, callan.com) should have an MX record, which then has to point to a hostname for which an Address (A) resource record must exist (though this requirement gets violated often and people point an MX record to a CNAME). If you want callan.com to resolve to an IP address, for the benefit of web surfers, that should work as well. All MTA's I'm familiar with will do an MX lookup first, and if that fails, an A lookup on the right-hand portion of the address (again, callan.com in your case). So if you had callan.com resolving to an A record that's different than what you have for MX, that shouldn't break things. "Shouldn't" being the operative word. -jav ================================================================================ Archive-Date: Wed, 16 Feb 2000 17:00:29 -0500 Date: Wed, 16 Feb 2000 13:55:29 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: How SMTP percieves addresses(DNS question) Message-ID: <0002161346320.11021-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Feb 2000 13:38 -0800, Javier Henderson wrote: ... > All MTA's I'm > familiar with will do an MX lookup first, and if that fails, an A > lookup on the right-hand portion of the address (again, callan.com in > your case). So if you had callan.com resolving to an A record that's > different than what you have for MX, that shouldn't break things. This behavior is required by RFC1123, which is now about 11 years old. -d ================================================================================ Archive-Date: Thu, 17 Feb 2000 07:02:18 -0500 From: Alan Reply-To: Info-MultiNet@process.com Subject: RE: How does multinet redirect to SYS$INPUT ? Date: Thu, 17 Feb 2000 11:30:55 GMT To: INFO-MULTINET@PROCESS.COM In article <009E5C05.B7E20F77.1@ALPHA.WKU.EDU>, Hunter Goatley wrote: > Alan writes: > > > >I was wondering how multinet sets up SYS$INPUT of the process that it > >is creating (using SYS$CREPRC) to be the port that it has just opened. > > > In the call to $CREPRC, is simply specifies the INETx: or BG: device > associated with the port as the input for the process. > Thanks. Do you know how I can get another process (one that is already running detatched) to access this device. Whenever I try, I am told that it is already allocated to another user. I have tried de-assigning the channel ($DASSGN) and de-allocating the device ($DALLOC), but still get the same message. What I want to do is write a program that will wait for a connection on a port. When it receives a connection I want to pass control of the conection to another process (running detached) so that it can process the message and reply to the client. I know that Multinet 'sort of provides' this functionality, but I would like to control it myself, and I am interested in how it works anyway ! TIA --- Alan Campbell alanc@mullen.demon.co.uk Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Thu, 17 Feb 2000 07:56:38 -0500 From: Bernhard Wulf Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Subject: noecho in telnet to cisco router Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Feb 2000 12:55:53 +0100 To: INFO-MULTINET@PROCESS.COM Working on a problem since a couple of time... I want to connect to the collected knowledge in this newsgroup. Perhaps this was fixed a 1000 times before. My problem is... Telnet to a CISCO Router is giving no echo on the screen. All command must be typed in blind, there is no way ( up to now ) to get the input back on my terminal. Telnet Version... $ telnet /ver This is MultiNet TELNET-32 Version V4.1(103) Cut and Paste from a session with my CISCO $ telnet /debug /log cbrout Trying... Connected to RHR-CBROUT.DSAG.DEUTSCHE-SHELL.DE. *S*IAC,DO,SUPPRESS GO AHEAD (DONT REPLY)* *S*IAC,WILL,TERMINAL TYPE (DONT REPLY)* *S*IAC,DO,ECHO (DONT REPLY)* *R*IAC,WILL,ECHO (DONT REPLY)* *R*IAC,WILL,SUPPRESS GO AHEAD (DONT REPLY)* *R*IAC,DO,TERMINAL TYPE (DONT REPLY)* *R*IAC,DO,WINDOW SIZE (REPLY)* *S*IAC,WILL,WINDOW SIZE (DONT REPLY)* *S*SUBOPTION, WINDOW SIZE is 80x24* User Access Verification Password: *R*SUBOPTION, TERMINAL TYPE- REQUEST TO SEND* *S*SUBOPTION, TERMINAL TYPE is "vt300"* CBROUT> <<< gave an "ena" here. *S*SUBOPTION, WINDOW SIZE is 80x24* Password: CBROUT# <<< see no echo, I told the CISCO "conf net" Host or network configuration file [host]? Address of remote host [172.17.193.10 ]? Name of configuration file [dia2:access.lis]? Configure using dia2:access.lis from 172.17.193.10? [confirm] Loading dia2:access.lis from 172.17.193.10 (via Ethernet1/0): !!! [OK - 12937/30671 bytes] And now the contents of the logfile... User Access Verification Password: CBROUT> <<< gave an "ena" here. Password: CBROUT# <<< again, nothings coming back !!! I gave "conf net" Host or network configuration file [host]? Address of remote host [172.17.193.1 Name of configuration file [dia2:access.lis]? Configure using dia2:access.lis from 172.17.193.10? [confirm] Loading dia2:access.lis from 172.17.193.10 (via Ethernet1/0): !!! [OK - 12937/30671 bytes] CBROUT# Many thanks. For further info, don't hesitate to contact me. Bernhard Wulf Wulf@decus.decus.de ================================================================================ Archive-Date: Thu, 17 Feb 2000 08:16:11 -0500 Sender: schreiber@process.com Date: Thu, 17 Feb 2000 08:11:16 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: noecho in telnet to cisco router Bernhard Wulf writes: >Password: >CBROUT> <<< gave an "ena" here. >Password: >CBROUT# <<< again, nothings coming back !!! I gave "conf net" > >Many thanks. >For further info, don't hesitate to contact me. The first thing I would suggest is that you do a TCPdump of the connection. The telnet negotiation isn't telling the client not to echo, so I'm guessing your cisco router is doing it. The easy way to check is by doing a tcpdump of the connection, you can see if the client sends the characters you typed, and we can see if the server sends the echoed characters back and we don't display them, or if the server doesn't send them back. You might want to send the tcpdump directly to Process Software [or directly to me] and not the list itself, since it may have your password in it. [you could probably do the trace starting after you've logged in but before you've typed anything]. I would recommend a tcpdump command of something like: mu tcpdump/sna=2000/numer/verb/hex host cbrout port 23 -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Thu, 17 Feb 2000 11:46:53 -0500 Date: Thu, 17 Feb 2000 8:41:54 -0800 From: "Nik Zapantis, UVic Physics, Victoria BC (250)721-7729" Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM CC: ZAPANTIS@phys.UVic.CA Subject: MU DNS+MS SRV records? Does MU DNS server (4.2A) support SRV (MS Active directory) records? TIA Nik ================================================================================ Archive-Date: Thu, 17 Feb 2000 12:03:23 -0500 Date: Thu, 17 Feb 2000 11:58:14 -0500 From: Michael Corbett Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 To: info-multinet@process.com Subject: FW: MU DNS+MS SRV records? Content-Type: text/plain; charset=us-ascii > From: Nik Zapantis, UVic Physics, Victoria BC (250)721-7729 > > Does MU DNS server (4.2A) support SRV (MS Active directory) records? > Yes. 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: Thu, 17 Feb 2000 14:00:32 -0500 Date: Thu, 17 Feb 2000 10:51:04 -0800 From: Mark Berryman Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Subject: Re: noecho in telnet to cisco router Content-Type: text/plain; charset=us-ascii To: INFO-MULTINET@PROCESS.COM Bernhard Wulf wrote: > > Working on a problem since a couple of time... > I want to connect to the collected knowledge in this newsgroup. > Perhaps this was fixed a 1000 times before. > > My problem is... > Telnet to a CISCO Router is giving no echo on the screen. > All command must be typed in blind, there is no way ( up to now ) to get > the input back on my terminal. You don't say what version of the cisco IOS are you running. This is a bug in the Cisco IOS, not an issue with Multinet. IOS versions prior to 12 are quite a bit more susceptible to this problem than we have found v12.0 to be. Basically, if a telnet session does not exit cleanly from the router, it can trigger some problem on the router such that all subsequent telnet sessions to it get no echo. The only way we have ever found to clear the problem is to reboot the router. Mark Berryman Mark.Berryman@Mvb.Saic.Com ================================================================================ Archive-Date: Thu, 17 Feb 2000 14:22:13 -0500 Sender: goatley@triton.process.com Return-Path: Date: Thu, 17 Feb 2000 11:06:31 -0800 From: "David Spencer, Internet Handyman" Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: MultiNet ECO kits - are we getting near another point-release? I've been doing a little housekeeping lately and noticed that there have been a large number of ECOs issued since the last 4.2 release. Is there any word on when or if a 4.3 release wll be made to customers? I'm starting to get the feeling that I might have missed an ECO or two along the way. -- Dave Spencer, PageWeavers ================================================================================ Archive-Date: Thu, 17 Feb 2000 14:23:59 -0500 Date: Thu, 17 Feb 2000 13:19:04 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: MultiNet ECO kits - are we getting near another point-release? "David Spencer, Internet Handyman" writes: > >I've been doing a little housekeeping lately and noticed that there have >been a large number of ECOs issued since the last 4.2 release. Is there >any word on when or if a 4.3 release wll be made to customers? I'm starting >to get the feeling that I might have missed an ECO or two along the way. > MultiNet V4.3 is scheduled for sometime this summer. In the meantime, we're working on a list of "recommended ECOs" for V4.2A to help ensure that everyone is running everything they should be running. That list should be ready in the next week or so. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Thu, 17 Feb 2000 14:44:10 -0500 Date: Thu, 17 Feb 2000 11:39:15 -0800 From: "David Spencer, Internet Handyman" Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: MultiNet ECO kits - are we getting near another point-release? > MultiNet V4.3 is scheduled for sometime this summer. In the meantime, > we're working on a list of "recommended ECOs" for V4.2A to help ensure > that everyone is running everything they should be running. That list > should be ready in the next week or so. Thanks for the update Hunter! ================================================================================ Archive-Date: Thu, 17 Feb 2000 14:44:27 -0500 Date: Thu, 17 Feb 2000 11:34:11 -0800 (PST) From: Aaron Leonard Subject: Re: noecho in telnet to cisco router Sender: Aaron Leonard To: Info-MultiNet@process.com Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > > Working on a problem since a couple of time... > > I want to connect to the collected knowledge in this newsgroup. > > Perhaps this was fixed a 1000 times before. > > > > My problem is... > > Telnet to a CISCO Router is giving no echo on the screen. > > All command must be typed in blind, there is no way ( up to now ) to get > > the input back on my terminal. > You don't say what version of the cisco IOS are you running. This is a > bug in the Cisco IOS, not an issue with Multinet. IOS versions prior to > 12 are quite a bit more susceptible to this problem than we have found > v12.0 to be. Basically, if a telnet session does not exit cleanly from > the router, it can trigger some problem on the router such that all > subsequent telnet sessions to it get no echo. The only way we have ever > found to clear the problem is to reboot the router. > Mark Berryman Yeah, it looks like the IOS telnet server has had this problem crop up several times over the years. The most prominent instance of it is CSCdj22622, reported against 11.2(1) 11.1(11)CA1 11.0(14), fixed in 11.3(1.4) 11.2(11.3) 11.1(17.1)* 11.0(19.4). I.e. most any IOS release since June '98 should have the fix. Aaron ================================================================================ Archive-Date: Fri, 18 Feb 2000 09:23:51 -0500 Date: Fri, 18 Feb 2000 8:23:16 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: MultiNet-Announce@LISTS.PROCESS.COM Subject: MASTER_SERVER-070_A042 ECO put on hold A problem with the MASTER_SERVER-070_A042 ECO kit (released on 8-FEB-2000) has been found when that kit is used on VAXen. Process Software recommends that you do not install that ECO kit, especially on VAXen. A new kit will be made available as soon as the problem has been fixed. We apologize for any inconvenience this problem has caused. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 18 Feb 2000 09:39:34 -0500 Date: Fri, 18 Feb 2000 8:38:56 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: MultiNet-Announce@LISTS.PROCESS.COM, TCPware-Announce@LISTS.PROCESS.COM Subject: Process Software TCP/IP Telebriefing replay now available On Thursday, 17-FEB-2000, Process Software held a TCP/IP telebriefing for our customers. If you could not attend, we are providing a replay of the telebriefing, available now through 24-FEB-2000 at the following numbers: USA #: 800-475-6701 International #: 320-365-3844 After dialing the number, please enter the following access code when prompted: 501570 Here is the original description: > >Process Software is pleased that you will be joining our MultiNet and >TCPware TCP/IP Telebriefing this Thursday, February 17th at 1:00pm EST. > >Our engineering and marketing team look forward to providing you information >on maximizing your TCP/IP for OpenVMS product and learning about upcoming >technologies and product advancements. The Telebriefing will cover: > >- TCPware and MultiNet Product Roadmaps for 2000 >- Optimizing the performance of Process Software's TCP/IP stacks >- Introduction on Process Software's Paired Network Interface feature > which increases your networks throughput and adds reliability >- Performance testing results >- Question and answer period for participants Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 18 Feb 2000 10:35:25 -0500 Date: Fri, 18 Feb 2000 08:34:52 -0700 To: Info-TCPware@process.com, info-multinet@process.com From: Jim Mehlhop Reply-To: Info-MultiNet@process.com Subject: Re: Question on MPSYNC patch for Multinet MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Yes the kernel-update-021_a042 eco can be installed on MN4.1a or b Jim At 07:36 AM 2/18/00 -0600, you wrote: >In the teleconference, you spoke of the MPSYNC performance related patch for >Multinet 4.2. Can this be applied to 4.1? Here is response from Multinet >Show >/Version: > >B$ multi show/version >Process Software MultiNet V4.1 Rev A-X, AlphaServer 8400 5/440, OpenVMS AXP >V6.2-1H3 > >I was expecting a little more in you presentation on "tuning" or such that one >would want to look at to insure Multinet is performing at well as >possible. So >please let me ask one question regarding our current environment, >expection only >some generalities on your part, as you obvisously do not know specifics of our >system nor our network (which is the responsibility of another group). An >overview though, our network is based on Xylan switched ethernet with ATM >between chassis and other campuses. It is flat architecture, using virtual >lans, i.e no mater what part of town you are in, if they set the port for >10.1.x.x , you see all other 10.1.x.x devices. VMS system are in the 10.3.x.x >VLAN (as we are the outcast) to isolate DEC protocol traffic. So, getting to >the question, users see keyboard delays using telnet to our system, yet >not from >another system using ucx 4.2, (and this is a heavyly loaded axp 1000), and OUR >LAT users see no delay. Of course, if there is some serious network traffic, >all suffer, but our box, and the TCP/IP protoclol suffer the most, (i.e. >during >a broadcast storm or other network related problem). Are there any areas we >should look in on our system where we might improve Multinet >performance? (btw, >we are a Cerner client, and Multinet is sublicensed through them). > >Thanks, >Bob Drennon >Via Christi Health System >Wichita, KS >316-291-4393 ================================================================================ Archive-Date: Fri, 18 Feb 2000 15:55:02 -0500 Date: Fri, 18 Feb 2000 14:52:29 -0600 From: Steve +1 608 278 7700 Reply-To: Info-MultiNet@process.com Subject: Question on paired interface arrangement To: Info-MultiNet@Process.com MIME-Version: 1.0 Content-Type: text/plain === The original message was multipart MIME === === All non-text parts (attachments) have been removed === ================================================================================ Archive-Date: Fri, 18 Feb 2000 15:57:10 -0500 Sender: schreiber@process.com Date: Fri, 18 Feb 2000 15:56:46 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: Question on paired interface arrangement Steve +1 608 278 7700 writes: > > === The original message was multipart MIME === > === All non-text parts (attachments) have been removed === > Steve, As you see... We didn't get your message :) -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Fri, 18 Feb 2000 15:58:50 -0500 Date: Fri, 18 Feb 2000 14:58:19 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: Question on paired interface arrangement Jeff Schreiber writes: > >Steve +1 608 278 7700 writes: >> >> === The original message was multipart MIME === >> === All non-text parts (attachments) have been removed === >> > >Steve, > As you see... We didn't get your message :) > Looks like my filter was a little too overzealous. The message was: ------------------------------ I just listened to the recorded teleconference I missed yesterday. Thanks for making it available. I have a question that may be of general interest. In the paired arrangement that you'll be offerring in the next release of MultiNet, how will outbound packet transmission be done when the interfaces are not the same speed, e.g., 10 and 100 Mbs? Regards, "Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc. Address 2530 Targhee Street, Madison, Wisconsin 53711-5491 U.S.A. Telephone +1 608 278 7700 Facsimile +1 608 278 7701 Internet Stephen.L.Arnold@Arnold.com http://WWW.Arnold.com Pager (800) 351 8927 Arnold is a trademark and service mark of Arnold Consulting, Inc. ------------------------------ Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 18 Feb 2000 16:48:21 -0500 Date: Fri, 18 Feb 2000 15:47:09 -0600 (CST) From: Gary Lee McDonald Reply-To: Info-MultiNet@process.com Subject: Re: Process Software TCP/IP Telebriefing replay now available To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date sent: 18-FEB-2000 15:45:51 Would be nice if this were in a sound file that I could point a browser at... Give 'em an inch, ... :-) > >On Thursday, 17-FEB-2000, Process Software held a TCP/IP telebriefing >for our customers. > >If you could not attend, we are providing a replay of the >telebriefing, available now through 24-FEB-2000 at the following >numbers: > >USA #: 800-475-6701 >International #: 320-365-3844 > >After dialing the number, please enter the following access code when >prompted: 501570 > >Here is the original description: >> >>Process Software is pleased that you will be joining our MultiNet and >>TCPware TCP/IP Telebriefing this Thursday, February 17th at 1:00pm EST. >> >>Our engineering and marketing team look forward to providing you information >>on maximizing your TCP/IP for OpenVMS product and learning about upcoming >>technologies and product advancements. The Telebriefing will cover: >> >>- TCPware and MultiNet Product Roadmaps for 2000 >>- Optimizing the performance of Process Software's TCP/IP stacks >>- Introduction on Process Software's Paired Network Interface feature >> which increases your networks throughput and adds reliability >>- Performance testing results >>- Question and answer period for participants > > >Hunter >------ >Hunter Goatley, Process Software, http://www.process.com/ > http://www2.wku.edu/hunter/ UMKC GaryM. 5100 Rockhill Road Univ. of Mo. at K.C. Cockefair Hall (816) 235-1183 (work) 346-3447 (pager) Room 2, Gary Lee McDonald MCDONALD @ CCTR.UMKC.EDU Kansas City, Mo. 64110 POSTMASTER @ CCTR.UMKC.EDU ================================================================================ Archive-Date: Fri, 18 Feb 2000 16:49:58 -0500 Date: Fri, 18 Feb 2000 15:49:29 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Process Software TCP/IP Telebriefing replay now available Gary Lee McDonald writes: > >Date sent: 18-FEB-2000 15:45:51 > >Would be nice if this were in a sound file that I could point a browser at... >Give 'em an inch, ... :-) > Actually, we were discussing that just a bit ago. We're looking into it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 18 Feb 2000 21:58:21 -0500 Date: Fri, 18 Feb 2000 18:57:30 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Process Software TCP/IP Telebriefing replay now available Message-ID: <0002181856010.25809-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Feb 2000 15:49 -0600, Hunter Goatley wrote: > >Would be nice if this were in a sound file that I could point a browser at... > >Give 'em an inch, ... :-) > > > Actually, we were discussing that just a bit ago. We're looking into > it. How about a recording of the Process engineering group singing a song, too? ;-) Votes, anyone? [You might be able to listen to the conference using http://www.dialpad.com which dials any number in the US using voice over IP.] -d ================================================================================ Archive-Date: Sat, 19 Feb 2000 21:23:12 -0500 Sender: bryant@process.com Date: Sat, 19 Feb 2000 21:22:40 -0500 From: Geoff Bryant Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: bryant@process.com Subject: RE: Question on paired interface arrangement >I just listened to the recorded teleconference I missed yesterday. >Thanks for making it available. I have a question that may be of >general interest. Glad it was helpful. >In the paired arrangement that you'll be offerring in the next release >of MultiNet, how will outbound packet transmission be done when the >interfaces are not the same speed, e.g., 10 and 100 Mbs? If we do it the way we did in TCPware, it is done at the datalink layer inbetween the IP layer and VCI which controls the actual devices. While our intention is that it be for similar NIC cards, TCPware will let it be configured so long as the MTUs are the same. At that point we wouldn't notice any distinction between the 10 and 100 Mbs lines other than that the 10 would be more likely to be busy and have transmission move over to the 100. >Regards, >"Steve" Stephen L. Arnold, Ph.D., President, Arnold Consulting, Inc. >Address 2530 Targhee Street, Madison, Wisconsin 53711-5491 U.S.A. >Telephone +1 608 278 7700 Facsimile +1 608 278 7701 >Internet Stephen.L.Arnold@Arnold.com http://WWW.Arnold.com >Pager (800) 351 8927 >Arnold is a trademark and service mark of Arnold Consulting, Inc. ------------------------------------------------------------- Geoff Bryant bryant@process.com TCPware/Multinet Engineering Process Software Corporation http://www.process.com/ 959 Concord St. Framingham, MA 01701 USA ================================================================================ Archive-Date: Mon, 21 Feb 2000 05:33:19 -0500 From: Rüdiger Kresse Reply-To: Info-MultiNet@process.com Subject: F$SEARCH on NFS client Date: Mon, 21 Feb 2000 10:17:16 GMT To: INFO-MULTINET@PROCESS.COM What do i have to do to get F$SEARCH working on a NFS-Device ? It does return only a few files if I do a wildcard search... Sent via Deja.com http://www.deja.com/ Before you buy. ================================================================================ Archive-Date: Mon, 21 Feb 2000 06:20:59 -0500 Date: Mon, 21 Feb 2000 12:15:32 +0100 From: "Juan C. Blanco" Reply-To: Info-MultiNet@process.com Subject: Re: F$SEARCH on NFS client To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII What version of MultiNet are you using ?. We have had this same problem since Version 4.1, however the problem was fixed in the last patches of the NFS_CLIENT. My Multinet V4.2A with NFS_CLIENT-050_A042 eco is working fine, there are also ecos for V4.1 Regards Juan C. Blanco -- +----------------------------------------------------------------------------+ | Juan C. Blanco | | | | Centro de Calculo | | | Facultad de Informatica U.P.M. | E-mail: jcblanco@fi.upm.es | | Campus de Montegancedo | | | Boadilla del Monte | Tel.: (+34) 91 336 7466 | | 28660 MADRID (Spain) | Fax : (+34) 91 336 6913 | +----------------------------------------------------------------------------+ ================================================================================ Archive-Date: Mon, 21 Feb 2000 07:44:32 -0500 Sender: schreiber@process.com Date: Mon, 21 Feb 2000 07:43:55 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: Re: Process Software TCP/IP Telebriefing replay now available Dan Wing writes: > >How about a recording of the Process engineering group singing a song, >too? ;-) Votes, anyone? > You'd think that would be funny... wouldn't you. Just wait until we actually do it and force you to listen!!!! -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 22 Feb 2000 08:28:04 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Tue, 22 Feb 2000 08:27:29 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: FTP-050_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: FTP-050_A042 Description: MultiNet FTP update Release date: 22-FEB-2000 Versions: V4.2A, V4.1B, V4.1A ftp://ftp.multinet.process.com/patches/multinet042/ftp-050_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- This ECO kit provides a new version of FTP and applies to Multinet V4.2 Rev A, V4.1 Rev A and V4.1 Rev B. This kit provides the following changes to V4.2A: DE 3362 - Allow MGET to accept UNIX style file specifications. If the file specification contains a directory specification the directory specification is removed before creating the files in the local directory. Note that this is a change from previous behavior, which would create the file in the same directory path if the path existed, or give an error if the path did not exist. The FTP Server now will return UNIX like file specifications, with the directory if one was specified, for the NLST command when operating in UNIX mode. Previously the directory was not returned when operating in UNIX mode. DE 4545,5622 - Fix FTP_SERVER.EXE so that it doesn't crash when attempting to delete a file with MULTINET_FTP_UNIX_STYLE_BY_DEFAULT defined. Changed from SYS$ERASE & SYS$RENAME to LIB$DELETE_FILE and LIB$RENAME_FILE to let VMS take care of more of the details involved. DE 4643 - Correct a problem with RMDIR on OpenVMS 7.2 AXP that prevented directories from being deleted. DE 4774 - Correct a problem with transferring fixed length records in image mode when the record size is an odd number of bytes. New images for FTP.EXE and FTP_SERVER.EXE are supplied. You do not have to reboot after installing this kit. New FTP sessions will automatically use the new server or client image. [End of ECO announcement] ================================================================================ Archive-Date: Tue, 22 Feb 2000 11:48:00 -0500 Date: Tue, 22 Feb 2000 17:40:53 +0100 From: "Heinze, Robert" Reply-To: Info-MultiNet@process.com Subject: dhcpd.conf multiple files To: "'INFO-MULTINET@PROCESS.COM'" CC: Heinze Robert MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Hi, i would like to devide my dhcpd.conf file in seperate files to have a more structured configuration. Is this possible ? Thanks Regards Robert Robert Heinze Fachhochschule Kiel - University of Applied Sciences Abt. Informations/Kommunikationstechnik Sokratesplatz 1 D-24149 Kiel Tel: 0431-210-1310 Fax: 0431-210-6-1310 ================================================================================ Archive-Date: Tue, 22 Feb 2000 11:49:28 -0500 Sender: miller@process.com Date: Tue, 22 Feb 2000 11:48:53 -0500 From: Valerie Miller Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: miller@process.com Subject: RE: dhcpd.conf multiple files >i would like to devide my dhcpd.conf file in seperate files to have a more >structured configuration. > >Is this possible ? If you are asking if there is an "include" type directive in dhcpd.conf to pull in other files, No, there isn't. Valerie Miller Process Software ================================================================================ Archive-Date: Tue, 22 Feb 2000 13:21:43 -0500 Date: Tue, 22 Feb 2000 19:14:34 +0100 From: "Heinze, Robert" Reply-To: Info-MultiNet@process.com Subject: RE: dhcpd.conf multiple files To: "'miller@process.com'" CC: "'Info-MultiNet@process.com'" MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII >i would like to devide my dhcpd.conf file in seperate files to have a more >structured configuration. > >Is this possible ? -If you are asking if there is an "include" type directive in dhcpd.conf -to pull in other files, No, there isn't. Thanks Valerie, this was something i am looking for. Any other hint how to manage this ? Regards Robert Robert Heinze Fachhochschule Kiel - University of Applied Sciences Abt. Informations/Kommunikationstechnik Sokratesplatz 1 D-24149 Kiel Tel: 0431-210-1310 Fax: 0431-210-6-1310 ================================================================================ Archive-Date: Tue, 22 Feb 2000 13:31:03 -0500 Sender: miller@process.com Date: Tue, 22 Feb 2000 13:30:25 -0500 From: Valerie Miller Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: miller@process.com Subject: RE: dhcpd.conf multiple files >this was something i am looking for. If this is something you really want in the next version of MultiNet, please contact tech support (support@process.com) and ask them to file an enhancement request (use my name). >Any other hint how to manage this ? About all I can suggest is for you to have a command procedure that appends your different files together and then uses $ multinet netcontrol dhcp reload to restart the dhcp server. Valerie Miller Process Software ================================================================================ Archive-Date: Wed, 23 Feb 2000 13:21:54 -0500 Date: Wed, 23 Feb 2000 13:22:13 -0500 From: "Randy Baker" Reply-To: Info-MultiNet@process.com To: Subject: Boot problems MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII I am having an intermittent problem that I suspect may be due to a flaky network card, but I am not certain yet. I have recently installed Multinet 4.2a on an Alpha 1000 4/266 on a VMS 7.1 Single User License system, but have not yet installed any patch kits. In the last week or so, I have been losing network connections. It seems that after I boot this system, I may, or may not have TCP/IP running. I guess it depends on the phase of the moon or something. Once TCP/IP is running, it will run for a while and then things seem to die. For example, while trying to download patches from the Multinet FTP site this morning, the ftp session hung but never timed out. (I had hash enabled, but the hash marks did not incrementing part way through. CTRL-T indicated that the only I/O was the CTRL-T action over a period of about 10-15 minutes.) I logged out of DEC Windows then attempted to TELNET to the system from my PC. I was able to get logged in, get the $ prompt, but the connection would time out and die. I rebooted this system, but now Multinet won't start at all this time. I get link lights on the NIC, and I have moved to different ports on the switch with no different results. Multinet chokes as follows: %EWA0, Full Duplex, Twisted Pair (10BASE-T) Ethernet Connection Selected %MULTINET-W-STARTUPERR, Error Starting LAN Device for SE0 - SYSTEM-F-IVADDR, Invalid Media Address. Multinet attempts to start with 3 buffers, and decrements by 1 until it determines that it is unable to start the LAN Device. I do not see any errors on the system, (SHOW ERROR) and the device SE0 is there. SE0 is a DE435. Any ideas? Thanks Randy Baker ================================================================================ Archive-Date: Wed, 23 Feb 2000 14:15:21 -0500 Date: Wed, 23 Feb 2000 14:14:23 -0500 From: "Tom Skipper" Reply-To: Info-MultiNet@process.com To: RBaker@georgianc.on.ca, info-multinet@process.com Subject: Re: Boot problems MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII My first guess here would be a duplicate decnet node address or name. I seem to recall this exact type problem (as evident by the error message you mentioned) at a previous job. We chose a different decnet node address and name and all became normal. If you are NOT loading decnet, then I suppose this is just a lot of hot air. /tom >>> "Randy Baker" 02/23 1:22 PM >>> I am having an intermittent problem that I suspect may be due to a flaky network card, but I am not certain yet. I have recently installed Multinet 4.2a on an Alpha 1000 4/266 on a VMS 7.1 Single User License system, but have not yet installed any patch kits. In the last week or so, I have been losing network connections. It seems that after I boot this system, I may, or may not have TCP/IP running. I guess it depends on the phase of the moon or something. Once TCP/IP is running, it will run for a while and then things seem to die. For example, while trying to download patches from the Multinet FTP site this morning, the ftp session hung but never timed out. (I had hash enabled, but the hash marks did not incrementing part way through. CTRL-T indicated that the only I/O was the CTRL-T action over a period of about 10-15 minutes.) I logged out of DEC Windows then attempted to TELNET to the system from my PC. I was able to get logged in, get the $ prompt, but the connection would time out and die. I rebooted this system, but now Multinet won't start at all this time. I get link lights on the NIC, and I have moved to different ports on the switch with no different results. Multinet chokes as follows: %EWA0, Full Duplex, Twisted Pair (10BASE-T) Ethernet Connection Selected %MULTINET-W-STARTUPERR, Error Starting LAN Device for SE0 - SYSTEM-F-IVADDR, Invalid Media Address. Multinet attempts to start with 3 buffers, and decrements by 1 until it determines that it is unable to start the LAN Device. I do not see any errors on the system, (SHOW ERROR) and the device SE0 is there. SE0 is a DE435. Any ideas? Thanks Randy Baker ================================================================================ Archive-Date: Wed, 23 Feb 2000 15:40:58 -0500 From: Robin Daiell Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: F$SEARCH on NFS client Date: Wed, 23 Feb 2000 15:39:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Info-MultiNet@process.com [mailto:Info-MultiNet@process.com] Sent: Monday, February 21, 2000 5:33 AM To: INFO-MULTINET@PROCESS.COM Subject: F$SEARCH on NFS client Return-Path: Received: from triton.process.com (198.115.138.29) by alcor.process.com (MX V5.1-X A2w8g) with ESMTP; Mon, 21 Feb 2000 05:32:55 -0500 X-Listname: Process MultiNet Discussion List From: Rdiger Kresse Reply-To: Info-MultiNet@process.com Subject: F$SEARCH on NFS client Date: Mon, 21 Feb 2000 10:17:16 GMT Message-ID: <88r3bb$qnp$1@nnrp1.deja.com> To: INFO-MULTINET@PROCESS.COM List-Unsubscribe: What do i have to do to get F$SEARCH working on a NFS-Device ? It does return only a few files if I do a wildcard search... Sent via Deja.com http://www.deja.com/ Before you buy. If the My Multinet V4.2A with NFS_CLIENT-050_A042 patch doesn't fix your problem, please write back with more detail... For instance: what version on client, do you see just one file or several files, what is the wildcard search pattern. thanks Robin Daiell Software Engineer Process Software ================================================================================ Archive-Date: Wed, 23 Feb 2000 15:46:13 -0500 From: "Harms,Jon" Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: using group permissions over NFS Date: Wed, 23 Feb 2000 14:45:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Here is the situation: Node1 --> 10 users (all in the same group) Node2 --> 1 user (same group) I would like to nfsmount Node1's drives from Node2, which I can successfully do, but I would like to "map" the 1 user to all 10 or use group permissions to access the files. Is this possible? The server and client are running Multinet 4.1b and OpenVMS 7.1 currently, but that is likely to change to be mismatched VMS versions. I do NOT want to cluster the nodes. I don't want to have to maintain UAF records on both nodes if I don't have to, because that will be a pain to do. I have been able to map one user to one user but every file that doesn't have a mapped owner in NFS gets the DEFAULT user permissions, which is none. I would like to map the one user to all ten on the other node if possible. Does anyone have any experience doing anything similar? Is it possible? -- Jon Harms Tech Dev System Developer jharms@cerner.com - http://www.cerner.com/ ================================================================================ Archive-Date: Thu, 24 Feb 2000 03:53:24 -0500 Date: Thu, 24 Feb 2000 00:52:41 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: Re: using group permissions over NFS Message-ID: <0002240051340.5477-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 23 Feb 2000 14:45 -0600, Harms,Jon wrote: > Here is the situation: > Node1 --> 10 users (all in the same group) > Node2 --> 1 user (same group) > > I would like to nfsmount Node1's drives from Node2, which I can > successfully do, but I would like to "map" the 1 user to all 10 or use group > permissions to access the files. Is this possible? The server and client are > running Multinet 4.1b and OpenVMS 7.1 currently, but that is likely to > change to be mismatched VMS versions. I do NOT want to cluster the nodes. I > don't want to have to maintain UAF records on both nodes if I don't have to, > because that will be a pain to do. > I have been able to map one user to one user but every file that > doesn't have a mapped owner in NFS gets the DEFAULT user permissions, which > is none. I would like to map the one user to all ten on the other node if > possible. > Does anyone have any experience doing anything similar? Is it > possible? The MultiNet CD used to have a SYSUAF2UID.COM utility which would parse the output from Authorize and build a UID/GID file for use by the NFS client and server. This can be used to synchronize the on-the-wire UID/GID between the two nodes to be exactly what you want and could be extended to programmatically do the mapping you want between your two systems. -d ================================================================================ Archive-Date: Thu, 24 Feb 2000 04:39:38 -0500 From: sudiady.aminata@amd.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: LPD Problems. Date: Thu, 24 Feb 2000 17:37:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, I've setup a LPD print queue in Multinet ver. 4.1A under VAX OpenVMS ver. 6.2. When printing a large print job (more than 100 pages), some pages was missing & some of the printed format also corrupted. Any Idea why? Is a software or hardware / Firmware problem? My Multinet version as the following: $ type multinet:MULTINET_VERSION. VERSION V4.1 REVISION A-X DATE 1-MAR-1998 PRODUCER PSC INSTALLED_IPAPPS YES INSTALLED_NFSCLIENT YES INSTALLED_NFSSERVER YES INSTALLED_NETWARESERVER NO INSTALLED_SECUREIP_CLIENT NO INSTALLED_SECUREIP_SERVER NO INSTALLED_WEB_SERVER NO INSTALLED_DOCUMENTATION YES INSTALLED_LIBRARIES YES XREPLACED NFS_CLIENT_ACP.VUI NFS_CLIENT-010_A042 25-NOV-1999 XREPLACED MULTINET_LPD_SYMBIONT.VUI LPDSMB-030_A042 23-FEB-2000 $ I've used the "Print/passall" and also the "NOFFLF=Y" in my printer logical, but still not able to solve the problem. "MULTINET_NLP3_REMOTE_PRINTER" = "Address=x.x.x.x,Printer=LPT1,NOFFLF=Y" My hardware is: Intermec Printer model 4420 with the Internal NIC model INTERMEC 540+. Regards, Sudiady Aminata ================================================================================ Archive-Date: Thu, 24 Feb 2000 09:07:19 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Thu, 24 Feb 2000 09:06:44 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: NFS_CLIENT-060_A042 MultiNet ECO kit announcement The following ECO kit is now available for MultiNet: ECO: NFS_CLIENT-060_A042 Description: NFS client update to fix 127-block directory problem under VMS V7.1+ Release date: 24-FEB-2000 Versions: V4.2A ftp://ftp.multinet.process.com/patches/multinet042/nfs_client-060_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- This kit updates Multinet V4.2 Revision A with a new version of the NFS Client. The problem(s) corrected are as follows. NFS_CLIENT-060_A042: SWL 17-Feb-2000 o Directory listings for directories greater than 127 blocks returned SS$_BADIRECTORY for OpenVMS versions 7.1, 7.2, and 7.21. Fixes I/O requests of greater than 127 blocks. NFS_CLIENT-05_A042: MDD 02-DEC-1999 o Infinite loop introduced by fix to D/E 1543. (No D/E) (The only V4.2 systems affected are V4.2A with NFS_CLIENT-01 through NFS_CLIENT-04). NFS_CLIENT-04_A042: MDD 01-SEP-1999 o ACL entries may not be added to or consistently read from files on NFS volume. (D/E 4141, VAX: V7 ; AXP: V6,V7) NFS_CLIENT-03_A042: RFD 04-JUN-1999 o Fix RPC mount error when attempting to access a symlink or when using the nfs lockmanager. Client NFS error message: "RPC: Program unavailable" Problem developed from Rev 4.0C. (d/e 3515, 3580) NFS_CLIENT-02_A042: MDD 26-MAY-1999 o First call to $SEARCH or f$search returns correct filespec, but second call incorrectly returns "no more files" (RMS$_NMF) status. ( d/e 3784, 4.1A, 4.1B, 4.2A ) NFS_CLIENT-01_A042: MDD 06-APR-1999 o Filenames including certain character sequences, often including dollar signs ($), cause "bad file name syntax" errors. This behavior has been changed. The old behavior may be restored (on a system-wide basis only) by defining a system logical MULTINET_NFS_CLIENT_OLD_SRIMAP to any value. ( d/e 1543, 4.1b and earlier, V4.2a ) ---------------------------------------------------------------------- You must reboot your system(s) after installing this kit. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 24 Feb 2000 09:19:48 -0500 From: norm.raphael@jamesbury.com Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Date: Thu, 24 Feb 2000 09:26:36 -0500 Subject: Re: MultiNet ECO kit available: NFS_CLIENT-060_A042 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > This kit updates Multinet V4.2 Revision A with a new version of the > NFS Client. > > The problem(s) corrected are as follows. > > > NFS_CLIENT-060_A042: > > > SWL 17-Feb-2000 > > o Directory listings for directories greater than 127 blocks > returned SS$_BADIRECTORY for OpenVMS versions 7.1, 7.2, and 7.21. > Fixes I/O requests of greater than 127 blocks. > Does this also apply to V7.1-2? ================================================================================ Archive-Date: Thu, 24 Feb 2000 09:21:30 -0500 Date: Thu, 24 Feb 2000 8:20:50 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: MultiNet ECO kit available: NFS_CLIENT-060_A042 norm.raphael@jamesbury.com writes: > >> NFS_CLIENT-060_A042: >> >> o Directory listings for directories greater than 127 blocks >> returned SS$_BADIRECTORY for OpenVMS versions 7.1, 7.2, and 7.21. >> Fixes I/O requests of greater than 127 blocks. >> > >Does this also apply to V7.1-2? > Yes. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 25 Feb 2000 07:01:36 -0500 Subject: Here is the information you requested. From: recipient@hotmail.com To: member@process.com Content-Type: text/plain; charset=ISO-8859-1 Reply-To: Info-MultiNet@process.com Date: Fri, 25 Feb 2000 06:59:39 -0500 ================================================================================ Archive-Date: Fri, 25 Feb 2000 08:52:51 -0500 Date: Fri, 25 Feb 2000 08:53:08 -0500 From: "Randy Baker" Reply-To: Info-MultiNet@process.com To: Subject: Fwd: Here is the information you requested. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Did anyone else get one of these today? It appears that I have attempted to unsubscribe from this list, but I have not initiated such an action. Randy Received: from triton.process.com by Groupwise.georgianc.on.ca; Fri, 25 Feb 2000 07:03:07 -0500 X-ListName: Process MultiNet Discussion List Subject: Here is the information you requested. From: recipient@hotmail.com To: member@process.com Content-Type: text/plain; charset=ISO-8859-1 Reply-To: Info-MultiNet@process.com X-Original-Reply-To: recipient@hotmail.com Message-ID: Date: Fri, 25 Feb 2000 06:59:39 -0500 List-Unsubscribe: ================================================================================ Archive-Date: Fri, 25 Feb 2000 09:06:31 -0500 Reply-To: Info-MultiNet@process.com Sender: a.pratico@surpas.com (Anthony Pratico) To: Subject: RE: Here is the information you requested. Date: Fri, 25 Feb 2000 09:08:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Yes, I received it with no information in it..I deleted it.. -----Original Message----- From: Randy Baker [mailto:RBaker@georgianc.on.ca] Sent: Friday, February 25, 2000 8:53 AM To: info-multinet@process.com Subject: Fwd: Here is the information you requested. Did anyone else get one of these today? It appears that I have attempted to unsubscribe from this list, but I have not initiated such an action. Randy Received: from triton.process.com by Groupwise.georgianc.on.ca; Fri, 25 Feb 2000 07:03:07 -0500 X-ListName: Process MultiNet Discussion List Subject: Here is the information you requested. From: recipient@hotmail.com To: member@process.com Content-Type: text/plain; charset=ISO-8859-1 Reply-To: Info-MultiNet@process.com X-Original-Reply-To: recipient@hotmail.com Message-ID: Date: Fri, 25 Feb 2000 06:59:39 -0500 List-Unsubscribe: ================================================================================ Archive-Date: Fri, 25 Feb 2000 09:13:42 -0500 Date: Fri, 25 Feb 2000 09:12:00 -0500 (Eastern Standard Time) From: Mike Cliffe Reply-To: Info-MultiNet@process.com Subject: Re: Fwd: Here is the information you requested. To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Feb 2000, Randy Baker wrote: RB> Did anyone else get one of these today? It appears that I have attempted to unsubscribe from this list, but I have not initiated such an action. RB> RB> Randy RB> RB> RB> Received: from triton.process.com RB> by Groupwise.georgianc.on.ca; Fri, 25 Feb 2000 07:03:07 -0500 RB> X-ListName: Process MultiNet Discussion List RB> Subject: Here is the information you requested. RB> From: recipient@hotmail.com RB> To: member@process.com RB> Content-Type: text/plain; charset=ISO-8859-1 RB> Reply-To: Info-MultiNet@process.com RB> X-Original-Reply-To: recipient@hotmail.com RB> Message-ID: RB> Date: Fri, 25 Feb 2000 06:59:39 -0500 RB> List-Unsubscribe: I got one. It smells like spam. The message however contains list management information that I think process.com provides by the way they have configure the mailing list. Some mail user agents (ie. PINE) can recognize the List-*: envelope headers to make list subscriptions/unsubscriptions easier. -- Mike Cliffe (MC307) mailto:mike.cliffe@saultc.on.ca .`. http://goliath.saultc.on.ca/~mcliffe/ , * , Voice: +1 705.759.2554 x675 `,` `,` Fax: +1 705.256.5944 Sault College Sault Ste. Marie, Ontario, CANADA ================================================================================ Archive-Date: Fri, 25 Feb 2000 09:36:04 -0500 From: Ken Lang Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: Here is the information you requested. Date: Fri, 25 Feb 2000 06:35:53 -0800 MIME-Version: 1.0 Content-Type: text/plain yes, I got it also Ken Lang > -----Original Message----- > From: Randy Baker [SMTP:RBaker@georgianc.on.ca] > Sent: Friday, February 25, 2000 5:53 AM > To: info-multinet@process.com > Subject: Fwd: Here is the information you requested. > > Did anyone else get one of these today? It appears that I have attempted > to unsubscribe from this list, but I have not initiated such an action. > > Randy > > > Received: from triton.process.com > by Groupwise.georgianc.on.ca; Fri, 25 Feb 2000 07:03:07 -0500 > X-ListName: Process MultiNet Discussion List > Subject: Here is the information you requested. > From: recipient@hotmail.com > To: member@process.com > Content-Type: text/plain; charset=ISO-8859-1 > Reply-To: Info-MultiNet@process.com > X-Original-Reply-To: recipient@hotmail.com > Message-ID: > Date: Fri, 25 Feb 2000 06:59:39 -0500 > List-Unsubscribe: > ================================================================================ Archive-Date: Fri, 25 Feb 2000 09:45:56 -0500 Date: Fri, 25 Feb 2000 8:45:13 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: Re: Fwd: Here is the information you requested. Mike Cliffe writes: > >I got one. It smells like spam. The message however contains list >management information that I think process.com provides by the way they >have configure the mailing list. Some mail user agents (ie. PINE) can >recognize the List-*: envelope headers to make list subscriptions/unsubscriptions easier. > Yes, exactly. It's empty spam that made it through the filter---guess that's another check the filter needs. ;-) Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Fri, 25 Feb 2000 11:17:45 -0500 From: goathunter@PROCESS.COM Reply-To: Info-MultiNet@process.com Date: Fri, 25 Feb 2000 11:17:11 -0500 To: MultiNet-Announce@PROCESS.COM Subject: MultiNet ECO kit available: MASTER_SERVER-080_A042 MultiNet ECO kit announcement ******* This ECO kit corrects the VAX FTP problem introduced in the -070 ECO. ******* The following ECO kit is now available for MultiNet: ECO: MASTER_SERVER-080_A042 Description: MultiNet master server update to fix -070 bug Release date: 25-FEB-2000 Versions: V4.2A,V4.1B,V4.1A,V4.0C ftp://ftp.multinet.process.com/patches/multinet042/master_server-080_a042.zip To search the MultiNet ECO database, please visit the following URL: http://www.multinet.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- The MASTER_SERVER-080_A042 kit updates MultiNet V4.2 Rev A, V4.0 Rev C, V4.1A and V4.1B with a new version of SERVER.EXE which include following changes: Changes since 4.2A 1) Go to AST level before checking the number of active servers and possibly setting the MAX_SERVERS_REACHED flag. This corrects a problem where the master server would get slightly off on whether or not a new request could be handled and cause a delay in handling the request. 2) A potential buffer overflow that could corrupt the master servers stack has been corrected. 3) Make certain that the number of active servers is only adjusted when at AST level to avoid possible synchronization problems that could let the master server get confused about whether or not more requests can be accepted. 4) Close the UDP socket if connect failed when doing DNS resolver queries. This prevents UDP connections from building up on heavily loaded systems and eventually causing the system to run out of available sockets. 5) Always issue a new read to the termination mailbox. This prevents the server count from erroneously getting stuck at the maximum and no new accepts for incoming requests being issued. This would cause a lot of connections to be left in Close Wait state. 6) Correct a possible denial of service attack. 7) Internal POP3 module will accept null as valid Application Protocol Version String to support new Eduroa Version 4. 8) Correct a problem with MASTER_SERVER-070_A042 that would cause the master server to accvio on VAX. (DE 5738) Changes since 4.1B 1) Change to the memory allocation routines to prevent corruption that was causing the MASTER_SERVER to crash. 2) Change to memory allocation routine to close a small timing window on AXP that was causing the MASTER_SERVER to crash. Changes since 4.1A 1) MASTER_SERVER were crashing without leaving process dump due to exhausted channels, at the same time, leaving large number of permanent mailboxes behind, which may eventually exhaust the available mailboxes on the system and hang the system. This regression in 4.0C for UCX service is corrected to properly reuse the permanent mailbox created by the master server. 2) Channel leak in the UCX service was fixed which was causing server crashing with exhausted channels. 3) Possible server ACCVIO on AXP was fixed 4) More problems with UCX service are fixed and channel count usage is reduced to one. Changes since 4.0C 1) The logical MULTINET_POP3_INPUT_WAIT can be defined as the amount of time the POP3 server should wait for input from the client before closing the connection. The value is a normal VMS time string. 2) Just to be more lenient, the MASTER_SERVER now automatically uppercases all program names when it reads the services configuration file. You do not have to reboot after installing this kit. After installing, execute: @MULTINET:START_SERVER to restart the new master server. [End of ECO announcement] ================================================================================ Archive-Date: Mon, 28 Feb 2000 08:49:36 -0500 From: gartmann@immunbio.mpg.de (Christoph Gartmann) Subject: DNS & Port 1024? Date: 28 Feb 2000 12:44:18 GMT Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Hello, I noticed that there are quite a few UDP connection requests from various outside hosts at port 53 to our DNS at port 1024. Our DNS is running Multinet V4.2 with a lot of patches under VAX-VMS 6.2 . Is this normal behaviour? If I assume the packets in question are answers for our DNS. Do these answers always arrive on port 1024? Regards, Christoph Gartmann -----------------------------------------------------------------------+ | Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 | | Immunbiologie | | Postfach 1169 Internet: gartmann@immunbio.mpg.de | | D-79011 Freiburg, FRG | +------------ http://www.immunbio.mpg.de/english/menue.html -----------+ ================================================================================ Archive-Date: Mon, 28 Feb 2000 08:54:56 -0500 Date: Mon, 28 Feb 2000 08:53:26 -0500 From: Ung Yi Reply-To: Info-MultiNet@process.com Subject: Vms upgrade and multinet To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hello, I am upgrading Vms from 6.2-1H3 to 7.2-1. I heard that I'll need to reinstall the multinet sw(4.1B) that's already installed on the system. Does this mean I need to deinstall the multinet and reinstall it? Thanks, yi ================================================================================ Archive-Date: Mon, 28 Feb 2000 09:08:20 -0500 From: "Russell. Tadhg" Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: Vms upgrade and multinet Date: Mon, 28 Feb 2000 14:07:30 -0000 MIME-Version: 1.0 Content-Type: text/plain Yi, you do not need to deinstall Multinet.... I assume your Sysadmin wants you to re-install to relink Multinet against new version of VMS ..... Installation is easy....you dont even need to reconfigure afterwards. Just recompile your host table... cheers, Tadhg ================================================================================ Archive-Date: Mon, 28 Feb 2000 09:28:24 -0500 Date: Mon, 28 Feb 2000 09:27:17 -0500 From: Michael Corbett Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 To: info-multinet@process.com Subject: RE: DNS & Port 1024? Content-Type: text/plain; charset=us-ascii > > Hello, > > I noticed that there are quite a few UDP connection requests from various > outside hosts at port 53 to our DNS at port 1024. Our DNS is running Multinet > V4.2 with a lot of patches under VAX-VMS 6.2 . Is this normal behaviour? If > I assume the packets in question are answers for our DNS. Do these answers > always arrive on port 1024? > Unlike the version 4.x BIND server the BIND 8 server by default will send queries from an ephemeral port not port 53. This can be controlled using the query-source option. Here is the relevant section from the Bind Configuration File Guide - Query Address If the server doesn't know the answer to a question, it will query other nameservers. query-source specifies the address and port used for such queries. If address is * or is omitted, a wildcard IP address (INADDR_ANY) will be used. If port is * or is omitted, a random unprivileged port willbe used. The default is query-source address * port *; Note: query-source currently applies only to UDP queries; TCP queries always use a wildcard IP address and a random unprivileged port. -- +-------------------------------------------------------------------------+ 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: Mon, 28 Feb 2000 10:29:06 -0500 Sender: schreiber@process.com Date: Mon, 28 Feb 2000 10:28:08 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: DNS & Port 1024? Michael Corbett writes: > >> I noticed that there are quite a few UDP connection requests from various >> outside hosts at port 53 to our DNS at port 1024. Our DNS is running Multinet >> V4.2 with a lot of patches under VAX-VMS 6.2 . Is this normal behaviour? If >> I assume the packets in question are answers for our DNS. Do these answers >> always arrive on port 1024? > > Unlike the version 4.x BIND server the BIND 8 server by default will >send queries from an ephemeral port not port 53. This can be controlled >using the query-source option. > If you look at the messages on nameserver startup, you can see what port it's using to forward from: named: default: info: Forwarding source address is [0.0.0.0].1035 Using the "query-source address * port 53;" option, you will see: named: default: info: Forwarding source address is [0.0.0.0].53 -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Mon, 28 Feb 2000 13:02:44 -0500 From: gartmann@immunbio.mpg.de (Christoph Gartmann) Subject: IDENT on Port 113 Date: 28 Feb 2000 16:18:51 GMT Reply-To: Info-MultiNet@process.com To: INFO-MULTINET@PROCESS.COM Hello, this time I noticed requests to port 113 of our Multinet host running V4.2 under VAX-VMS 6.2 . Does Multinet answer these requests? Is the protocol widely used? Regards, Christoph Gartmann -----------------------------------------------------------------------+ | Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452 | | Immunbiologie | | Postfach 1169 Internet: gartmann@immunbio.mpg.de | | D-79011 Freiburg, FRG | +------------ http://www.immunbio.mpg.de/english/menue.html -----------+ ================================================================================ Archive-Date: Mon, 28 Feb 2000 13:46:13 -0500 Date: Mon, 28 Feb 2000 12:45:30 -0600 From: Hunter Goatley Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: IDENT on Port 113 gartmann@immunbio.mpg.de (Christoph Gartmann) writes: > >this time I noticed requests to port 113 of our Multinet host running V4.2 >under VAX-VMS 6.2 . Does Multinet answer these requests? Not by default, no, but there is a server written by Matt Madison. You can find it on ftp.multinet.process.com in [.CONTRIBUTED-SOFTWARE.APPLICATIONS.IDENT]. ftp://ftp.multinet.process.com/contributed-software/applications/ident/ident.zip >Is the protocol >widely used? > I wouldn't call it widely-used, no. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www2.wku.edu/hunter/ ================================================================================ Archive-Date: Mon, 28 Feb 2000 13:58:17 -0500 Date: Mon, 28 Feb 2000 14:04:12 -0500 To: Info-MultiNet@process.com From: Dan Sugalski Reply-To: Info-MultiNet@process.com Subject: RE: IDENT on Port 113 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:45 PM 2/28/00 -0600, Hunter Goatley wrote: >gartmann@immunbio.mpg.de (Christoph Gartmann) writes: > >Is the protocol > >widely used? > > >I wouldn't call it widely-used, no. I would. Most RedHat Linux distributions seem to do ident lookups at the drop of a hat. (wu_ftpd does it by default on any inbound connects, and it looks like some sendmail setups do too) Damned annoying too, since it causes timeout problems if the ident packets are dropped or filtered somewhere along the way. This doesn't mean ident's *useful*, mind, just in use. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk ================================================================================ Archive-Date: Mon, 28 Feb 2000 14:06:19 -0500 From: Javier Henderson Reply-To: Info-MultiNet@process.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Feb 2000 11:05:23 -0800 (PST) To: Info-MultiNet@process.com Subject: RE: IDENT on Port 113 References: <000228124530.202000c1@process.com> <4.3.0.20000228140203.02255ae0@24.8.96.48> Dan Sugalski writes: > At 12:45 PM 2/28/00 -0600, Hunter Goatley wrote: > >gartmann@immunbio.mpg.de (Christoph Gartmann) writes: > > >Is the protocol > > >widely used? > > > > >I wouldn't call it widely-used, no. > > I would. Most RedHat Linux distributions seem to do ident lookups at the > drop of a hat. (wu_ftpd does it by default on any inbound connects, and it > looks like some sendmail setups do too) Damned annoying too, since it > causes timeout problems if the ident packets are dropped or filtered > somewhere along the way. > > This doesn't mean ident's *useful*, mind, just in use. Yeah, and sendmail (and perhaps other MTA's) do ident queries as well. So far, I haven't ran into any SMTP server that will refuse connections from a host that doesn't run identd, but it does take a bit longer to get the dialog going without identd (waiting for the MTA indent request to timeout). -jav ================================================================================ Archive-Date: Mon, 28 Feb 2000 15:52:36 -0500 Date: Mon, 28 Feb 2000 12:51:39 -0800 (PST) From: Dan Wing Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com Subject: RE: IDENT on Port 113 Message-ID: <0002281249230.9374-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 28 Feb 2000 12:45 -0600, Hunter Goatley wrote: > >Is the protocol > >widely used? > > > I wouldn't call it widely-used, no. There are attempts by many folks to widely mis-use IDENT. That's why it wasn't included in MultiNet as a standard feature. Leave it off and don't worry about it. It's a silly protocol and only useful if the remote system fully trusts your system hasn't been compromised -- which isn't a good assumption and about as reliable as using IP address to authenticate rshell connections. -Dan Wing ================================================================================ Archive-Date: Tue, 29 Feb 2000 04:05:30 -0500 Date: Tue, 29 Feb 2000 10:03:54 +0100 From: "Juan C. Blanco" Reply-To: Info-MultiNet@process.com Subject: MASTER_SERVER-080_A042 To: info-multinet@process.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hello, We have experienced some problems after the installation of the last eco for MASTER_SERVER, after a time of working right, the systems fails to respond to any incoming connection managed by the Master server, examining the OPERATOR.LOG file we have see some messages like this: %%%%%%%%%%% OPCOM 29-FEB-2000 00:14:31.67 %%%%%%%%%%% Message from user SYSTEM on ZIPI MultiNet Server: accept: no I/O channel available Prior to this patch the system was working fine Any ideas about the problem ?. Reagrds Juan C. Blanco -- +----------------------------------------------------------------------------+ | Juan C. Blanco | | | | Centro de Calculo | | | Facultad de Informatica U.P.M. | E-mail: jcblanco@fi.upm.es | | Campus de Montegancedo | | | Boadilla del Monte | Tel.: (+34) 91 336 7466 | | 28660 MADRID (Spain) | Fax : (+34) 91 336 6913 | +----------------------------------------------------------------------------+ ================================================================================ Archive-Date: Tue, 29 Feb 2000 06:54:10 -0500 From: "Russell. Tadhg" Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: MASTER_SERVER-080_A042 Date: Tue, 29 Feb 2000 11:09:53 -0000 MIME-Version: 1.0 Content-Type: text/plain Anyone got any opinions on this reported bug ? I am planning to install this software to a very high-priority system this weekend. We are going from Multinet 4.1a to Multinet 4.2a + patches (including MASTER_SERVER-080_A042) to fix an Oracle TNS Listener hanging problem. I dont want to introduce more problems than are already there. Any timely replies gratefully welcomed... Tadhg Russell, ESB, Ireland. ================================================================================ Archive-Date: Tue, 29 Feb 2000 09:22:22 -0500 From: Richard Whalen Reply-To: Info-MultiNet@process.com To: "'Info-MultiNet@process.com'" Subject: RE: MASTER_SERVER-080_A042 Date: Tue, 29 Feb 2000 09:20:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I've done some investigation, and found a code path in the FTP code that could leave a channel open. I'm working on a fix. -----Original Message----- From: Juan C. Blanco [mailto:jcblanco@fi.upm.es] Sent: Tuesday, February 29, 2000 4:04 AM To: info-multinet@process.com Subject: MASTER_SERVER-080_A042 Hello, We have experienced some problems after the installation of the last eco for MASTER_SERVER, after a time of working right, the systems fails to respond to any incoming connection managed by the Master server, examining the OPERATOR.LOG file we have see some messages like this: %%%%%%%%%%% OPCOM 29-FEB-2000 00:14:31.67 %%%%%%%%%%% Message from user SYSTEM on ZIPI MultiNet Server: accept: no I/O channel available Prior to this patch the system was working fine Any ideas about the problem ?. Reagrds Juan C. Blanco -- +--------------------------------------------------------------------------- -+ | Juan C. Blanco | | | | Centro de Calculo | | | Facultad de Informatica U.P.M. | E-mail: jcblanco@fi.upm.es | | Campus de Montegancedo | | | Boadilla del Monte | Tel.: (+34) 91 336 7466 | | 28660 MADRID (Spain) | Fax : (+34) 91 336 6913 | +--------------------------------------------------------------------------- -+ ================================================================================ Archive-Date: Tue, 29 Feb 2000 15:29:06 -0500 From: "Dennis Leiterman" Reply-To: Info-MultiNet@process.com Subject: bind_movefile. Date: Tue, 29 Feb 2000 13:18:59 -0500 To: INFO-MULTINET@PROCESS.COM Hi, I am using Multinet 4.2A. I have set up some secondaries on this bind and send them to a subdirectory off the multinet root. All the secondary files are there, but I notice a lot of bind_movefile.somenumber files in there. The bind_movefile file are the zone files that get transfered. Anybody know why they are there and, (besides deleting them manually), how to get rid of them. Thanks!!! -Dennis Leiterman ================================================================================ Archive-Date: Tue, 29 Feb 2000 15:52:49 -0500 Sender: schreiber@process.com Date: Tue, 29 Feb 2000 15:51:50 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: bind_movefile. "Dennis Leiterman" writes: > >Hi, I am using Multinet 4.2A. I have set up some secondaries on this >bind and send them to a subdirectory off the multinet root. All the >secondary files are there, but I notice a lot of bind_movefile.somenumber >files in there. The bind_movefile file are the zone files that get >transfered. >Anybody know why they are there and, (besides deleting them manually), >how to get rid of them. Thanks!!! > I'm not sure I exactly follow what you are reporting. Can you send me your MULTINET:NAMED.CONF file, and a directory listing of the subdirectory you are referring to? -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================ Archive-Date: Tue, 29 Feb 2000 16:01:20 -0500 Sender: schreiber@process.com Date: Tue, 29 Feb 2000 16:00:23 -0500 From: Jeff Schreiber Reply-To: Info-MultiNet@process.com To: Info-MultiNet@process.com CC: schreiber@process.com Subject: RE: bind_movefile. Jeff Schreiber writes: > >"Dennis Leiterman" writes: >> >>Hi, I am using Multinet 4.2A. I have set up some secondaries on this >>bind and send them to a subdirectory off the multinet root. All the >>secondary files are there, but I notice a lot of bind_movefile.somenumber >>files in there. The bind_movefile file are the zone files that get >>transfered. >>Anybody know why they are there and, (besides deleting them manually), >>how to get rid of them. Thanks!!! >> > > I'm not sure I exactly follow what you are reporting. Can you send > me your MULTINET:NAMED.CONF file, and a directory listing of the > subdirectory you are referring to? > While your at it. Get the directory listing with /own/prot/acl. Did you install any NAMED patches? -Jeff -- Jeff Schreiber, Process Software Corp. schreiber@mx.process.com http://www.process.com TCPware & MultiNet: Stronger than Ever ================================================================================