HDTenEightyP/NetNews huggingface dataset:
From: snyder@voodoo.utcc.utk.edu (kim snyder)
Subject: hardware,software,policy for dial-in IP lines
Followup-To: comp.protocols.ppp
Keywords: security, cost, efficiency, maintainability, etc.
Organization: University of Tennessee Computing Center
Distribution: na
Date: Tue, 25 Aug 1992 21:53:27 GMT


We're finally getting around at the center here to thinking 
about maybe, possibly getting dial-in IP lines to supplement 
the DCA.  I am interested in hearing from other sites who have 
already implemented dial-in IP lines about their setup.  What you 
think you did right, what you would've done differently.  The hardware
you used and why, software you used and why, security issues that
need to be addressed, etc.  Authentication mechanisms...Do you support 
advertised subnets on the other side?  Billing algorithms.   We have
several isolated ppp links, but no "mass" offering, if you will.

Thanks for any info,

Kim Snyder
University of Tennessee
Knoxville, TN  37996 
snyder@utkux1.utk.edu
fax (615) 974-2622
fone (615) 974-6616

Newsgroups: comp.protocols.ppp
From: stevew@helios.unl.edu (Steve Wu)
Subject: ppp on SLC help.
Organization: University of Nebraska - Lincoln
Date: 27 Aug 92 16:19:27 GMT


  Hi, I need some help on MorningStar PPP setup. We have one SS2 run
4.1.2 with PPPbeta1.01 and it was fine when we had a Sun3/50 running
the same package and both these two machine talking well. Recently we
replace the Sun3 with SLC and I try to setup ppp again. The problem I
have now is when I run ppp on SLC, I have the following message:
   ppp:  tcsetpgrp(): inappropriate ioctl ...

  I sent mail to Karl Fox (author) yesterday but he was on vacation.
So I have to post to get some help.

  I appricate any information and I would post summery after.

  Thanks.

  steve
--
stevew@helios.unl.edu  |=| \ Fender / |=| ... smoke on the water, fire in
                       |=|   \    /   |=| the sky...   Smoke on the water.
stevew@hoss.unl.edu    |=|     \/     |=|     (36 bars guitar solo)
		      Deep purple, the best
From: dswartz@redondo.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.protocols.ppp
Subject: PPP for Mac (A/UX)
Date: 30 Aug 92 21:34:19 GMT
Organization: Stratus Computer, Software Engineering


The subject says it all.  I've poked around and every PPP package I've
seen seems to be for Sun, sparc, Vax or something else.  Failing an
A/UX version, how about a generic SysV version I could hack up?

-- 

Dan S.
From: rhoward@matd.gatech.edu (Robert L. Howard)
Newsgroups: comp.protocols.nfs
Subject: Re: PC-NFS & NIS
Date: 31 Aug 92 16:51:07 GMT
Organization: Georgia Tech Research Institute

hanke@nessie.cs.id.ethz.ch (Norbert Hanke) writes:

>On quirk remains, however: trying to NET USE $NISSERVER:$HOME fails with
>the message
>  NFS057F : $HOME may only be used if the network information service is up.

Actually I think you can do a simple:

NET USE $HOME		(leaving off the $NISSERVER)


>Doing a NET NAME >NUL before NET USE makes also this problem disappear.

Yes, I ran across this problem too.  I reported it to Sun a L*O*N*G
time ago.....

Robert
--
| Robert L. Howard              |   Georgia Tech Research Institute     |
| robert.howard@matd.gatech.edu |   MATD Laboratory                     |
| (404) 528-7165                |   Atlanta, Georgia  30332             |
-------------------------------------------------------------------------
| "See, when the GOVERNMENT spends money, it creates jobs; whereas when |
| the money is left in the hands of TAXPAYERS, God only knows what they |
| do with it.  Bake it into pies, probably.  Anything to avoid creating |
| jobs." -- Dave Barry                                                  |
From: slang@waikato.ac.nz
Newsgroups: comp.protocols.nfs
Subject: PC-NFS name mapping.
Date: 3 Sep 92 12:39:47 +1200
Organization: University of Waikato, Hamilton, New Zealand

Another little interesting problem.

When a PC-NFS 4.0a client tries to access a NFS server that has some of its
files in Uppercase, then PC-NFS does it's filename truncating stuff. This is of
course entirely valid as if a server has two different files with the same name,
but one entirely in uppercase, and one entirely in lowercase, they are actually
different files from most servers point of view. DOS would treat these files as
exactly the same.

Now, when you have a OS/2 NFS server using an HPFS partition, HPFS preserves the
case, but is not case sensitive. In these servers, the file would be the same
from the servers point of view, however PC-NFS would still do the filename
truncation if it contained any uppercase characters in the filename. In this
case it doesn't really make sence to do the name mapping.

What is even worse is if you have a OS/2 NFS server serving out a FAT partition
to PC-NFS FAT clients. FAT filesystems have no concept of case, and will only
store files in UPPERCASE. This means that if you do mount a FAT filesystem on an
OS/2 NFS server, every file will be mapped into a different name-space.

E.g..

PC-NFS		Unix Server		OS/2 Server
				HPFS Partition	FAT Partition

SLANG~3A					SLANG
SLANG~6A	SLang		SLang
SLANG		slang		slang

The PC-NFS column is what PC-NFS reports back to DOS as the real filename. The
other columns are what the actual filename is depending on what type of server/
filesystem is being used.

In the case where you have a FAT partition on a server, and a DOS systems as a
client, it seems stupid that you can't even access the files by their own name!

Is there a way around this at all? Am I missing something?

I'm not looking to turn off all Name mapping, but if we were given the option
of specifying UPPERCASE filenames to be the default, and then lowercase would
be mapped, then it would fix at least one _SIMPLE_ situation that we have here.

Cheers --
 
	   Drink is the curse		Steve Lang
	of the working class man	Systems Programmer Analyst
	Work is the curse of the	University of Waikato
	   Drinking class man		Hamilton
					NEW ZEALAND
					<slang@waikato.ac.nz>
					Ph	+64-7-856 2889 Ext 8341
					Fax	+64-7-838 4066

I am not responsible for my employers opinion (thank heavens,) and neither are
they for mine.
Newsgroups: comp.protocols.nfs
From: hanke@nessie.cs.id.ethz.ch (Norbert Hanke)
Subject: PC-NFS & NIS
Summary: PC-NFS 4.0a fails to find NIS server, 3.5c works 
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Thu, 27 Aug 1992 10:34:57 GMT

A few days ago we upgraded our installation from PC-NFS 3.5c to 4.0a, and
since then, PC-NFS has problems finding the NIS server.
Exactly the same configuration works ok with 3.5c but has problems with 4.0a.

We issue the following commands:

NET NISDOMAIN ournisdomain

--> [PC-NFS is Installed]

NET START RDR

--> NFS126W :  Unable to get hostname by ip addr (cor.rect.ip.address)

NET NAME

--> The name of this system is UNKNOWN
--> , and its IP address is cor.rect.ip.address.
--> The subnet mask is 255.255.255.192 [0xffffffc0].
--> It is in network information service domain ournisdomain, for which there is no NIS server.
--> There is no authentication (PCNFSD) server
--> No gateway is currently defined.
--> You are logged in as nobody, with UID -2 and GID -2.
--> It is Thu Aug 27 10:58:52 1992, CET

It seems that RARP works correctly: the PC knows its IP address after the
NET START RDR command, also the subnet mask is correct. But it's unable to 
contact the NIS (and simulatinous PCNFSD) server. 

There exists a workaround, however: If I replace the simple NET START RDR from
above with the following sequence, everything works ok, apart from the same
error message as described above.

NET START RDR
NET NISSET ournisserver
NET STOP RDR
NET START RDR

Any explanations for this behaviour? Any help is appreciated.

Norbert Hanke
ETH Zurich, Switzerland
From: bmb11@cus.cam.ac.uk (B.M. Bolker)
Newsgroups: comp.protocols.nfs
Subject: PCNFS 4.0/Viglen IV/WD8003E problems: DOS COPY and more
Date: 3 Sep 92 17:50:44 GMT
Organization: U of Cambridge, England


   we are running PC-NFS 4.0 on a Viglen III (386) PC and a Viglen IV (486)
PC.  The server is a SPARCstation 1 running SunOS
4.1.1.  All the PCs are running DOS 5.0.  (We recently upgraded from
PCNFS 3.5 where we had the identical problem -- hoped it would fix it
but didn't ...)
   Everything works fine on the Vig III.  On the Vig IV *most* things
work (printing, telnet, ftp, etc., etc.) *but* DOS COPY garbles files greater
than about 10K (this is very approximate) when it retrieves them from
the Sun disk to the PC ... rcp and ftp and unix2dos appear to work fine.
(COPY *only* screws things up in the Sun -> PC direction.  The other
direction, PC->sun, appears fine.)  The problem
appears to apply to all types of files (ascii, .EXE, Lotus worksheet,
compressed (.ARC), etc.) equally.  The problem also makes it practically
impossible to run PC executable files that reside on the server disk.
(At least, I assume it's another facet of the same problem.)
   The machines are configured practically identically, both using WD8013E
cards (using the WD8003E driver in PC-NFS), both running PC-NFS 4.0 and
DOS 5.0.  The details of IRQ, and memory are slightly different,
but I've tried changing IRQ around a bit on the Vig IV with no success.

  I don't really have any idea what the problem is ... *maybe* it's
because the driver is for the WD8003E and I've got the WD8013E?  There
is supposedly a Western Digital (=WD) bulletin board available by
modem access in the US that has new drivers on it (at least that's
what the two-year-old README file that came with the WD cards says),
but I don't have a dialout line nor could I really call the US.

  I hope I've included all the relevant information.  Please feel
feel free to e-mail for more info if you think you have an idea.
Crazy speculations less welcom, but also OK.
  Suggestions?  Has anyone seen this before?
  Please e-mail suggestions.

    Ben Bolker
    bmb11@cus.cam.ac.uk
From: sterling@atlastele.com (Sterling Huxley)
Newsgroups: comp.protocols.nfs
Subject: NFS recursion
Date: 3 Sep 92 00:08:22 GMT
Organization: Atlas Telecom Inc.
Disclaimer: Views expressed do not necessarily represent those of my employer.

Will this work?
	# hostname
	navstar
	# mkdir /navstar
	# mount  navstar:/  /navstar

nfs mounting your own root in your own root directory?

-- 
Sterling Huxley              sterling@atlastele.com
Why doesn't my fast forward button work on Reality?
From: aarond@xibm.StorTek.com (Aaron Dailey)
Newsgroups: comp.protocols.nfs
Subject: Re: PCNFS and symbolic links
Date: 4 Sep 92 15:39:42 GMT
	<dbmn2=r.dbander@netcom.com>
Organization: StorageTek


   In article <1992Sep3.210904.8297@twg.com> oldera@twg.com (Ed Alcoff -  Prod Mtg) writes:
   >(Geoff) correct me if I'm wrong, but I believe that PC-NFS
   >can handle symbolic links, and if they are absolute, then
   >you use the "net join" program.

   How about it Geoff, is there a way for PC-NFS to see symbolic links?
   Whenever I do a DIR or even an ls in a mounted directory known to 
   contain symbolic links, the symbolic links do not appear.

   Am I missing something?

   -- 
   /------------------------------------------------------------------\
   |     David B. Andersen             (dbander@netcom.com)           |
   \------------------------------------------------------------------/

This topic has cmoe up before, and I believe the answer is that as
long as the link is to a directory contained on the mounted drive it
will work.  But, PC-NFS can't figure out symbolic links to filesystems
that it doesn't have mounted as part of that drive.  For example, we
have a symbolic link

 /project/lcp/src/sys -> /project/twolf/src/sys386

And we have mount /project/lcp/src as a drive on PC-NFS, it won't be
able to find it.  If the symbolic link were to another point within
the mounted filesystem, it could find the file.  Geoff could give the
technical reason why.

I believe that one of the other NFS client for PC vendors has a way
around this (FTP, B&W?).

--
Aaron Dailey Internet: Aaron_Dailey@stortek.com
StorageTek Corporation   Voice: (303) 673-4989, FAX: (303) 673-2570
Mail:  MS0242, 2270 South 88th Street, Louisville, C0 80028
Newsgroups: comp.protocols.nfs
From: fred@maccs.dcss.mcmaster.ca (Fred Whiteside)
Subject: Re: Memory usage of NFS daemon bwnfsd 
Reply-To: fred@bws.com (Fred Whiteside) 
Organization: Beame & Whiteside Software Ltd. 
Date: Wed, 2 Sep 1992 13:47:01 GMT

In <1992Sep2.073146.2534@monu6.cc.monash.edu.au>, sci213v@monu6.cc.monash.edu.au writes:
>I have a question about the daemon that runs on a Unix host to provide
>print and filelocking/sharing services to PC NFS clients.  I am using the
>Beame and Whiteside product bwnfsd and it is running on Ultrix4.2 on a
>DECStation 5000/120.
>
>I have noticed that over a period of time (a week or so) that the memory
>usage of bwnfsd as reported by 'ps -aux' grows from 1.9% to approx 35%.  I
>have confirmed this growth with a DEC public domain programme called 'pmon'.
>
>The rate at which the memory usage grows depends on the actual usage by the
>PC clients.  By the way, the DECStation has 16MBytes of RAM. I have 5 PC-NFS
>clients attached to the Unix box and the load is only light -approx 5 megabytes
>of data a day between the 5 PC's.

	i assume that you have 5 Beame & Whiteside NFS clients, as PC-NFS
clients do not use bwnfsd for authentication/printing.

	ahem. "PC-NFS is a trademark of Sun Microsystems and should not
	be used as a generic term to indicate PC implementations of NFS".
	(thought i'd say it before geoff had to :-))

	our version 2.2 daemon had a memory leak. it was fixed in the version
2.3 daemon.  we are about to release version 3.0, which also has a fairly
substantially changed daemon.  i don't really want to send out the 3.0
version until next week sometime, but the 2.3 daemon should solve your
memory problems.

	hope this helps,

	Fred Whiteside
-- 
Fred Whiteside   Beame & Whiteside Software Ltd., Caledonia, Ontario
fred@bws.com   fred@maccs.DCSS.McMaster.CA   ...!uunet!utai!utgpu!maccs!fred
Newsgroups: comp.protocols.nfs
From: costello@eplrx7.es.duPont.com (Tim Costello)
Subject: Re: PCNFS and local printing
Organization: DuPont Engineering Physics Laboratory
Date: Wed, 26 Aug 1992 13:51:21 GMT

From article <1992Aug26.035214.4703@access.usask.ca>, by reeves@rocky1 (Malcolm Reeves):
> From article <8328@sirius.ucs.adelaide.edu.au>, by george@ucs.adelaide.edu.au (George Travan):
>> 
>> I have installed pcnfs4.0 on our pc network linked to our SUN IPX.
>> Remote printing to the Sparcprinter on the IPX works OK from the pc's,
>> even within MS windows applications, such as MSword etc.
>> My problem which I just noticed is that I can no longer print to a 
>> pc's local printer when NFS is installed. Even as the default printer 
>> though the control panel this doesnt work.
>> 
>> To print to the local printer I have to uninstall PCNFS
>> It says in the manual that PCnfs 'doesnt interfere with the operation 
>> of any printers attached to your PC'. But I cant see anything wrong
>> with the way I access the local printer from mswindows.
>> Anyone have any pointers??
>> 
>> /Geo
> 
> Don't have any answer but I have the same problem. Also I can't get a
> shared printer on a PC to function with any degree of reliability. 
> Apparently this was also a problem in PCNFS 3.5. Anyone know a fix ?
> 
> Malcolm
> 
> --
> ------------------------------------------------------------------------------
> Malcolm Reeves, Geological Engineering, University of Saskatchewan, Saskatoon,
> SK, S7N 0W0 aka reeves@rocky1.usask.ca aka reeves@dvinci.usask.ca
> ------------------------------------------------------------------------------
	We overcame the problem by changing the output port for the local
printer from (for instance) LPT1: to LPT1.OS2, in the control panel/printer
setup.  I don't quite remember how this was discovered but I dimly remember
that another Windows application recommended trying this if we had trouble
printing locally.  We also still have Print Manager enabled, but it didn't
really seem to make a difference if we did not, once we set the definition
to LPT1.OS2.

	This is all running under Win 3.1, can't tell you if the same effect
would be seen in Win 3.0.

Tim Costello
Du Pont Merck Pharmaceutical
costello@eplrx7.es.dupont.com
-- 
Tim Costello
Du Pont Merck Pharmaceutical
costello@eplrx7.es.dupont.com
Newsgroups: comp.protocols.nfs
From: rabbe@infolog.se (Rabbe Fogelholm)
Subject: Ctrl-P key confusing to PC-NFS?
Organization: Infologics AB, Sollentuna, Sweden
Date: Thu, 3 Sep 1992 21:06:02 GMT

I recently started to use PC-NFS (Sun Microsystems, 4.0) on a Toshiba
5100, using a Xircom "pocket Ethernet adapter". It more or less works
fine, but there is some conflict between the Ctrl-P key and the PC-NFS
setup. When I use emacs on a remote host via a telnet session, nothing
happens when I push Ctrl-P. Instead, when I have closed the telnet
session and I am back in MS-DOS, I get a message complaining about
"device PRN" (I think it was) and an "Abort, Retry, Ignore, Fail" prompt.

Is this because of some ancient feature of DOS (I use MS-DOS 3.30)?
Or has it something to do with the fact that the Xircom adapter is
plugged into the printer port?  When I use a terminal emulator that is
part of Kermit (MS-Kermit 2.26), accessing the COM1 port, there is no
problem with Ctrl-P, though.

Thankful for any advice on this.

________________________________________________________________________
Rabbe Fogelholm, Infologics AB     rabbe@infolog.se    fax: +46 8 960846
Newsgroups: comp.protocols.nfs
From: blm@teal.csn.org (Brian L Moore)
Subject: Re: PCNFS and local printing
Organization: Colorado SuperNet, Inc.
Date: Wed, 26 Aug 1992 14:03:54 GMT

reeves@rocky1 (Malcolm Reeves) writes:

[...stuff deleted about local printers with PC-NFS...]

>Don't have any answer but I have the same problem. Also I can't get a
>shared printer on a PC to function with any degree of reliability. 
>Apparently this was also a problem in PCNFS 3.5. Anyone know a fix ?

When you have a printer defined in PC-NFS as the same port as a local printer
uses (e.g. LPT1:),  PC-NFS will intercept everything before it reaches your 
local port and send it to the remote printer.  The only way around this is to
not use the PC-NFS LPT port that your local printer is on.

You can also switch back and forth, disabling the net printer by using
	NET USE LPT1: /D
and re-enabling it by using
	NET USE LPT1: \\<machine>\<printer>
However, this seems to confuse PC-NFS after doing this a few times.  *sigh*

-Brian
	
Newsgroups: comp.protocols.nfs
From: gjm@bio.vu.nl (Gijs Mos)
Subject: PC-NFS / Netware / Paradox file locking
Organization: VU Biology, Amsterdam, The Netherlands
Date: Thu, 3 Sep 1992 19:17:39 GMT

I run PC-NFS 4.0a and Netware concurrently in my PC, using ODI drivers and
an ODI to packet interface. For locking I run Share. Unfortunately Paradox
seems to lose its lock on paradoc.net when something else is started from
whithin Paradox (Tools|More|ToDos). Now, if I don't load PC-NFS locking
works fine over Netware.

Does anyone knows what causes this problem. Can I fix/circumvent it.
Can Sun fix it?

Gijs Mos
gjm@bio.vu.nl
From: curt@ekhadafi.austin.ibm.com (Curt Finch 903 2F021 curt@aixwiz.austin.ibm.com 512-838-2806)
Newsgroups: comp.protocols.nfs
Subject: NIS across gateways
Date: 27 Aug 92 15:52:41 GMT
Organization: IBM AWD, Austin

I have a customer who sent me the following question:

>Within in an "area" there may or may not be routers.  We are thinking of
>proposing the following idea regarding NIS:

>Within an area, there is one NIS master.  All other servers are
>designated as slaves.  This will get around the router problem.
>However, we noted that slaves could not get new copies of the maps
>unless they were bound to the master.  Ideally, we would like to
>have each slave bound to itself.  This way if a server goes down,
>we know that users on the surviving servers do not have to wait
>until their server is rebound.  We are unsure of deciding how to
>best design around these binding issues.

NIS can't bind through a gateway generally since broadcasting doesn't
work.  What sort of strategy might work for this, here are two I thought
of:

1.  Leave the slave bound to itself.  You might try having the master
    rsh to the slave and run a shell script which does the following
    whenever it's time to yppush:
        ypset master
        get all the maps
        ypset slave

2.  Or you could try leaving the slave always bound to the master but
    running a cron job which tries to figure out when the master dies
    and at that time rebinds to the slave until the master comes back
    using ypset.

Can anyone tell me these ideas are wrong, or think of some others?
-- 
curt@aixwiz.austin.ibm.com (Curt L. Finch) | AIX NFS/NIS Field Quality 
My views are unrelated to those of IBM     |        Austin, TX
  Social Security isn't a retirement plan.  It's middle class welfare.
Newsgroups: comp.protocols.nfs,comp.dcom.lans,comp.protocols.tcp-ip
From: kozlowsk@Informatik.TU-Muenchen.DE (Rolf Kozlowski)
Subject: Question for RPC - gurus
Keywords: RPC
Originator: kozlowsk@hprbg4.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 28 Aug 1992 13:07:30 GMT
Reply-To: Rolf.Kozlowski@Informatik.TU-Muenchen.DE


Hi,

I have written a little sample programm using RPC (see any RPC Guide like 
HP's `Programming and Protocols for NFS Services` ).  The client only makes 
a request for an integer value and the server returnes an integer.
Afterwords I have put some timestamps into the client and measured with
our network monitor the time of the packets on the ethernet.
The C-Source looked like this:

	...
	gettimeofday (&timval1, &timzone);
	clnt_stat = clnt_call (client, RUSERSPROC_NUM, xdr_void, 	
	   0, xdr_u_long, &nusers, total_timeout)) != RPC_SUCCESS);
	gettimeofday (&timval1, &timzone);
	...

The results were like this:
	- Output client) 
		the result of the RPC: 777
		    RPC-delay = 2694 usec
				---------
	- Delay between the request-packet from the client and the reply from 
	  the server:            633 usec
				---------
	  (this delay includes: send the request (client), 
				receive the packet and prepare it (server)
				send the reply (server) )

	The time between receiving the frame from ethernet and returnung from 
	the `clnt_call()` is about 2 msec's!!

Now my question:
	What happens after the client has received the reply ?? 

Thanks

---------------------------------------------------------------------------------
Rolf Kozlowski	Inst. fuer Informatik, Technische Universitaet Muenchen
		PO-Box 202420, 8000 Muenchen 2, Germany
Rolf.Kozlowski@Informatik.TU-Muenchen.DE	Tel: +49 89 2105 8193

				
		

Newsgroups: comp.protocols.nfs
From: hoffman@tsla.noava.lisc.lockheed.com (John Hoffman)
Subject: PCNFS 4.0 and Windows Lockup
Organization: LISC Noava
Date: Mon, 31 Aug 92 22:33:56 GMT

I have found and interesting couple of cases where pcnfs 4.0a and windows are
causing lockups.  This first case has be reported by a couple of users, when
they are running telnet under windows and they do a printscreen 3 times on the
third time the system locks up.  I have also noticed that if on my system
you do a printscreen from a dos window the system will sometimes print the 
wrong information or not print atall.  But if I make the screen full-screen
everything prints ok on my system.

Another one, If I go into a dos window and print a file useing the print command
the file will print but the print program never comes back.  If I control-Alt-
del and hit return telling windows to kill the program the screen will snap to 
full screen mode and leave me at the dos prompt.  If I exit I'm back in windows.

The system configuration used is an everex 386/25 with 8MB memory and for the 
user a Cabletron 20xx network card for my system a WD ethernet card.  Has anyone
seen these kinds of problems and are there any solutions.  All the machines are
running Dos 5.0 and windows 3.0 for the customer and 3.1 for myself.

Thanks,
John
Newsgroups: comp.protocols.nfs