The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for December 1990 (339 messages, 196491 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/12.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 90 07:53:28 GMT
From:      usc!samsung!think.com!barmar@apple.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ICMP Time Exceeded sent on non-initial fragments?
In article <17727@shlump.nac.dec.com> ciarfella@shug.enet.dec.com (Paul Ciarfella) writes:
>	RFC 1122 says that ICMP messages must not be generated as a
>	result of receiving non-initial fragments of a datagram.
>	But, what happens if reassembly of a datagram times out 
>	and the initial fragment was never received.  Does this
>	mean that I cannot send an ICMP Time Exceeded given that
>	I don't have the initial fragment?

Correct.  ICMP error messages are supposed to contain the first N data
octets from the IP datagram that caused the error.  This allows the
recipient of the ICMP error to determine which higher-level protocols got
the error, and report the error back to the appropriate entities.  If you
haven't received the first fragment then you can't have the first N data
octets, so you won't be able to construct a useful error datagram.

If you don't receive the initial fragment then the sender will simply
behave as if no fragments made it to you, presumably timing out and perhaps
retransmitting.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 90 13:03:03 GMT
From:      eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: reuse of addresses when calling bind()
In article <87047@lll-winken.LLNL.GOV>, Mark Boolootian writes:

   Unfortunately, I still don't see how this particular error
   [EADDRINUSE] can occur once the socket has been correctly
   setsockopt()'ed.

A TCP connection is uniquely identified by the 4-tuple <Raddr, Rport,
Laddr, Lport> where R means Remote and L Local, a total of 96 bits!
Given that you always have a peer in an established connection, I have
never understood what you gain from defaulting to consider only the
<Laddr, Lport> pair for uniqueness.  Seems silly.  Even with several
processes listen()ing to the same Lport, it isn't a problem, since the
TCP handler will arbitrarily assign a connection to one of the waiting
processes, and thereafter the connection is uniquely identified.  Can
someone with first-hand experience tell me why BSD sockets don't
default to "reusing" addresses?  (I think "reuse" is a misnomer, too,
since it's not actually reused, unless you narrow your view to the
local <addr, port> pair, sort of like thinking that the horizon is a
place.)

However, there is a chance that things may go astray.  If a broken
application (say, one which always calls out on the SMTP port (25),
instead of getting a fresh Lport) attempts to connect to the same host
on the same port (say, SMTP), the 96-bit connection "identifier" is
already in use.  In most of the implementations of TCP that I have
seen, you would have to work _real_hard_ to accomplish this.  (At
least I would have to work real hard, others may find it obvious that
it should be done that way, and complain about how stupid TCP is. :-)

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Dec 90 16:16:19 GMT
From:      sfrazier@vlink01.UUCP (8780)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP on a DOS Machine

Could someone explain to me if I could do the following:

	I will have TCP/IP installed on my UNIX Box (SCO).
	I want to put a dos machine on the TCP/IP.
	Can I do that and allow the dos machine to do rlogin, telnet,
	ftp?  If so, what software would I need to get for the DOS machine?
	Could I have several dos machines on this arrangement.

Thank you very much in advance for you help.  Please email me your responeses.

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Sat Dec  1 18:04:10 1990
From:      root%shiva@shakti.ernet.in
To:        
>From NIC.DDN.MIL!tcp-ip-RELAY  Mon Nov 12 06:32:11 1990 remote from shakti
Received: by shakti.ernet.in (1.2/Ultrix2.0-B) for ernet.in
	id AA00523; Mon, 12 Nov 90 06:32:17+0530
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP 
	id AA21066; Sun, 11 Nov 90 19:54:53 -0500
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 10 Nov 90 13:39:52 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA24877; Sat, 10 Nov 90 13:36:56 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 10 Nov 90 20:09:42 GMT
From: shakti!decwrl.dec.com!sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino
Organization: University of Kansas Academic Computing Services
Subject: humanitarian request
Message-Id: <26685.273c1836@kuhub.cc.ukans.edu>
Sender: shakti!nic.ddn.mil!tcp-ip-relay
To: shakti!nic.ddn.mil!tcp-ip



Dear NetFolks,

We would appreciate your responding to the request of Craig Shergold who
is a seven year old boy with an inoperable tumor on his brain.

He has not been given a very long time to live and it is Craig's ambition
to enter the Guiness Book of World Records for the largest number of get
well cards ever received by an individual.

Please send your card to:

     Craig Shergold
     % Children's Make-A-Wish Foundation
     32 Parimeter Center East
     Atlanta, Georgia 30346


               -------------------------------------

Letters similar to this have been sent out by traditional mail to large
organizations all across the U.S. on Craigs behalf. Instead of passing
it on by land-mail, I thought the net would be a great way of getting 
the word out to as many people as possible in as short a time as possible.

Please pitch-in & send Craig a get well card, and by all means feel free
to circulate this letter to local businesses/organizations, or other
BBS's you may belong to. All your help and effort will certainly be 
appreciated! Thank you.

                                      Sincerely,
                                                Jack Petrino          
                              
                              
----------------------------------------------------------------------
       Jack Petrino (DRAGON)        int: PETRINO@KUHUB.CC.UKANS.EDU         
       Systems Testing              bit:     PETRINO@UKANVAX
       University of Kansas         vox:      (913)864-0443          
       Computer Center              fax:      (913)864-0485    
-----------------------------------------------------------------------

PS - I apologize for the possible redundancy of posting this net-wide. I
     hope everyone can understand the necessity/urgency of the situation.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 01:26:55 GMT
From:      usc!oxy!schorsch@ucsd.edu  (Brent William Schorsch)
To:        tcp-ip@nic.ddn.mil
Subject:   Help finding telenet software to perform ftp as remote
I am currently using NCSA Telenet software (from Univ. of Illinois at urbana
with a MacSE appletalk connected to a fastpath -> ethernet to Usenet
I currently have to connect to a local Sun Workstation and ftp from there,
then, ftp to my mac and send from the Sun to me, I would like to remove
the middle step... ( I read a review in Macworld Jan 91, p. 207 on
TCP/Connect II 1.0, has anyone used this?)
How about a pd program like NSCA Telnet, (TCP/Connect is $495!!)
Thanks, Brent Schorsch (schorsch@oxy.edu)
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 05:15:24 GMT
From:      nigel@cnw01.storesys.coles.oz.au (Nigel Harwood)
To:        comp.protocols.tcp-ip
Subject:   rlogin and run a command etc

Apologies if this is a FAQ but I have up till now not read
this news group (I did read all postings not yet expired).

I have two systems connected via Win TCP/IP Ethernet.

One system is to be used by the users to run all their jobs
irregardless of which machine the job runs on.

I cannot use the remote shell as some of the jobs they run
are COBOL programs which use cursor addressing etc.

Rlogin seemed to be promising as it can be auto-login with
Win TCP/IP.

The problem was that I cannot tell it to run a command as soon as
it has logged in.

Someone pointed out that the TERM variable was exported (nothing
else from the environment sadly).

By a slight fudge I could use TERM and the .login to do the job
but is there a better way ?

I have toyed with getting the source to rlogin but I'd rather not.

Regards
-- 
<<<<<<<<<<<<<<<<<<<<<<<<<  Nigel Harwood  >>>>>>>>>>>>>>>>>>>>>>>>>>>
<< Post:  Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia     >>
<< Phone: +61 3 829 6090  E-mail: nigel@cnw01.storesys.coles.oz.au >>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 12:45:10 GMT
From:      mcsun!unido!pemstgt!ralfi@uunet.uu.net  (Ralf Holighaus)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: need URGENT help with SCO UNIX TCP/IP - please
schweigl@edvvie.at (Johnny Schweigl) writes:


>Error:
>	After entering userid and passwd (telnet session is ok) SCO UNIX
>	responds with "Cannot obtain database information on this terminal".
>	when logging on as root on /dev/console, the system tells me that
>	"The security databases are corrupt". No new logins are allowed after
>	this error had occured.
>	The error seems to have no systematic behaviour. It appears at random
>	points in time, with 3 telnet sessions or 20, or something like that.

>Possible sources of error:
>	Someone modified /etc/passwd manually. System will be reinstalled
>	completely this weekend. If this was the only problem, shouldn't the
>	error occur permanently? Quite contrary, it is not reproducible.

Do you have any software installed on your system which maybe changes
either /etc/passwd or /etc/group directly? We had a problem with some database
software which behaved like that and therefore had to reinstall the entire 
system!

Rgds
Ralf
-- 
Programmentwicklung fuer    Microcomputer |         Ralf U. Holighaus
PO-Box 810165        Vaihinger Strasse 49 |         >> PEM Support <<
D-7000 Stuttgart 80          West Germany | holighaus@pemstgt.PEM-Stuttgart.de
VOICE: x49-711-713045 FAX: x49-721-713047 |      ..!unido!pemstgt!ralfi 
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 14:40:32 GMT
From:      n8emr!vlink01!sfrazier@tut.cis.ohio-state.edu  (8780)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP From DOS
I need some help.  I have (just installed) SCO Unix TCP/IP.  It resides on the
UNIX box with (1) WD8003 card and hooks to a DOS XT with (1) WD8003 card there.

The TCP/IP is up and running on the UNIX Box.  I need to know what software
package(s) that are available from the DOS Machine to access rlogin, telnet,
ftp on the Unix Box.  The DOS machine will not or is not on a LAN now and
only has a couple of software packages on it as this time.  It will be used
as a terminal off of the UNIX Box.

Please email me your thoughts and help.

Thanks in advance.

Steve
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 14:46:04 GMT
From:      n8emr!vlink01!sfrazier@tut.cis.ohio-state.edu  (8780)
To:        tcp-ip@nic.ddn.mil
Subject:   NCS TELNET - The Package
Could someone tell me about NCS TELNET?  Where can you get it?  What
is the cost? ETc.?

Thanks.

Please email me your thoughts.

Steve


-- 
V-Link                                  | Steven E Frazier
1828 Darrow Drive                       |---------------------------------------
Powell OH   43065-9261                  | Local : sfrazier
614-365-3056                            | Remote: sfrazier@vlink01.UUCP
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 14:58:25 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when connecting to an Internet
On 26 Nov 90 17:32:00 GMT, damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") said:

damian> Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree
damian> completely with all comments regarding host based security
damian> rather than network imposed security. However, that is often not
damian> possible due to the internal politics of an enterprise network
damian> and who administers its hosts.

Well, if you are given goals and responsibility for them and not the
ability to reach them, you are in a grave situation. You may be able to
come up with a temporary patch up job, that will make people think that
you have solved the problem, until disaster strikes, and *you* are the
scapegoat.

damian> The majority of hosts on my internet are administered by
damian> engineers NOT network managers or systems programmers. The
damian> reality of my situation is that I cannot dictate how individual
damian> hosts are to be configured because I do not own them.

This sums up to saying that these machines have ZERO (repeat ZERO)
security. Does it really make a difference whether anybody within the
company or anybody within the Internet can access them? How do you know
that one of these guys does not already have an Internet connection?
This is a deadly serious problem. You cannot take responsibility for the
security of machines you do not own. Monitoring or controlling internet
traffic is just not a viable substitute (monitoring however is an
important aid). I would not bet my job and reputation on it.

damian> Yes, this does lead to MANY problems...  Limiting the visibility
damian> of an internet via router/bridge filtering will buy time until
damian> you can get the job done right.

But as somebody else has said the solution is not to filter packets.  It
is to establish a gateway under administrative control, and allow
internet access only from the gateway machine(s).

Otherwise you (I mean here "you, the generic sysadmin") are going to
have the unsustainable problem of being *responsible* for internet
traffic while you have no control over the security of *neither* of the
machines involved. This is a joke.  The time it buys you is not the time
to build the right solution; it just gives the illusion that the problem
has been solved, and this will mean that the right solution will be no
longer urgent.

Note that I do not advocate you having control over all the machines at
your site -- this would be a nightmare for your site and you (unless you
are one of the many mad and insecure sysadmins with world-domination
plans :->). What I am saying is that you should take responsibility only
for what you can reliably devote your attention to, which usually is
very little, and making your management accept the situation. If they
don't accept the situation and tell you not to cause problems, you are
risking your job and reputation (by all means put into writing your
comments, cover your ass, find another job, ...).

I wish people studied more closely the environment of project Athena (or
Andrew). Only a few core machines are well protected and secured, and
any other is just not trusted. Security, even at minimal levels, is
terribly difficult and expensive, and rarely needed...

Finally, my favourite quote (I don't know whom from): the greatest
security hazard is a false sense of security.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 15:03:27 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP modem autodialing and idle line detection
On 26 Nov 90 12:02:54 GMT, bushell@HAWK.NSTN.NS.CA (Tom Bushell) said:

bushell> We're about to offer dial in Internet access over SLIP for NSTN
bushell> (the Nova Scotia Technology Network).  Our plan is to let our
bushell> customers use public domain packages like NSCD Telnet with the
bushell> Clarkson SLIP packet driver to dial in to a central teminal
bushell> server, using Hayes compatable modems with their PCs.

I will not comment on the auto-dial problem, which is fairly obvious,
but I will sternly warn you that using SLIP for such an application is
largely suboptimal. By all means switch to PPP. SLIP is a patch up job
for connecting _two_ machines with a temporary link. If you want to do
the proper thing, that is a dial up IP network, PPP is the answer. It
provides the framework to solve many difficult problems that any SLIP
setup just ignores.

There are already PPP implementations for the most popular
architectures, and I seem to remember that ther eis even a NOS version
with PPP compiled in.

PPP support is not as diffuse as SLIP support, but since you are just
starting, by all means do not lock yourself into a dead end.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Dec 90 00:27:09 PST
From:      Greg Satz <satz@cisco.com>
To:        mussar@bnr.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: X25 over IP
Our X.25 over TCP carries the X.25 packet intact so the M/D/Q bits are
conveyed from source to destination.

Greg
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Dec 90 21:34:29 GMT
From:      ndsuvm1!mtus5!pecampbe@cunyvm.cuny.edu
To:        tcp-ip@nic.ddn.mil
Subject:   SLFP, SLIP, and changing addresses
I have been running my own machine on the Merit network via dial-up SLFP.
It will connect with an address of 35.198.81.12, 35.198.81.13, or
35.198.81.14. At the current time, we are not assigned a name; however, we
are supposed to have all 3 lines labelled via.mtu1.merit.edu (from what
the local name servers seem to reveal). Actually, the names are not
broadcast, which is even better since the machines there change all the
time.
     Under SLFP, there is a provision to get your ip address. It also
handles checksums and handshaking so that IP packets are pretty clean.
SLIP has no provisions. SLIP simply sends a single byte indicating that
an IP packet is coming up and then blasts the packet raw, trusting to the
various CRC's in UDP, TCP, and other protocols to resend or reject the
bad packets (which works well).
     We are also implementing first a Usenet gateway (and hopefully
eventually a mail gateway) between Internet and the Citadel bbs network
from another machine.
     The only problems we have had so far are:
     In this area with only 3 dial-up lines that are also used for more
'normal' access to the Merit network, getting a line can often be a
problem. The gateway program runs through an 8-line site (no problems).
     Without an 'official' name, a few ftp sites are being rather rude
and rejecting our connect attempts.
     Since we are not continuously online, we can't receive mail from
this sort of gateway.

     By the way, we would be eternally grateful if any of you who are
running POPmail sites would allow us to sign-up for your services. We
have already tried doing this with the University of Minnesota. After
several telephone calls, the administrator there insisted that it took
almost none of the resources to handle pop mail (it doesn't) and that
anyone could get it. All they wanted was $20/year. They sent my check
back with a letter explaining that this offer was not available to
anyone other than students at U of Minn. (even though I asked about
that specifically on the phone).
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 02:09:29 GMT
From:      snow.Berkeley.EDU!hzhang@ucbvax.Berkeley.EDU  (Hui Zhang)
To:        tcp-ip@nic.ddn.mil
Subject:   Hotel of IEIF in Boulder
I would like to know the hotel of this coming week's IETF meeting in Boulder.

Please respond to hzhang@tenet.Berkeley.EDU.

Thanks a lot.

Hui
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 10:07:00 CST
From:      durham@mdc.com
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   centrally administered user authorization
What's available to provide a centrally administered user authorization
database? The goal is to allow a user to logon to any host in the network.
Some bells such password expiration and accounting records would be nice.
Thanks in advance.

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Mon, 03 Dec 90 10:20:16 CST
From:      MAINT@ASNTSU.asn.net
To:        tcp-ip@nic.ddn.mil
Thanks for the response to my request about SLIP, it was a bit overwhelming.
I now have all the information I need, maybe more than I want. Thanks again.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Mon, 3 Dec 90 10:35:24 EST
From:      Christopher Maeda <cmaeda@A.GP.CS.CMU.EDU>
To:        root%shiva@shakti.ernet.in
Cc:        petrino@kuhub.cc.ukans.edu, tcp-ip@nic.ddn.mil
Subject:   Craig Shergold
Shame on you for polluting the net with this stuff.

     Ask for Cards, and Ye Shall Receive and Receive and Receive
			   by Douglas Burns

       WEST PALM BEACH, Fla. -- A 7-year-old English boy with cancer is
finding that once a story hits the modern-day grapevine of fax
machines and computer bulletin boards, it is impossible to stop.
       Critically ill with a rare brain tumor, Craig Shergold told his
parents and nurses at a British hospital in September of his wish
to be in the Guinness Book of World Records for owning the world's
largest collection of post cards. The same wish was fulfilled only
a year earlier for another English boy with cancer.
       Once the news was out, it flowed through every conceivable
medium to even the most unimaginable places on the globe.
       Budget Rent A Car in Miami got news about Craig from a Budget
office in Gibraltar and sent one of their employees out to alert
South Florida businesses.
       ``We also passed it around to all our offices in the nation,''
said Maria Borchers, director of travel marketing.
       Children's Wish International, a non-profit organization based
in Atlanta, is also working to get cards for Craig. One of its
appeals made its way to a computer bulletin board run by Bechtel, a
Maryland-based company with an office in Palm Beach Gardens.
       ``We are getting 10,000 to 15,000 cards for Craig per day,''
said Arthur Stein, director of Children's Wish International.
       But Craig doesn't want any more cards.
       In November, he received a certificate from Guinness after his
mountain-sized collection of 1.5 million cards broke the record set
in 1988 by Mario Morby, a 13-year-old cancer victim.
       Since then, Craig's dream has become a logistical nightmare for
his parents, phone operators and the Royal Marsden Hospital in
Surrey, England.
       Monday, the unofficial count for Craig's collection reached 4
million, said Mark Young, a Guinness Publishing Ltd. spokesmen. The
hospital has set up a separate answering service to implore callers
to refrain from sending more postcards.
       Despite pleas of mercy and reports in the media, hundreds of
post cards continue to pour into the hospital every day.
       ``Thank you for being so kind,'' said Maria Dest, a nurse at
Royal Marsden. ``But he really does not need any more post cards.''
       Dest said that whenever a corporation gets wind of Craig's
plight, the bundles of mail increase.
       ``As soon as it starts to slow down, it goes around again,'' she
said. Dest would not discuss the specifics of his condition. ``His
condition is deteriorating, but he is still able to talk and
function,'' she said.
       Young, with Guinness, said he gets several calls every day from
people who question if Craig Shergold even exists.
       ``This is definitely legitimate and Craig will be in the 1990
Guinness Book,'' said Young.
       But because of the problems the two appeals have caused, Young
said Guinness plans to discontinue the category.
       The public outpouring for Mario and now Craig surprised
virtually everyone involved, he said.
       ``These two boys really captured the public imagination,'' Young
said.
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 08:27:09 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: X25 over IP

Our X.25 over TCP carries the X.25 packet intact so the M/D/Q bits are
conveyed from source to destination.

Greg

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 15:33:52 GMT
From:      usc!cs.utexas.edu!solo!vaxb.acs.unt.edu!billy@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   New release of Internet library guide
Hi,

The latest version of "UNT's Accessing On-line Bibliographic Databases" handout
is now complete.  It nows contains about 120 libraries, appendices on types of
library software, and an appendix on TELNET/TN3270 escape keys.

I received well over a hundred letters based on my request for information.   I
may have lost some library information in the shuffle (sorry if I did).  Also,
I did not have time to respond to all of the mail.  If you had an important
request that I didn't reply to, send me another message (note: a couple of
people had invalid return addresses).

Included at the end of this letter is the answer to some questions that have
popped up on numerous occasions.  Further discussion should take place on
either the PACS-L mailing list or the COMP.MISC newsgroup.

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX/Unix Systems Manager      THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================

Some commonly asked questions:


How do I acquire the files?

The files are available on vaxb.acs.unt.edu via anonymous FTP.  The files are:

LIBRARIES.TXT - ASCII version
LIBRARIES.PS  - Postscript version
LIBRARIES.WP5 - WordPrefect 5.1 source (transfer in binary mode)
LIBRARIES.ADR - Numeric IP addresses of Internet libraries
LIBRARIES.CONTACTS - Contacts for some of the Internet libraries
NETWORKS.HLP - VMS help file source for a wide area networks help topic,
               which includes a section on library systems.

BITNET only users should use BITFTP to acquire the files.  As an absolute last
resort, the files may be requested via email (note: some networks such as UUCP
may file size limits that may prohibit the transfer of these documents through
electronic mail).




Why is there UNT's guide and the Art St. George/Ron Larsen guide?

Art St. George and I have some differences of opinion in the area of formatting
and what should be included in an Internet library guide.  Though I could just
use the St. George guide, I need to format the information into a easy to use
for novice computer users for my on-campus users.  It is not much harder to
provide it to the Internet at large and also gather my own information.  Joe
St. Sauver, the author of the VAXbook, on PACS-L put forth a rather good 
argument for the case that two guides are actually a benefical thing.



Where do I send updates?

Send all new information, updates, and deletions to BILLY@VAXB.ACS.UNT.EDU 
(more details on first page of guide). If you are using a TELNET/TN3270 package
not listed in the appendix, please send me the information on it.  Also, if you
have instructions for a library software package not yet described, please
send them to me and give me at least one example where it is in use.




I had problems with the lines being longer than 80 characters (TEXT version).  
Any ideas?

In past versions that was true.  I *believe* the problem is fixed in this
version.  If not, then send mail to billy@vaxb.acs.unt.edu.



The document appears to be all on one line for every paragraph (TEXT version).
Any ideas?

I'm clueless on this one.  I have tested the document on MS-DOS and VMS. 
Neither system gives me the problem.  The TEXT version is generated by Text Out
in WordPrefect 5.1.  If anybody out there runs into this problem, let me know.
If you know a solution, then send me mail at billy@vaxb.acs.unt.edu.
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 15:35:24 GMT
From:      cmaeda@A.GP.CS.CMU.EDU (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   Craig Shergold

Shame on you for polluting the net with this stuff.

     Ask for Cards, and Ye Shall Receive and Receive and Receive
			   by Douglas Burns

       WEST PALM BEACH, Fla. -- A 7-year-old English boy with cancer is
finding that once a story hits the modern-day grapevine of fax
machines and computer bulletin boards, it is impossible to stop.
       Critically ill with a rare brain tumor, Craig Shergold told his
parents and nurses at a British hospital in September of his wish
to be in the Guinness Book of World Records for owning the world's
largest collection of post cards. The same wish was fulfilled only
a year earlier for another English boy with cancer.
       Once the news was out, it flowed through every conceivable
medium to even the most unimaginable places on the globe.
       Budget Rent A Car in Miami got news about Craig from a Budget
office in Gibraltar and sent one of their employees out to alert
South Florida businesses.
       ``We also passed it around to all our offices in the nation,''
said Maria Borchers, director of travel marketing.
       Children's Wish International, a non-profit organization based
in Atlanta, is also working to get cards for Craig. One of its
appeals made its way to a computer bulletin board run by Bechtel, a
Maryland-based company with an office in Palm Beach Gardens.
       ``We are getting 10,000 to 15,000 cards for Craig per day,''
said Arthur Stein, director of Children's Wish International.
       But Craig doesn't want any more cards.
       In November, he received a certificate from Guinness after his
mountain-sized collection of 1.5 million cards broke the record set
in 1988 by Mario Morby, a 13-year-old cancer victim.
       Since then, Craig's dream has become a logistical nightmare for
his parents, phone operators and the Royal Marsden Hospital in
Surrey, England.
       Monday, the unofficial count for Craig's collection reached 4
million, said Mark Young, a Guinness Publishing Ltd. spokesmen. The
hospital has set up a separate answering service to implore callers
to refrain from sending more postcards.
       Despite pleas of mercy and reports in the media, hundreds of
post cards continue to pour into the hospital every day.
       ``Thank you for being so kind,'' said Maria Dest, a nurse at
Royal Marsden. ``But he really does not need any more post cards.''
       Dest said that whenever a corporation gets wind of Craig's
plight, the bundles of mail increase.
       ``As soon as it starts to slow down, it goes around again,'' she
said. Dest would not discuss the specifics of his condition. ``His
condition is deteriorating, but he is still able to talk and
function,'' she said.
       Young, with Guinness, said he gets several calls every day from
people who question if Craig Shergold even exists.
       ``This is definitely legitimate and Craig will be in the 1990
Guinness Book,'' said Young.
       But because of the problems the two appeals have caused, Young
said Guinness plans to discontinue the category.
       The public outpouring for Mario and now Craig surprised
virtually everyone involved, he said.
       ``These two boys really captured the public imagination,'' Young
said.

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 16:07:00 GMT
From:      durham@MDC.COM
To:        comp.protocols.tcp-ip
Subject:   centrally administered user authorization

What's available to provide a centrally administered user authorization
database? The goal is to allow a user to logon to any host in the network.
Some bells such password expiration and accounting records would be nice.
Thanks in advance.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 16:20:16 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

Thanks for the response to my request about SLIP, it was a bit overwhelming.
I now have all the information I need, maybe more than I want. Thanks again.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 17:00:31 GMT
From:      ncsuvm!ucf1vm!maukonen@ncsuvx.ncsu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
I remeber hearing that there ar dedicated "boxes" for SLIP routing.
Can somebody please send me some information on this. I need a place to
start looking.

Much Thanks in advance.

Chris Maukonen
maukonen@uc
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 01:13:42 PST (Tue)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        jbvb@ftp.com
Cc:        bob@mstar.morningstar.com, tcp-ip@nic.ddn.mil
Subject:   SLIP
   Date: Wed, 28 Nov 90 12:34:37 -0500
   From: jbvb@ftp.com  (James B. Van Bokkelen)
   Reply-To: jbvb@ftp.com
   Sender: jbvb@ftp.com
   Repository: babyoil.ftp.com
   Originating-Client: plug.ftp.com

	  Does anybody have a version of SLIP or PPP with SLFP (Serial Line
	  Framing Protocol) support in it?  Merit ... does SLFP.

       Is SLFP HDLC?  If not, is SLFP documented in a readily-accessible
       place?

   SLFP is another way of encapsulating IP on serial lines that is neither SLIP
   nor PPP.  It has never been written up in an RFC, and if anything exists
   besides the source code, it is probably an internal MIT LCS document (John?
   Jerry?).

Uh, I think it was described in an appendix of the PC/IP programmer's
manual ("MIT IBM PC TCP/IP PC/IP Programmer's Manual" or something
like that with too many acronyms in it). I don't have a copy anymore.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 17:48:24 GMT
From:      kdb@macaw.intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Re: Product Informatation

In article <1990Nov30.130305.20835@lavaca.uh.edu>, dinah@karazm.math.uh.edu
(Dinah McNutt) writes:
> Intercom's Netnews and TN3270 products

That's InterCon.  Not Intercom, sorry, but everyone I talk to over the phone
makes the same mistake. :-)  Sigh.

Anyway, you might want to look at the two NFS clients that just came out
for the Mac.  Wollongong has one and InterCon has one.  On the PC side of
things InterCon has a PC product that runs over AppleTalk Cards on the PC.
You also might want to consider getting information from FTP Software 
(info@ftp.com I think) about their PC products, they have NFS for the PC as 
well.  Sun also, of course, has a PC product called PC-NFS, has a limited 
telnet and NFS, but no mail, etc..

There is a lot more to your question that what I answered, but I am sure
that others will be more than helpful in filling out what I missed.  Hope
this helps.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 17:53:04 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Berkeley Socket Libraries for Macintosh?
In article <1990Nov5.215358.27116@terminator.cc.umich.edu>,
baw@terminator.cc.umich.edu (Brian Wolfe) writes:
> Does anyone know if there is a Berkeley sockets API
> (for TCP-IP) available for the Macintosh? The people I've spoken 
> to at Wollengong have said that they will have such a product    
> in about 6 months.
> 

There is a PD version available from University of Toronto, I think.
There is also a socket package from Novell that (the last I heard) worked
with both their TCP stack and MacTCP.

Hope that helps.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 18:24:21 GMT
From:      mcsun!cernvax!chx400!ugun2b!cui!bursens@uunet.uu.net  (BURSENS Reginald)
To:        tcp-ip@nic.ddn.mil
Subject:   3270 for CommToolbox

Asc3270 Annoucement

###############-- To whom it may concern: --################

ASC presents another new product, which was announced at the San Jose
Worldwide Developpers Conference: Asc3270, scheduled for distribution
as of December 15 1990.

It is currently undergoing Beta-Testing, and will be available as of
December 1, thru AppleLink in the Third Party Connection, Software
Demos, Network and Communication folder, from where you can download
and test it (do not forget to download TCPack as well, from the same
section).

Asc3270 is a terminal tool developed by Advanced Software Concepts,
designed to offer full 3270 terminal emulation using the standard
access interfaces of Apple's Communication Toolbox.

Asc3270 can be used by any application designed to take advantage of
the Communication Toolbox (such as Sample or MacTerminal 3.0),
provided the application respects the programming standards published
by Apple for this architecture.

Asc3270 proposes:

#3278 models 1,2,3,4,5
  -Terminal settings:
  -Emulate 3278 model
  -On line/Off line work
  -Cursor type (block, underline, blink)
  -Font size (9/12)
  -3270 Extended Data Stream (on/off)
  -Status bar control (on/off)

#Support of TCP/IP connections to AS400 series

#Extensive keyboard functions:
   -Keyboard settings:
   -Insert mode after Attention Key (on/off)
   -Discard Trailing blanks  (on/off)
   -Key-click sound (on/off)
   -User-definable Keyboard:
   -Reconfigurable Macintosh keyboard
   -Multi-keyboard configuration
   -Click-and-drag mapping interface
   -Full international character set support:
   -Accentuated, diacritical and other characters supported
 
#Full color support:
   -3270 color mapping with Apple's Color Picker Dialog box
   -3270 screen attributes mapping into Macintosh text attributes

#Two levels of On-line Help:
   -General Help: verbose description of the configuration functions
   -Local Help: point-click-and-display of short help messages 
    at any time

Fully integrated with Esmeralda, our 100% MacWorkStation-compatible
language that supports the CTB and adds many interesting features to
MWS.

Fully integrated with TB-User, our communications application that
supports terminal emulations (all those available under CTBI),
scripting language, CCL, revamping, collaborative processing, Comm
ToolBox and more.

TB-User provides a powerful tool to connect to IBM, Vax and/or Unix
mainframes in a multi-session,multi-protocole environment.

We are waiting for the official IBM RFC's on 5250 to be published, in
order to come out with a 5250 Terminal Emulation Tool. Upgrade policy
from ASC3270 to ASC5250 available on request.

Pricing: Individual package, at a price of French F 480.- Includes
User Guide and software.

Fell free to contact us for more information.


TO:    Advanced Software Concepts 
Attn:  Rodrigo CABALLERO 

9551, route de Saint Laurent du Var 
F-06610 LA GAUDE 
France

Phone : (33) 93-24-76-00 
Fax   : (33) 93-24-76-06 
E-Mail: adv.soft@applelink.apple.com
Applelink ADV.SOFT
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 19:51:30 GMT
From:      geoff@bodleian.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Re: Product Informatation

Quoth kdb@macaw.intercon.com (Kurt Baumann) (in <275A8FE8.3C5F@intercon.com>):
#Sun also, of course, has a PC product called PC-NFS, has a limited 
#telnet and NFS, but no mail, etc..

Hmmm... Kurt, check your facts. Just because we unbundled email and
backup doesn't mean we don't offer these capabilities. Shall I send
you some data sheets? :-)

Geoff
-- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)   --
   *** "Now is no time to speculate or hypothecate, but rather a time ***
   *** for action, or at least not a time to rule it out, though not  ***
   *** necessarily a time to rule it in, either." - George Bush       ***

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 20:17:14 GMT
From:      cs.utexas.edu!asuvax!anasaz!qip!chad@tut.cis.ohio-state.edu  (Chad R. Larson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP modem autodialing and idle line detection
In article <1852@hawk.nstn.ns.ca> bushell@hawk.nstn.ns.ca writes:
+---------------
| We have three main requirements:
| 
| 1) Must be able to automatically establish a SLIP connection over a modem.
| 
| 2) Must be able to automatically accept an IP number assigned by the
| terminal server being dialed into, and run public domain applications like
| KA9Q and NCSD Telnet with this IP number.
| 
| 3) To try to minimize connect charges for the users, we want to monitor the
| line for user activity, and drop it after a specified period if there
| is none, even if he/she is still in the application.  We want to
| reconnect when activity is detected.
+---------------
A product called the "NetBlazer" from Telebit meets all your needs, I
believe.  It is a combination Bridge/Router/Terminal server built on a
PC chassis.  It supports ethernet cards, wide area net cards, and Digiboard
multi-port async cards in combination.   It uses Phil Karn's Network
Operating System as its heart.

The serial cards are used to provide both terminal service and dial-up
IP connections.  The dial-up connections may be either dial out or in,
and either SLIP or PPP.  The modems I saw it demo'd with were Telebit
Trailblazers (natch) but I think any Hayes compatable will do.

You can set a time-out value on a link, and the dial connection will be
dropped after the time out.  The TCP connection need not be dropped, and
when the next packet arrives the dial connection is re-established.

I saw it demo'd at InterOp '90 in San Jose.  I have no connection with
Telebit.
-- 
Chad R. Larson          ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP
Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020
(602) 870-3330            "I read the news today, oh boy!"  -- John Lennon
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 21:24:49 GMT
From:      chad@anasaz.uucp (Chad R. Larson)
To:        comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   logical networks (TCP routing)

I would appreciate advice on how to run two separate logical networks
over a single physical network and have them interoperate.

I am currently serving as the SysAdmin for two companies.  Each of them
has an officially assigned Class B network address.  Both of them are
running IP over Ethernet (802.3) physical facilities.  The networks are
mostly 10baseT implemented with AT&T StarLan10 and David Systems
hardware.  The computers involved are 5 Pyramids (4 MIServers and 1
9845), an NCR Tower 32/600 and about a dozen AT&T 6386/33 WGS machines.
The Pyramids are running OSx5.0d and the Tower is running SysVr3.2 with
WIN/TCP as are the WGSs.

I need to be able to connect the two networks together for a short while
during a joint software development program.  I do not currently have
access to a router.  None of the machines on either network has more
than one Ethernet interface, so I cannot build a classical gateway.  I
am planning on using a MAC-level bridge on each end of a T1 to link the
networks at the physical level.  I already have the bridges (Halley
ConnectLan 100s).

What I need to know is how to build the functional equivalent of a
gateway on one of the machines to link the two IP networks.  It would
seem that by hand constructing the routing tables that this should be
possible, but I confess to being a novice in this area.

Can this be done?  Can you explain it to me?  Does the route daemon help
or hinder in this?  If I cannot construct a software solution, I will
probably try to get another Ethernet interface installed in one of the
386s and build a gateway.  Either that or open up the net mask so all
machines think they are on the same net.  The first takes additional
hardware (and the time to acquire it), the second could have
unpredictable side effects (and would have to be undone when the link is
broken).

Please e-mail to me at the below address.  I'll post the most cogent
explanation to the net.  Thanks!
	-crl
--
Chad R. Larson       ..{hrc,mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP
Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020
(602) 870-3330            "I read the news today, oh boy!"  -- John Lennon

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 22:55:48 GMT
From:      usc!cs.utexas.edu!solo!vaxb.acs.unt.edu!snms4@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: cisco routers
In article <45@vlink01.UUCP>, root@vlink01.UUCP (Superuser) writes:
> Could someone tell me the phone number/address for cisco for their routers?
> 
> Thanks in advance.
> 
> 
> -- 
> V-Link                                  | System Administration V-Link
> 1828 Darrow Drive                       |---------------------------------------
> Powell OH   43065-9261                  | Local : root
> 614-365-3056                            | Remote: root@vlink01.UUCP
>->* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * <-<

         I'll do one better:

         customer-support@cisco.com

         (I'm pretty sure of this.  I'm at home away from my Cisco
         docs.)
         -KwM-
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Dec 90 23:48:25 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Product Informatation
In article <3503@jaytee.East.Sun.COM>, geoff@bodleian.East.Sun.COM (Geoff
Arnold @ Sun BOS - R.H. coast near the top) writes:
> Quoth kdb@macaw.intercon.com (Kurt Baumann) (in <275A8FE8.3C5F@intercon.com>):
> #Sun also, of course, has a PC product called PC-NFS, has a limited 
> #telnet and NFS, but no mail, etc..
> 
> Hmmm... Kurt, check your facts. Just because we unbundled email and
> backup doesn't mean we don't offer these capabilities. Shall I send
> you some data sheets? :-)
> 
> Geoff

Oopps, I stand corrected.  I forgot about reading about the release of mail
by SUN for the PC as well.  Sorry about that.

And yes, please send me a data sheet.  (If you feel real generous send me
a copy of the software so we can test it against ours :-))

Anyway, thanks for clearing that up.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 01:29:02 GMT
From:      mcsun!ukc!stl!stc!miclon!ibmpcug!haeb@uunet.uu.net  (Harry Broomhall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SPIDER's address
In article <9011301343.AA15278@uc.msc.edu> zentelis%sdav01.decnet@WIN1.IMS.ABB.COM ("SDAV01::ZENTELIS") writes:
> Hi
> 
> I'm looking for SPIDER:s address in Great Britain or SPIDERS:s reseller in
> Sweden. 
> My mailing address is : ZENTELIS%SDAV01.DECnet@WIN1.IMS.ABB.COM
> Nicolas Zentelis

    Because of a broken mailer at this end I am having to post this
reply rather than mail it.  :-(

   Spider Systems Ltd,
     Spider Park,
       Stanwell St,
         EDINBURGH  EH6 5NG

   Telephone +44 31 554 9424     
  
   They are also reachable by mail as spider.co.uk

    Regards,
       Harry.

-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 01:35:11 GMT
From:      mcsun!ukc!stl!stc!miclon!ibmpcug!haeb@uunet.uu.net  (Harry Broomhall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none)
In article <9012021338.AA04769@uunet.UU.NET> root%shiva@SHAKTI.ERNET.IN writes:
> 
> 
> We would appreciate your responding to the request of Craig Shergold who
> is a seven year old boy with an inoperable tumor on his brain.
> 
> 
> Please send your card to:
> 
>      Craig Shergold
>      % Children's Make-A-Wish Foundation
>      32 Parimeter Center East
>      Atlanta, Georgia 30346
> 
> 
> Letters similar to this have been sent out by traditional mail to large
> organizations all across the U.S. on Craigs behalf. Instead of passing
> it on by land-mail, I thought the net would be a great way of getting 
> the word out to as many people as possible in as short a time as possible.
> 
> Please pitch-in & send Craig a get well card, and by all means feel free
> to circulate this letter to local businesses/organizations, or other
> BBS's you may belong to. All your help and effort will certainly be 
> appreciated! Thank you.
> 


    ARGH!  Not again!   This is VERY old!   It first apeared about 
a year and a half ago.   Craig was in a UK hospital, and indeed was
very ill.   Following a vast number of cards received a plea went
out to STOP! :-)

    Please don't start up again!   This keeps on reappearing on the
nets.

    Regards,
         Harry.











-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 90 13:39:18 -0700
From:      eam@phx.mcd.mot.com (Ed Morhman)
To:        tcp-ip@nic.ddn.mil
Subject:   Window on Sparc station as console to Motorola system
We routinely do what you describe.

We hook an rs232 cable between the console port of the Motorola system
to a serial port of another system (in your case - a SUN).

Then, from an xterm, run cu to the Sun serial port. By doing this, your
xterm window is the console for the Motorola system.

Ed
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 02:46:02 GMT
From:      munnari.oz.au!csc.anu.oz.au!axt654@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   3C503 shared memory conflict
Hi,
	I'm running Sun's version of PC-NFS on a 386 PC with a 3C503 card but
also want to run NCSA Telnet because I need some of it's features. The problem
is that the NCSA driver (and the packet driver) need a shared memoryt address
available (eg dc00 or d800) but the NFS software requires this to be disabled
(PC-NFS version 3.0.1). Is there some way around this? Is there a packet driver
that runs with shared mem disabled? 

Thanks,
Andrew Tridgell
tridge@aerodec.anu.oz.au
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 90 11:31:46 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        munnari.oz.au!csc.anu.oz.au!axt654@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  3C503 shared memory conflict
The packet driver does not support running two stacks of the same protocol
(e.g. PC-NFS and NCSA, which are both TCP/IP). Both stacks will have to 
receive broadcast packets, such as ARPs, and one will loose. The packet 
driver is useful for running two different protocols stacks (e.g. TCP/IP
and IPX), where each packet is clearly destined for one or the other.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 03:54:30 GMT
From:      munnari.oz.au!darwin.ntu.edu.au!jennerr@uunet.uu.net  (Bob Jenner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help finding telenet software to perform ftp as remote
In article <131134@tiger.oxy.edu> schorsch@oxy.edu (Brent William 
Schorsch) writes:
> I am currently using NCSA Telenet software (from Univ. of Illinois at 
urbana
> with a MacSE appletalk connected to a fastpath -> ethernet to Usenet
> I currently have to connect to a local Sun Workstation and ftp from 
there,
> then, ftp to my mac and send from the Sun to me, I would like to remove
> the middle step... ( I read a review in Macworld Jan 91, p. 207 on
> TCP/Connect II 1.0, has anyone used this?)
> How about a pd program like NSCA Telnet, 
I am currently using BYU Telnet which allows direct FTP. However you also 
need Mac TCP which is available from APDA. Incedentally, there is also a 
stack called Hyper FTP which is very nice. I can't recall which site it is 
on but if you want more info, send me an e-mail.
Regards

Bob Jenner, Northern Territory University
Computing Dep't.
PO Box 40146, Casuarina NT Australia 0811
Tel 089-466397
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 03:58:20 GMT
From:      magoo@pvi.UUCP (Tim Lentz x255)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Re: PCNFS mail (was Re: Product Information)

In article <275A8FE8.3C5F@intercon.com> kdb@macaw.intercon.com (Kurt Baumann) writes:
>In article <1990Nov30.130305.20835@lavaca.uh.edu>, dinah@karazm.math.uh.edu
>(Dinah McNutt) writes:
> ...  Sun also, of course, has a PC product called PC-NFS, has a limited 
>telnet and NFS, but no mail, etc..
> ...

Just a quick comment and correction. Sun's PCNFS product seems very stable and easy to manage (pcnfsd include with SunOS, great config scripts).. 
Telnet and ftp work very well. Even has some r stuff (rsh, etc). It also has 
an add on mail/backup ultility called Lifeline. I haven't worked much with the 
backup but the mailer may be configured to use SMTP or POP (included). 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
boulder!pvi!magoo				Just a fool waiting on the wrong
Ass. System Mgr.				block. Putting a little ZEP in 
Precision Visuals, Inc. Boulder, Co		your step.

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Tue, 04 Dec 90 10:02:01 EST
From:      todd@Cambridge.IBM.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Cancel Subscription
Please cancel my subscription to this discussion.
Thank You.

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 05:06:52 GMT
From:      groucho!davis@handies.ucar.edu  (Glenn P. Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Sockets, TLI, or what
We are writing a system which will use process to process communication
with the processes perhaps residing on different hosts.
The emphasis is on portability.

My first cut at this uses BSD 4.3 style TCP sockets.
My boss is wondering why I wasn't forward looking enough to use
didn't use "Transport Level Interface" from System V.
(He has been reading the Sun "Network Programming Guide" which
contains a warning that "Socket based IPC is no longer the preferred
framework for transport level programming....").

My sense is that more systems currently support the BSD socket interface
than support TLI or STREAMS.  Is this the case? My sense is that
this will remain the case for some time, at least on the order of 3 years.
Or, at worst case, that the BSD socket interface will still be around for
awhile.  What about that? 

Is TLI or Streams in 4.4 BSD?
How does 4.4 BSD handle alternate, say OSI, transport?

Thank You for your responses.

Glenn P. Davis
UCAR / Unidata
PO Box 3000                   3300 Mitchell Lane, Suite 170
Boulder, CO 80307-3000        Boulder, CO  80301

(303) 497 8643
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 1990 10:28:12 EST
From:      rizzo@hub.eng.wayne.edu (Frank F. Rizzo)
To:        tcp-ip@nic.ddn.mil
Subject:   3270 emulator for Macintosh
I heard from a friend that about three months ago, there
was an announcement about a freeware Macintosh application which
supported 3270 emulation over serial and TCP/IP connections.

Does anybody know anything about such an application?

-- 
-------------------------------------------------------------------------------
Frank F. Rizzo                                   Rm. 2351.11
Network Software Manager, Postmaster             Engineering Computer Center
Phone: (313) 577-3824                            Wayne State University
FAX #: (313) 577-3881                            5050 Anthony Wayne Drive
Internet: rizzo@hub.eng.wayne.edu                Detroit, Michigan  48202
-------------------------------------------------------------------------------
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 05:49:09 GMT
From:      cme!libes@uunet.uu.net  (Don Libes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rlogin and run a command etc
In article <1141@cnw01.storesys.coles.oz.au> nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes:
>[Neither rsh nor rlogin does what I want - to run a command, possibly
>with cursor addressing, as soon as it has logged in, all non-interactively]

Get 'expect'.  It follows a script to talk to interactive programs
like rlogin, telnet, tip, etc.  The scripting language is quite general.

We use it like crazy here to automate a lot of stupid programs with
interactive-only interfaces.  We've even have scripts that control our
VMS computers from UNIX.  For example, I can set my password on our
UNIX boxes and have it automatically change passwords on our VMS
machines.  It's good for regression testing interactive software, too,
not to mention controlling our network boxes.

expect can be ftp'd as pub/expect.shar.Z from durer.cme.nist.gov.
Request email delivery by mailing to "library@cme.nist.gov".  The
contents of the message should be (no subject line) "send
pub/expect.shar.Z".

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 90 13:37 CST
From:      "Igor Martinez (GymKata)" <IGOR@UDLAPVMS.PUE.UDLAP.MX>
To:        tcp-ip@nic.ddn.mil
Subject:   Question about mapping between Ethernet Address & Internet Address
Date sent:  4-DEC-1990 13:29:33 

Hi Friends , I have a question .

I'm using NCSA telnet (PC Version), but I want that NCSA do something
like a one-to-one mapping between Ethernet address and Internet address

Somebody have an idea in order to do this !!



	Thanks in advance !!


----------------------------------------------------------------------------
Igor Martinez Oropeza                                       .      
Igor@UdlaPVMS ( Bitnet )                                   ..     ......       
Igor@UdlaPVMS.Pue.Udlap.Mx ( Internet )	                  ...    .......
			                                 ....   ........
			                                .....       ...
University of the Americas                              .....        .
Department of Networks & Telecomm.                     ......      
Sta. Catarina Martir	                                .................
Cholula, Puebla, Mexico	                                 ...............
(22) 47-4321		                                  .............
			                                   ...........
----------------------------------------------------------------------------
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 90 16:58:11 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        fks@ftp.com, munnari.oz.au!csc.anu.oz.au!axt654@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  3C503 shared memory conflict
Actually, that was a bad explanation! One of the stacks will loose 
long before a broadcast packet. The packet driver decides where to 
send a packet based on what protocol it is. Only one IP stack (I 
believe the one loaded last) will get the packets, and it will get
both the packets intended for it, and the ones intended for the other
stack, which, if you're lucky, it will ignore.


Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Tue, 4 Dec 90 15:58:08 CST
From:      "Capt E. Lee Hutchins" <hutch@ssmct62.ssc.af.mil>
To:        tcp-ip@nic.ddn.mil
Subject:   SCO E-Mail & MMDF; Followup to previous question
Greetings Once again!

	Thanx to all that responded to my previous query.  We have not solved
the problems as of yet but are closer.

	First of all COURIER mail was not at fault.  Although it does help to
have proper addressing anywhere you go- problem #1.

	Secondly, the MMDF configuration on my SCO Unix machine seems to be
working OK, however, we have narrowed the problem on mail receipt to a very
perculiar symptom.

	If the machine is on my local network (140.185.x.x) and is not in
my /etc/hosts table my SCO Unix machine will not allow a mail connection 
(i.e. telnet machine.domain 25).  However those local hosts which were left in
my host table (prior to my use of a nameserver) could send mail to me.  Finally
everyone outside the 140.185.x.x network can send mail to me without being in
the /etc/hosts table.

	What is going on????  I thought MMDF was completely seperate from
the "normal" network services provided by UNIX.

	I also got several suggestions on MMDF docs.  A short configuration
guide provided to me help a bit.  But I was told of an "ftp" source for 
troff docs.  They have been printed out and I am checking for their applicabily
to SCO MMDF.  More later.

	If those who might have some additional ideas on these questions could
respond to me directly, I'll post a final summary later.

	thanx
		Lee Hutchins
		hutch@ssmct62.ssc.af.mil
		(205) 279-4555
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 11:39:39 GMT
From:      munnari.oz.au!mel.dit.csiro.au!smart@uunet.uu.net  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X25 over IP
In article <9012031018.AA18270@ucbvax.Berkeley.EDU> satz@CISCO.COM (Greg Satz) writes:
>Our X.25 over TCP carries the X.25 packet intact so the M/D/Q bits are
>conveyed from source to destination.
>
We would also like to run X.25 over our IP network (don't ask). It would
be nice if someone would threaten to publish an RFC on a protocol for
doing this. This would flush out Cisco's intentions: do they intend to
standardize their protocol or do they intend to IBM their customers
(any noun can be a verb: see recent posting on computer jargon).

Bob Smart <smart@mel.dit.csiro.au>
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 13:33:40 GMT
From:      mcsun!hp4nl!afa!hvli!root@uunet.uu.net  (System Administrator)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 emulation for SCO tcp/ip
In article <28214@usc>, mcitron@phad.hsc.usc.edu (Mark Citron) writes:
> 
> Is there an IBM 3270 front end emulator for SCO tcp/ip for Unix?
> We want to do a 3270 emulation with telnet.
> 

We at the Zeeland Polytechnic are planning to buy the SCO-TCP/IP package
for our 386 system running SCO Xenix 386 rel 2.3.
This system will be serving as the central mailer/postoffice system for our
organisation, so the "server" or "host" specific applications must be
present (like inetd, ftpd, telnetd, smtpd etc.) so that it will be possible
to login to the 386 system over our local internet (ethernet), and use the
ftp and smtp protocols to the 386 system as a server.

So far, I haven't been able to find (in the product-sheets of SCO-TCP/IP)
wether or not the server applications are included and/or supported in
that package, and with our system.

Can anybody shine some light on this ?

Thanks in advance.
Eddy van Loo
-- 
root@hvli.UUCP			Eddy van Loo, System Administrator
...hp4nl!afa!hvli!root		Zeeland Polytechnic, Flushing NL.
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 15:52:44 GMT
From:      visix!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In article <9389@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes:
> We are writing a system which will use process to process communication
> with the processes perhaps residing on different hosts.
> The emphasis is on portability.
> 
> My first cut at this uses BSD 4.3 style TCP sockets.
> My boss is wondering why I wasn't forward looking enough to use
> didn't use "Transport Level Interface" from System V.

If you're really concerned about portability, you are going to have to do both.
My suggestion is to write a higher-level library that provides the functions
you need, and hides the underlying mechanism.  This way you don't end up with`
socket (or TLI) dependencies sprinkled through your code.  Which version you
start with depends mainly on what machine(s) you are using for your initial
development.

I would, however, suggest that you read up on TLI before you start writing much
code, just so you have enough background knowledge to avoid any major
differences in capability (not that I remember any off hand).

Amanda Walker
Visix Software Inc.
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 16:48:21 GMT
From:      usc!samsung!b-tech!zeeff@ucsd.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
>Uh, I think it was described in an appendix of the PC/IP programmer's
>manual ("MIT IBM PC TCP/IP PC/IP Programmer's Manual" or something
>like that with too many acronyms in it). I don't have a copy anymore.

You can get the file slfp.info via anon ftp from ais.org.  There is 
also a copy of the tunnel driver and a slfp "driver" I did for it.  

-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 16:59:31 GMT
From:      usc!samsung!umich!terminator!merit.edu!rsc@ucsd.edu  (Richard Conto)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
In article <9012040113.AA00194@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
>	  Does anybody have a version of SLIP or PPP with SLFP (Serial Line
>	  Framing Protocol) support in it?  Merit ... does SLFP.
>
>       Is SLFP HDLC?  If not, is SLFP documented in a readily-accessible
>       place?
>
>   SLFP is another way of encapsulating IP on serial lines that is neither SLIP
>   nor PPP.  It has never been written up in an RFC, and if anything exists
>   besides the source code, it is probably an internal MIT LCS document (John?
>   Jerry?).
>
>Uh, I think it was described in an appendix of the PC/IP programmer's
>manual ("MIT IBM PC TCP/IP PC/IP Programmer's Manual" or something
>like that with too many acronyms in it). I don't have a copy anymore.

There's an FTP'able version on UM.CC.UMICH.EDU (and UB.CC.UMICH.EDU) in
MNET:MIT.SLFP . Use ASCII (text) file transfers.  I couldn't find a copy
on any of the anonymous ftp servers that I'm aware that Merit runs.

--- Richard Conto
	rsc@merit.edu
	Richard_Conto@um.cc.umich.edu
	USERW014@UMICHUM (bitnet)
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 17:52:43 GMT
From:      igloo!ddsw1!corpane!brooks@gargoyle.uchicago.edu  (David E. Brooks Jr)
To:        tcp-ip@nic.ddn.mil
Subject:   NP600 driver for NCSA telnet?
I just recently obtained NCSA telnet with the Clarkson Unversity mods, and
noticed there isn't a driver for the Micom-Interlan NP600 card.  Before
I go and try and write a packet driver for it, does anyone know of one
that exists?  (We've got a handful of them I'd like to try and use if I
could)

Thanks,
-- Dave
-- 
David E. Brooks Jr                      UUCP :  ...{ddsw1,ukma}!corpane!brooks
Corpane Industries Incorporated            -or- brooks@corpane.UUCP
10100 Bluegrass Parkway                 Phone:  +1 502 491 4433 x122
Louisville, KY  40299                   Quote:  printf("%c", (char) 34)
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 18:03:25 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help finding telenet software to perform ftp as remote
In article <131134@tiger.oxy.edu>, schorsch@oxy.edu (Brent William Schorsch)
writes:
> How about a pd program like NSCA Telnet, (TCP/Connect is $495!!)

The $495 price is for the Extended version, which probably contains more
functionality than what you need.  Give us a call at 703.709.9890 X231 (sales)
or drop me a note with your address.  We do have other levels of the product
that may better (and less expensivily) meet your need.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 18:59:51 GMT
From:      agate!shelby!snorkelwacker.mit.edu!usc!cs.utexas.edu!helios!utarlg.utarl.edu!c145gmk@ucbvax.Berkeley.EDU  (GORDON KEEGAN)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet driver for Western Digital's WD8013EBT card

Has anyone written or seen a packet driver for this ethernet card?
I've already checked the clarkson and simtel ftp sites, to no avail.
Reply by e-mail and I'll summarize.  Thanks!

-----------------------------------------------------------------------------
|  Gordon Keegan                    ||   Bitnet  : c145gmk@utarlg           |
|  Systems Programmer               ||   THEnet  : UTARLG::C145GMK          |
|  Academic Computing Services      ||   Internet: c145gmk@utarlg.utarl.edu |
|  University of Texas, Arlington   ||   AT&TNet : 817-273-2208             |
-----------------------------------------------------------------------------
|  It's all in the reflexes.   Jack Burton, Big Trouble in Little China     |
-----------------------------------------------------------------------------
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 20:34:22 GMT
From:      olivea!tymix!cirrusl!sun600!dhesi@apple.com  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In <9389@ncar.ucar.edu> davis@groucho.ucar.edu (Glenn P. Davis) writes:

>(He has been reading the Sun "Network Programming Guide" which
>contains a warning that "Socket based IPC is no longer the preferred
>framework for transport level programming....").

This comes from the AT&T SVR4 manuals and represents a corporate "party
line" rather than any practising software engineer's opinion.
Considering that 99% of existing implementations of UNIX provide no
support for TLI, using it at this point would result is extermely
nonportable code.

SVR4 is still in its infancy.  Except for a few bugs, it supports the
socket interface.  Since no existing software uses AT&T's TLI, which is
very new and untested, your best bet is to (a) use the socket interface
but (b) make sure your code doesn't trigger the socket-related bugs in
SVR4, which are documented in the AT&T manuals.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 20:40:22 GMT
From:      fed!m1rts00@uunet.uu.net  (Robert T. Semon)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP on DOS workstations.
We are doing a cost/benefit analysis of various configurations which 
could connect DOS workstations running TCP/IP to UNIX hosts.

The DOS workstations (IBM PC/AT, PS/2) are networked on a token ring 
and the UNIX hosts (Sun/Sol.) on an Ethernet.

Are their any sites with experience connecting the two platforms?  What kind 
of spanning device (bridge, router) was used?  Was it a high performance 
specialized box (e.g., cisco, Wellfleet, etc.) or another PC running routing
software?

What TCP software was used on the DOS station?  Any experience with one of
the "X on DOS" applications?  Does it work with Windows 3.0?

We've been evaluating an RS/6000 to be both the router and a UNIX host, and
now wish to look at solutions using other devices.  I will summarize if 
there are others interested in this subject out there in netland.

Please send responses to me at:

		rsemon@fed.frb.gov  (or uunet!fed!rsemon)

Thanks for your help.

Robert T. Semon <rsemon@fed.FRB.GOV>
Federal Reserve Board 
Wash, DC 20551		(202) 452-2515
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Dec 90 21:40:26 GMT
From:      harvarda.harvard.edu!conrad@husc6.harvard.edu  (Conrad C. Nobili)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help finding telenet software to perform ftp as remote
In article <131134@tiger.oxy.edu> schorsch@oxy.edu (Brent William 
 Schorsch) writes:
> I am currently using NCSA Telenet software (from Univ. of Illinois at 
 urbana
> with a MacSE appletalk connected to a fastpath -> ethernet to Usenet
> I currently have to connect to a local Sun Workstation and ftp from 
 there,
> then, ftp to my mac and send from the Sun to me, I would like to remove
> the middle step... ( I read a review in Macworld Jan 91, p. 207 on
> TCP/Connect II 1.0, has anyone used this?)
> How about a pd program like NSCA Telnet, (TCP/Connect is $495!!)
> Thanks, Brent Schorsch (schorsch@oxy.edu)

You describe an obvious need.  I will describe what I find to be a good 
(and cheap) solution.  I am sure you will also hear about the virtues of 
some of the commercial solutions.  Certainly you will hear about 
TCP/Connect II, as there seems to be a dedicated Intercon presence on this 
group :-) !  (btw, I am NOT complaining about too much commercial 
salesmanship or anything, as most posts mention some competing commercial 
or "PD" option, and there seems to be an effort to exhibit thorough 
knowledge of these options (understandably not always fulfilled 
completely, what with all that's out there and product changes)....)

I have found that HyperFTP works very well for ftp-ing directly from the 
Mac.  HyperFTP 1.3 can be gotten at various Mac archives (did I get mine 
from Sumex?).  I am sure that someone can provide the name of its "home" 
archive.

HyperFTP is a HyperCard stack, and may not be ideal for that reason 
(memory problems, disdain for HyperCard and the people who use it, etc.).  
It also requires Apple's MacTCP drivers, and so I guess it is not free if 
you don't already own them.  (You can get them for free if you buy 
Mathematica!  8-)  )  Despite various rumblings, I have found MacTCP 1.0.1 
to be very nice.  (It enables me to use the netnews reader stack that can 
be gotten as part of the MacTCP Toolkit from apple.apple.com by anonymous 
ftp, from which I am posting this.)

The greatest thing about HyperFTP, what makes it worth getting extra 
memory for your Mac if you need it (c'mon, it's less that $40/MB now) and 
swallowing your pride about HyperCard, is that it can AUTOMATICALLY 
UNBINHEX FILES AS THEY ARE BEING DOWNLOADED!!!!!  I really love this 
feature!  It has saved me many hours and lots of annoyance....

You can of course get NCSA Telnet 2.3.2 BYU from zaphod.ncsa.uiuc.edu by 
anonymous ftp.  If you cannot use MacTCP you can use the NCSA version of 
this.  Expect a TRULY CRUFTY, minimal ftp client.  It works, but the user 
interface stinks.

--Conrad

                     C o n r a d  C .  N o b i l i
Harvard University                 |  Internet: conrad@harvarda.harvard.edu
Office for Information Technology  |  BITNET:   CONRAD AT HARVARDA
Information Services               |  voice:    (617) 495-8554
Technical and User Services        |  fax:      (617) 495-0715
                    < < < D i s c l a i m e r > > >
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 02:02:28 GMT
From:      cec@cup.portal.com (Cerafin E Castillo)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Re: Product Informatation

If you are looking for Wide Area Networking using TCP/IP (ie SLIP/CSLIP/PPP),
check out the TELEBIT NetBlazer.  With InterCon and FTP Software Inc.
applications, you could connect your UNIX/MAC/DOS systems in no time!

E-mail me for more details and a complete package.  (Sorry, for the
salesy plug, but I do have all this stuff...).

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 02:10:09 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP on a DOS Machine
I have found that there seems to be a third camp to the Ethernet vs.
Token Ring debate, this is one of serial I/O usage.  SLIP/CSLIP/PPP
can be used on PC's that might not be able to handle an ethernet
interface, or where there is a cost restraint.

Using freeware applications such as KA9Q (Mac/DOS) for SLIP/CSLIP/PPP,
or applications software by InterCon and FTP Software Inc., along
with SLIP/CSLIP on UNIX systems such as SCO, AIX, AUX, etc.. will
allow for inexpensive internetworking of DOS/MAC/UNIX systems
utilizing serial line IP.

The TELEBIT NetBlazer provides serial ports capable of serial line IP
protocols, such as these, as well as an ethernet interface for LAN
hook-up.  While the NetBlazer is made more specifically for dial-up IP
applications using V.32 modems, it can work as a 'star' device for 
this type of networking.

Terminal servers, such as the Xylogics Annex IIe, also fall in this
category.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 02:15:14 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCS TELNET - The Package
I believe you mean NCSA Telnet.  This should be available for the Mac
and DOS systems from a system at uiuc.edu (?) for anon FTP.  I wish
I could be more specific, but I don't have my mac near me to check.
Good Luck!

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 02:21:38 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 emulator for Macintosh
NCSA Telnet from uiuc.edu (?) has a tn3270 emulator which can be anonymously
ftp'ed from this site and runs within NCSA Telnet.  Very good freeware.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Dec 90 09:09:51 EST
From:      Steve Carmody <STC@brownvm.brown.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   question about architecture of AGS+
Here at Brown, we've been having fun this fall trying to select a
vendor for high speed, multi-protocol routers. At this point,
we've got a few questions which we haven't been to resolve.
In most cases, we have multiple answers to the questions, but
haven't been able to determine which is the correct one. If
someone can answer one or more of these, we'd appreciate the
help. All of the questions are about the Cisco AGS+.

1.  If a box is configured with MEC ethernet cards and an
FDDI interface, packets usually seem to stay within the c-
bus. When, if ever, must a network interface card send the
packet back to the main processor card (located on the VME
bus)?

2. In the most recent Bradner tests, the performance of the
AGS+ fell off in the Dual-stream
between interface cards test when filters were turned on. The box
ran well with dual streams without filters, but throughput
fell as soon as one filter was enabled. Does anyone know why?

3. The numbers in the Bradner tests seem to indicate that the
AGS+ performs well. We have heard rumors (but have seen no
numbers) that claim that performance of the AGS+ falls off if
it must route mutiple streams containing multiple protocols.
Does anyone have any measured numbers to support this rumor?

4. One of the software improvements Cisco has introduced to
boost performance is called "fast switching". This seems to
allow the network interface board to make more of the
decision about which interface to send the packet to. That's
good news. We've heard (again, no more than a rumor) that the
fast switch code uses a seven entry cache on the network
interface card. If thats true, a synthetic benchmark could
run well (or could be tuned to run poorly), depending on the
contents of the packet stream directed at the router being
tested. Does anyone know how the fast switch code really
works?

once again, thanks for any help.
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Dec 90 15:55:53 MST
From:      chiang@phx.mcd.mot.com (Mei-Ling Chiang)
To:        tcp-ip@nic.ddn.mil
Cc:        chiang@phx.mcd.mot.com (Mei-Ling Chiang)
Subject:   SIGCOMM '90 Proceedings

I would like to have a copy of SIGCOMM '90 Proceedings.  Can yoy
send me a copy.  If you do not have, please let me know where I can 
get one.   Thanks for your help.


Mei-Ling Chiang                   chiang@phx.mcd.mot.com
Technical System Division         (602) 940-1434    
Motorola Inc.
2900 S. Diablo Way, DW278
Tempe, AZ 85282
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 10:03:26 GMT
From:      mcsun!cernvax!jimi@uunet.uu.net  (Jean-Michel Jouanigot)
To:        tcp-ip@nic.ddn.mil
Subject:   High speed interface wanted.
Hi all,

  Our project is to run TCP/IP over a 8 Mbit/s satellite link.

  Our main problem is to connect a unix host to the satellite modem, using a
  high speed serial interface, preferably VME.
  We are desperately looking for such a card, with the following
  characteristics:

  - At least, 2 Mbit/s throughput, preferably 8 Mbit/s (or more !)
  - HDLC framing is accepted
  - SunOs driver (if available)
  - if 8 Mbit/s not achieved, several lower speed interfaces accepted (i.e.
  2*4 or 4*2). However, these interfaces should be supported by the same
  board.
  - If possible, the serial interface should be G703.

  Information welcome. Please reply directly to me.

-----
Jean-Michel Jouanigot
External TCP/IP, CERN-CN/CS/EN
CH-1211 Geneva 23, Switzerland
e-mail: jimi@cernvax.cern.ch, jimi@cernvax.bitnet, jimi@cernvax.uucp
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 5 Dec 1990 22:08:20 PST
From:      lixia@parc.xerox.com
To:        tcp-ip-RELAY@nic.ddn.mil
Subject:   Re: SIGCOMM '90 Proceedings
I assume you'd get lots of responses.  But if not, I have a spare
copy to give to you.  Let me know if you still need.
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 14:09:51 GMT
From:      STC@BROWNVM.BROWN.EDU (Steve Carmody)
To:        comp.protocols.tcp-ip
Subject:   question about architecture of AGS+

Here at Brown, we've been having fun this fall trying to select a
vendor for high speed, multi-protocol routers. At this point,
we've got a few questions which we haven't been to resolve.
In most cases, we have multiple answers to the questions, but
haven't been able to determine which is the correct one. If
someone can answer one or more of these, we'd appreciate the
help. All of the questions are about the Cisco AGS+.

1.  If a box is configured with MEC ethernet cards and an
FDDI interface, packets usually seem to stay within the c-
bus. When, if ever, must a network interface card send the
packet back to the main processor card (located on the VME
bus)?

2. In the most recent Bradner tests, the performance of the
AGS+ fell off in the Dual-stream
between interface cards test when filters were turned on. The box
ran well with dual streams without filters, but throughput
fell as soon as one filter was enabled. Does anyone know why?

3. The numbers in the Bradner tests seem to indicate that the
AGS+ performs well. We have heard rumors (but have seen no
numbers) that claim that performance of the AGS+ falls off if
it must route mutiple streams containing multiple protocols.
Does anyone have any measured numbers to support this rumor?

4. One of the software improvements Cisco has introduced to
boost performance is called "fast switching". This seems to
allow the network interface board to make more of the
decision about which interface to send the packet to. That's
good news. We've heard (again, no more than a rumor) that the
fast switch code uses a seven entry cache on the network
interface card. If thats true, a synthetic benchmark could
run well (or could be tuned to run poorly), depending on the
contents of the packet stream directed at the router being
tested. Does anyone know how the fast switch code really
works?

once again, thanks for any help.

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 14:54:39 GMT
From:      utkcs2!de5@gatech.edu  (Dave Sill)
To:        tcp-ip@nic.ddn.mil
Subject:   Need detailed FTP documentation
Where can I find detailed information about what conversions FTP will
perform in different modes and between different systems?  E.g., does
it do byte order swaps in binary mode between a VMS VAX and
SPARCstation?  What conversions does ASCII mode imply?  Etc.

The man page doesn't have it, and the RFC index doesn't show anything
promising. 

Thanks in advance.  Please reply by e-mail.  

-- 
Dave Sill (de5@ornl.gov)
Martin Marietta Energy Systems
Workstation Support
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Dec 90 20:23:27 EST
From:      Peter DiCamillo <CMSMAINT@brownvm.brown.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: 3270 emulator for Macintosh
Brown University distributes tn3270 for the Macintosh at no charge over
BITNET and the Internet.  Two versions are available, one with built-in
TCP/IP code, and one which uses MacTCP.  Brown also distributes a serial
communications program called Term, which has a user interface similar
to tn3270, and may be used with 3270 protocol converters that support
TVI 950 terminals.  These files are available via anonymous FTP to
brownvm.brown.edu, and over BITNET from LISTSERV@BROWNVM.  Feel free to
contact me for more information.

Peter
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 15:47:57 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   NFS biod question

I have a question regarding biods and their use in NFS.

How does a biod function when transmitting data from a client to an NFS
server?  The particular brand of NFS running on the server only allows a
cumulative total of 8K block i/o size per mount.
What specifically is the 8K limit?



Charles DeRykus				Internet:   ced@bcstec.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced
Renton, WA.  M/S 6R-37			(206) 234-9223

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 16:17:30 GMT
From:      csus.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bu.edu!dartvax!sunapee.dartmouth.edu!wbc@ucdavis.ucdavis.edu  (Wayne B. Cripps)
To:        tcp-ip@nic.ddn.mil
Subject:   Very Slow ip on Dec 5000's

We recently added 11 dec-5000's to our network, which is
one rather busy wire with multiports but no gateways or bridges,
except for our connection to the outside world.  We notice
that traffic to and from the decs is very slow - nfs
traffic hangs so much that compiles fail, for example.
We have NeXT, sun, apple, hp, and ibm machines on the same wire, 
and they have no problem.  We are running Ultrix 4.0 -
we did not notice the problem with Ultrix 2.0 on dec 3100's
earlier this year.  Has anyone else seen this slowness?
Any suggestions as to what causes it?

	Wayne

	Wayne Cripps
	wbc@DARTMOUTH.EDU		wbc@sunapee.dartvax.uucp
	Bradley Hall, Dartmouth College, Hanover N.H. 03755 (603) 646-3198
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 16:36:32 GMT
From:      usc!sdd.hp.com!samsung!cs.utexas.edu!sun-barr!newstop!texsun!netdev!root@ucsd.edu  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   TOKEN BUS CONTROLLER NEEDED
We are looking for a Token-bus controller for the AT/PC bus. Please respond
via e-mail. Thanks

 -Alex
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 18:19:02 GMT
From:      usc!wuarchive!cs.utexas.edu!asuvax!anasaz!qip!chad@apple.com  (Chad R. Larson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In article <2766@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com
(Rahul Dhesi) writes:
+---------------
| Considering that 99% of existing implementations of UNIX provide no
|                 ^^^^^
| support for TLI, using it at this point would result is extermely
| nonportable code.
+---------------
73.4% of the people who quote statistics make them up.

At our site, we have four different vendors for Unix and three of them
support TLI.  That makes it 25% if you are counting types.  If you count
population of machines, its more like 30 to 5 (or 16%) and the 5 are
scheduled for upgrade.

If you are concerned with portability (and the original poster was), you
can't ignore TLI and streams.  It is the socket interface that will be
going away (but not for a *long* time...).
	-crl
-- 
Chad R. Larson          ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP
Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020
(602) 870-3330            "I read the news today, oh boy!"  -- John Lennon
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 20:47:13 GMT
From:      BINGZHI@ICNUCEVM.CNUCE.CNR.IT (BingzhiLi)
To:        comp.protocols.tcp-ip
Subject:   Communication between IBM and VAX



Hello, TCP-IPers
I am making the programs of connecting VAX/VMS host to IBM/CMS host
for interactive file transfer using TCP/IP. Now some problems arise.
  1)Is it possible to connect IBM host(TCP/IP installed) and VAX(WIN/TCP
    installed) due to the diffenent version of softwares?
2)Is there any problem due to the different languages used(Pascal on
    IBM, C on VAX)?
Someone told me there have been this kind of software developed for the
communication of IBM and VAX.  Does anybody know anything about these
matters? or provide some informatin for me?  Thank you in advance !

Bingzhi  Li

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Bingzhi  Li                                               *
Institute of CNUCE                                      *****
Italian National Research Council                      *******
36 Via S. Maria                                       *********
56100 Pisa, Italy                                    ***********
Voice: +39 59 593343                             Happy    *  Boun
Email: bingzhi@icnucevm.cnuce.cnr.it           Christmas  *   Natale
                                                          *
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Wed, 05 Dec 90 21:47:13 MET
From:      BingzhiLi <BINGZHI@ICNUCEVM.CNUCE.CNR.IT>
To:        multi-recipients <tcp-ip@nic.ddn.mil>
Subject:   Communication between IBM and VAX


Hello, TCP-IPers
I am making the programs of connecting VAX/VMS host to IBM/CMS host
for interactive file transfer using TCP/IP. Now some problems arise.
  1)Is it possible to connect IBM host(TCP/IP installed) and VAX(WIN/TCP
    installed) due to the diffenent version of softwares?
2)Is there any problem due to the different languages used(Pascal on
    IBM, C on VAX)?
Someone told me there have been this kind of software developed for the
communication of IBM and VAX.  Does anybody know anything about these
matters? or provide some informatin for me?  Thank you in advance !

Bingzhi  Li

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Bingzhi  Li                                               *
Institute of CNUCE                                      *****
Italian National Research Council                      *******
36 Via S. Maria                                       *********
56100 Pisa, Italy                                    ***********
Voice: +39 59 593343                             Happy    *  Boun
Email: bingzhi@icnucevm.cnuce.cnr.it           Christmas  *   Natale
                                                          *
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Dec 90 23:51:27 GMT
From:      ee.udel.edu@louie.udel.edu  (Darren New)
To:        tcp-ip@nic.ddn.mil
Subject:   1990 version of GROPE now available

University of Delaware is pleased to announce the availability of 
    GROPE - Graphical Representations of Protocols in Estelle

GROPE (Graphical representation of protocols in Estelle) is a tool for 
graphically animating the dynamic execution of an Estelle formal specification.
Developed in Smalltalk-80 and based on a SUN 3/110 workstation, GROPE is a 
window-based system that pictorially represents a protocol's architecture, 
animates transitions firing and the exchange of interactions between modules, 
graphically displays a module's extended finite state machine and the 
changing of states, and so on.

It is expected that the GROPE tool will assist the original protocol specifier 
in the design and debugging process, promote faster understanding of a 
protocol by those using it for the first time, and facilitate the development 
of effective test scenarios.

GROPE runs on Sun-3s, Sun-4s, Macintoshes, IBM PCs, and others (tm's).
It requires ParcPlace Smalltalk-80(tm) Version 2.5 and works best with
NIST's WISE interpreter.  Full details of system requirements may be
found in the Grope-Readme file.

GROPE is available via EMail by anyone sending their email address to
grope@udel.edu.  If possible, please send your name and affiliation for
the purpose of allowing me to support claims of usefullness. The actual
code is available, as are Postscript versions of articles describing
GROPE and its operation.

Also available via email is a collection of ``real world'' Estelle
specifications, many of which have been made to work with GROPE.  Send
mail to "Est-Specs@udel.edu" for more information. Contributions
welcome!

If you have any comments, questions, problems, or suggestions for improvement,
please feel free to contact us at GROPE@UDEL.EDU or USA phone number
(302) 451-8013 (Darren New) or (302) 451-1944 (Paul Amer, CIS dept).
GROPE can also be obtained by those without email access: contact us.
Our mailing address is 
   Paul Amer
   c/o Department of Computer and Information Science
   103 Smith Hall
   University of Delaware
   Newark, DE 19717
   FAX: 302-451-8000

A complete description of GROPE is appeared in
    Information Software and Technology
in March of 1990 under the title
    "Adding Graphics and Animation to Estelle".
Also, an update on the status of GROPE was presented at FORTE'90
in Madrid, Spain and will appear in those proceedings. 
These papers are available in Postscript form to those who request it.
A LaTeX version of these papers are also available for those without
Postscript, but lacking issulstrations suffer in their presentation.

Thank you for your time.       -- Darren New (new@udel.edu)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

New features since FORTE~'89:

GROPE can currently interface to the NIST WISE interpreter, which is
also written in Smalltalk, and can display the results of WISE
interpreting an arbitrary Estelle specification.  At FORTE'89, GROPE
was only capable of receiving information from WISE and outputting
graphical information to the screen: there was no communication path
established from GROPE back to WISE. This restricted GROPE's
applicability. Now, GROPE includes a mechanism whereby GROPE can
respond not only to WISE but to any program to which it is interfaced,
again maintaining the flexibility of using GROPE with a variety of
other tools.

The ability of a user to select and examine the contents of queues, the
ability to resolve non-determinism, and the ability to inspect the
bodies of transitions are all available in GROPE at this time.

It should be stressed that GROPE can interface to any Estelle
interpreter implemented in any language. The University of Delaware is
prepared to work with other tool builders to enhance their tools by
adding GROPE as a graphical front-end.

At FORTE'89, reducing the size of a GROPE window caused the
contained information to be scaled to a smaller size. 
This reduction sometimes made complex FSMs illegible.

A feature has been added to GROPE whereby windows can be ``zoomed'' in
to display only local areas of an FSM. As transitions fire, these
windows scroll to remain centered on the currently active state or
transition.  This allows many more state machines to be viewed
simultaneously without any becoming illegible due to a small window size.

Needless to say, most of the annoying bugs have been fixed.

Future Research:

We are investigating GROPE's ability to visually display a FSM at
varying levels of detail, i.e., not showing all states and transitions
at once.  This would allow complex machines to be studied
incrementally, aiding the visualization process. It is expected that
this feature will also allow improved first-guess graphics of a finite
state machine and may even lead to automatic modularization of poorly
written specifications. In addition, investigation of a graphical
Estelle editor based on GROPE is in progress, as is investigation of an
automatically-generated test case visualizer.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Availability:
  GROPE is available for Smalltalk-80 VI2.5 (ParcPlace ObjectWorks)
  and Smalltalk-80 VI2.2.  This file contains the code for VI2.5.

  The Grope-Wise-Driver (which allows WISE to call GROPE during execution)
  also is available for VI2.5.  It is untested for the latest version
  of WISE under VI2.2.

  WISE is available directly from National Institute of Standards
  and Technology (NIST, formerly NBS), without whose help GROPE would
  never have come to be.
    >From: Rachid Sijelmassi <sijel@apm1.ncsl.nist.gov>
    >Organization: National Institute of Standards and Technology (NIST)
    >Sub-Organization: National Computer Systems Laboratory
    >
    >The latest version of WISE is available by anonymous FTP
    >from osi.ncsl.nist.gov.  The code for WISE is part of
    >the OSIkit package, so you can take all or part of it.
    >Once you are on osi.ncsl.nist.gov, go to pub/osikit.
    >You will find the Estelle-to-C compiler (estpc.tar),
    >the ASN1 tool (asnfvt.tar), Wizard (estwizard.tar),
    >WISE (estwise.tar) and the manuals (mansrc.tar).
  Please note that to translate from Estelle to Smalltalk,
  estwizard.tar will be needed in addition to estwise.tar.

  The Smalltalk-80 interpreter is available from ParcPlace Systems
  at a cost of several hundred dollars (depending on the machine) for
  educational institutions.  
  ParcPlace Systems
  1550 Plymouth Street
  Mountain View
  California 94043
  Info@ParcPlace.com  Info@ParcPlace.uucp

Please read the comments in the Grope-Display classes for documentation
of the menus available within GROPE.

Please note that Smalltalk-80 is a liscenced product and a registered 
trademark of ParcPlace Systems.  GROPE is copyright 1988 1989 1990 by the
University of Delaware (All Rights Reserved) but may be freely redistributed
in its original form and without modification, addition, or deletion.
GROPE may NOT be redistributed for a fee except media costs, small
handling charges, and normal downloading fees.  GROPE may be posted
to private or commercial bulletin-boards within these restrictions.
Please contact us before charging fees for commercial support of GROPE.
Please contact us if you make any improvements or bug-fixes to GROPE
in order that we may incorporate your changes (with thanks!) into
our "official" version.

GROPE is supported, in part, by the US Army CECOM Center of Software
Engineering and the Office of Naval Research (N14-83-K-0320, N14-88-K-0253).
WISE is in the public domain (as far as I know) as is most material
developed by NIST.

I would like to thank the people at NIST who encouraged me and made valuable
suggestions about the structuring of GROPE and who provided the WISE 
interpreter that makes GROPE worthwhile in the first place.  I would also like
to thank Dr. Paul Amer who supplied the original ideas for GROPE, as well
as the funding.

------------------------------------------------------
Note that you MUST have Smalltalk-80 Virtual Image version 2.5 to run this
version of GROPE.  Please contact GROPE@UDEL.EDU if you have an older
version (2.2, 2.3, or 2.4).

To install GROPE into your Smalltalk-80 image, follow these steps:
1) If you have a postscript printer and you wish GROPE to be able
    to print, file in the printer support stuff.
2) You MUST file in the FStream.st file from the Smalltalk utils directory
    in order to run WISE under VI2.5.
3) FileIn the wise.st code to load WISE. Note that the wiseForm* must 
    be in the current directory (not the same as the Wise directory)
    before trying to FileIn wise. Note that two methods will fail to
    compile and that many warnings will be generated.  On the failing methods,
    just select "proceed" to ignore the erroneous methods.
4) FileIn the wise-patches-for-25.st file, which will fix the incorrect methods,
    will eliminate the warning messages, and will fix a couple of bugs in
    the WISE routines.  Exactly what changes are made is documented at the
    beginning of that file.
5) FileIn the grope code. During the GropeView class>initialize code, the
    Grope-Queue-Forms.st file will be sought. If you get no queues
    displaying, reinitialize GropeView and make sure that the file
    is found. Also, the files Grope-Driver-Form.st and 
    Grope-Background-Form.st will be read.  These should probably be 
    renamed before filing in GROPE unless you enjoy gaudy backgrounds.  
    These can be deleted safely and are used primarily when the UDel GROPE 
    team demos GROPE to others. The Grope-ABP* files
    include the forms for the GROPE demo.  If you select not to install
    the standard GROPE screen menu (a BinaryChoice will appear during filein)
    you may need to press break (Ctrl-C) and close the notifier to regain
    control.  
6) To actually interpret an Estelle spec with wise, you must do the
    following:
6a)  Edit the Estelle spec (say "plover.e"). End the name with .e
      To avoid confusion, name the specification body "plover".
6b)  Due to restrictions of the current Grope-Wise driver, all transitions
      must be expanded and named with the "name :" clause.  That is, each
      transition body must correspond to exactly one arc in the FSM
      drawing and each must have a unique (within the body) name.
      This is not a restriction of WISE, but only of the current version
      of GROPE, and will eventually be lifted.  You need to name transitions
      even if the only state is the default state; however, if there are
      no named states then you will see no FSM pictures.
6c)  Copy the Estelle spec to a Smalltalk name:
      cp plover.e plover.st
6d)  Start the wizard program:
      wizard plover.st
6e)  type "escape e" to translate to smalltalk.  If you get an
      error message instead of smalltalk on the screen, type
      "escape e control-x control-w escape s control-x control-c"
      and look in the plover.st file for the string "===" which will
      mark error messages. If you got "Syntax error on line XX" then
      just "control-x control-c escape s" to exit wizard and fix the
      offending lines. If you got smalltalk code, type
      "control-x control-w escape s control-x control-c" to save
      the smalltalk code.  P.S., this takes several minutes.
6f)  Start ST80, choose "wise" from the screen controller, and choose
      "add a spec" from the upper-left pane. Then, add a site, select
      the spec and the site, and start the selected spec. Fiddle around.
7) To interpret it with GROPE, you must file in Grope-Wise-Driver.st 
    after loading WISE and GROPE (in that order) but before loading
    specifications with WISE.  Then simply choose "build grope" from the
    specification menu before starting the specification under wise.

Note that WISE has some serious user-interface problems, primarily in the
scheduling of views. GROPE also needs some work, but not as much. Both of 
these are prototypes, so don't expect to use them in a "production" environment.

Known bugs in Grope-Display:
1) Sometimes when multiple Processes update at the same time (multiple
   transitions firing at once, multiple outputs, etc.) reverse-video
   spots will be left on the screen. This is new since VI2.5 and I
   suspect that something has become non-atomic. If you find out
   what is causing this, please let me know.
2) Doing "restore display" while transitions are in the middle of firing
   can cause updates to lock up the scheduler. This is due to the way
   that refreshing is handled; basically, I busy-loop waiting for updates
   to complete. I'll work on this.

Known bugs in Grope-Wise-Driver:
1) You need names on the transitions even if you have no states and thus
   can't display the FSM. Since I plan to eventually not require
   expansion of the transitions, I don't plan to fix this one soon.

Known bugs in Wise:
1) Due to the way WISE views are added to ScheduledControllers, sometimes
   moving the pointer from one view to another and trying to use the
   menu does not work. To work around: move to the background, bring up the
   screen menu (to unselect all views) and then move off that menu,
   release the mouse button, and move to the WISE view you wish to work on.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

File in the Grope-Display.st class.
(Grope-other stuff will be drivers for Grope)
It will add the category Grope-Display.
It will also add several graphical operations to the Path, 
Point, Curve, Form, DisplayObject classes.
It will add some functionalty to ScreenController and 
BlockContext as well; the ScreenController>>openGrope will display
an example of AlternatingBit protocol.
Use "Smalltalk browseAllCallsOn: #GropeDisplay" to
see all changes outside of the Grope-Display category.

The GropeSpec class has several examples.
The GropeView class has several parameters which
can be modified by the user; some are constants and some 
are initialized class variables. GropeView version will return
a string describing the current version, currently 0.95.

To run a demo of GROPE, send the current screen controller
the message openGrope (like by putting it in the screen menu
or by typing that method into a workspace).
Open out the window, which will show the architecture
of the AlternatingBitExample. Click anywhere in the window away
from other things, which should make the border turn gray.
Select "load" off the yellow menu, and AlternatingBitExample.gr
should be loaded (if in the current directory). This should cause the
window to redraw. Make sure your transcript is open, and then
use "test" from the yellow menu while the specification body is
selected to "simulate" a driver (with informative messages going
to the transcript). Due to Smalltalk's lack of clipping, GROPE windows
which are overlapped by other windows will not be updated.

My preference is to open the transcript at the bottom,
the specification body on the left side,
AlternatingBit[1] on the top right (showing FSM),
AlternatingBit[2] on the bottom right (showing FSM).
Leave the AlternatingBit modules in the specification
showing the architectures (for the queues).
Note that the rectangle that would be overlapped were
the label of a window to be extended fully to the right
is considered part of the window; thus, a GROPE window
overlapping this area will not be updated.

To exit this demo, hold all three mouse buttons down until you get
an "ABORTED" message in the Transcript (appologies to thos with one- and
two-button mice). To pause, move the cursor to the upper-left corner.

Please see the class comments for GropeDBody, GropeDSpecBody, 
GropeDLink, GropeDIP, GropeDState and GropeDTransition
for explainations of the menus.
------------------------------------------------------

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 00:51:15 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!fallst!tkevans@ucsd.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   Missing Object (snmpmon) from CMU SNMP Package
I just ftp'd the CMU SNMP package, straight from the horse's
mouth, but when I went to compile it (on a Sun 3), the make
blew up over a missing object 'snmpmon'.  What do I do now?

Thanks
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 00:53:21 GMT
From:      usc!sdd.hp.com!samsung!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!cc.utah.edu!jzzr@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP book recommendations

TO: INTERNET READERS
Fm: jzzr@cc.utah.edu - Dave Francetic
Re: TCP/IP book recommendations

Can anyone recommend books useful for programmers writing TCP/IP interfaceses?

If it makes any difference we are using Interactive Unix 386ix Ver: 2.2  .

Please E-mail directly to me.   Thanks in advance.
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 01:23:27 GMT
From:      CMSMAINT@BROWNVM.BROWN.EDU (Peter DiCamillo)
To:        comp.protocols.tcp-ip
Subject:   Re: 3270 emulator for Macintosh

Brown University distributes tn3270 for the Macintosh at no charge over
BITNET and the Internet.  Two versions are available, one with built-in
TCP/IP code, and one which uses MacTCP.  Brown also distributes a serial
communications program called Term, which has a user interface similar
to tn3270, and may be used with 3270 protocol converters that support
TVI 950 terminals.  These files are available via anonymous FTP to
brownvm.brown.edu, and over BITNET from LISTSERV@BROWNVM.  Feel free to
contact me for more information.

Peter

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 02:37:50 GMT
From:      prism!prism.gatech.EDU!ce1zzes@gatech.edu  (Eric Sheppard)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet Beta v12 problems
Well, the new beta package seems to be a mixed blessing.  I'm having
problems with my ethernet card.

Setup:  AT compatible with 2Meg RAM, 3Com 3C503 card using thick cable.
Version 7 packet driver.

FTP cannot initialize the network card.  I've tried using the internal
3C503 support, and the packet driver.  Neither work.  Telnet, when using
the internal defs, crashes fiercely after displaying the greeting screen.
It seems to work fine with the packet driver installed.

My card has 300 I/O address, dc000 base memory address, and interrupt level
3 currently set.  I was previously using beta level 9 software with a packet
driver loaded, using interrupt 0x7e.

I first changed the hardware spec lines in config.tel to several values.
All crash the system (telnet) or refuse to load(ftp).  Then, I removed all
memory-resident programs (console driver, mouse driver, etc.) and tried
again.  No luck.  

Good advice welcomed and appreciated.

Eric, tinkerer-at-large
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 10:47:16 PST (Thu)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        de5@ornl.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Need detailed FTP documentation
In FTP ASCII mode, posit the existence of a newline convention for the
two systems doing the FTP. I'm not sure what VMS does; suppose it
indicates newline by storing a carriage return line feed sequence (CR
LF). Suppose the other end is a UNIX system, indicating newline with
just linefeeds. [There have been other systems, like Symbolics lisp
machines, that would indicate line feed with a character > 128
decimal]

As the server picks up the file it's going to send, it maps every
instance of the newline indicator (CR LF in this case) to CR LF over
the TCP connection. So in this example, no work is done. It also maps
any lone CR to CR NUL. The client, receiving the file, maps every
instance of CR LF to its local newline format, in this instance, LF.
And it umaps CR NUL to just CR.

Basically, FTP has its own representation of newlines for the file
while the file is in transit. The transmitter must encode the file
from its own format into that representation; the receiver must decode
it from FTP's representation into its own format.

In image (binary) mode, FTP doesn't know anything about byte swaps or
file formats. It picks up a pile of bytes off the disk, sends them,
and the receiver writes what it receives. If you're moving a binary
database between processors with different word sizes and byte orders,
there's no way for FTP to know how to convert those. You've got to do
that conversion either before or after you move the file.

There's also a mode called "local n" for dealing with non-8 bit word
systems, like TOPS-20 or lisp machines, which doesn't really matter
here.

		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 03:16:48 GMT
From:      prism!prism.gatech.EDU!ce1zzes@gatech.edu  (Eric Sheppard)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet to a PC?
I put Telnet beta v12 in server mode and tried to telnet to it from another
machine.  It responded:

Packet received for invalid port -- reset sent

Can one log onto a PC over telnet?  How can this be accomplished?

Eric
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 6 Dec 1990 9:22:26 CST
From:      JAFFE@SSCNET.SSC.GOV
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for copy of 12/5/90 gov't computer security report...

Does anyone know where I can obtain a copy of the computer security report 
presented in Washington D.C. on 12/5/90?

Thanks in advance.

Mike Jaffe
Superconducting Super Collider Laboratory
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 11:26:09 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!labtam!cnw01!nigel@ucsd.edu  (Nigel Harwood)
To:        tcp-ip@nic.ddn.mil
Subject:   Strange rwho demon behavior
I have a situation where some machines on our TCP/IP network
are not listing all other machines when an rwho or ruptime
is done.

The majority of these machines are running Excelan TCP/IP on V.2
although one is running Win TCP/IP on V.3.

All machines have complete /etc/hosts files.

Machine A will list A, B, C, D

Machine B will list B, C

Machine D will list A, B, C, D

Basically what I'm asking is, is there a gotcha in how rwho
determines who to tell about itself or alternatively who
to listen to.

I thought rwho was pretty straight forward, am I wrong ?

Could it have something to do with addressing schemes which
changed here a little while back (I can't categorically
blame that as I did not notice the behavior for a while).

Also, all machines can rlogin etc to each other.

Thoughts ?

-- 
<<<<<<<<<<<<<<<<<<<<<<<<<  Nigel Harwood  >>>>>>>>>>>>>>>>>>>>>>>>>>>
<< Post:  Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia     >>
<< Phone: +61 3 829 6090  E-mail: nigel@cnw01.storesys.coles.oz.au >>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 14:28:00 GMT
From:      mcsun!ukc!tcdcs!nixeid!keogh@uunet.uu.net  (Paul Keogh)
To:        tcp-ip@nic.ddn.mil
Subject:   IP down scaling (linear or what) ?
I am trying to determine, quantitively or qualititively, the effect of 
reducing the bandwidth of an IP link.

Lets assume I'm running FTP over Ethernet, with resulting throughput varying
between 50Kbytes and 100Kbytes, averaging out at say 80Kbytes. I then want to
replace the 10Mbits media with 2Mbits and then with 64Kbits (using bridges).

Obivously at 10Mbits, the average speed of an FTP transfer is not influenced
by the physical media but what happens at speeds of 2Mbits and 64Kbits ?

I am trying to establish the relationship:

	Speed(FTP) = G(Speed(physical media)) + F(other factors)

where F(other factors) is assumed the same for all instances of the test.

Does anyone have any ideas for the nature of G() as described above ?

Thanx,
Paul Keogh
keogh@u.nix.ie
-- 
Paul Keogh, 				  *
Nixdorf Computer Research & Development,  *	Ha! you think it's funny,
Dublin, Ireland.			  *	Turning rebellion into money
					  *
Net: keogh@u.nix.ie		          *    
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 16:54:59 GMT
From:      sci34hub!gary@uunet.uu.net  (Gary Heston)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rlogin and run a command etc
In article <1141@cnw01.storesys.coles.oz.au> nigel@cnw01.storesys.coles.oz.au (Nigel Harwood) writes:
> [ using rlogin ]
>The problem was that I cannot tell it to run a command as soon as
>it has logged in.

Change the userid entry in /etc/passwd so that it runs the command (your
COBOL menu, in this case) upon login instead of /bin/sh (or whichever).

For an example, look at the entry for nuucp--it automatically runs 
/usr/lib/uucico (unless someone's removed it for security reasons).

-- 
Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or
My opinions, not theirs.  SCI Systems, Inc.     gary@sci34hub.sci.com
  The sysadmin sees all, knows all, and doesn't tell the boss who's
  updating their resumes....  This .sig Copyright G. L. Heston, 1990
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 17:54:01 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Re: Product Informatation

kdb@macaw.intercon.com (Kurt Baumann) writes:
> That's InterCon.  Not Intercom, sorry, but everyone I talk to over the phone
> makes the same mistake. :-)  Sigh.

	I don't remember who it was, but somebody once suggested that good
code should meet the telephone test -- you should be able to read your
program to somebody over the phone and have them understand it.  Perhaps
company names should be held to the same standard?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 18:08:14 GMT
From:      csus.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!clarkson!sun.soe.clarkson.edu!jk0@ucdavis.ucdavis.edu  (Jason Coughlin)
To:        tcp-ip@nic.ddn.mil
Subject:   Raw sockets (HELP! :-)
I want to write a simple program to capture the IP traffic coming
into my machine and to "dump" the packets to the screen.
There is little documentation on raw sockets.  I have already looked
at _Unix Network Programming_ and various man pages.  Can someone
familiar with the semantics of raw sockets *please* send me 
some email??!

My understanding is that a raw socket receives a copy of all
data at the specified protocol layer.  It's not working that
way.

Below is an example program that I've been playing with.  It has
seen numerous modifications so it's not a great program.

Thanks for any help!!

--
Jason Coughlin
( nibmjake@ralvmm.iinus1.ibm.com, jk0@sun.soe.clarkson.edu, -or-
  jk0@clutx.BITNET )

----[Cut me!]-----------------------------------
/* raw.c -- Capture raw IP traffic.
	Written by Jason Coughlin.
 
   NOTES:
 
	* I don't know what I'm doing with this stuff yet.
*/
 
/* you NEED this define!  otherwise the header files won't align the
 * byte correctly.
 */
#define OS2
 
#define MAX_BUFFER		8192
#define MAX_COUNT		20
#define WAIT			-1
 
#include <types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdlib.h>
#include <stdio.h>
 
#include "in_systm.h"
#include "ip.h"
 
main(argc, argv)
int argc;
char *argv[];
{
   int fromlen;
   struct sockaddr_in from;
   struct protoent *proto;
   int n, count;
   int sock;
   int ready[1];
   char *pkt;
 
   if ( (pkt = (char *)malloc(MAX_BUFFER)) == NULL ) {
	printf("Can't allocate packet!\n");
	exit(1);
   }
 
   sock_init();
 
#ifdef TESTING
   /* lookup the protocol to get the protocol entry which contains
    * the protocol number.
    */
   if ( (proto = getprotobyname("icmp")) == NULL ) {
	perror("getprotobyname");
	exit(1);
   }
#endif
 
   /* allocate raw socket which listens to the IP protocol layer. */
   if ( (sock = socket( AF_INET, SOCK_RAW, IPPROTO_RAW )) < 0 ) {
	perror("socket");
	exit(1);
   }
 
   ready[0] = sock;
   fromlen = sizeof(from);
   count = 1;
 
   printf(" #   VER  HLEN  SRV      TLEN    ID   TTL   PROTO   CKSUM\n");
 
   while (1) {
 
#ifdef NOT_WORKING
	/* wait for input */
	if ( select(ready, 1, 0, 0, WAIT) < 0 ) {
		perror("select");
		exit(2);
	}
#endif
 
	/* recv it */
	if ( (n = recvfrom(sock, pkt, MAX_BUFFER, 0, &from, &fromlen)) < 0 )
		perror("recv");
	else {
		struct ip *iph;
 
		iph = (struct ip *)pkt;
 
		/* dump it to screen */
		printf("%d: ", count);
		printf("%d ", iph->ip_v);
		printf("%d ", iph->ip_hl);
		printf("%d ", iph->ip_tos);
		printf("%d ", iph->ip_len);
		printf("%d ", iph->ip_id);
		printf("%d ", iph->ip_ttl);
		printf("%d ", iph->ip_p);
		printf("%d ", iph->ip_sum);
		printf("\n");
		fflush(stdout);
	}
 
	/* increment count.  we do count packets then pause to give the
	 * user a chance to kill this program.
	 */
	if ( ++count > MAX_COUNT ) {
		printf("Press any key ...");
		(void)getchar();
		count = 1;
		printf("\n\n");
		printf(" #   VER  HLEN  SRV      TLEN    ID   TTL   PROTO   CKSUM\n");
	}
   }
}

--
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." -- They Might Be Giants
"If you read the _TV Guide_, then there's no need for a TV." -- Lost Boys
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 20:12:23 GMT
From:      bbs!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Write Structured Field responses/actions... any docs?
Does anyone have a list of the write structured field queries, and the
appropriate responses?

We have a working X-windows client here now for TN3270, and it's great
except for the fact that it is missing that functionality.  We need it, at
least in the query mode (to say "I can't do that!")

Pointers to working code are ok as well.

Thanks in advance!

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 21:48:46 GMT
From:      mintaka!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!hardiman@bloom-beacon.mit.edu  (Paul V Hardiman)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for K200
We have an opportunity to pick up a Fibronics K200 Ethernet interface
that is going to be surplussed by another department.  This box connects
an IBM mainframe channel to an Ethernet.

Is there any freeware/shareware/cheapware that will support TCP/IP over
this box?  We need only FTP, TELNET, and SMTP.  We're running MVS/XA.

Please respond via email.

Thank you!
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      6 Dec 90 22:03:34 GMT
From:      motcid!derosa@uunet.uu.net  (John DeRosa)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help finding telenet software to perform ftp as remote
Have you tried on of the TelNet hacks that was done by
BYU?  It has host ftp built in, i.e. you can ftp into 
a distant computer instead of logging into the distant
computer and then ftp'ing back again.
-- 
=       John DeRosa, Motorola, Inc, Cellular Infrastructure Group          =
= e-mail:    ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net          =
= Applelink: N1111                                                         =
=I do not hold by employer responsible for any information in this message =
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 07 Dec 90 12:46:38 -0800
From:      jqj@duff.uoregon.edu
To:        keogh@u.nix.ie
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IP down scaling (linear or what) ?
>I am trying to determine, quantitively or qualititively, the effect of 
>reducing the bandwidth of an IP link.

One important point with slow links is cascade effects going through
multiple routers or bridges.  Since very few router technologies allow the
retransmission of a packet until reception is complete, each hop typically
adds the total transmission time for the packet on that hop to the round
trip time.  For example, a 19.2Kbit/sec serial connection with 640byte
packets contributes about 270ms each way.

Each hop of course also adds the bit propagation delay, e.g. a satellite
link may add hundreds of ms.  On the other hand, terrestrial links seem to
have propagation delays of a few 10s of ms for digital circuits and on the
order of 100ms for analog circuits with modems (speed of light Oregon to
South Dakota places a lower bound on that link of about 15ms; empirically
I measured about 150ms including modulation/demod delay in a pair of
Fujitsu 19.2Kb trellis modems).  It also adds think time in a router for
routing decisions and transfer of the packet from the input interface to
the output interface, but that's typically well under 10ms in modern
routers.

Bottom line is that if your path is through 3 19.2Kbps analog links you
should expect to see RTTs of more than 2s, and that RTT will be affine in
1/bandwidth for any given technology and topology.

For FTP with well-tuned TCP implementations, the RTT should not
dramatically effect total thruput at typical current bandwidths and
delays; only the minimum bandwidth over the various hops in the path will
have a significant (and to a first approximation linear!) effect. 
However, for any synchronous or packet exchange application, e.g. typical
telnet with remote echo or RPC (e.g. NFS!), large RTTs will kill you.  

Long RTTs can even have a big effect on FTP, since TCP allows only a
fairly small amount of unacked data.  But "small" is relative here, and it
isn't too relevant for the range of bandwidths the original poster asked
about, *unless* you have a couple of satellite links in the picture.  
The picture is very different for gigabit nets!
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 01:16:25 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet to a PC?
My experience with PC/Mac related TCP/IP (SLIP) software (KA9Q) is
that you need a psuedo tty (login proces) as well as a telnet
port in order to gain access to the PC/Mac.  Most of the time,
I FTP to the PC/Mac and move about from directory-to-directory,
as well as list directories and upload/download files within the
FTP shell.  I don't know of any PC/Mac applications which would
launch on the PC/Mac and output over telnet.  X-Windows clients
might be the closest you'll get.  Hope this helps.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 01:38:08 GMT
From:      uupsi!sunic!lulcps!mk@rice.edu  (Michael Kolmodin)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for system V.3 (where can i find it?)
I have a system V.3 machine (a motorola delta thing) with 
Berkeley network extensions includning a fairly complete
socket library. Is there a SLIP version somewhere I can use?

--michael
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 01:57:17 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP modem autodialing and idle line detection
While the virtual circuit, IP addressing, and idle time may be
critical points to your application(s), I would have to agree on
the speed of SLIP.  Currently, most SLIP/CSLIP/PPP are run via high-speed
modems and hardwired links which are limited to the abilities of
the serial I/O port in combination with the phone line or copper wire
bandwith.  18 Kbps is the fastest currently possible on the phone line
(Telebit PEP) but V.32 (9600) is the most responsive to interactive
full-duplex sessions.  38.4 Kbps is quite suitable via hardwired connection.
But for a WAN, its got to be modems or special services (leased, 56k, T1).

The NetBlazer introduces two ways in which one can attain high throughput
while using SLIP/CSLIP/PPP.  A 56 kbps V.35/RS-232 interface board can
be integrated into the NetBlazer and used with Synchronous PPP to talk
to another NetBlazer OR the Cisco, Novell, and 3COM PPP Routers.  INVERSE
MULTIPLEXING is yet another way to gain a high thorughput, BUT over
phone lines!

Inverse muxing is a way of taking two or more modems (TELEBIT V.32s) and
dividing an IP data stream amongst them.  Thus, you multiply your bandwith
by the number of modems used and their throughput:

     6 modems x 9600 bps (V.32) = 57.6 kbps (approx.)

This can be done using SLIP/CSLIP/PPP, BUT requires two NetBlazers (1-mux
-> 2-demux) and multiple phone lines and modems to accomplish the connection.
The modems are assigned as a group and the high-water mark is the maximum
number of modems in the group.  Thus, if your file transfer or X-Windows
session does not require all 6 modems, only the number needed to get the
job done (as calculated by the NetBlazer) are used.  The other modems remain
on standby or are used on a first-come; first-serve basis, depending on the
number of overlapping groups given access to the modem pool.  Any contension
for modems yield a 'Network Unreachable' error.  The modems go on and off
hook as more or less bandwith is needed throughout the connection.
I understand that Inverse Muxing has been tested with up to 24 modems so
far, with reliablity and good throughput (remember TCP/IP overhead over 
serial lines...).

These two features are meant to provide ease of dialbackup or Point-of-
Presence (POP) applications in WANs.  If your 56 kbps goes down, several
modems pick-up and replace the high-throughput connection (metrics are
used to keep traffic on 56 kbps channel until modems are needed; OSPF is
on the way in the NetBlazer - '91).  These features will also serve quite
well for a dial-up IP service provider.  The nice part about this is that
the modems are auto initialized and configured for the connection in the
virtual circuit.  This leaves the Sys or Net Admin to worry about IP addresses
and and network topography rather then hacking SLIP drivers and configuring
modems to auto-dial.  RIP makes this box go well with your routers, gated,
and routed systems and SNMP MIB I and II provide good network support.

NCSA Telnet, KA9Q [NOS] (PPP.12), freeware SLIP for Suns, as well as VJ
CSLIP, FTP Software Inc. PC-205 for DOS, and InterCon InterConnect II for
Mac; were all tested with this box doing SLIP/CSLIP/PPP.  I used them all
quite a bit and found no problems.  I am waiting for the virtual circuit
capabilities to be built into these applications in order to enjoy this
connectionless IP environment from my Mac/PC/UNIX sys at home to my office
NetBlazer.  It'd be nice to see this in a few X-Windows terminals, as well.
We'll see what the future brings for these product.

For more information, please feel free to e-mail or phone, I'm a TELEBIT
distributor, as well as an ex-Telebit (NetBlazer) employee.  (Sorry for
the salesy plug, but I do have this info and carry the products...;-).


===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Dec 90 11:34:00 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        cec@cup.portal.com  (Cerafin E Castillo)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP modem autodialing and idle line detection
While our SLIP version of PC/TCP has been around for a long time,
note that we are not yet shipping our PPP.  Xmas?

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 04:37:50 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In article <9389@ncar.ucar.edu>, davis@groucho.ucar.edu (Glenn P. Davis) writes:
>...[about TLI or Streams vs. Sockets]...


It would be really keen if someone could and would say something numeric
about the relative speed of TLI (ne XLI or whatever--any version more
recent than the one delivered to AT&T in 1986) compared to sockets
(any version from 4.2 to Reno and beyond).

Yes, this is my quarterly request for time-to-port-ttcp-from-sockets-to-tli
and/or performance-of-ttcp-over-tli numbers.


(TTCP is the most common TCP benchmark.  Most commonly used as well as most
commonly abused and perverted to generate marketing numbers, and most
commonly enhanced to do things the enhancer considers important.  Look
for the authorative source on brl.mil and more or less true copies many
other places, including sgi.com.)


Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Dec 90 14:47:12 -0500
From:      Bob Stewart <rlstewart@eng.xyplex.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help finding telenet software to perform ftp as remote
> I am currently using NCSA Telenet software (from Univ. of Illinois at urbana
> with a MacSE appletalk connected to a fastpath -> ethernet to Usenet
> I currently have to connect to a local Sun Workstation and ftp from there,
> then, ftp to my mac and send from the Sun to me, I would like to remove
> the middle step... ( I read a review in Macworld Jan 91, p. 207 on
> TCP/Connect II 1.0, has anyone used this?)
> How about a pd program like NSCA Telnet, (TCP/Connect is $495!!)
> Thanks, Brent Schorsch (schorsch@oxy.edu)

I'm writing this reply from TCP/Connect II.  Overall I like it, but it needs
at least one more maturing release.  I haven't completely switched over to
TCP/Connect for mail, as it is a bit less optimized than GNU Emacs for that
purpose.  For Telnet connections and FTP in and out of the Macintosh, it's
pretty good.  Mostly I use it for access to the Unix system that is my primary
access to the Internet.

TCP/Connect II has a lot more features than NCSA Telnet, such as FTP client
capability, 3270 emulation (which I haven't tried), and even an SNMP agent.
Even if all you want is Telnet, TCP/Connect's terminal emulator is improved
over NCSA's.

	Bob

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 10:41:35 GMT
From:      julius.cs.uiuc.edu!ux1.cso.uiuc.edu!krol@apple.com  (Ed Krol)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP down scaling (linear or what) ?
Just remember that as the link speed decreases the IP (and presumably)
TCP headers take up a greater percentage of the available bandwidth.
Leaving less room for real data.  (At a link speed of about 500 baud
you have just enough bandwidth to send TCP IP headers and do HDLC
bitstuffing - sorry no room for data)
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 7 Dec 90 13:34:34 GMT
From:      Sean Mc grath <sean@fiamass.ie>
To:        tcp-ip@nic.ddn.mil
Cc:        sean@fiamass.ie
Subject:   NDIS spec.
I have only recently heard of a new software interface specification for
   network cards in PC's called NDIS.  3COM tell me that their TCP/IP uses
   it.  Has anyone out their anymore details about NDIS?

   Thanks In Advance,
   Sean Mc Grath (sean@fiamass.ie)
   Fiamass Ireland Ltd.
   12 Clarinda Park North
   Dun Loaghaire
   Co. Dublin.
   Ireland.


-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 16:13:42 GMT
From:      sci34hub!gary@uunet.uu.net  (Gary Heston)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none)
In article <9012021338.AA04769@uunet.UU.NET> root%shiva@SHAKTI.ERNET.IN writes:
>Subject: humanitarian request

Which has no place in this newsgroup.

>We would appreciate your responding to the request of Craig Shergold who
>is a seven year old boy with an inoperable tumor on his brain.

NO! NOT AGAIN! The Craig Shergold Worm has returned!

DON'T send cards; they're immediately sold as scrap paper. Donate the cost
of a card and postage to your local Red Cross or something...

> [ usual plea deleted ]
>PS - I apologize for the possible redundancy of posting this net-wide. I
>     hope everyone can understand the necessity/urgency of the situation.

Apology REFUSED! This has been posted and reposted too many times; it is
NOT a valid request any more (and hasn't been for a year or so). DON'T
POST ANY MORE OF THESE, ANYWHERE OFF YOUR SITE. And, after looking at the
Newsgroups: line, if it turns out you posted individual copies to multiple
newsgroups instead of at lease having the sense to crosspost, you'll get 
an individual flame (from me, at least) for each one I find. What a waste
of bandwidth this has become!

-- 
Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or
My opinions, not theirs.  SCI Systems, Inc.     gary@sci34hub.sci.com
  The sysadmin sees all, knows all, and doesn't tell the boss who's
  updating their resumes....  This .sig Copyright G. L. Heston, 1990
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 16:51:52 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   Can a receiving application change window size?

I have been under the impression that the window presented by a TCP receiver is
tied to the amount of socket buffer available.  Thus, if I setsockopt() and
change the socket receive buffer size, I would note a change in the size of
the receive window.  Unfortunately, after looking at some ethernet traces, I
have found this not to be the case.  I have looked (briefly and without a lot
of comprehension) at the BSD4.3 (Ultrix flavored) source and it sure looked like
the receive window was tied to the size of the socket buffer. But the window
presented by our vax is always 4K, even when I set a receive buffer size of
32K.

So my question is:

Is there any way for an application (who wishes to receive data) to increase
the window presented to the sender?

Many thanks in advance,
mb
booloo@lll-crg.llnl.gov

btw, I had previously asked how it was possible for bind() to return EADDRINUSE
once SO_REUSEADDR had been set on a socket.  Unfortunately, nobody has been able
to provide (what I consider to be) a satisfactory answer.  I'd still really like
to know...
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 16:56:56 GMT
From:      usc!samsung!noose.ecn.purdue.edu!sparkyfs.erg.sri.com!davy@apple.com  (David Curry)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for copy of 12/5/90 gov't computer security report...
In article <901206092226.18e2@SSCNET.SSC.GOV> JAFFE@SSCNET.SSC.GOV writes:
>
>Does anyone know where I can obtain a copy of the computer security report 
>presented in Washington D.C. on 12/5/90?
>
>Thanks in advance.
>
>Mike Jaffe
>Superconducting Super Collider Laboratory


Call the National Academy Press (the publishing arm of the National
Research Council, National Academy of Sciences, etc.) at

	1-800-624-6242

The publication is entitled "Computers at Risk".  It's $19.95 plus
$2.00 shipping.  They'll take credit cards over the phone, or you
can send a check or purchase order.

I just ordered mine; they say the book will be in Wednesday (12/12)
and will ship UPS ground.

Dave Curry
SRI International
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 17:05:01 GMT
From:      bcstec!voodoo!voodoo.voodoo.uucp@uunet.uu.net  (howie)
To:        tcp-ip@nic.ddn.mil
Subject:   New Comer Book
I see there's a Second Edition of Comer's Internetworking book out.


Anybody know if it's worth buying if the First Edition is already owned?


How about an upgrade kit from Prentice-Hall?  :)
--
				       howie              

				       uunet!bcstec!voodoo!howie
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 17:23:24 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!ultra!wayne@ucsd.edu  (Wayne Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD sockets question
Sorry to bother the TCP/IP group with a BSD-sockets-specific question, 
but it really does relate to protocol behavior.

Anyway, my question is the following:  For connected stream sockets,
are there ANY semantic differences between shutdown(2) and close()?
If so, can somebody please explain them?  (For example, if multiple
processes are sharing a connected socket, only the LAST close() will
have an effect; is this true with shutdown(2)?  Is "data in the pipe"
treated any differently?  Etc ...)

Oh, when I say "shutdown(2)" I mean the shutdown() system call with
a "how" parameter of "2," meaning shutdown both read and write; I am
NOT alluding to section 2 of the manual.

Thanks muchly!

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!

PS:  For that matter, can anybody explain what shutdown does with a
     connected DATAGRAM socket?  Thnx again.
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 17:40:48 GMT
From:      karl@naitc.naitc.com (Karl Denninger)
To:        comp.protocols.ibm,comp.syprotocols.tcp-ip
Subject:   Gateway between SNA and TCP hosts; any solutions that WORK?

Hi Usenet.oracle.

We're experiencing no end of difficulty with our Mitek "Open Connect"
server.  It simply won't work through a port contention unit; it drops
connections with a surprising amount of repeatability.

Mitek has been unable to correct the problem after repeated attempts.  They
claim to be continuing to work on it, but we're out of patience and time.

Is there anyone out there who has a SNA <> TCP/IP gateway that can do the
following:

1)	Support TN3270-style connections
2)	Looks like a 3174-type controller
3)	Handles 64 or more LUs
4)	WORKS RELIABLY with a port contender on a 56KB leased line

5)	Runs on either a dedicated machine or will operate on one of:
	a)	Sun Sparcstation
	b)	ISC (Interactive 2.2) 386 Unix 
	c)	MIPS Magnum

Ideally, we would also like an X-window client that can handle 3278/3279
emulation with GDDM graphics capability.  Right now, though, we'll settle
for much less - like a working gateway!

Note that the client software has to be good -- we need support specifically
for Write Structured Field calls.  We also need support for IND$FILE
file transfer in both directions.

Any help appreciated.  I've tried LYNX and MIPS directly so far, with no
luck at all.  Any other ideas? 

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 20:41:53 GMT
From:      bbs!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Netbios .vs. encapsulated Netbios; any gates?
Hello again net.oracle!

We have encapsulated Netbios capability on our PCs right now... we are
looking for a way to convert NBP to TCP/IP-encapsulated NETBIOS, and 
the reverse?

We have a couple of programs which want to see NBP Netbios packets on the
LAN.  Specifically, a 3270-gateway product.  Our TCP/IP can encapsulate
Netbios, but the gateway runs a dedicated OS and we can't get in there to
replace the protocol stack with something that can understand this.

Any ideas?  We understand it will double Netbios traffic; that's acceptable.

--
--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 21:47:52 GMT
From:      ncrlnk!ncrstp!npdiss1!mercer@uunet.uu.net  (Dan Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none) (Really,  it's the get-well card scam again)
In article <9012021343.AA05169@uunet.UU.NET> root%shiva@SHAKTI.ERNET.IN writes:
:To: shakti!nic.ddn.mil!tcp-ip
:
:Dear NetFolks,
:
:We would appreciate your responding to the request of Craig Shergold who
:is a seven year old boy with an inoperable tumor on his brain.
:
:He has not been given a very long time to live and it is Craig's ambition
:to enter the Guiness Book of World Records for the largest number of get
:well cards ever received by an individual.
:
:Please send your card to:
:
:     Craig Shergold
:     % Children's Make-A-Wish Foundation
:     32 Parimeter Center East
:     Atlanta, Georgia 30346
:
:
:               -------------------------------------
:
:Letters similar to this have been sent out by traditional mail to large
:organizations all across the U.S. on Craigs behalf. Instead of passing
:it on by land-mail, I thought the net would be a great way of getting 
:the word out to as many people as possible in as short a time as possible.
:
:Please pitch-in & send Craig a get well card, and by all means feel free
:to circulate this letter to local businesses/organizations, or other
:BBS's you may belong to. All your help and effort will certainly be 
:appreciated! Thank you.
:
:                                      Sincerely,
:                                                Jack Petrino          
:                              
:                              
:----------------------------------------------------------------------
:       Jack Petrino (DRAGON)        int: PETRINO@KUHUB.CC.UKANS.EDU         
:       Systems Testing              bit:     PETRINO@UKANVAX
:       University of Kansas         vox:      (913)864-0443          
:       Computer Center              fax:      (913)864-0485    
:-----------------------------------------------------------------------
:
:PS - I apologize for the possible redundancy of posting this net-wide. I
:     hope everyone can understand the necessity/urgency of the situation.

I've got a better idea.   Let's all send Jack a get well card.  I'm
sure he'll be needing one after all the third degree flamings he's
going to get.  Isn't there anyway we can put this puppy to sleep for
good?

-- 
Dan Mercer
NCR Network Products Division      -        Network Integration Services
Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 21:53:58 GMT
From:      snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!ub!tksjmi@bloom-beacon.mit.edu  (JoAnn Illuzzi)
To:        tcp-ip@nic.ddn.mil
Subject:   fax data over ip anyone?

 Anyone using tcpip protocols to transfer fax data?  Is anyone developing
 a device that can fax on one interface, then transport via tcpip out
 the other device interface?

 JoAnn Illuzzi
 University of Buffalo Technical Services
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Dec 90 23:15:02 GMT
From:      swrinde!elroy.jpl.nasa.gov!jpl-devvax!jato!sesun!jaw@ucsd.edu  (Joe Wieclawek)
To:        tcp-ip@nic.ddn.mil
Subject:   Interoperability?
We must be doing something wrong.

This was in December 3,1990 Network World, Volume7,Number 49 "The
Newsweekly of User Networking Strategies":

Article on page 1: "MAP/TOP group charts new course" by Ellen
Messmer
(paragraph 12)
	Bride* said a network manager interconnecting a large
multivendor TCP/IP installation will discover that vendors
have implemented TCP/IP differently and interoperability
is unattainable. "You can"t build a national and international
network using TCP/IP," Bride said.

	* Laurie Bride, manager of network architecture at
Boeing Computer Services Co.


Joe Wieclawek                   jaw@sesun.Jpl.Nasa.Gov
Jet Propulsion Laboratory       Mail stop: 602-145
4800 Oak Grove Drive            Office: (818)354-2419   FTS: 792-2419
Pasadena CA     91109           
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 00:27:41 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!hubcap!ncrcae!ncr-sd!se-sd!scottp@ucsd.edu  (Scott Platenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   TTCP wanted

  I recently saw reference to TTCP "the most common TCP benchmark" in 
another newsgroup.  I am interested in obtaining this if possible.  Can
anyone help?  Please email as I don't have ftp access :-(
Thanks,
Scott
scottp@se-sd.sandiego.ncr.com 
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 00:33:40 GMT
From:      hpda!hpcupt1!hpindwa!alp@ucbvax.Berkeley.EDU  (Arnold Patton)
To:        tcp-ip@nic.ddn.mil
Subject:   Questions on TCP shutdown and RFC-793

I have two questions concerning the implementation of TCP and the
interpretation of RFC-793, specifically concerning connection
shutdown.

Question #1:

In step 8, on page 75, RFC-793 states that:

  "If the FIN bit is set, signal the user 'connection closing' and
   return any pending RECEIVEs with same message, advance RCV.NXT
   over the FIN, and send an acknowledgment for the FIN.  Note that
   FIN implies PUSH for any segment text not yet delivered to the
   user."

Notice that the RFC does not mention checking the current RCV.NXT
value against the FIN sequence number.  If one were to interpret this
literally, then it would seem that one would accept the FIN and change
states even if there were still holes in the TCP reassembly queue due
to lost or dropped packets (assuming that we are doing the right thing
and not accepting only in-order packets).  If that is the intent of
the RFC, then the statement about PUSHing any text not yet delivered
is ambiguous or at least not detailed enough, since it is possible to
have data both before and after a hole in the reassembly queue.  Do we
push only the data before the hole?  Or do we push all the data and
ignore the hole?

It seems to me that this was not the intent of the RFC, and that the
assumption was being made that there would not be any holes in the
reassembly queue (which is normally the case) when the FIN is
received.  In my understanding, the FIN handshake was intended to
insure that all data has been received by both sides.  The "literal
interpretation" above would defeat this attribute of the FIN handshake.
I thought that perhaps HOSTS RFC (RFC 1122) had clarified RFC-793's
statement, but it does not.  In fact, when I checked a copy of the BSD
4.3 TCP code, it appears that they indeed accept the FIN no matter
what!  (However, I haven't tested the actual behavior of the code, and
I may have overlooked something.  It would be difficult to believe
that the BSD code would behave this way.)

Also, if you do not accept the FIN right away, what do you do with it?
Options seem to be either set some state vector or to drop the FIN
packet and to pick it up in a retransmission after your reassembly
queue has been filled.  The second option would cause a delay in
waiting for the retranmitted FIN, and has a potential danger in that
if the retransmitted FIN is dropped in between (say at a gateway), the
remote connection half may time out.  However, the first option also
has the preformance penalty of always needing to check against this
new state vector to see if we should accept the FIN now.

Does the standard really intend some sort of bizarre behavior here?
Or does someone know of a reference in the standards which clarifies
things?  What behavior do BSD SOCKETS and other ULPs based on TCP
expect?  Or have I missed the boat entirely and overlooked something
in RFC-793?

Question #2:

This question also regards TCP connection shutdown implementations.

I thought that I read somewhere (I thought it was HOSTS RFC) that if
you get a FIN without an ACK of FIN while you are in the FINWAIT1
state that you should reply with a FIN, ACK of FIN packet (not just
ACK of FIN as RFC-793 states), but I can no longer find the reference.

I can see why you might want to do this, but I think it would work either
way.

Was I just imagining things?  Or does someone know of such a reference?
If you could pass it on to me, it'd be much appreciated.

-------------------------------------------------------------------------------
 Arnold Lee Patton    | MPE/XL Networking Engineer | I wonder how much time is
 Hewlett-Packard  Co. | alp@hpindwa.cup.hp.com     | spent figuring out clever
                      |                            | notes for this space.
-------------------------------------------------------------------------------
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Sat, 8 Dec 1990 10:21:43 PST
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: New Comer book
The Second edition of Comer's book is much expanded compared to the
first. Also, a second *volume* dealing with implementation and programming
issues is due out soon. 

A review of the first of these (2nd edition, volume 1) can be found in
the January 1991 issue of ConneXions, also due out soon.

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 03:21:13 GMT
From:      sdd.hp.com!think.com!barmar@ucsd.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interoperability?
In article <1990Dec7.231502.27773@jato.jpl.nasa.gov> jaw@sesun.Jpl.Nasa.Gov (Joe Wieclawek) writes:
>	Bride* said ... "You can"t build a national and international
>network using TCP/IP," Bride said.

Whew, it's good she warned us before we tried implementing the MILnet, the
Arpanet, NSFnet, PSInet, ....
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 06:59:35 GMT
From:      agate!shelby!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!stiatl!srchtec!srchtec.uucp@ucbvax.Berkeley.EDU  (Michael Almond)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for Ultrix 4.1
Does anyone know of a SLIP implementation for Ultrix 4.1?  I found one
version called cslip, but it doesn't contain any code for dialing out.

The Ultrix slattach which comes unsupported core dumps (nil diagnostics).

Thanks.

---
Michael R. Almond (Georgia Tech Alumnus)           mra@srchtec.uucp (registered)
search technology, inc.				      mra%srchtec@salestech.com
4725 peachtree corners cir., suite 200		       emory!stiatl!srchtec!mra
norcross, georgia 30092					 (404) 441-1457 (office)
[search]: Systems Engineering Approaches to Research and Development
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 09:33:17 GMT
From:      snorkelwacker.mit.edu!think.com!samsung!sol.ctr.columbia.edu!emory!rsiatl!jgd@bloom-beacon.mit.edu  (John G. DeArmond)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: New Comer Book
howie@voodoo.voodoo.uucp (howie) writes:

>I see there's a Second Edition of Comer's Internetworking book out.
Yes indeed.

>Anybody know if it's worth buying if the First Edition is already owned?

Absolutely.  The data is current as of the first part of 1990.  He covers
the changes in the internet/nsfnet in a manner that those of us who 
don't make the net our profession can quickly assimilate.  Plus he
covers all the generally adopted improvements to IP up through the
middle of this year.

There is also an information coupon from Interop Inc. who sponsors Comer's 
seminars.  I've heard very good things about his 4 day implementor's 
course.  The Interop Contact numbers are 415 941 3399 ex 667 or fax 
415 949 1779.


>How about an upgrade kit from Prentice-Hall?  :)

Yep, but you can do it yourself.  Find someone with a casual interest
in TCP/IP and sell him Version 1 for about $25 or so.  Then buy the
new one.  Or just keep the old one so that when you have grandkids,
you can stroke your greybeard and cite the "bible" when telling those
"way back when I was a kid, we networked with tin cans and string" 
stories. :-)

john

>--
>				       howie              

>				       uunet!bcstec!voodoo!howie
-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      | "Vote early, Vote often"
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 11:52:13 GMT
From:      snorkelwacker.mit.edu!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@bloom-beacon.mit.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions on TCP shutdown and RFC-793

	If you check in the beginning of the "SEGMENT ARRIVES" section of
RFC 793, it says that they assume packets have already been sequenced in
proper order for the rest of it.
	Re: shutdown(2) in BSD implementations. It corresponds roughly to
the TCP ABORT function, but not quite. In particular, as the manual page
says, any buffered data pending will be dropped. It isn't really the
"half close" that RFC 793 wants, and it should only be used in programs
that are aborting or, because of mechanisms in the application protocol,
already know that the data has been delivered. It should *not* be used for
applications that have done writes and just want to mark the end of data for
the peer, since any data still pending in the local send buffers is discarded
and never delivered.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Dec 90 14:20:26 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!fallst!tkevans@tut.cis.ohio-state.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   VAX 11/750 as Internet Gateway?
Looking for a low-cost way to connect to the Internet, it occurs
that a spare VAX 11/750 running 4.2BSD might be used as a gateway.
Can anyone comment on whether/how well this might work?  I think
I understand that BIND might not work without a lot of recompiling,
but presumably I could run the resolver on another machine in the
local network.  What else?

I will summarize if there's interest.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Dec 90 00:20:29 EST
From:      enger@seka.scc.com (Robert M. Enger)
To:        tcp-ip@nic.ddn.mil, usc!samsung!noose.ecn.purdue.edu!sparkyfs.erg.sri.com!davy@apple.com
Subject:   Re: Looking for copy of 12/5/90 gov't computer security report...

Does anyone else find it discouraging that the gov't computer security report
can't be obtained on-line across the gov't sponsored computer network?

Bob Enger
Contel Federal Systems
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Sun, 9 Dec 90 15:20:40 EST
From:      enger@seka.scc.com (Robert M. Enger)
To:        jaw@sesun.Jpl.Nasa.Gov, tcp-ip@nic.ddn.mil
Subject:   Re:  Interoperability?  (MAP/TOP must include DRUG use!)


"You can"t build a national and international
network using TCP/IP," Bride said.

From the Namedroppers e-mail list:


----- Begin Included Message -----

From namedroppers-RELAY@NIC.DDN.MIL Sat Dec  8 07:11:06 1990
Return-Path: <namedroppers-RELAY@NIC.DDN.MIL>
Received: from sccgate.scc.com by seka.scc.com (4.1/SMI-4.1)
	id AA09250; Sat, 8 Dec 90 07:11:04 EST
Received: from NIC.DDN.MIL by sccgate.scc.com (5.61/1.34)
	id AA09082; Sat, 8 Dec 90 07:03:43 -0500
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 8 Dec 90 03:37:49 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA21970; Sat, 8 Dec 90 03:33:40 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for namedroppers@nic.ddn.mil (namedroppers@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 8 Dec 90 02:36:58 GMT
From: uvaarpa!murdoch!murdoch.acc.virginia.edu!dwells@mcnc.org  (Don Wells)
Organization: National Radio Astronomy Observatory, Charlottesville, VA
Subject: 26 Countries now
Message-Id: <DWELLS.90Dec7213658@fits.cx.nrao.edu>
Sender: namedroppers-relay@nic.ddn.mil
To: namedroppers@nic.ddn.mil
Status: RO


       =-=-= The Research Internet as of 07 December 1990 =-=-=

The count is now 26 countries (up from 24):

Continents:	IP_connected Countries:
----------	----------------------

Asia:		IL, IN, JP, KR 

Australasia:	AU, NZ

Europe:		AT, BE_[4], CH, DE, DK, ES_[5], FI, FR, GR, IS, IT, 
		NL, NO, SE, UK 

North_America:	CA, MX, US (includes Hawaii and Puerto_Rico)

South_America:	AR, CL_[6] 

		  =-=-= Notes =-=-=

[1] I count only those countries whose connectivity I have confirmed
with a ping and a TELNET operation. I choose to count only the
research portions of the Internet, not the private corporate IP nets
or military IP nets. If either of the latter two categories were
included the country count would be increased.

[2] An item on p.12 of the 26_November issue of COMPUTERWORLD, under
the title "Casting a wide-reaching Internet", begins: "Internet is a
loosely coupled network of networks --- approximately 5,000 of them in
35 countries serving more than 3 million users." I would like to know
who told the magazine the number "35", and which countries are in that
list. Also, the numbers "5,000" and "3 million" are somewhat higher
than I would have guessed.

[3] Inclusion of certain islands (e.g., NZ, IS, Puerto_Rico) in the
"continent" lists is somewhat arbitrary.

[4] Katholieke Universiteit Leuven is now connected. I have been told
that the SOA for the Belgium [BE] domain is likely to be moved to a
host in the KULEUVEN.BE domain soon.

[5] Spain [ES] is now well connected, and its nameservers advertise
subdomains UPM.ES, IRIS-DCP.ES, CIEMAT.ES, US.ES, FUNDESCO.ES, CICA.ES
and ARTIX.ES. (NOTE: The SOA for ES is still seismo.css.gov in the US,
but mcsun.eu.net says SOA for ES is sun.iris-dcp.es.)

[6] The host in question is physically in Chile, but its name is in
the EDU domain.

		 =-=-= Anticipated Connectivity =-=-=

I have been informed that:

	* Brazil (BR) already has one IP circuit; another is expected.
	* Ireland (IE) is expected to connect soon.
	* Portugal (PT) is expected to connect soon.
	* Hong Kong (HK) is expected to connect soon.
	* Antartica (?? :-) ) is expected to connect soon.
	* South Africa (ZA) is likely to connect within a year.

I would appreciate being told of any connected IP address in Brazil. I
would appreciate hearing of any other countries that are either
IP_connected, or that expect to be IP_connected "soon".

--

Donald C. Wells, Assoc. Scientist  |        dwells@nrao.edu
Nat. Radio Astronomy Observatory   |         6654::DWELLS
Edgemont Road                      | +1-804-296-0277      38:02.2N
Charlottesville, VA 22903-2475 USA | +1-804-296-0278(Fax) 78:31.1W


----- End Included Message -----

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 90 18:57:54 GMT
From:      pathak@MBUNIX.MITRE.ORG  (Pathak)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP book recommendations


Internetworking with TCP/IP by Douglas Comer.  

IMHO the book is a must for anyone doing anything with TCP/IP.  

Heeren Pathak
pathak@mitre.org
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 90 19:16:34 GMT
From:      usc!samsung!sol.ctr.columbia.edu!ira.uka.de!smurf!wrkof!dksoft!dirk@apple.com  (Dirk Koeppen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP using Arcnet boards on UNIX ?
Is there any vendor which supports Arcnet boards on his
386 based UNIX TCP/IP port ?

Thanks,
dirk
-- 
..............							  .............
...........							     ..........
........  Dirk Koeppen - Holzwiesenweg 22 - D-6050 Offenbach - Germany  .......
.....  Phone: +49 69 89 3000 - FAX: +49 69 89 3004 - uucp: dirk@incom.de  .....
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 90 19:44:32 GMT
From:      news@ncsuvx.ncsu.edu  (Daniel L'Hommedieu)
To:        tcp-ip@nic.ddn.mil
Subject:   Unix to DOS
Hello, netlanders.  I hope I've got a simple request.  I'm trying to
hook up my DOS machine via a 19.2 KBaud link, through a terminal server,
to a MicroVAX 3300 by SLIP.  I would like to open up FTP to the DOS
machine, and I would like to be able to FTP or telnet from the DOS
machine, as well as receive and send mail from the DOS machine.
I am having trouble locating a version of SLIP for Ultrix 3.1 or Ultrix
4.0.  Can anyone please point me in the right direction? 

What do I need to have running on the MicroVAX to start up SLIP?  I know
I need to have a dedicated tty to the machine, and I'm working on that
now.  Does anyone have a recommendation for SLIP software for DOS?
Thanks in advance for all help. 
 
--
Daniel C. L'Hommedieu III             Internet:  eagle@catt.ncsu.edu
Prodigy ID: BCCJ33D                             dclhomm@eos.ncsu.edu
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Dec 90 23:42:08 GMT
From:      bbn.com!craig@eddie.mit.edu  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SIGCOMM '90 Proceedings
In article <9012052255.AA16387@liberty.phx.mcd.mot.com> chiang@phx.mcd.mot.com (Mei-Ling Chiang) writes:
>
>I would like to have a copy of SIGCOMM '90 Proceedings.  Can yoy
>send me a copy.  If you do not have, please let me know where I can 
>get one.   Thanks for your help.

SIGCOMM proceedings can be ordered from the ACM.  Call their order number
at +1 301-528-4261 (in the US, outside Maryland and Alaska, call
1-800-342-6626).  The SIGCOMM '90  proceedings are order number 533900.

Craig Partridge
Editor, SIGCOMM Computer Communication Review
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 05:25 CDT
From:      "Kevin W. Mullet, Univ. of N. Tx" <SNMS4@vaxb.acs.unt.edu>
To:        cisco@spot.colorado.edu, protocols@rutgers.edu, tcp-ip@nic.ddn.mil, pcip@udel.edu
Subject:   Summary: IP Routing Documents
A couple of weeks ago, I was prompted by an offhanded comment by our VAX
manager that IP routing was probably over my head to try and find as many
sources for IP routing information as I could and live/eat/breathe IP routing
for a time, indignantly I might add.  :)

After posting a query to a number of newsgroups and mailing lists, I've got a
good start on this path and have once again affirmed my belief that nothing is
over anyone's head as long as you can reduce it to an appropriate metaphor.

Below is a representative sample of the replies I got.  These documents should
be available to anyone who gets this note.  Internet folks can FTP directly,
BITNET folks will have to use BITFTP.  Thanks to all who replied.  I appreciate
each of the replies I got, even the one that sent me the entire RFC Index as an
attachment.  (Gads!)  :)
======= cut here =====================================================
From:	IN%"rlg@desktalkdesktalk.com" 26-NOV-1990 22:14:22.66

Hi Kevin,

Got your note from tcp-ip@nic.ddn.mil (along with a billion others from the
same place), and thought this might help.  Here is a copy of the RFC index.

Check it out for RFCs on Routing Information Protocol (1058 I think),
Open Shortest Path First (OSPF), End System-Intermediate System (ES-IS).

From:	IN%"MH@NIC.DDN.MIL"  "Mark Hamamoto" 28-NOV-1990 13:31:59.55

Network Working Group                                J. Mogul (Stanford)
Request for Comments: 950                                J. Postel (ISI)
                                                             August 1985

                 Internet Standard Subnetting Procedure

[RFC followed . . . ]

From:	IN%"root@rainbow.cse.nau.edu" 29-NOV-1990 09:46:08.08

There's a good document describing RIP routing, which is what the
"routed" daemon uses.  RIP is too simple / small to use on the Internet,
but many sites still use it within their local network.  Other routing
protocols you should look at include IGRP, invented by cisco Systems,
and used in some areas on the Internet, if I understand correctly.

You can ftp a copy of "rip.txt" document from spot.colorado.edu,
in the "pub" directory.  It's good information, and easier to read
than RFCs.
                                                -- paul

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 09:42:50 PST
From:      postel@venera.isi.edu
To:        gkunis@boeing.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Boeing and Internet
Gary:

Can you forward this to Laurie Bride?

--jon.

----- Begin Included Message -----
From tcp-ip-RELAY@NIC.DDN.MIL Fri Dec  7 20:09:39 1990
Date: 7 Dec 90 23:15:02 GMT
From: swrinde!elroy.jpl.nasa.gov!jpl-devvax!jato!sesun!jaw@ucsd.edu  (Joe Wieclawek)
Subject: Interoperability?
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

We must be doing something wrong.

This was in December 3,1990 Network World, Volume7,Number 49 "The
Newsweekly of User Networking Strategies":

Article on page 1: "MAP/TOP group charts new course" by Ellen
Messmer
(paragraph 12)
	Bride* said a network manager interconnecting a large
multivendor TCP/IP installation will discover that vendors
have implemented TCP/IP differently and interoperability
is unattainable. "You can"t build a national and international
network using TCP/IP," Bride said.

	* Laurie Bride, manager of network architecture at
Boeing Computer Services Co.


Joe Wieclawek                   jaw@sesun.Jpl.Nasa.Gov
Jet Propulsion Laboratory       Mail stop: 602-145
4800 Oak Grove Drive            Office: (818)354-2419   FTS: 792-2419
Pasadena CA     91109           


----- End Included Message -----
----- Begin Included Message -----

From namedroppers-RELAY@NIC.DDN.MIL Sat Dec  8 03:57:48 1990
Date: 8 Dec 90 02:36:58 GMT
From: uvaarpa!murdoch!murdoch.acc.virginia.edu!dwells@mcnc.org (Don Wells)
Subject: 26 Countries now
Sender: namedroppers-relay@nic.ddn.mil
To: namedroppers@nic.ddn.mil


       =-=-= The Research Internet as of 07 December 1990 =-=-=

The count is now 26 countries (up from 24):

Continents:	IP_connected Countries:
----------	----------------------

Asia:		IL, IN, JP, KR 

Australasia:	AU, NZ

Europe:		AT, BE_[4], CH, DE, DK, ES_[5], FI, FR, GR, IS, IT, 
		NL, NO, SE, UK 

North_America:	CA, MX, US (includes Hawaii and Puerto_Rico)

South_America:	AR, CL_[6] 

		  =-=-= Notes =-=-=

[1] I count only those countries whose connectivity I have confirmed
with a ping and a TELNET operation. I choose to count only the
research portions of the Internet, not the private corporate IP nets
or military IP nets. If either of the latter two categories were
included the country count would be increased.

[2] An item on p.12 of the 26_November issue of COMPUTERWORLD, under
the title "Casting a wide-reaching Internet", begins: "Internet is a
loosely coupled network of networks --- approximately 5,000 of them in
35 countries serving more than 3 million users." I would like to know
who told the magazine the number "35", and which countries are in that
list. Also, the numbers "5,000" and "3 million" are somewhat higher
than I would have guessed.

[3] Inclusion of certain islands (e.g., NZ, IS, Puerto_Rico) in the
"continent" lists is somewhat arbitrary.

[4] Katholieke Universiteit Leuven is now connected. I have been told
that the SOA for the Belgium [BE] domain is likely to be moved to a
host in the KULEUVEN.BE domain soon.

[5] Spain [ES] is now well connected, and its nameservers advertise
subdomains UPM.ES, IRIS-DCP.ES, CIEMAT.ES, US.ES, FUNDESCO.ES, CICA.ES
and ARTIX.ES. (NOTE: The SOA for ES is still seismo.css.gov in the US,
but mcsun.eu.net says SOA for ES is sun.iris-dcp.es.)

[6] The host in question is physically in Chile, but its name is in
the EDU domain.

		 =-=-= Anticipated Connectivity =-=-=

I have been informed that:

	* Brazil (BR) already has one IP circuit; another is expected.
	* Ireland (IE) is expected to connect soon.
	* Portugal (PT) is expected to connect soon.
	* Hong Kong (HK) is expected to connect soon.
	* Antartica (?? :-) ) is expected to connect soon.
	* South Africa (ZA) is likely to connect within a year.

I would appreciate being told of any connected IP address in Brazil. I
would appreciate hearing of any other countries that are either
IP_connected, or that expect to be IP_connected "soon".

--

Donald C. Wells, Assoc. Scientist  |        dwells@nrao.edu
Nat. Radio Astronomy Observatory   |         6654::DWELLS
Edgemont Road                      | +1-804-296-0277      38:02.2N
Charlottesville, VA 22903-2475 USA | +1-804-296-0278(Fax) 78:31.1W


----- End Included Message -----

Boeing Corporation (BOEING-DOM)
   Seattle, WA 98124-2499
 
   Domain Name: BOEING.COM

   Administrative Contact, Technical Contact, Zone Contact:
      Kunis, Gary  (GK44)  gkunis@BOEING.COM
      (206) 865-7044

   Record last updated on 23-Oct-90.

   Domain servers in listed order:

   NSGENG.NWNET.NET             130.42.101.98
   NWNAME.BOEING.COM            130.42.93.102
   HANDIES.UCAR.EDU             128.117.64.4
   HANNA.CAC.WASHINGTON.EDU     128.95.120.1
   AKBAR.CAC.WASHINGTON.EDU     128.95.112.1


To see this host record with registered users, repeat the command with
a star ('*') before the name; or, use '%' to show JUST the registered users.
postel 306% 
[No name] (BOEING)		ATC.BOEING.COM			  130.42.28.80
Boeing Advanced Systems Facilities (NET-BOE-AS-NET) BOE-AS-NET 132.224.000.000
Boeing Advanced Systems Facilities (NET-BOE-KSC-NET) BOE-KSC-NET
							       134.072.000.000
Boeing Aerospace Coporation (NET-BOE-AE-NETS) BOEING-AE	       192.065.099.000
Boeing Aerospace Corporation (NET-BAC-NET) BAC-NET	       128.166.000.000
Boeing Aerospace Corporation (NET-BOEING-BCAR-NETS) BOEING-BC-APRING
							       192.048.000.000
Boeing Aerospace Corporation (NET-BOEING-BCAR-NETS1) BOEING-BCAR
							       192.054.000.000
Boeing Computer Services (NET-BE-NET) BE-NET		       130.076.000.000
Boeing Computer Services (NET-BOE-AUB-NET) BOE-AUB-NET	       136.203.000.000
Boeing Computer Services (NET-BOE-KSCE-NET) BOE-KSCE-NET       137.136.000.000
Boeing Computer Services (NET-BOE-REN-NET) BOE-REN-NET	       136.202.000.000
Boeing Computer Services (NET-BOE-SREN-NET) BOE-SREN-NET       137.137.000.000
Boeing Computer Services (NET-BOEING) BOEING-BNETS	       136.240.000.000
Boeing Computer Services (NET-BOEING-ATC) BOEING-ATC	       192.031.005.000
Boeing Computer Services (NET-BOEING-LOCALNETS)	BOEING-LOCALNETS
							       192.033.037.000
Boeing Computer Services (NET-BOEING-NETS) BOEING-NETS	       130.001.000.000
Boeing Computer Services (NET-BOEING-PSN) BOEING-PSN	       128.207.000.000
Boeing Computer Services (NET-BOEING747NET) BOEING747NET       130.121.000.000
Boeing Computer Services (NET-BOEINGAERO) BOEINGAERO	       130.122.000.000
Boeing Computer Services (NET-BOENSG-NETS) BOENSG-NETS	       192.042.009.000
Boeing Computer Services (NET-BOERESNET) BOERESNET	       130.042.000.000
Boeing Computer Services (NET-DOERLNET)	DOERLNET	       130.097.000.000
Boeing Computer Services (NET-DOERLNET2) DOERLNET2	       132.191.000.000
Boeing Computer Services (NET-NORTHWESTNET) NORTHWESTNET       192.031.173.000
Boeing Computer Services (NET-NWNET3) NWNET3		       192.035.180.000
Boeing Computer Services (NET-PEACE-SHBLOCK) PEACE-SHBLOCK     192.076.187.000
Boeing Computer Support Services (NET-PSCI-BLOCK) PSCI-NETS1   192.067.119.000
Boeing Computer Support Services (NET-PSCI-NETS) PSCI-NETS     192.067.107.000
Boeing Computer Support Services (NET-PSCI1-NET) PSCIK1-NET    192.067.118.000
Boeing Computer Support Services (NET-PSCNI-NET-1) JSC-SSE-46  192.055.199.000
Boeing Computer Support Services (NET-PSCNI-NETS) JSC-SSE-1    192.058.019.000
Boeing Corporation (BOEING-DOM)					    BOEING.COM
Boeing Corporation (NET-BOE-GIS)BOE-GIS			       134.052.000.000
Boeing Corporation (NET-BOEING-EN) BOEING-EN		       128.225.000.000
Boeing Military Aircraft Facility (NET-BMA1) BMA-1	       192.042.207.000
Boeing Military Aircraft Facility (NET-BMA10) BMA-10	       192.042.216.000
Boeing Military Aircraft Facility (NET-BMA11) BMA-11	       192.042.217.000
Boeing Military Aircraft Facility (NET-BMA12) BMA-12	       192.042.218.000
Boeing Military Aircraft Facility (NET-BMA13) BMA-13	       192.042.219.000
Boeing Military Aircraft Facility (NET-BMA14) BMA-14	       192.042.220.000
Boeing Military Aircraft Facility (NET-BMA15) BMA-15	       192.042.221.000
Boeing Military Aircraft Facility (NET-BMA16) BMA-16	       192.042.222.000
Boeing Military Aircraft Facility (NET-BMA17) BMA-17	       192.042.223.000
Boeing Military Aircraft Facility (NET-BMA18) BMA-18	       192.042.224.000
Boeing Military Aircraft Facility (NET-BMA19) BMA-19	       192.042.225.000
Boeing Military Aircraft Facility (NET-BMA2) BMA-2	       192.042.208.000
Boeing Military Aircraft Facility (NET-BMA20) BMA-20	       192.042.226.000
Boeing Military Aircraft Facility (NET-BMA21) BMA-21	       192.042.227.000
Boeing Military Aircraft Facility (NET-BMA22) BMA-22	       192.042.228.000
Boeing Military Aircraft Facility (NET-BMA23) BMA-23	       192.042.229.000
Boeing Military Aircraft Facility (NET-BMA24) BMA-24	       192.042.230.000
Boeing Military Aircraft Facility (NET-BMA25) BMA-25	       192.042.231.000
Boeing Military Aircraft Facility (NET-BMA26) BMA-26	       192.042.232.000
Boeing Military Aircraft Facility (NET-BMA27) BMA-27	       192.042.233.000
Boeing Military Aircraft Facility (NET-BMA28) BMA-28	       192.042.234.000
Boeing Military Aircraft Facility (NET-BMA29) BMA-29	       192.042.235.000
Boeing Military Aircraft Facility (NET-BMA3) BMA-3	       192.042.209.000
Boeing Military Aircraft Facility (NET-BMA30) BMA-30	       192.042.236.000
Boeing Military Aircraft Facility (NET-BMA4) BMA-4	       192.042.210.000
Boeing Military Aircraft Facility (NET-BMA5) BMA-5	       192.042.211.000
Boeing Military Aircraft Facility (NET-BMA6) BMA-6	       192.042.212.000
Boeing Military Aircraft Facility (NET-BMA7) BMA-7	       192.042.213.000
Boeing Military Aircraft Facility (NET-BMA8) BMA-8	       192.042.214.000
Boeing Military Aircraft Facility (NET-BMA9) BMA-9	       192.042.215.000
Boeing Military Aircraft Facility (NET-BOE-MIL)	BOE-MIL	       134.051.000.000
Boeing Military Aircraft (NET-BOE) BOE-TRANS		       130.247.000.000

To single out one record, look it up with "!xxx", where xxx is the
handle, shown in parenthesis following the name, which comes first.
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 03:12:48 GMT
From:      kramden.acf.nyu.edu!brnstnd@nyu.edu  (Dan Bernstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sockets, TLI, or what
In article <9389@ncar.ucar.edu> davis@groucho.ucar.edu (Glenn P. Davis) writes:
  [ use sockets or TLI? ]

You could ftp pub/flat/inet-socketstream from stealth.acf.nyu.edu to get
the archive of the last discussion we had on the topic.

---Dan
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 15:13:23 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        sean@fiamass.ie, tcp-ip@nic.ddn.mil
Subject:   Re:  NDIS spec.
NDIS (Network Driver Interface Specification) is not a card
specification, but, as the name says, a driver specification.
The specification was written by Microsoft and 3Com, to provide,
like the packet driver, a common interface to many cards, which 
send packets to a single stack or demultiplex packets of different
types for two protocol stacks. Although Version 2.0.1 of the spec
came out about a year ago, most available drivers are still 1.0.1
based, and do not support unbinding. 

Both versions of the spec are available by anonymous ftp to vax.ftp.com.
A packet driver to ndis converter, for most software that will run on 
the packet driver to use an NDIS driver, is available also, under the
name "dis_pkt.dos."

Unlike packet drivers, most NDIS drivers are written by hardware
manufacturers, and are owned by those manufacturers. (As far as I
know, however, only Ungerman-Bass charges customers for their NDIS
driver.) They tend to be supported software.


Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 07:30:30 GMT
From:      cme!libes@uunet.uu.net  (Don Libes)
To:        tcp-ip@nic.ddn.mil
Subject:   Translating names/addresses to human-readable descriptions
In perusing our ftp logs, we are trying to figure out who some of the
hosts really are.

About 80% of the IP addresses are successfully mapped back to fully-
qualified domain names (FQDN) by ftpd.  We've found that connecting to
a host's smtp port often yields its name, too.  Between the two of
those, only 2 hosts in 1000 couldn't be mapped to a FQDN.

Unfortunately, some of the names aren't very descriptive.  We'd like
to be able to give a domain to some piece of software and have it tell
us what it is.  (I.e. "nist.gov" => "National Institute of Substandard
Technology, Gaithersburg, MD".)

The whois database at nic.ddn.mil is a start.  It knows all of the
subdomains in the .edu, .com and some other domains.  It seems most
knowledgeable about the .mil domain, returning information about even
subdomains within the subdomains of .mil.

On the other hand, it knows very little about the geographical
domains.  For example, it could tell us that .AT was Austria and .CA
was Canada, but it didn't seem to know subdomains within those.  It
could tell us the domain name servers for those domains, but none of
them run a whois service like nic.ddn.mil.

Is there some way to get this information, short of bothering the
human zone contact for a domain?

In the meantime, we've been translating FQDNs to IP numbers and then
asking the NIC what it knows about the net (i.e., "whois net 129.6.32").
In the case of non-US hosts, this is much more informative than a
domain query, yet it is much less informative than getting a real
answer to the domain question.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 14:47:36 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        ospwd@emoryu1.cc.emory.edu (Peter Day)
Cc:        tcp-ip@nic.ddn.mil, tech@lanslide.hls.com (S. E. Mailing List)
Subject:   Re: restricting internet access
Peter, we have a similar need to protect from both outgoing and incoming
packets.  We use a bridge (our own product 8033 in our case) and we program 
a static table of source addresses which are "authorized" to access the other
side.  Non authorized packets do not pass the threshold.  It is still possible 
for outside packets to wend their way into our private net, but since most
protocols require an answering packet at some point, this does not tend to
violate the access provisions.  With newer software, even this breach can
be rectified.

Bridges of this type can be obtained for less than $5K, and their performance
exceeds the needs of the channel.
> 
> We need to prevent anonymous Internet access which is currently
> possible from our Annex terminal servers and from microcomputers
> attached to the network. My thought is to only allow Internet access to
> computers on our campus which force a user to login.  Can we give the
> p4200 a list of the IP numbers of those nodes that would be allowed
> Internet access and have all other nodes on campus denied direct
> Internet access?  Is there a better way to accomplish this?
> 
> Thanks,
> Peter Day
> 
> Research and Planning, Information Technology Division,
> Uppergate House, Emory University, Atlanta, GA 30322 
> DOMAIN: ospwd@emoryu1.cc.emory.edu                      
> UUCP: gatech!emoryu1!ospwd       PHONE: +1 404 727-7678
> BITNET: ospwd@emoryu1            FAX:   +1 404 727-2599   
> AppleLink: ospwd@emoryu1.cc.emory.edu@dasnet#
> 


-- 
-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 09:47:58 GMT
From:      eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can a receiving application change window size?
In article <87439@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:

   btw, I had previously asked how it was possible for bind() to
   return EADDRINUSE once SO_REUSEADDR had been set on a socket.
   Unfortunately, nobody has been able to provide (what I consider to
   be) a satisfactory answer.  I'd still really like to know...

It seems, after discussing this with numerous people for a while
(whose names are unfortunately hidden in my mailbox at work, not here
at the U), that the rationale was to be able to find sockets that were
not in use, without adding a lot of overhead to the connect() call.
Instead, if a _port_ is in use when you do the bind() with port
specified, you get EADDRINUSE.  This doesn't make much sense in normal
TCP/IP ways, but the folks at Berkeley had this great idea about
security with rlogin (etc), so they demanded that the port number of
the caller be in the range 512-1024, i.e. within the privileged range
in their own systems.  Now, how to find an unused port in a specific
range?  Trial and error, basically.

The half-way right way to do it, however, is a system call specifying
the low end and the high end of the range you need.  The kernel knows
which ports are in use, and can give you a port in the range you
request.  The kernel can also ensure that you don't get a port which
has just recently beed closed unilaterally.

Finally, the truly _right_ solution is not to depend on port ranges at
all, rendering the whole stupid question moot.

I hope this has cleared things up a bit, although I would agree that
the rationale is utterly bogus, and doesn't make any sense, except in
the absence of rational design.  BSD = Bogus Software Design.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863	ISO 8859-1: [\] FXE FXE {|} fxe fxe
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 10:00:04 GMT
From:      eru!hagbard!sunic!nuug!ifi!enag@bloom-beacon.mit.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Translating names/addresses to human-readable descriptions
In article <8698@muffin.cme.nist.gov> libes@cme.nist.gov (Don Libes) writes:

   Unfortunately, some of the names aren't very descriptive.  We'd like
   to be able to give a domain to some piece of software and have it tell
   us what it is.  (I.e. "nist.gov" => "National Institute of Substandard
   Technology, Gaithersburg, MD".)

It's time to rehash the old TXT RR, again, I see.  It can be used for
this purpose; it can be used to present your ICBM address (longitude
and latitude); it can hold whatever you want it to hold.  It's real
neat, and totally underutilized.

To show how really neat it can be, you can put in a TXT RR for
cme.nist.gov, explaining what "CME" means, and another with the exact
location of the domain (if applicable).

People will immediately and intuitively see how useful this is, and do
the same thing _within_days_, so we could have some real, useful
information about hosts _everywhere_.  Or am I full of dreamstuff?

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863	ISO 8859-1: [\] FXE FXE {|} fxe fxe
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 10:25:00 GMT
From:      SNMS4@vaxb.acs.unt.edu ("Kevin W. Mullet, Univ. of N. Tx")
To:        comp.protocols.tcp-ip
Subject:   Summary: IP Routing Documents

A couple of weeks ago, I was prompted by an offhanded comment by our VAX
manager that IP routing was probably over my head to try and find as many
sources for IP routing information as I could and live/eat/breathe IP routing
for a time, indignantly I might add.  :)

After posting a query to a number of newsgroups and mailing lists, I've got a
good start on this path and have once again affirmed my belief that nothing is
over anyone's head as long as you can reduce it to an appropriate metaphor.

Below is a representative sample of the replies I got.  These documents should
be available to anyone who gets this note.  Internet folks can FTP directly,
BITNET folks will have to use BITFTP.  Thanks to all who replied.  I appreciate
each of the replies I got, even the one that sent me the entire RFC Index as an
attachment.  (Gads!)  :)
======= cut here =====================================================
 From:	IN%"rlg@desktalkdesktalk.com" 26-NOV-1990 22:14:22.66

Hi Kevin,

Got your note from tcp-ip@nic.ddn.mil (along with a billion others from the
same place), and thought this might help.  Here is a copy of the RFC index.

Check it out for RFCs on Routing Information Protocol (1058 I think),
Open Shortest Path First (OSPF), End System-Intermediate System (ES-IS).
 
From:	IN%"MH@NIC.DDN.MIL"  "Mark Hamamoto" 28-NOV-1990 13:31:59.55

Network Working Group                                J. Mogul (Stanford)
Request for Comments: 950                                J. Postel (ISI)
                                                             August 1985

                 Internet Standard Subnetting Procedure

[RFC followed . . . ]
 
From:	IN%"root@rainbow.cse.nau.edu" 29-NOV-1990 09:46:08.08

There's a good document describing RIP routing, which is what the
"routed" daemon uses.  RIP is too simple / small to use on the Internet,
but many sites still use it within their local network.  Other routing
protocols you should look at include IGRP, invented by cisco Systems,
and used in some areas on the Internet, if I understand correctly.

You can ftp a copy of "rip.txt" document from spot.colorado.edu,
in the "pub" directory.  It's good information, and easier to read
than RFCs.
                                                -- paul

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 18:31:17 CST
From:      slevy@poincare.geom.umn.edu
To:        erik@naggum.uu.no
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Translating names/addresses to human-readable descriptions
Erik Naggum <erik@naggum.uu.no> wrote:
> ... To show how really neat it can be, you can put in a TXT RR for
> cme.nist.gov, explaining what "CME" means, and another with the exact
> location of the domain (if applicable). ...

Beware: the TXT RR is unknown to the BIND 4.8 server, which is still
pretty widespread.  It may be unknown to some later versions too, I haven't
checked.  If you use TXT RR's run BIND 4.8, or the secondaries for your
server run 4.8, you'll lose!  This is probably the reason several people,
including Paul Pomes at UIUC and we at UMN, use HINFO rather than TXT RR's
to store miscellaneous text in the DNS -- it's kludgy but effective.

     Stuart Levy, Geometry Group, University of Minnesota
     slevy@geom.umn.edu
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 14:26:09 GMT
From:      haven!adm!lhc!nih-csl!helix.nih.gov!young@ames.arc.nasa.gov  (Jeff Young)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp course

Anyone know of a good tcp course offered soon - December/January.  Three or four
days, in the vicinity of the east coast of the united states would be nice but 
would consider anywhere (same continent please).

thanks

jy
young@alw.nih.gov
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 19:32:08 EST
From:      Doug Nelson <08071TCP%MSU@pucc.PRINCETON.EDU>
To:        "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Interoperability?
>We must be doing something wrong.
>
>This was in December 3,1990 Network World, Volume7,Number 49 "The
>Newsweekly of User Networking Strategies":
>
>Article on page 1: "MAP/TOP group charts new course" by Ellen
>Messmer
>(paragraph 12)
>        Bride* said a network manager interconnecting a large
>multivendor TCP/IP installation will discover that vendors
>have implemented TCP/IP differently and interoperability
>is unattainable. "You can"t build a national and international
>network using TCP/IP," Bride said.
>
>        * Laurie Bride, manager of network architecture at
>Boeing Computer Services Co.

Very interesting...  Well, would someone explain exactly what it is that
we all *haven't* built over these last 20 years?  It may well be that
*full* interoperability is unattainable; after all, 20,000 nodes at a
large institution such as Boeing must be running a large and expanding
number of different TCP/IP implementations, and there are certain to be
a growing number of combinations that aren't fully interoperable.  I'll
give her credit if this is what she's implying.

I feel sorry for her, though, if she thinks that OSI is going to solve
all her interoperability problems (and in her lifetime, yet!).

Doug Nelson
Michigan State University
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Mon, 10 Dec 90 14:52:42 GMT
From:      saunders@hawk.nstn.ns.ca (Jim Saunders)
To:        tcp-ip@nic.ddn.mil
Subject:   Search for Synchronous PC Boards

Hello,

I am looking for a synchronous board for an IBM AT compatible computer.  I am 
looking for a board with a device driver for QNX that will support HDLC.
A relatively slow board is required (up to 4800 baud) but I will not 
rule out using an intelligent serial card.

If any one knows of such boards even with device drivers for other PC 
operting systems, please forward any list to me.

Thanks in advance,

Jim Saunders
Software kinetics
saunders@hawk.nstn.ns.ca
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 15:06:05 GMT
From:      ndsuvm1!nibmscm@cunyvm.cuny.edu
To:        tcp-ip@nic.ddn.mil
Subject:   PPP Shopping
Have a picture in my head, but need to replace the black boxes with some
real names - your help would be appreciated.  I'm putting together a SUN
system that will serve PC's that connect both over E-net and Async.  The
main purpose for the connection in either mode is to perform FTP's or
use NFS - also, am using IP all over to limit the support headaches for
this setup.
  I'm looking for hardware and software that would allow for installation of
this setup using PPP (due to horror stories on SLIP performance).  On the
async side, I need to be able to attach multiple simultaneous async users.
There.  I'll be waiting patiently - thanks in advance...

Regards,

Steve Malme
Development Mgr - FBS Data Systems
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 15:48:16 GMT
From:      ndsuvm1!nibmscm@cunyvm.cuny.edu
To:        tcp-ip@nic.ddn.mil
Subject:   PPP Shopping...
So, here I am attempting to put together a "good" solution for PC connection
to a SUN system over both E-net and Async.  To reduce future headaches, I'd
like to do this using a single protocol (TCP/IP or OSI).  The connecting
stations in this environment are looking for mainly FTP and NFS capabilities.
  I'm pretty comfortable with the setup over E-net, but not very comfortable
with the Async.  I've heard horror stories about SLIP, and so am looking very
hard at PPP (but don't have a clue what products are available and if the SUN
station is capable of supporting this connection).  If possible, I'd like to
find a single DOS (and MAC if possible) solution that would allow me to
connect using either the LAN or phone lines.
  Thanks in advance for your help...

Regards,
Steve Malme
Development Mgr - FBS Data Systems
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 18:11:16 GMT
From:      rex!wuarchive!cs.utexas.edu!news-server.csri.toronto.edu!hub.toronto.edu!thomson@ames.arc.nasa.gov  (Brian Thomson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions on TCP shutdown and RFC-793
In article <2452@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	Re: shutdown(2) in BSD implementations. It corresponds roughly to
>the TCP ABORT function, but not quite. In particular, as the manual page
>says, any buffered data pending will be dropped. It isn't really the
>"half close" that RFC 793 wants, and it should only be used in programs
>that are aborting or, because of mechanisms in the application protocol,
>already know that the data has been delivered. It should *not* be used for
>applications that have done writes and just want to mark the end of data for
>the peer, since any data still pending in the local send buffers is discarded
>and never delivered.

I think the original question was about the TCP shutdown procedure, not the
BSD shutdown() system call, but this answer caught my attention because it
seems to contradict everything I thought I knew about the BSD routine.
My understanding is as follows:
	shutdown(s, 0)	- flushes data queued for receive, and shrinks
			  my receive window to zero.  Succeeding reads will
			  fail.
	shutdown(s, 1)	- data already queued will be delivered, followed
			  by a FIN.  Succeeding writes will fail.
	shutdown(s, 2)	- equivalent to { shutdown(s, 0); shutdown(s, 1); }

The second of these is precisely the orderly half close.
None of them performs the TCP ABORT function.

And, to top it off, my manual pages (Sun) say nothing about loss of
buffered data pending.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 20:29:43 GMT
From:      mentor.cc.purdue.edu!dls@purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions on TCP shutdown and RFC-793
In article <1990Dec10.131116.19393@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
> 
> I think the original question was about the TCP shutdown procedure, not the
> BSD shutdown() system call, but this answer caught my attention because it
> seems to contradict everything I thought I knew about the BSD routine.
> My understanding is as follows:
> 	shutdown(s, 0)	- flushes data queued for receive, and shrinks
> 			  my receive window to zero.  Succeeding reads will
> 			  fail.
> 	shutdown(s, 1)	- data already queued will be delivered, followed
> 			  by a FIN.  Succeeding writes will fail.
> 	shutdown(s, 2)	- equivalent to { shutdown(s, 0); shutdown(s, 1); }
> ...
> 
> And, to top it off, my manual pages (Sun) say nothing about loss of
> buffered data pending.

	Sorry, I had forgotten where I saw it. It isn't in the man page, and
I originally came across it in the code, but I knew there was a documentation
reference as well. The "IPC Primer" (section 2.6) says:

	"....Applying shutdown to a socket causes any data queued to be
immediately discarded."

Also, from the "Advanced 4.3BSD IPC Tutorial" (PS1:8-8):

	"Once a socket is no longer of interest, it may be discarded by
applying close to the descriptor, close(s);
	If data is associated with a socket which promises reliable delivery
(e.g., a stream socket) when a close takes place, the system will continue
to attempt to transfer the data. However, after a fairly long period of time,
if the data is still undelivered, it will be discarded. Should a user have no
use for a any pending data, it may perform a shutdown on the socket prior to
closing it."
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 01:29:48 EDT
From:      "Prof. Morton F. Taragin" <MFT00117%GWUVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: 3270 for CommToolbox
As you can probably tell, I am vsmorty at WEIZMANN, not mft00117@gwuvm
anymore
-morty
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 22:25:02 GMT
From:      pyramid!infmx!aland@hplabs.hpl.hp.com  (Colonel Panic)
To:        tcp-ip@nic.ddn.mil
Subject:   Ports card and Win/TCP won't play nice
I'm having a somewhat bizarre problem changing to a newer-generation
ports card on an existing 386 UNIX box.

The players:     AT&T 6386E/33 (33 MHz 386, Intel-made) w/24MB
                 AT&T UNIX System V/386 Rel 3.2.2
                 WIN/TCP for 386 STREAMS Release 3.1.0
                 WD8003E Ethernet Card
                 Consensys PowerPorts 16/512  16-port card
                     (to be replaced by:
                         Consensys PowerPorts/HD 32-port card)

The problem: the existing setup is working dandy.  I went to replace
the existing 16-port card with the new HD card.  Once the hardware and
software are installed and I reboot, I get lots of messages out of
the network driver (specifically, the n8390_recv() function).  The
network software, however, appears to still work to some degree (I can 
rlogin to the machine with one session just fine).

The ports card and network card have nonconflicting i/o base addresses,
and nonconflicting shared memory addresses (the ports card uses
CE000-CFFFF; the network card uses D0000-D1FFF).  I have tried moving
the shared memory addresses of both with no impact.  The ports card
uses defaults for everything, while the network card uses i/o base
240H and IRQ2.  The network card is in slot #1, and the ports card is 
in slot #4, if that means anything.

When I gave up and reinstalled the old ports card, things are hunky
dory again.

Any ideas appreciated.  

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland

"She was wearing a pair of Clamdiggers that had obviously never been to a
 beach; and a halter top, that had been in a dryer, on high, for three weeks.
 My contact lenses popped out and went looking for water."
        - "Santa Ana Woman",  The BOBS
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      10 Dec 90 23:11:10 GMT
From:      envy!karn@bellcore.com  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP down scaling (linear or what) ?
In article <1990Dec7.104135.12@ux1.cso.uiuc.edu>, krol@ux1.cso.uiuc.edu
(Ed Krol) writes:
|> Just remember that as the link speed decreases the IP (and
presumably)
|> TCP headers take up a greater percentage of the available bandwidth.
|> Leaving less room for real data.  (At a link speed of about 500 baud
|> you have just enough bandwidth to send TCP IP headers and do HDLC
|> bitstuffing - sorry no room for data)

Nonsense. The overhead of a TCP/IP link is entirely determined by the
amount of data in each packet vs the size of the headers. The link
speeds don't enter into it at all.

When the application queues many small packets for transmission, a TCP
that implements the Nagle algorithm (now a required part of the
standard) actually *reduces* the header overhead automatically as the
link speed decreases. Rather than launch multiple small packets into a
narrow pipe, a Nagle TCP bunches them together by delaying
transmission of new data when there is already unacknowledged data in
the pipe; multiple packets are launched only when they are
maximum-sized (i.e., have minimum header overhead).

Phil
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 00:04:35 GMT
From:      snorkelwacker.mit.edu!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@bloom-beacon.mit.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions on TCP shutdown and RFC-793

	More information: I looked briefly through our (4.3 Tahoe) code and
it does in fact appear to do shutdown(2) as the "half-close" that you (and
I) want it to do. That is, it doesn't deallocate the send buffer until the
final close and it does appear to go into TIME_WAIT, instead of just
deallocating the TCB.
	So, if you trust my cursory reading of the current code and you don't
take the documentation I quoted too literally, then shutdown(2) appears to
be safe after a write, even if it's buffered, in at least 4.3 Tahoe. :-)
	I unfortunately don't have time to look at it in detail enough to turn
the "appears to be safe" to just "is safe" right now, but if anyone else does,
I'd like to see what you find.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 00:22:03 GMT
From:      elroy.jpl.nasa.gov!usc!samsung!olivea!orc!inews!intelca!mipos3!scdt!echan@ames.arc.nasa.gov  (Eldon Chan ~ )
To:        tcp-ip@nic.ddn.mil
Subject:   Information on FDDI
Hi networkers,

  Our group is planning to evaluate FDDI sometime in Q1/91.  I would
like to gather some information before we actually start the test.
  If you have implemented one, would you tell me what drive you to
implement FDDI, is it just for positioning for the future or you have
some specific problem that require FDDI to solve?

  What kind of tests you have done before you put FDDI into your
production network?  What vendor did you pick and why?

  What are the pros and cons of the bridging and routing soultions ?

  Any pointers/advises to papers, user/news groups, RFCs and reports are
appreciated.

  I will be on vacation for the next three weeks,  please reply to me
directly and I will do a summary when I come back. 

  Thanks in advance.

Eldon Chan
echan@scdt.intel.com
Design Technology
Intel Corporation
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 00:24:14 GMT
From:      pyramid!lstowell@hplabs.hpl.hp.com  (Lon Stowell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none) (Really,  it's the get-well card scam again)
In article <766@npdiss1.StPaul.NCR.COM> mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes:
    (Lines removed from Petrino's original posting)
    (which Mr. Mercer re-posted....with justifiable
    (flaming...
>:
>:     Craig Shergold
>:     % Children's Make-A-Wish Foundation
>:     32 Parimeter Center East
>:     Atlanta, Georgia 30346
>:
>:
>:               -------------------------------------
>:
>:                                                Jack Petrino          
>:                              
>:                              
>:----------------------------------------------------------------------
>:       Jack Petrino (DRAGON)        int: PETRINO@KUHUB.CC.UKANS.EDU         
>:       Systems Testing              bit:     PETRINO@UKANVAX
>:       University of Kansas         vox:      (913)864-0443          
>:       Computer Center              fax:      (913)864-0485    
>:-----------------------------------------------------------------------
>I've got a better idea.   Let's all send Jack a get well card.  I'm
>sure he'll be needing one after all the third degree flamings he's
>going to get.  Isn't there anyway we can put this puppy to sleep for
>good?
>

A much better idea, which would make the punishment fit the
crime, is to FLOOD Mr. Jack Petrino with junk FAX and E-mail.
Mr. Petrino was nice enough to include his E-mail address and
that of his FAX....perhaps a few gigabytes of junk will keep
this type of junk OFF the bulletin boards?
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 01:24:12 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp course
In article <721@nih-csl.nih.gov> young@alw.nih.gov (Jeff Young) writes:
>Anyone know of a good tcp course offered soon - December/January.Three or four
>days, in the vicinity of the east coast of the united states would be nice but 
>would consider anywhere (same continent please).

Jeff and others interested:

CERFnet is hosting Doug Comer's Introduction to TCP/IP class on
Jan 30-31, 1991 in *sunny* San Diego.

Drop a note to help@cerf.net for registration information.

--pushpendra
Network Co-ordinator
CERFnet
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 01:38:06 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP for system V.3 (where can i find it?)
Sys V.3 SLIP is probably best attained by checking out KA9Q.  This
is how most people I know are running it on Sys V.  Interactive and
SCO have SLIP in their Sys V kernels, you might want to try them
and see if they don't have a public domain access site they can
point you at.

As for Ultrix 4.1, CSLIP is an augmentation of SLIP by Van Jacobson.
It had both Sun and Ultrix code which should be compatible with any
Ultrix 2.3 (?) system and above.  If you down load  this code and
read the readme files, and code, you will instructions and a patch
to get it running on your Ultrix system.

Hope this helps.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 10:06:41 -0500
From:      H. Craig McKee <mckee@chance.mitre.org>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interoperability?
>We must be doing something wrong.
>
>This was in December 3,1990 Network World, Volume7,Number 49 "The
>Newsweekly of User Networking Strategies":
>
>        * Laurie Bride, manager of network architecture at
>Boeing Computer Services Co.

Let's not be too quick in our judgement.  I'm more inclined to doubt the
accuracy of the reporting done by Network World.
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 05:29:48 GMT
From:      MFT00117@GWUVM.BITNET ("Prof. Morton F. Taragin")
To:        comp.protocols.tcp-ip
Subject:   Re: 3270 for CommToolbox

As you can probably tell, I am vsmorty at WEIZMANN, not mft00117@gwuvm
anymore
-morty

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 06:42:50 GMT
From:      cs.utexas.edu!oakhill!abair@tut.cis.ohio-state.edu  (Alan Bair)
To:        tcp-ip@nic.ddn.mil
Subject:   Hopefull question about SLIP on Sun
I am trying to setup a SLIP connection between my Sun3/80 at work and my
Amiga 3000 at home.  I have the KA9Q/NOS code installed on my Amiga.  It
seems to work fine using the loopback port.  On the Sun I have obtained the
slipware.tar package, which consists of slip-4.0 and tip modified to be able
to run dialout SLIP.  I have that installed, but have had trouble getting it
to connect to the Amiga.  Any hints at getting them to connect would be
appreciated. 

However, what I really want to know is if it is possible to have SLIP on the
Sun without installing the pseudo-device in the kernel?  I would like to make
the Sun SLIP available to some other people where we cannot update the kernel.
I know my way around UNIX fairly well, but not the insides of the kernel or
implementing device handlers.  If there is some way to do this, I would
appreciate any pointers to the software.
--
Alan Bair                 SSDT (formerly SPS CAD)
Motorola, Inc.            Logic Simulation & Test
Austin, Texas             abair@turbinia.sps.mot.com
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 12:08:53 EST
From:      kate@tecnet1.jcte.jcs.mil
To:        tcp-ip@nic.ddn.mil
Subject:   YP
I'm looking for a good source on YP. Not implementing it, but how it works
and it's rules.

Thanks
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 08:38:52 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   needs VT220 host, was emulation

On Wed, 19 Sep 90 11:29:05 -0500 James B. Van Bokkelen said:
>If it has to replace ours, he needs an IBM PC DOS VT220 emulator with
>7-bit and 8-bit support, the ISO Latin character set, keyboard and
>display re-mapping and print screen support, built into a Telnet with
>a built-in FTP server and multi-session capability.  Novell (Excelan)
>offers VT220 in their product for the EXOS205, but I don't know its
>capabilities.  Sun, IBM and 3Com had VT100 last I knew, I don't know
>what Beame & Whiteside offers.  One could also get a VT220 emulator
>from one of the Ascii emulator specialists and use it with an INT 14
>Telnet redirector.  I don't recall any INT 14 redirector or VT220
>emulator Telnets that are free...

Fine to us, those "foreign" language speakers, James.
Now we have the terminal, how can we have the host. Let me explain.
To us, computers codes are just as different as EBCDIC is from ASCII.
This is because we do have to use an 8-bit code and the "ASCII extension" of
the PC and the Macintosh, for example, are not compatible.
It needs little reasoning to come to the conclusion that a standard code has
to be defined to be used on the communication line, just as ASCII is, that is
of course an extension of ASCII. Telnet binary mode, for one, is not enough
because it does not enforce computers to use the same exchange code. The same
problem occurs for several other application protocols and the rule should be
that either a system simply uses that standard code or has to translate its
own to standard when exchanging data on communication lines. A 8-bit
invertible translation has to be defined for each proprietary code, even if
the character set does not match the standard set exactly. The programming
key is to use the standard code in memory and provide a translation at the
device level (keyboard, screen, file), optional by possibly being null.
It needs very little indeed to fit the 4th wheel to the great TCP/IP car.
Unhappily, most of the TCP/IP protocols do not define that 8-bit code (X is
the counter example, however) worse have a tendency to restrict to 7-bit.

Everyone, including X, seems to agree that this code is ISO 8859/1 (for Latin
group 1 languages, others would use other versions untranslatable to each
other, except for the common ASCII lower half).
But I find this agreement too silent. Which 8-bit code to use seems to be
left to anybody's whim. Unix moves to 8-bit, but which mainly depends on
the character code of the devices (terminals and printers mainly).
I have heard of installations using Unix with PC code page 850 (exactly the
same character set as ISO 8859/1, but with different code points), even IBM
saying that it's the code of AIX. Thus, VT220 and Macintoshes cannot be used.
I've heard that SunOS 4.1 starts using ISO 8859/1 (is that correct?).

The higher VT models emulation does just that: translate ISO 8859 to local.
The specific question is: how does this integrate with Telnet and how does
a Unix host have to be setup to use 8859?
Should a 7-bit path be used with SO/SI shifting for both screen and keyboard
(seems a pain, especially to recover from entering the wrong mode), or will
the emulator request binary mode and Unix understand?
Unix applications (of those being able to process 8 bits) should work
unaware of terminal setup requirements. How will the VT terminal enter
ISO 8859/1 mode (or shouldn't the emulator best be locally configurable to
use ISO 8859/1 without any system or application action?).
In a word, how use ISO 8859/1 as simply as ASCII? Sorry I am not a Unix man.

Please excuse my difficulties to use this standard language on communication
lines, and believe I'd really like to be able to use my own to send correct
mail to French talking people, including those in so far away Quebec :-)

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 09:38:52 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   needs VT220 host, was emulation
On Wed, 19 Sep 90 11:29:05 -0500 James B. Van Bokkelen said:
>If it has to replace ours, he needs an IBM PC DOS VT220 emulator with
>7-bit and 8-bit support, the ISO Latin character set, keyboard and
>display re-mapping and print screen support, built into a Telnet with
>a built-in FTP server and multi-session capability.  Novell (Excelan)
>offers VT220 in their product for the EXOS205, but I don't know its
>capabilities.  Sun, IBM and 3Com had VT100 last I knew, I don't know
>what Beame & Whiteside offers.  One could also get a VT220 emulator
>from one of the Ascii emulator specialists and use it with an INT 14
>Telnet redirector.  I don't recall any INT 14 redirector or VT220
>emulator Telnets that are free...

Fine to us, those "foreign" language speakers, James.
Now we have the terminal, how can we have the host. Let me explain.
To us, computers codes are just as different as EBCDIC is from ASCII.
This is because we do have to use an 8-bit code and the "ASCII extension" of
the PC and the Macintosh, for example, are not compatible.
It needs little reasoning to come to the conclusion that a standard code has
to be defined to be used on the communication line, just as ASCII is, that is
of course an extension of ASCII. Telnet binary mode, for one, is not enough
because it does not enforce computers to use the same exchange code. The same
problem occurs for several other application protocols and the rule should be
that either a system simply uses that standard code or has to translate its
own to standard when exchanging data on communication lines. A 8-bit
invertible translation has to be defined for each proprietary code, even if
the character set does not match the standard set exactly. The programming
key is to use the standard code in memory and provide a translation at the
device level (keyboard, screen, file), optional by possibly being null.
It needs very little indeed to fit the 4th wheel to the great TCP/IP car.
Unhappily, most of the TCP/IP protocols do not define that 8-bit code (X is
the counter example, however) worse have a tendency to restrict to 7-bit.

Everyone, including X, seems to agree that this code is ISO 8859/1 (for Latin
group 1 languages, others would use other versions untranslatable to each
other, except for the common ASCII lower half).
But I find this agreement too silent. Which 8-bit code to use seems to be
left to anybody's whim. Unix moves to 8-bit, but which mainly depends on
the character code of the devices (terminals and printers mainly).
I have heard of installations using Unix with PC code page 850 (exactly the
same character set as ISO 8859/1, but with different code points), even IBM
saying that it's the code of AIX. Thus, VT220 and Macintoshes cannot be used.
I've heard that SunOS 4.1 starts using ISO 8859/1 (is that correct?).

The higher VT models emulation does just that: translate ISO 8859 to local.
The specific question is: how does this integrate with Telnet and how does
a Unix host have to be setup to use 8859?
Should a 7-bit path be used with SO/SI shifting for both screen and keyboard
(seems a pain, especially to recover from entering the wrong mode), or will
the emulator request binary mode and Unix understand?
Unix applications (of those being able to process 8 bits) should work
unaware of terminal setup requirements. How will the VT terminal enter
ISO 8859/1 mode (or shouldn't the emulator best be locally configurable to
use ISO 8859/1 without any system or application action?).
In a word, how use ISO 8859/1 as simply as ASCII? Sorry I am not a Unix man.

Please excuse my difficulties to use this standard language on communication
lines, and believe I'd really like to be able to use my own to send correct
mail to French talking people, including those in so far away Quebec :-)

Andr'e PIRARD             SEGI, Univ. de Li`ege
B26 - Sart Tilman         B-4000 Li`ege 1 (Belgium)
pirard@vm1.ulg.ac.be  or  PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 14:13:10 GMT
From:      ncis.tis.llnl.gov!blackbird!udecc.engr.udayton.edu!turner@lll-winken.llnl.gov  (Bob Turner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Boeing and Internet
In article <9012101742.AA19643@bel.isi.edu> postel@VENERA.ISI.EDU writes:
>
>We must be doing something wrong.
>
>This was in December 3,1990 Network World, Volume7,Number 49 "The
>Newsweekly of User Networking Strategies":
>
>Article on page 1: "MAP/TOP group charts new course" by Ellen
>Messmer
>(paragraph 12)
>	Bride* said a network manager interconnecting a large
>multivendor TCP/IP installation will discover that vendors
>have implemented TCP/IP differently and interoperability
>is unattainable. "You can"t build a national and international
>network using TCP/IP," Bride said.
>
>	* Laurie Bride, manager of network architecture at
>Boeing Computer Services Co.
>
>
>Joe Wieclawek                   jaw@sesun.Jpl.Nasa.Gov
>Jet Propulsion Laboratory       Mail stop: 602-145
>4800 Oak Grove Drive            Office: (818)354-2419   FTS: 792-2419
>Pasadena CA     91109           
>

	I am somewhat suprised that Laurie Bride would make a rash statement
like that. I obviously had a higher opinon of her than she deserved. It
would seem that she needs to read the Open Book and reassess her statements.



-- 
====================================================================
Bob Turner                    Network Manager, School of Engineering
513-229-3171                           turner@udecc.engr.udayton.edu
Univ. of Dayton, Engineering Computing Center-KL211, Dayton OH 45469
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 1990 13:41:51 +0100
From:      Erik Naggum <erik@naggum.uu.no>
To:        slevy@poincare.geom.umn.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Translating names/addresses to human-readable descriptions
> Beware: the TXT RR is unknown to the BIND 4.8 server, which is still
> pretty widespread.  It may be unknown to some later versions too, I
> haven't checked.  If you use TXT RR's run BIND 4.8, or the secondaries
> for your server run 4.8, you'll lose!  This is probably the reason
> several people, including Paul Pomes at UIUC and we at UMN, use HINFO
> rather than TXT RR's to store miscellaneous text in the DNS -- it's
> kludgy but effective.

Aaarggh!  I thought it would be enough to write an SMTP implementation
for UNIX platforms.  Now it seems it's necessary to write a DNS
implementation, too.  (By "implementation," I don't mean something
which can successfully mislead the amateur into believing it's
conformant, but a true, full, by-the-spec, robust implementation.)

Sigh.

[Erik Naggum]
Naggum Software, Oslo, Norway
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 20:25:10 EST
From:      G B Reilly <reilly@scotty.dccs.upenn.edu>
To:        Erik Naggum <erik@naggum.uu.no>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Translating names/addresses to human-readable descriptions

    > Beware: the TXT RR is unknown to the BIND 4.8 server, which is still
    > pretty widespread.  It may be unknown to some later versions too, I
    > haven't checked.  If you use TXT RR's run BIND 4.8, or the secondaries
    > for your server run 4.8, you'll lose!  This is probably the reason
    > several people, including Paul Pomes at UIUC and we at UMN, use HINFO
    > rather than TXT RR's to store miscellaneous text in the DNS -- it's
    > kludgy but effective.

    Aaarggh!  I thought it would be enough to write an SMTP implementation
    for UNIX platforms.  Now it seems it's necessary to write a DNS
    implementation, too.  (By "implementation," I don't mean something
    which can successfully mislead the amateur into believing it's
    conformant, but a true, full, by-the-spec, robust implementation.)

    Sigh.

    [Erik Naggum]
    Naggum Software, Oslo, Norway

Why don't you use MMDF for a good SMTP?  It was written by
the guy who wrote RFC 821.  Why not use the Toronto BIND - I
believe it supports the TXT RR

Brendan Reilly
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 16:03:20 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: IP down scaling (linear or what) ?

In article <1990Dec10.181110@envy.bellcore.com>, karn@envy.bellcore.com (Phil R. Karn) writes:
> In article <1990Dec7.104135.12@ux1.cso.uiuc.edu>, krol@ux1.cso.uiuc.edu
> (Ed Krol) writes:
> |> Just remember that as the link speed decreases the IP (and
 presumably)
> |> TCP headers take up a greater percentage of the available bandwidth.
> |> Leaving less room for real data.  (At a link speed of about 500 baud
> |> you have just enough bandwidth to send TCP IP headers and do HDLC
> |> bitstuffing - sorry no room for data)
> 
> Nonsense. The overhead of a TCP/IP link is entirely determined by the
> amount of data in each packet vs the size of the headers. The link
> speeds don't enter into it at all.

However, there are problems with large packets on slow links.  For
example, on a 9.6Kbps link, a 1K byte packet takes just under a second
to transmit.  If you have a smart router that tries to give priority to
short packets (i.e., telnet keystrokes and echoes), it will be helpless --
it can't pre-empt the packet that's already going.  (Well, it could,
I suppose, but that wouldn't be a very good idea...)

There's a second problem if you're going several hops at low speeds.
For each packet, a router can only start sending it once the whole
packet has been received.  Thus, if you have to go 4 hops at 9600 bps,
the total time to clock the bits onto the wire is about 4 seconds.  If
the same data were broken up into 256 byte chunks (or fragments), you
can get considerable overlap, as you can have several routers transmitting
simultaneously..

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Tue, 11 Dec 90 15:02:55 +0100
From:      Craig Partridge  <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM '91 Call for Papers

[Some folks expressed interest in knowing who was on the program
committee.  Program committee members are listed at the end of this
note. -- Craig]


		       Call For Papers

		 ACM SIGCOMM '91 CONFERENCE
  Communications Applications, Architectures and Protocols

	       ETH Zurich, Zurich, Switzerland
      September 4-6, 1991 (Tutorials September 3, 1991)


The conference provides an international forum for the  presenta-
tion  and  discussion  of  communication network applications and
technologies, as well as recent advances and proposals on commun-
ication  architectures,  protocols,  algorithms,  and performance
models. It is the first time that SIGCOMM will hold  its  confer-
ence outside of North America.

Authors are invited to submit full  papers  concerned  with  both
theory  and  practice.  The  areas of interest for the conference
include, but are not  limited  to  the  following:  Analysis  and
design  of computer network architectures and algorithms, innova-
tive results in local area networks, computer-supported  coopera-
tive  work,  network  interconnection  and  mixed-media networks,
high-speed networks, resource  sharing  in  distributed  systems,
network  management, distributed operating systems and databases,
protocol specification, verification, and analysis.

Papers should be about 20 double-spaced  pages  long  and  should
have  an  abstract of 100-150 words. All submitted papers will be
reviewed and will be judged with respect  to  their  quality  and
relevance. Authors of accepted papers will be expected to sign an
ACM copyright release form. The Proceedings will  be  distributed
at the conference and published as a special issue of ACM SIGCOMM
Computer Communication Review. Notable papers will be  considered
for publication in ACM Transactions on Computer Systems.

Submit 5 copies of each paper to  the  program  chairman  (or  in
North America, to the North American program committee contact):

Prof. Bernhard Plattner
Technische Informatik und Kommunikationsnetze   Telephone: +41 1 254 7000
ETH-Zentrum (IFW)                               Fax: +41 1 262 3973
8092 Zurich, Switzerland
EMAIL: <plattner@komsys.tik.ethz.ch> or
<C=ch; ADMD=arcom; PRMD=switch; O=ethz; ou1=tik; ou2=komsys; s=plattner>

The North American program committee contact is:

Greg Wetzel
AT&T Bell Laboratories                     Telephone: +1 (708) 979-4782
M/S IH 1B-213                              Fax: +1 (708) 979-2350
2000 N. Naperville Road                    E-Mail: g_f_wetzel@att.com
Naperville, IL  60566

For  more   information   about   the   conference,   e-mail   to
sigcomm91@nri.reston.va.us


Special session: Applications of High Speed Networks

One or more sessions of the conference will  be  devoted  to  the
subject  of  applications of high speed networks. Papers in these
sessions will focus on concepts, implementation and experience of
applications  that  need  the  performance that future high speed
networks will offer. Topics include, but are not limited  to  new
approaches  to computer-supported cooperative work, graphic visu-
alization, and access to  supercomputers.  Papers  submitted  for
these topics should address applications and their communications
requirements.

Student Paper Award

Papers submitted by students will  enter  a  student-paper  award
contest.   Among the accepted papers, a maximum of four outstand-
ing student papers will be awarded (1) one full conference regis-
tration  and  (2)  a  travel  grant  of US $1000. To be eligible,
student(s) must be the primary contributor(s) to the paper.

IMPORTANT DATES


Deadline for paper submission:   March 2, 1991.
Notification of acceptance:      April 30, 1991.
Camera ready papers due:         May 31, 1991.

Program Committee Members

Vinton G. Cerf, USA
A. Lyman Chapin, USA
Gary Delp, USA
Maria Dimou, Switzerland
Deborah Estrin, USA
Jose Garcia-Luna, USA
Jean-Pierre Hubaux, Switzerland
Phil Karn, USA
Lawrence H. Landweber, USA
Stewart Lee, Canada
Hannes Lubich, Switzerland
Derek R. McAuley, United Kingdom
Manel Medina, Spain
David Mills, USA
Gerald W. Neufeld, Canada
Craig Partridge, USA
Stephen Pink, Sweden
Bernhard R. Plattner, Switzerland
Marshall T. Rose, USA
Harry Rudin, Switzerland
Pietro Schicker, Switzerland
Deepinder Sidhu, USA
Hugh Smith, United Kingdom
Jonathan Smith, USA
Douglas B. Terry, USA
Paul von Binst, Belgium
Gregory Wetzel, USA
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 17:02:30 GMT
From:      pacbell.com!pacbell!well!osmana@ucsd.edu  (Osman Arslaner)
To:        tcp-ip@nic.ddn.mil
Subject:   Remote Command Execution over WAN.

Last weekend, we installed two Routers between Montreal and Toronto, 
connecting our backbone Ethernets through X.25.

When we execute remsh or rcp commands between two 3B2 UNIX systems
we encounter problems (either the connection hangs up or the command
aborts with an error message).
Has anybody encountered this problem before. ?
Any help will be appreciated. 

Osman Arslaner
Canadian National Railways.
Montreal, QUEBEC.
tel. (514) 399-7305
.
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 17:38:31 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none) (Really,  it's the get-well card scam again)
lstowell@pyrnova.pyramid.com (Lon Stowell) writes:
>A much better idea, which would make the punishment fit the
>crime, is to FLOOD Mr. Jack Petrino with junk FAX and E-mail.
>Mr. Petrino was nice enough to include his E-mail address and
>that of his FAX....perhaps a few gigabytes of junk will keep
>this type of junk OFF the bulletin boards?

No, all you'd accomplish by flooding him with junk mail is stopping him
from doing it again - and a simple polite note will probably do that,
since it seems he's a well-meaning individual.

Or do you somehow imagine that filling up one guy's mailbox is somehow
magically going to influence someone else half a continent away into not
repeating the mistake when he first comes on the network?

Seems to me you have even less regard for the consequences of your actions
as the guy who posted the note in the first place.  And HE meant well.

	Brian Kantor
		brian@ucsd.edu	BRIAN@UCSD ucsd!brian
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 17:46:24 GMT
From:      eru!hagbard!sunic!dkuug!freja.diku.dk!rimfaxe.diku.dk!krus@bloom-beacon.mit.edu  (Lars Povlsen)
To:        tcp-ip@nic.ddn.mil
Subject:   List of streams-based Protocol suites / Communication Packages
I am trying to get an overview of what STREAMS packages are available,
both commercially and PD/Educational.

If you could contribute to this list, it would be greatly appreciated.
Please reply to me, and I'll summarize to the net and directly to all
contributors, if wanted.

Most streams packages I have heard of is TCP/IP packs. A start for the
list could be thus be:

[Feel free to give additional information, or suggest other facts to
list for a package]

[[I know Retix have some OSI products, does anyone know?]]

Name		: Lachman TCP/IP
Manufacturer	: Lachman associates
OEMs		: ?
Product		: Full TCP/IP implementation
OS'es supported	: SCO, ATT V.4, Other?
Architectures	: i80386, i80486
Comments	:

Name		: Wollongong TCP/IP
Manufacturer	: The Wollongong Group
OEMs		: ?
Product		: Full TCP/IP implementation
OS'es supported	: SCO, ATT V.4, VMS
Architectures	: i80386, i80486, Vaxen
Comments	:

Name		: Spider TCP/IP
Manufacturer	: Spider Systems UK, Ltd.
OEMs		: ?
Product		: Full TCP/IP implementation
OS'es supported	: SCO, ATT V.4, Other?
Architectures	: i80386, i80486
Comments	:


Thanks for in advance for any contributions, or just pointers to more
information.

			Lars Povlsen,
			Denmark
			E-mail: krus@diku.dk
Lars Povlsen,
Computer Science Dept., University of Copenhagen, Denmark
E-mail: krus@diku.dk / ...!mcvax!dkuug!diku!krus
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 18:07:09 GMT
From:      ndsuvm1!mtus5!pecampbe@cunyvm.cuny.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: fax data over ip anyone?
In my TCP-IP software, there is an unused code segment to do fax transfers
of some sort. Judging by the looks of it, I think it works through the
mailer.
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 19:45:26 GMT
From:      pyramid!infmx!aland@hplabs.hpl.hp.com  (Colonel Panic)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3C503 shared memory conflict
In article <1990Dec4.124602.3672@csc.anu.oz.au> axt654@csc.anu.oz.au writes:
>Hi,
>I'm running Sun's version of PC-NFS on a 386 PC with a 3C503 card but
>also want to run NCSA Telnet because I need some of it's features. The problem
>is that the NCSA driver (and the packet driver) need a shared memoryt address
>available (eg dc00 or d800) but the NFS software requires this to be disabled
>(PC-NFS version 3.0.1). Is there some way around this? Is there a packet driver
>that runs with shared mem disabled? 

I faced a similar situation when trying to run WIN/TCP from UNIX and
PC-NFS from DOS on the same machine and card.  PC-NFS doesn't give you
a choice of enabling shared memory on those cards that it wants it
disabled by default.

I decided to shift to using the WD8003E instead, for which PC-NFS does
use shared memory mode.

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland

"When will Apple get socially responsible and offer separate trash can
 icons for glass, aluminum, and paper?"
  - Lincoln Spector
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 21:09:01 GMT
From:      usc!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mailer.cc.fsu.edu!prism!ce1zzes@ucsd.edu  (Eric Sheppard)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NDIS spec.
In article <9012102013.AA10764@ftp.com>, fks@FTP.COM (Frances Selkirk) writes:
> 
> Unlike packet drivers, most NDIS drivers are written by hardware
> manufacturers, and are owned by those manufacturers. (As far as I
> know, however, only Ungerman-Bass charges customers for their NDIS
> driver.) They tend to be supported software.
> 

I'd like to add that Ungermann-Bass' last quote on the yet-to-be-released
NDIS driver for their NIU (not NIC) cards is $395 for the TCP stack version.  
Man! Spend over a thousand for this NIU card, and it won't even work with 
anything that's not UB software until you fork over another $four hundred!  
We can't get non-UB cards to work with the UB-net software, we can't get 
NIU cards to run NFS.  What a waste!

Eric
-- 
Eric Sheppard      Georgia Tech    |   "Of course the US Constitution isn't
Atlanta, GA                        | perfect; but it's a lot better than what
ARPA: ce1zzes@prism.gatech.edu     |             we have now." -Unknown
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!ce1zzes
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 22:14:12 GMT
From:      uupsi!intercon!news@rice.edu  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Boeing and Internet
In article <9012101742.AA19643@bel.isi.edu>, postel@VENERA.ISI.EDU writes:
> "You can"t build a national and international
> network using TCP/IP," Bride said.

Yes this is interesting.  It has to be a mis-quote, right?  I mean, gee what
are we using right at this moment?

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      11 Dec 90 23:16:57 GMT
From:      usc!cs.utexas.edu!helios!utarlg.utarl.edu!c145gmk@ucsd.edu  (GORDON KEEGAN)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet driver for Western Digital's WD8013EBT card
In article <10661@helios.TAMU.EDU>, c145gmk@utarlg.utarl.edu (GORDON KEEGAN) writes...
> 
>Has anyone written or seen a packet driver for this ethernet card?
>I've already checked the clarkson and simtel ftp sites, to no avail.
>Reply by e-mail and I'll summarize.  Thanks!


	Well, the summary is that the packet driver for the 8003
	card will work for the 8013 card as well, using 8 bits
	instead of the full 16.  WD is supposedly working on a
	driver that will run all of the cards to their full
	capability.  We'll just have to wait 'n' see.
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 02:25:37 GMT
From:      sdcc6!mbongo!lindwall@ucsd.edu  (John Lindwall)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for USD TCP/IP registry
[I hope this is an appropriate location...]

In the Dec 10 "Communications Week" we saw an sidebar which
mentioned a registry maintained at the University of Southern
California.  It includes data from >130 vendors about their
networking systems.  It says "The TCP/IP community chose a
university as the guardian of this registry in an attempt
to provide an open way for users, vendors, and systems
integrators to access this information".  I just wish the
article had mentioned how/where to locate this document!

If anyone has any pointers to this registry please email
(or post if it's globally interesting information).  I have FTP
access.  Thanks!

John
-- 
John Lindwall			lindwall@ucsd.edu
"Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 10:23:33 CST
From:      Dave Bergum <bergum@cim-tune.honeywell.com>
To:        brian@ucsd.edu (Brian Kantor)
Cc:        tcp-ip@nic.ddn.mil, bergum
Subject:   Re: (none) (Really, it's the get-well card scam again)
>  Seems to me you have even less regard for the consequences of your actions
>  as the guy who posted the note in the first place.  And HE meant well.
>  
>  	Brian Kantor
>  		brian@ucsd.edu	BRIAN@UCSD ucsd!brian

Well said, Brian.
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 13:04:59 -0500
From:      aggarwal@nisc.jvnc.net (Vikas Aggarwal)
To:        snmp@nisc.nyser.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   The success of SNMP

Did someone ever address the issue of "community ids" in SNMP and 
their impact on troubleshooting ? OK, so I now have this magnificient
protocol called SNMP wich allows me to collect megabytes of data on
all my routers and allows me to plot those impressive charts, but
I *still* cannot query all those routers out there that have "cids"
set to something other than "public". So I go back to relying on
traceroute and SMTP mail messages and telephone calls and "whois"
and nslookup to try and track down routing problems -and I thought
that SNMP was the answer to my problems....

Are we *ever* going to resolve the issue (maybe just implementation),
where I can query any router about the 'necessary' routing information
without having to worry about coming up against a "cid" that I don't
know ?? Right now, when I trace the source of a route, I go through
my network, then set a "cid" for the NSFnet hosts and query them, then
hit another host who has a differant cid and so on ?? 

Do I have to rely on yet another *protocol* for addressing this issue
or do I stick to my nslookup & whois & SMTP & Bell for the rest of
the Internet's life ??

The God' s of SNMP ?? Anyone ???


 -vikas
 vikas@jvnc.net						(609) 258-2403
--------------------------------------------------------------------------
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 14:02:22 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   domain security & sendmail
Hi everyone.

We are setting up a Sun machine running SunOS 4.1.1 as our relay/gateway/
passthrough/what-have-you machine for Internet access, and are working on
some of the security aspects of this.

That relay machine will be the only system our router will pass traffic to
off the Internet.  One consequence of this is that any mail for any machine
in our domain must be sent in via the relay.  

I`d appreciate any advice you can offer on configuring Sun sendmail.cf and
domain name files (MX records ?) so that someone sending mail to jdoe@foo.com or
jdoe@x.foo.com will have that mail actually sent to relay.foo.com.

Thanks for your help. As usual, if one of you is caught or killed, the 
secretary will disavow any knowledge of your actions.

Richard 

rlg@desktalk.desktalk.com
. 
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 11:10:43 EST
From:      Christopher Maeda <cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU>
To:        brian@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   (none) (Really,  it's the get-well card scam again)
I already sent Petrino and root%shiva (the luser who forwarded
Petrino's original message) a copy of an article about the deluge of
cards.

Let's drop this.

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 14:49:38
From:      Sam Coleman <Sam_Coleman.NSD@lccmail.ocf.llnl.gov>
To:        ieee-mss@prandtl.nas.nasa.gov, tcp-ip@nic.ddn.mil, unicos-l@violet.berkeley.edu
Subject:   FTP enhancements
                       Subject:                               Time:8:39 AM
  OFFICE MEMO          FTP enhancements                       Date:12/5/90

We at LLNL are looking at requirements for future file transport between
various Unix machines.  We use FTP now and we've looked at Background FTP.  In
our environment, these seem to fall short in several areas that I'll describe
below.  I'd appreciate your corrections and additions.

We'd like to stick with "standard" interfaces, maybe enhancing FTP and/or BFTP.
 I'm wondering if anyone has encountered similar problems, developed better
solutions, or is interested in working with us to develop something better.

I haven't heard anything lately concerning the RFC for BFTP.  Is anything
happening there?  The chair of IETF (Internet Engineering Task Force), Phill
Gross, is not aware of any active FTP development.  Would it be reasonable to
form a working group under IETF to enhance FTP and/or BFTP?  Would an enhanced
FTP protocol make it easier to produce standard higher-level command or
graphical interfaces like HyperFTP and FTA?

Sam Coleman
Lawrence Livermore National Lab
coleman@llnl.gov

                          Some comments on FTP and BFTP
                          -----------------------------

Passwords - Both FTP and BFTP require clear-text passwords.  Our security folks
won't allow clear-text passwords to be stored in files. Is Kerberos a solution?

Persistence -  FTP has none; if a transfer fails, the user has to retry.
Background FTP has a simple retry mechanism.

Performance - File transfers go through the FTP client and TCP/IP.  Is there a
faster way to do the actual data transfers?

Notification - BFTP sends mail to the client when a transfer completes. Is this
the best way to handle notification in production environments?

Synchronous operation - FTP does one thing at a time.  The user can give 
BFTP multiple jobs, but BFTP seems to plug through these synchronously if they
are invoked using wild cards. Thus you can't take advantage of parallelism that
might be available in the file system (e.g. mounting tapes concurrently).

Flow control - FTP servers generally have no mechanisms to inhibit file
transfers during heavy load; file movement slows to a crawl as the load on the
server increases, then they reject log-ons, and then connections are refused
(maybe it's a good thing that FTP is synchronous?).  We would like to put flow
control in the FTP server to delay file transfers when necessary, but allow
log-ons and short commands (like ls).  Perhaps priority could be given to small
and/or fast transfers?

Tape files - FTP doesn't handle well the case where there is a delay accessing
a file, e.g. when the file is on tape.

Should there be a way to configure FTP?  A .FTPRC file to allow the user to
specify his own defaults.

Error reporting in some clients could be improved.

Clients - there are differences between various FTP clients.  Perhaps a working
group could help standardize them?

Missing functions - Some useful functions, like chmod, are provided by Unicos
FTP but not by other clients.  When FTP is the primary interface to an archive,
it would be nice to have more complete file system functionality.

Wild cards - FTP provides MGET, MPUT, and MDEL (why not GET *, etc?), but
functions like chmod don't support wild cards.  I would suggest wider and more
consistent semantics.  Should the server prompt the user rather than the
client?

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 07:20:59 GMT
From:      usc!almaak.usc.edu!tli@ucsd.edu  (Tony Li)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for USD TCP/IP registry
In article <14896@sdcc6.ucsd.edu> lindwall@mbongo.ucsd.edu (John Lindwall) writes:
    
    In the Dec 10 "Communications Week" we saw an sidebar which
    mentioned a registry maintained at the University of Southern
    California.  It includes data from >130 vendors about their
    networking systems.  It says "The TCP/IP community chose a
    university as the guardian of this registry in an attempt
    to provide an open way for users, vendors, and systems
    integrators to access this information".  I just wish the
    article had mentioned how/where to locate this document!
    
I suspect that this is in reference to the list of SNMP vendors.  The
list is available for anonymous FTP from venera.isi.edu as
mib/snmp-vendors-contacts.  

I just wish that journalists would get the "facts" that they publish straight.

-- 
Tony Li - USC Computer Science Department   		Internet: tli@usc.edu
		       The net is not what it seems.
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 08:23:26 GMT
From:      sco!ericd@uunet.uu.net  (Eric Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP From DOS

In article <47@vlink01.UUCP> sfrazier@vlink01.UUCP (8780) asks:
>I need some help.  I have (just installed) SCO Unix TCP/IP.  It resides on the
>UNIX box with (1) WD8003 card and hooks to a DOS XT with (1) WD8003 card there.
>
>The TCP/IP is up and running on the UNIX Box.  I need to know what software
>package(s) that are available from the DOS Machine to access rlogin, telnet,
>ftp on the Unix Box.  The DOS machine will not or is not on a LAN now and
>only has a couple of software packages on it as this time.  It will be used
>as a terminal off of the UNIX Box.

SCO has a TCP/IP package for DOS. It will allow your DOS machine to do 
all of the things mentioned above, and MORE!

Eric Davis					ericd@sco.COM
Techinical Support Engineer			{uunet|ucsc|att}!sco!ericd
The Santa Cruz Operation, Inc.

"We are the people our parents warned us about"
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 15:00:42 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CUNYVM.CUNY.EDU>
To:        Nigel Harwood <nigel@cnw01.storesys.coles.oz.au>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Strange rwho demon behavior
>I have a situation where some machines on our TCP/IP network are not
>listing all other machines when an rwho or ruptime is done.
>
>The majority of these machines are running Excelan TCP/IP on V.2
>although one is running Win TCP/IP on V.3.
>
>All machines have complete /etc/hosts files.
>
>Machine A will list A, B, C, D
>
>Machine B will list B, C
>
>Machine D will list A, B, C, D
>
>Basically what I'm asking is, is there a gotcha in how rwho
>determines who to tell about itself or alternatively who
>to listen to.
>
>I thought rwho was pretty straight forward, am I wrong ?
>
>Could it have something to do with addressing schemes which
>changed here a little while back (I can't categorically
>blame that as I did not notice the behavior for a while).
>
>Also, all machines can rlogin etc to each other.

"rwho" relies on broadcasts from the other systems.  Therefore, I'd
guess that your systems don't all agree on what to use for the IP
broadcast address.  You should use either <network>.<subnet>.<all one's>
or <all ones> (32 bits) for the broadcast address, but be consistent
among all systems.  If you aren't the network administrator, be sure to
contact that person to get the proper address.

If you have a large network, though, I would not recommend running
"rwhod" at all.  It's not much more than a waste of network bandwidth.
That's one of the first things I make sure is removed from systems on
our network.

Doug Nelson
Network Software Manager
Michigan State University











 d
 .edu>
 d
 .edu>,
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 20:26:35 -0500
From:      steve@umiacs.UMD.EDU (Steve D. Miller)
To:        erik@naggum.uu.no, reilly@scotty.dccs.upenn.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Translating names/addresses to human-readable descriptions
   Sorry to eat up bandwidth with this, but it seems that lots of people
don't know:  the latest version of BIND (4.8.3, which I suppose is also
known as 4.8.3.1, depending on what you look at) does support TXT records.
The support is not perfect.  However, the protocol-related part of the
support (i.e., the way the bits look on the wire) is right, so far as I
know.

   The MIT Hesiod servers also know about TXT records (and they're even
right now, as a side-effect of the BIND 4.8.3 development effort).  Probably
the UT BIND supports TXT, too, but I haven't looked at it recently...

	-Steve

P.S.:  While I'm cluttering up the net, has anyone implemented for BIND the
new RR types from RFC 1183?  I know about the AFSDB implementation.

Spoken: Steve Miller    Domain: steve@umiacs.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-405-6736  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 17:40:36 EST
From:      kasten@europa.InterLan.Com (Frank Kastenholz)
To:        sdcc6!mbongo!lindwall@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Looking for USD TCP/IP registry
 > From tcp-ip-RELAY@NIC.DDN.MIL Wed Dec 12 17:26:59 1990
 > From: sdcc6!mbongo!lindwall@ucsd.edu  (John Lindwall)
 > Organization: CSE Dept., UC San Diego
 > Subject: Looking for USD TCP/IP registry
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > [I hope this is an appropriate location...]
 > 
 > In the Dec 10 "Communications Week" we saw an sidebar which
 > mentioned a registry maintained at the University of Southern
 > California.  It includes data from >130 vendors about their
 > networking systems.  It says "The TCP/IP community chose a
 > university as the guardian of this registry in an attempt
 > to provide an open way for users, vendors, and systems
 > integrators to access this information".  I just wish the
 > article had mentioned how/where to locate this document!
 > 
 > If anyone has any pointers to this registry please email
 > (or post if it's globally interesting information).  I have FTP
 > access.  Thanks!
 > 
 > John
 > -- 
 > John Lindwall			lindwall@ucsd.edu
 > "Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot
 > 

I think that you want netinfo:vendors-guide.doc which is available
for anonymous FTP from nic.ddn.mil. The document is not exhaustive.

Frank Kastenholz
Racal Interlan

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Dec 90 14:14:16 GMT
From:      Sean Mc grath <sean@fiamass.ie>
To:        tcp-ip@nic.ddn.mil
Cc:        sean@fiamass.ie
Subject:   TCPIP ping problem
Hello there,
	We are having a small problem with our TCPIP for the PC from FTP Ltd.
We have a two machine network, each machine is a PC.  

From a reboot of both machines the sequence of events is as follows :-

Machine A            Machine B        Result
=========            =========        ======
ping B                               fails with "HOST NOT RESPONDING"
                     ping A          succeeds
ping B                               succeeds !

In effect, this means we must perform this little dance before we
can startup our socket software.

Does anyone know what is going on?

Sean Mc Grath (sean@fiamass.ie)
12 Clarinda Park North
Dun Loaghaire
Co. Dublin.
Ireland.

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 15:16:50 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Steven Eubanks)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NDIS spec.
In article <18484@hydra.gatech.EDU>, ce1zzes@prism.gatech.EDU (Eric
Sheppard) writes:
|> 
|> I'd like to add that Ungermann-Bass' last quote on the
|> yet-to-be-released
|> NDIS driver for their NIU (not NIC) cards is $395 for the TCP stack
|> version.  
. . .
|> We can't get non-UB cards to work with the UB-net software, we can't
|> get 
|> NIU cards to run NFS.  What a waste!
|>

Just a point of clarification:  I suspect that the $395 is for UB's TCP 
implementation (TCP for NDIS) which will run over their ($50) NDIS driver.  
You could purchase the UB NDIS driver for $50 and then go purchase
some other vendor's NDIS compliant TCP protocol stack which includes NFS, at 
that vendor's price.  That's the only way I've successfully run NFS on a
UB NIU.

The only advantage I could see in using 'TCP for NDIS' would be to preserve any
UB applications requiring their protocol stack by running 'TCP for NDIS'
over some
other vendor's NDIS compliant card/driver.  Theoretically speaking, of
course. :-)

Steve
-- 
Steven W. Eubanks,  EDS/LIMS			NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-8498					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 15:51:01 GMT
From:      pacbell.com!tandem!netcom!jbreeden@ucsd.edu  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NDIS spec.
In article <18484@hydra.gatech.EDU> ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:
>In article <9012102013.AA10764@ftp.com>, fks@FTP.COM (Frances Selkirk) writes:
>> 
>> Unlike packet drivers, most NDIS drivers are written by hardware
>> manufacturers, and are owned by those manufacturers. (As far as I
>> know, however, only Ungerman-Bass charges customers for their NDIS
>> driver.) They tend to be supported software.
>> 
>
>I'd like to add that Ungermann-Bass' last quote on the yet-to-be-released
>NDIS driver for their NIU (not NIC) cards is $395 for the TCP stack version.  
>Man! Spend over a thousand for this NIU card, and it won't even work with 
>anything that's not UB software until you fork over another $four hundred!  
>We can't get non-UB cards to work with the UB-net software, we can't get 
>NIU cards to run NFS.  What a waste!
>

I think that whoever you talked to gave you bad info. UB sells their 
complete set of NDIS MAC drivers (ISA & MCA NIC & NIUs) for fifty
bucks. They figure by charging, they stop the people who are "just
collecting drivers", big customers get them for free.

Something tells me you got a quote for a tcp-ip package - not NDIS drivers.

I don't work for UB, but I know what they charge for the drivers.
-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 16:10:43 GMT
From:      cmaeda@EXXON-VALDEZ.FT.CS.CMU.EDU (Christopher Maeda)
To:        comp.protocols.tcp-ip
Subject:   (none) (Really,  it's the get-well card scam again)

I already sent Petrino and root%shiva (the luser who forwarded
Petrino's original message) a copy of an article about the deluge of
cards.

Let's drop this.

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 16:55:31 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   CERFnet Hosts Introduction To TCP/IP Course
I have had numerous requests for information after my message
indicating CERFnet was hosting Doug Comers TCP/IP class in late
January.

Here is the  complete announcement.

--pushpendra
Network Co-ordinator
CERFnet



**CERFnet presents :*************************************************

		INTRODUCTION TO TCP/IP PROTOCOL SUITE
			DR. DOUG COMER

			JANUARY 30-31, 1991
		UNIVERSITY OF CALIFORNIA, SAN DIEGO

*****************************************************************************

OVERVIEW

The TCP/IP Internet protocol suite is a set of computer communication protocols
that make it possible for heterogeneous machines to communicate across
heterogeneous packet switching networks. TCP/IP makes the set of interconnected
networks function like a single, uniform, virtual network. This comprehensive
course describes the TCP/IP protocol technology; related protocols like FTP,
ARP, EGP, Telnet, and RIP; and the basics of internet architecture, including
the Domain Name System. It introduces the concepts and principles that underlie
Internet protocols and shows how application programs like electronic mail and
file transfer use the Internet. The course sorts through the myriad of
technical terms and acronyms, defining and explaining them. 

WHAT YOU WILL LEARN

After taking this course, the student will be familiar with the architectural
components of an internet (including autonomous systems, routers, and backbone
networks), the concepts that underlie each of the major Internet protocols
(e.g., TCP and IP), the IP address scheme (including subnet addressing), and
the major applications that use TCP/IP (e.g., electronic mail, file
transfer, and remote login). In addition, the student will have mastered most
of the Internet terminology and acronyms. Finally, the student will see the
format and contents of most protocol messages, including the layout and
contents of IP datagrams and routing update messages. 

WHO SHOULD ATTEND

This is an excellent seminar for anyone interested in designing or building
products that use the Internet or TCP/IP protocols, anyone interested in
specifying or choosing products that use or supply Internet services, anyone
interested in building applications for the Internet, or anyone interested in
understanding the principles that underlie TCP/IP Internet technologies. It is
especially pertinent for anyone who wants to read the literature (e.g., RFC
documents) because it provides a conceptual overview that is extremely
difficult to obtain elsewhere. 
	Attendees should have a general background in computing, but need not
be experts in data communications. 

INSTRUCTOR

Dr. Douglas Comer is a full professor in the Computer Science Department at
Purdue University where he teaches graduate-level courses in operating systems,
internetworking, and distributed systems. He has written numerous research
papers and five textbooks, and has been a principal investigator on many
research projects. He designed and implemented the X25NET and Cypress network,
as well as the Xinu operating system. He directs the Xinu, Cypress, Shadow
Editing, and Multiswitch research projects. He is a member of the Internet
Research Steering Group, and is a former member of the CSNET Executive
Committee and the Internet Activities Board. Professor Comer holds a Ph.D. in
Computer Science from The Pennsylvania State University. 

REGISTRATION

The seminar is $450.00 per person if payment is received before January 9th and
$550.00 per person if payment is received after January 9th. The cost includes
handouts and lunch. 
	To register by electronic mail, send a messagewith the following
information to Mike Beach (beachm@cerf.net): Name,
Institution/Company, Mailing Address, E-mail Address, date when we can expect
payment, and Telephone Number. 
	To register by regular mail or phone, please send the above information
to the following address or call Mike Beach at (619) 534-5181. 
	Mike Beach
	CERFnet
	c/o San Diego Supercomputer Center
	P. O. Box 85608
	San Diego, CA  92186-9784

	Checks should be made payable to General Atomics and be sent to Karen 
McKelvey at the above address.
	Hotel information will be mailed with your registration packet.


SYLLABUS

Introduction and general definitions--people and organizations (IAB,
IRTF, IETF, FRICC, etc.); documents (RFCs, IENs, etc.); overview of services;
networking definitions and basics (e.g., packet switching and multiplexing);
network technologies and physical (hardware) addressing. 

Internet model and basics--TCP/IP internet concepts and general model; the goal 
of interoperability; Internet addresses and address binding; subnet addressing; 
ARP/RARP protocols; IP datagram format; datagram delivery paradigm; Internet 
routing algorithm; fragmentation and reassembly; ICMP and error handling.

Protocols, layering, and network services--Internet and OSI layered reference
models; the layering principle; difference between model and software;
machine-to- machine and end-to-end layers; unreliable datagram delivery (UDP);
reliable stream delivery (TCP); socket interface; dynamic and well-known
protocol ports. 

Architecture of a TCP/IP Internet--simple examples; backbones; examples from
the connected TCP/IP Internet; notion of core gateways (SPREAD); autonomous
systems (EGP); interior gateway protocols (RIP/Hello/gated); domain naming
(DNS). 

Application-level services--client-server paradigm; client responsibilities
and algorithm; server responsibilities and algorithm; examples of servers; mail
(RFC 822 format and SMTP); remote login (TELNET, rlogin, rsh); ^le transfer
(FTP, TFTP); network management. 

Questions and answers--questions posed by the audience, usually on topics of 
current interest (e.g., white pages services).
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 18:35:44 GMT
From:      csus.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!clarkson!grape.ecs.clarkson.edu!nelson@ucdavis.ucdavis.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet driver for Western Digital's WD8013EBT card
In article <10814@helios.TAMU.EDU> c145gmk@utarlg.utarl.edu (GORDON KEEGAN) writes:

   In article <10661@helios.TAMU.EDU>, c145gmk@utarlg.utarl.edu (GORDON KEEGAN) writes...
   > 
   >Has anyone written or seen a packet driver for this ethernet card?
   >I've already checked the clarkson and simtel ftp sites, to no avail.
   >Reply by e-mail and I'll summarize.  Thanks!

   	Well, the summary is that the packet driver for the 8003
   	card will work for the 8013 card as well, using 8 bits
   	instead of the full 16.

No, the 7.x packet driver for the wd8003e runs it in 16-bit mode.

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  FAX 315-268-7600
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 20:00:42 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange rwho demon behavior

>I have a situation where some machines on our TCP/IP network are not
>listing all other machines when an rwho or ruptime is done.
>
>The majority of these machines are running Excelan TCP/IP on V.2
>although one is running Win TCP/IP on V.3.
>
>All machines have complete /etc/hosts files.
>
>Machine A will list A, B, C, D
>
>Machine B will list B, C
>
>Machine D will list A, B, C, D
>
>Basically what I'm asking is, is there a gotcha in how rwho
>determines who to tell about itself or alternatively who
>to listen to.
>
>I thought rwho was pretty straight forward, am I wrong ?
>
>Could it have something to do with addressing schemes which
>changed here a little while back (I can't categorically
>blame that as I did not notice the behavior for a while).
>
>Also, all machines can rlogin etc to each other.

"rwho" relies on broadcasts from the other systems.  Therefore, I'd
guess that your systems don't all agree on what to use for the IP
broadcast address.  You should use either <network>.<subnet>.<all one's>
or <all ones> (32 bits) for the broadcast address, but be consistent
among all systems.  If you aren't the network administrator, be sure to
contact that person to get the proper address.

If you have a large network, though, I would not recommend running
"rwhod" at all.  It's not much more than a waste of network bandwidth.
That's one of the first things I make sure is removed from systems on
our network.

Doug Nelson
Network Software Manager
Michigan State University











 d
 .edu>
 d
 .edu>,

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 20:02:39 GMT
From:      usc!zaphod.mps.ohio-state.edu!wuarchive!emory!hubcap!ncrcae!ncr-sd!se-sd!nolet@apple.com  (Jason Nolet)
To:        tcp-ip@nic.ddn.mil
Subject:   NETBIOS/RFCs 1001/1002 Question
Hi.  I have a question about RFCs 1001/1002 (or maybe its
really a NETBIOS question, I'm not sure...)

If a node on the network initiates a call to a NETBIOS
name which happens to be a group name being used by
several other nodes on the network, how is the call to
the group name resolved into a single session with a
specific member of the group?  Is it based on the first
name query response received?  Is this an error
condition?

The text of RFC 1001 says, "The NETBIOS specification
does not define how a connection request to a group name
resolves into a session.  The usual *assumption* is that
a session may be established with any one owner of the
called group name."

Note that my question is specific to B-node processing 
only (no central name server).

Any insight will be greatly appreciated!

Jason.

/******************************************************/
/* Jason Nolet                                        */
/* Systems Engineering - San Diego, NCR Corporation   */
/* email:  Jason.Nolet@SanDiego.NCR.COM               */
/* Phone:  (619) 578-9000                             */
/* Fax:    (619) 693-5705                             */
/******************************************************/
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 20:53:21 GMT
From:      pacbell.com!tandem!Tandem.COM!kevinr@ucsd.edu  (Kevin J. Rowett)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interoperability?
In article <1990Dec7.231502.27773@jato.jpl.nasa.gov>, jaw@sesun.jpl.nasa.gov (Joe Wieclawek) writes:
|> (paragraph 12)
|> 	Bride* said a network manager interconnecting a large
|> multivendor TCP/IP installation will discover that vendors
|> have implemented TCP/IP differently and interoperability
|> is unattainable. "You can"t build a national and international
|> network using TCP/IP," Bride said.
|> 
|> 	* Laurie Bride, manager of network architecture at
|> Boeing Computer Services Co.

The person quoted is one of the most self serving individuals ever
to roam corporate America. Ask her if they ever let Jeff Yaplee's
voice be heard. He's one of the few sane individials in the BNA
group.

kevinr@tandem.com
408.285.4325
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      12 Dec 90 22:49:38 GMT
From:      Sam_Coleman.NSD@LCCMAIL.OCF.LLNL.GOV (Sam Coleman)
To:        comp.protocols.tcp-ip
Subject:   FTP enhancements


                       Subject:                               Time:8:39 AM
  OFFICE MEMO          FTP enhancements                       Date:12/5/90

We at LLNL are looking at requirements for future file transport between
various Unix machines.  We use FTP now and we've looked at Background FTP.  In
our environment, these seem to fall short in several areas that I'll describe
below.  I'd appreciate your corrections and additions.

We'd like to stick with "standard" interfaces, maybe enhancing FTP and/or BFTP.
 I'm wondering if anyone has encountered similar problems, developed better
solutions, or is interested in working with us to develop something better.

I haven't heard anything lately concerning the RFC for BFTP.  Is anything
happening there?  The chair of IETF (Internet Engineering Task Force), Phill
Gross, is not aware of any active FTP development.  Would it be reasonable to
form a working group under IETF to enhance FTP and/or BFTP?  Would an enhanced
FTP protocol make it easier to produce standard higher-level command or
graphical interfaces like HyperFTP and FTA?

Sam Coleman
Lawrence Livermore National Lab
coleman@llnl.gov

                          Some comments on FTP and BFTP
                          -----------------------------

Passwords - Both FTP and BFTP require clear-text passwords.  Our security folks
won't allow clear-text passwords to be stored in files. Is Kerberos a solution?

Persistence -  FTP has none; if a transfer fails, the user has to retry.
Background FTP has a simple retry mechanism.

Performance - File transfers go through the FTP client and TCP/IP.  Is there a
faster way to do the actual data transfers?

Notification - BFTP sends mail to the client when a transfer completes. Is this
the best way to handle notification in production environments?

Synchronous operation - FTP does one thing at a time.  The user can give 
BFTP multiple jobs, but BFTP seems to plug through these synchronously if they
are invoked using wild cards. Thus you can't take advantage of parallelism that
might be available in the file system (e.g. mounting tapes concurrently).

Flow control - FTP servers generally have no mechanisms to inhibit file
transfers during heavy load; file movement slows to a crawl as the load on the
server increases, then they reject log-ons, and then connections are refused
(maybe it's a good thing that FTP is synchronous?).  We would like to put flow
control in the FTP server to delay file transfers when necessary, but allow
log-ons and short commands (like ls).  Perhaps priority could be given to small
and/or fast transfers?

Tape files - FTP doesn't handle well the case where there is a delay accessing
a file, e.g. when the file is on tape.

Should there be a way to configure FTP?  A .FTPRC file to allow the user to
specify his own defaults.

Error reporting in some clients could be improved.

Clients - there are differences between various FTP clients.  Perhaps a working
group could help standardize them?

Missing functions - Some useful functions, like chmod, are provided by Unicos
FTP but not by other clients.  When FTP is the primary interface to an archive,
it would be nice to have more complete file system functionality.

Wild cards - FTP provides MGET, MPUT, and MDEL (why not GET *, etc?), but
functions like chmod don't support wild cards.  I would suggest wider and more
consistent semantics.  Should the server prompt the user rather than the
client?

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 00:25:47 GMT
From:      usc!wuarchive!emory!hubcap!ncrcae!ncr-sd!iss-rb!sun411g!johnh@apple.com  (John Holmes 2540)
To:        tcp-ip@nic.ddn.mil
Subject:   Mentor/HP/Apollo networking over T1 - Interfaces? Vendors? Experience?
If anyone could provide information on tying HP/Apollo networks together over
long distances, I would appreciate hearing from you.  Our expectation is to
use a T1 line and some kind of bridge hardware/software to link two remote
sites with some level of network transparency.  Please Email (post if you
must) suggestions on vendors, hints for success, etc.  

(I am interested in bridging via the token ring or Ethernet).

Thanks in advance,

John Holmes
(619) 485-2540
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 00:54:08 GMT
From:      pmafire!mica.inel.gov!sixmile!jfp@uunet.uu.net  (Jeff Pack)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VAX 11/750 as Internet Gateway?

In article <1865@fallst.UUCP>, tkevans@fallst.UUCP (Tim Evans) writes:
|> Looking for a low-cost way to connect to the Internet, it occurs
|> that a spare VAX 11/750 running 4.2BSD might be used as a gateway.
|> Can anyone comment on whether/how well this might work?  I think
|> I understand that BIND might not work without a lot of recompiling,
|> but presumably I could run the resolver on another machine in the
|> local network.  What else?
|> 
|> I will summarize if there's interest.
|> -- 
|> UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
|> INTERNET:	tkevans%fallst@wb3ffv.ampr.org
|> Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

You may want to check into the subnetting issues involved with BSD 4.2.
If I remember right, it's not particularly clean....
---------------------------------------------------------------
Jeff Pack                         UUCP:  ...!uunet!inel.gov!jfp
Idaho National Engineering Lab    Internet:  jfp@inel.gov
P. O. Box 1625 M.S. 2603          Phone:  (208) 526-0007
Idaho Falls, ID 83415             FAX:  (208) 526-9936
========== long legal disclaimer follows, press n to skip ===========
^L
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Dec 90 10:33:52 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: needs VT220 host, was emulation
    The specific question is: how does this integrate with Telnet and how does
    a Unix host have to be setup to use 8859?

We've been doing this for a while now, and not nearly enough people have
picked up on it.  Maybe this will help the process...

What we did was designed to interoperate with DEC VMS systems, since they
were the first widely-available Ascii-based hosts to support both useful
8-bit data streams and ISO-Latin.  PC/TCP's VT220 Telnet does the following:

a. Offers a "DEC-VT220" terminal type option value (per RFC 1091)

b. Accept VT220 escape sequences to switch between "VT220 7-bit" and "VT220
   8-bit" modes.  When entering 8-bit, we initiate negotiations for the Telnet
   "Binary" option (we also initiate it on user request).

c. If "Binary" is accepted, we switch to sending 8-bit CSI sequences instead
   of the 7-bit versions.  If "Binary" is refused, we continue to send the
   two character 7-bit CSI, since the single-character 8-bit version would
   probably get destroyed by a masking operation at the server.

d. Accept standard 7-bit or 8-bit CSI values regardless, including the
   sequences which display the VT220's "ISO Latin" characters.

It's complicated, there are pitfalls (some applications won't accept 7-bit
CSIs if they have sent the "switch to 8-bit VT220 mode" command, but we
can't send 8-bit because the "Binary" option was refused - solution is to
fix the host's Telnet server), but in general it works for those who can
be satisfied by ISO Latin.  It is interoperable to the extent that the
8859 alphabets can be (as long as the community uses the same subset of
it).  It is a general solution because it is based on the terminal type,
and hosts/applications understanding that VT220s can switch to 8-bit mode.
Unix doesn't understand 8-bit terminals in general, and normally runs the
VT220 in 7-bit mode, so it needs quite a bit of work on the host side to
get off the ground.

A possible first major improvement is to propagate 8-bit-awareness (most
conveniently in the guise of a VT220) to the Unix of your choice.  If an
application works with a direct-attached VT220 in 8-bit mode (set via the
'init-string' in termcap or whatever), it would only need a cooperative
Telnet server to work over the net - this requires careful consideration of
which of the available terminal modes would most usefully map to "Binary"
('raw' doesn't cut it).

A more far-reaching solution is to switch to 16-bit or 32-bit characters.
Of course, the theory is that this will make the whole world happy (I may
not be able to pronounce some of the characters I see displayed, but I can
forward the message intact to someone who does), but it isn't anywhere
near general availability yet.  If this is done as DBCS or ISO-646
successor terminals become available, it can just continue to use the
Telnet Terminal Type and Binary options, and will remain backwards
compatible.  I would discourage anyone setting out to write a "Telnet DBCS
(or whatever) data stream option" RFC, because it bypasses the Terminal
Type and loses backwards compatibility.

Getting anywhere with any of the available Unices will probably require
either source code or vendor cooperation.  If your Unix vendor is interested,
they can talk to/test against us, but so far I haven't been approached
by any willing to admit that there was anything to learn from VMS, or who
felt that improving support for a DEC terminal was in their interest...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Dec 90 10:37:51 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil, usc!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mailer.cc.fsu.edu!prism!ce1zzes@ucsd.edu
Subject:   Re: NDIS spec.
	
>I'd like to add that Ungermann-Bass' last quote on the yet-to-be-released
>NDIS driver for their NIU (not NIC) cards is $395 for the TCP stack version.  

Er, by, "TCP Stack version," they must mean they include a TCP stack. The
NDIS driver for the NIU card cost $50, last I checked, and was already 
released two months ago, when we went and got it for testing.

Works fine, btw.


	

Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Dec 90 12:09:52 PST
From:      postel@venera.isi.edu
To:        iana@venera.isi.edu, sdcc6!mbongo!lindwall@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Looking for USD TCP/IP registry
The base document is called "Assigned Numbers" and was most recently published
as RFC-1060.  The group that maintains the data is called the "Internet
Assigned Numbers Authority" (or IANA) and is located at the Information
Sciences Institute (ISI) of USC.  ISI is in Marina del Rey.  The staff of the
IANA is Joyce Reynolds & Jon Postel.

Specific question may be addressed to "IANA@ISI.EDU".

--jon.

   Date: 12 Dec 90 02:25:37 GMT
   From: sdcc6!mbongo!lindwall@ucsd.edu  (John Lindwall)
   Subject: Looking for USD TCP/IP registry
   To: tcp-ip@nic.ddn.mil
   
   [I hope this is an appropriate location...]
   
   In the Dec 10 "Communications Week" we saw an sidebar which
   mentioned a registry maintained at the University of Southern
   California.  It includes data from >130 vendors about their
   networking systems.  It says "The TCP/IP community chose a
   university as the guardian of this registry in an attempt
   to provide an open way for users, vendors, and systems
   integrators to access this information".  I just wish the
   article had mentioned how/where to locate this document!
   
   If anyone has any pointers to this registry please email
   (or post if it's globally interesting information).  I have FTP
   access.  Thanks!
   
   John
   -- 
   John Lindwall			lindwall@ucsd.edu
   "Oh look at me! I'm all flooby! I'll be a son of a gun!" -- Flaming Carrot
   

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 04:39:49 GMT
From:      att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pdcst@ucbvax.Berkeley.EDU  (Patrick D. Champion)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP on DOS workstations.

	What do I need to do to get telnet and ftp to recognise name 
addresses that don't exist in my /etc/hosts file?  I can ftp and telnet
given the number addresses.  For example ftp 26.2.0.74 gets me simtel20
but I can't give the name wsmr-simtel20.army.mil unless I put it in my
hosts file. 
	I have tried creating a  /etc/named.boot  file with the name of a
supposed server in it.
		secondary	pitt.edu	130.49.1.254
I think that was the line as well as the primary and my suns address
but I still can ftp to any name.

	What am I missing?  I have a Sun386i on the internet and our
sendmail runs fine with names.  

Pat Champion
pchamp@edc3jr.gsph.pitt.edu
pdcst@unx.cis.pitt.edu
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Dec 90 14:53:47 -0500
From:      Bob Stewart <rlstewart@eng.xyplex.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Boeing and Internet
> 	I am somewhat suprised that Laurie Bride would make a rash statement
> like that. I obviously had a higher opinon of her than she deserved. It
> would seem that she needs to read the Open Book and reassess her statements.

Has anyone checked with Laurie Bride to see if she may have been misquoted?

	Bob

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 12:03:20 GMT
From:      roes@phcoms.seri.philips.nl (Aloys Roes)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   FTP server, VMS 5.4 (new password hashing)

We recently received VMS 5.4 and found that it introduced a new password
hashing algorithm. For normal use this is no problem however, a number of
FTP servers do their own checking of passwords and use the older hashing
algorithm for that. So whenever a user changes his password under VMS 5.4
he/she can no longer FTP into that account. We have this problem with the 
following TCP/IP implementations: FNS version 3.3.7, Novell LAN-service
version 3.5 (EXCELAN) and CMU 6.5. The other TCP/IP implementations that 
are used in our company (UCX from DEC and WIN/TCP from Wollongong)
have solved the problem by using LOGINOUT.EXE for password checking.

Does anyone know if there are solutions for the above three TCP/IP
implementations and how we can get hold of them?

Thanks,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl

-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 13 Dec 90 23:21:39 -0500
From:      ado@BBN.COM
To:        tcp-ip@nic.ddn.mil
Cc:        ado@BBN.COM
Subject:   forward igp?
What will various ip routers do with an ip packet that is recieved
which is not destined for the router, but which has ip protocol type
IGP?  (Or which carries the ip protocol id of whatever routing
protocol the router is using for its igp.)  It seems clear that a
router following the directives of the router requirements draft will
blithely forward the packet.  Will any routers instead drop the
packet, or incorrectly try to process the packet?

Is it explicitly intended that IGP and other routing protocol packets
may be forwarded?  Do any existing routers or routing protocols use
this capability?
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 15:05:51 GMT
From:      usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Can Someone Recommend Me a Reliable Datagram Protocol?
I am looking for a reliable datagram protocol.  Any recommendations?
I would like something simple like UDP but with reliability.  I want
to run it on top of IP.

Thanks.

--
Adnan Yaqub (adnan@sgtech.uucp)
Star Gate Technologies
29300 Aurora Rd, Solon, OH, 44139, USA, +1 216 349 1860
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 18:58:07 GMT
From:      ehrhart@etmsun.ericsson.se (Tim Ehrhart)
To:        comp.protocols.tcp-ip
Subject:   68k exec + BSD 4.3 TCP/IP


I am looking for 68k based executives with FULL BSD 4.3
TCP/IP support, not just socket layer support. It must
support multiple interfaces and routing protocols such
as EGP.

Can anyone help with references. Please reply by e-mail.

Thanx,
Tim Ehrhart
--
+ Tim Ehrhart                     EMAIL: ehrhart@ericsson.se  +
+ Ericsson Telecommunicatie BV    PHONE: +31 1612 29308       +
+ Rijen, The Netherlands	      FAX:   +31 1612 27160       +

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 19:08:36 GMT
From:      oracle@dayton.saic.com
To:        comp.protocols.tcp-ip
Subject:   XENIX and TCP/IP?


I have a 386SX machine with a 3COM 503 Etherlink II card, and a partitioned 
hard disk ( 10M DOS, and 30M XENIX ).  The DOS partition includes CU/TCP which
works fine under MS-DOS!  When I am running SCO XENIX System V rel 2.3.2, I
would like FTP and TELNET capability.  Is there a public domain package 
available for XENIX, or must I grovel for more money?  I am a XENIX rookie
and would appreciate any help/guidance.

Thanx in Advance,

Tim
_____________________________________________________________________________
  ____ ____    ___               Tim Granger
 /___ /___/ / /     Science Applications International Corporation
____//   / / /___                Dayton, Ohio
-----------------------------------------------------------------------------
           Internet: Oracle@Dayton.SAIC.COM  uucp: uunet!dayvb!Oracle

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 20:25:25 GMT
From:      fmbutt@mrbt.sw.stratus.com (Farooq Butt)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Ethernet Vs. IEEE 802.3 ??????????


Net.TCP/IPGurus:
(I'll save net.bandwidth and keep it brief...)

Is IEEE 802.3 the very same thing as the "Ethernet" standard ?  In what 
ways are the two different ?  I know that 802.3 is usually implemented 
at a hardware level, what about "Ethernet" ?  Which one is older ?  
Does using one seriously preclude you from connecting with machines 
using the other flavor ?  Finally which is "better" ;-) ?

thanks for your input,

-fmb

--
Hi-Tech Disclaimer: NOTHING in the above article has any relationship
            to reality. If any reality correspondences are found, 
            please notify me IMMEDIATELY.  Any threats or abuse 
            of any kind is purely unintentional. My employer is not liable.  

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Dec 90 09:50:06 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        ado@BBN.COM
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: forward igp?

Well, actually, at the last router requirements meeting I suggested that
RIP and all routing protocols which broadcast updates should require
the TTL of the outgoing packets to be set to 1.  This will result in
a TTL expiration if a router attempts to forward it.  

In OSPF, we multicast instead of broadcast, so normally, routers not running
the protocol will never see the traffic.  However, in the case that someone
has a bug in their multicast support, they might still try and 
forward it, which is why we also specified all multicasts should have
a IP TTL of 1.  Sure enough, we ran into someone who had such a bug about
a month ago, and the only thing that prevented it from trying to forward
the datagram was the TTL being set to 1.  

In general, routing packets should never be forwarded, but because of 
problems with certain implementations not being able to tell if a particular
packet came in via a media level multicast, you can still run into trouble.
This is why the setting of the TTL to 1 is a good idea.


						Thanks,
						   Milo
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 21:38:07 GMT
From:      usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!scotty.dccs.upenn.edu!tony@ucsd.edu  (Anthony Olejnik)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for help with IBM's 3172 and MVS
I'm going thru a *GREAT* learning curve on this, so please pardon
me if this request sounds like its coming from a novice (its only
because I *AM* a novice at this).

We have an MVS system which we are trying to bring up IBM's TCP/IP
product using a 3172.  We think we have both the software on the
host side configured correctly as well as the software on the 3172.

However, we are getting the following error message:

	IEE025I UNIT C00 HAS NO LOGICAL PATHS

Looking thru the manuals for additional info on this indicates that
the varried device online command has not been executed.  The operator
action is supposed to make sure that the channel is enabled and the
device set online. The 'UNIT C00' is the address of our 3172 in our
configuration.  We think that the channel is enabled and the device 
is already set online.

So, can anyone help us out on this?
What is ment by 'no logical paths'?
Is there a way we can verify that the channel is enabled?
Is there a way we can verify that the device is online?

Any help would be *GREATLY* appreciated.

Thanks.

--Tony Olejnik
  University of Pennsylvania
  Data Communications and Communications Services
  Suite 221A
  3401 Walnut Street
  Philadelphia, PA 19104
  (215) 898-9408
  tony@scotty.dccs.upenn.edu
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      13 Dec 90 22:08:12 GMT
From:      he@spurv.runit.sintef.no (Havard Eidnes)
To:        comp.protocols.tcp-ip
Subject:   Re: Translating names/addresses to human-readable descriptions

In article <1990-344-45711@uunic.uu.no>, erik@naggum.uu.no (Erik Naggum) writes:
|> In article <9012110031.AA11352@warschawski.geom.umn.edu>,
|>               slevy@POINCARE.GEOM.UMN.EDU (Stuart Levy) writes:
|> > Beware: the TXT RR is unknown to the BIND 4.8 server, which is still
|> 
|> Aaarggh!  I thought it would be enough to write an SMTP implementation
|> for UNIX platforms.

May I remind you that BIND 4.8.3 has support for TXT records. However, the
claim that its predecessors (4.8, 4.8.1) are still in widespread use is 
still valid, and that's probably not going to change overnight.

- Havard

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 01:00:44 GMT
From:      dynasys!jessea@rutgers.edu  (Jesse W. Asher)
To:        tcp-ip@nic.ddn.mil
Subject:   How can I forward mail without bind or named?
I've got a 3B2 running SysV 3.0 with an equally old version of TCP/IP.
The problem is that this older version of TCP/IP does not have either bind
or named so I can't forward mail bound for hosts that are not listed in
/etc/hosts.  My question is:  Is there a way to forward mail to a specific
host (so it can resolve the appropriate address from the name) using some
other facility (like sendmail)?  If so, exactly what do I need to do to
get this working.  We are working on getting this updated, but I'm sure
it will be a while and I need to use it now.  I would appreciate any help.


---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---
      Jesse W. Asher                             Phone: (901)382-1609 
               6196-1 Macon Rd., Suite 200, Memphis, TN 38134
                UUCP: {fedeva,chromc,rutgers}!dynasys!jessea
 -> 
-- 
      Jesse W. Asher                             Phone: (901)382-1609 
               6196-1 Macon Rd., Suite 200, Memphis, TN 38134
                UUCP: {fedeva,chromc,rutgers}!dynasys!jessea
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 02:27:04 GMT
From:      terry@csd.uwo.ca (Terry Cudney)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP / PPP


     Is SLIP and/or PPP source available for anonymous ftp? Indeed, are they
freely redistributable? If so, where are they located? IP numeric addresses
would be appreciated, since our site doesn't understand domain names :-(.
Thanks.

-- 
--terry
/* terry@chaplin.csd.uwo.ca
 * Terry Cudney Amistosa MicroWare 9 Durham Street, LONDON, Ontario, N5Y 2H9
 */

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Dec 90 10:52:24 -0500
From:      mrf@ftp.com
To:        sco!ericd@uunet.uu.net  (Eric Davis)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP From DOS
To: sco!ericd@uunet.uu.net  (Eric Davis)
Subject: Re: TCP/IP From DOS
From: mrf@babyoil.ftp.com
Reply-To: support@ftp.com
Cc: tcp-ip@nic.ddn.mil

    SCO has a TCP/IP package for DOS. It will allow your DOS machine to do 
    all of the things mentioned above, and MORE!
    
    Eric Davis                                      ericd@sco.COM
    Techinical Support Engineer                     {uunet|ucsc|att}!sco!ericd
    The Santa Cruz Operation, Inc.

There are also several other vendors who supply TCP/IP products for
DOS PC's.  The commercial products with which I am familiar are
PC NFS from Sun Microsystems, WIN/TCP from Wollongong, Beame and
Whiteside's TCP/IP product, and FTP Software's PC/TCP.  There are
also several public domain packages which may include the
functionality that you require.

There is a mailing list called pcip@udel.edu (which can be joined
by writing to pcip-request@udel.edu) which deals with TCP/IP 
running on DOS PC's (both commercial and public domain packages).
A posting to the pcip mailing list is likely to provide you with a more
complete list of available packages than any one person can supply.

I hope that this information is useful to you.

Margaret Forsythe	Technical Support	FTP Software, Inc.
(617) 246-2920		FAX: (617) 245-7943	E-mail: mrf@ftp.com
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Dec 90 15:56:23 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pdcst@ucbvax.Berkeley.EDU, tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP on DOS workstations.
What name services TCP/IP applications use is implementation
dependent.  Our PC/TCP can use host tables, domain name servers and
IEN-116 name servers, but I'm not sure how common that is. I've heard
some packages require particular name servers, but only using hosts
files seems unduly restrictive. It's worth checking your software's
configuration information, to see if there is an option you are not
using, or posting again with information about who's TCP/IP you have.


Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 09:30:29 GMT
From:      snms4@vaxb.acs.unt.edu
To:        comp.protocols.tcp-ip
Subject:   Hughes Lan System MIB extensions


         I suppose I should have tried the NET first, but I really
         like to think that the best source of support is usually the
         vendor. (*guffaw*)

         I'm installing this really wonderful "free, unsupported,
         available-to-all" SNMP software on my PC that runs with the
         packet driver.  It doesn't support the entire rfc1156 MIB
         (only the system, interfaces, at & ip top level variables)
         but the primitives are there in the enclosed library to, I
         hope, enable you to support anything you dang well please in
         your own program.

         Here's the problem: As far as agents go, I've got Cisco
         routers, and Hughes Lan Systems terminal servers.  I've got
         the Cisco MIB, but the folks at the Hughes Technical
         Assistance Center tell me that there is no written document
         in existance (available to me, anyway) that details the
         Hughes MIB extensions.  It's all supposedly hardcoded into
         their SUN software.

         Is there anyone out there who's running the Hughes SNMP
         software for Suns?  Does it come with a listing of the MIB? 
         Does anyone know where I can get a copy of the Hughes MIB? 
         I'm not looking for something 'on the sly', but rather hoping
         that there's a remote chance the fellows I talked to at
         Hughes could have been mistaken and there really is a
         public-access file documenting the Hughes MIB extensions that
         I can get to.

         Thanks in advance,
         Kevin Mullet
         University of North Texas
         ----
         oh... by the way:  When I got the Cisco MIB, they pointed me
         to a host that had just TONs of MIB extensions online. 
         naturally, I lost the address.  Would anyone know where this
         is?

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 14:27:26 GMT
From:      princeton.edu!tengi@princeton.edu  (Christopher Tengi)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for a VMS (CMU/TEK) POP or IMAP server
Greetings,
    Does anybody out there know of any POP or IMAP server that runs
under VMS, using CMU/TEK for the transport?  Naturally, the lower the
cost, the better, but we are interested in anything that might be out
there.  We are also running the RPI MX mailer on this VAX, if that
makes a difference.  Please reply to me by mail, and I will
summarize....

					Thanks,
						/Chris
-- 

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 14:41:49 GMT
From:      julius.cs.uiuc.edu!rpi!uupsi!sunic!dkuug!daimi!jt!erl@apple.com  (Erik B. Larsen)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP printning

Do anyone know how you should configurate the /etc/printcap file
on a Sun if you want to print to an IP-adress.


Regards



Erik Bruijn Larsen
Sun System Administrator
Jutland Telephone Company
Denmark
Email: erl@jt.dk
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 15:22:29 GMT
From:      doug@jhunix.HCF.JHU.EDU (Douglas W O'neal)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: FTP server, VMS 5.4 (new password hashing)

In article <566@phcoms.seri.philips.nl-> roes@phcoms.seri.philips.nl (Aloys Roes) writes:
->We recently received VMS 5.4 and found that it introduced a new password
->hashing algorithm. For normal use this is no problem however, a number of
->FTP servers do their own checking of passwords and use the older hashing
->algorithm for that. So whenever a user changes his password under VMS 5.4
->he/she can no longer FTP into that account. We have this problem with the 
->following TCP/IP implementations: FNS version 3.3.7, Novell LAN-service
->version 3.5 (EXCELAN) and CMU 6.5. The other TCP/IP implementations that 
->are used in our company (UCX from DEC and WIN/TCP from Wollongong)
->have solved the problem by using LOGINOUT.EXE for password checking.
->
->Does anyone know if there are solutions for the above three TCP/IP
->implementations and how we can get hold of them?
->
A post came out on the cmutek mailing list on 3-dec-1990 that a patched
ftp is available from 128.2.232.20 and it will be included in future
distributions of cmutek tcp/ip

Doug

-- 
Doug O'Neal, Distributed Systems Programmer, Johns Hopkins University
doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu, mimsy!aplcen!jhunix!doug 
Like many of the features of UNIX, UUCP appears theoretically 
unworkable... - DEC Professional, April 1990

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 14 Dec 90 15:26:28 GMT
From:      Sean Mc grath <sean@fiamass.ie>
To:        tcp-ip@nic.ddn.mil
Cc:        sean@fiamass.ie
Subject:   TCPIP ping problem

Apologies for being a bit short in information with my last posting.  here
is a more complete description of my problem.  

Hardware :-
	Two Nec 386 PC machines.
	1 with wd8003 ethernet board.
	1 with 3c503 ethernet board.

Software :-
PC/TCP  from FTP software version 2.05

The machines are connected over thin ethernet forming a bare two machine
network.

Configuration is as follows :-

Machine A                         Machine B                       
==========                        ==========
IP address : 192.9.200.2          IP address : 192.9.200.7
Ethernet   : 2:60:8c:d:a1:a3      Ethernet   : 0:0:c0:d3:55:18
3c503 ethernet board.             WD8003 ethernet board.

local file used on either end as hosttable. (Files are identical)

time ordering of events is as follows :-

Machine A            Machine B                   Result 
==========           ==========                  =======
reboot.              Reboot.
inet arp                                         cache empty
                     inet arp                    cache empty
                     ping A                      ARP fails. Host unreachable.
inet arp                                         cache empty
                     inet arp                    cache empty
ping B                                           Succeeds.
inet arp                                         Entry for B in cache.
                     inet arp                    Entry for A in cache.

It seems to me that machine A must be caching the ethernet address of B
after B does "ping A" otherwise its own ping would fail.  If so, why do
the caches look empty?  Any help would be gratefully received.

Sean Mc Grath (sean@fiamass.ie)
Fiamass Ltd.
12 Clarinda Park North
Dun Loaghaire
Co. Dublin
Ireland.


-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 15:45:07 GMT
From:      usc!julius.cs.uiuc.edu!zweig@ucsd.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCPIP ping problem
At a wild guess I would say it's an ARP problem.  If neither machine is
answering ARP requests, but both see the requests from the other host and
update their ARP caches you cou ld have a stat in which each machine had to
attempt to ping (or telnet/rlogin/ftp/anything else) the other for them to be
able to talk.  A way to test this would be to have A and B both ping C (which
needn't actually exist) and see if they notice each other.

-Johnny Guessing
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 16:13:49 GMT
From:      psuvm!ysub!msu!cmuvm!34aej7d@psuvax1.cs.psu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   KA9Q
Does anyone know the ftp site for the most current version of the
KA9Q software?
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 16:26:25 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!darrell!gaudi!zimmer.CSUFresno.EDU!jimm@apple.com  (Jim Michael)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for help with IBM's 3172 and MVS
tony@scotty.dccs.upenn.edu (Anthony Olejnik) writes:

>I'm going thru a *GREAT* learning curve on this, so please pardon
>me if this request sounds like its coming from a novice (its only
>because I *AM* a novice at this).

>We have an MVS system which we are trying to bring up IBM's TCP/IP
>product using a 3172.  We think we have both the software on the
>host side configured correctly as well as the software on the 3172.

>However, we are getting the following error message:

>	IEE025I UNIT C00 HAS NO LOGICAL PATHS

>Looking thru the manuals for additional info on this indicates that
>the varried device online command has not been executed.  The operator
>action is supposed to make sure that the channel is enabled and the
>device set online. The 'UNIT C00' is the address of our 3172 in our
>configuration.  We think that the channel is enabled and the device 
>is already set online.

>So, can anyone help us out on this?
>What is ment by 'no logical paths'?
>Is there a way we can verify that the channel is enabled?
>Is there a way we can verify that the device is online?

I would refer anyone having this sort of difficulty to the appropriate
System Commands manual for their version of MVS.  In my case (MVS/ESA) I
use IBM manual GC28-1826-2.

In particular review the sections on display unit, display M (system
configuration info) for CHP and dev. Vary command for unit and path and
config for the CHP.

I have responded in for detail to the original poster.  This is more
than RTFM because somtimes it's a case of WHICH FM! ;-).

Jim


-- 
Jim Michael - jim_michael@CSUFresno.EDU

My opinions are my own ... what else?
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      14 Dec 90 21:05:48 GMT
From:      mips!twg.com!david@apple.com  (David S. Herron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: List of streams-based Protocol suites / Communication Packages
In article <1990Dec11.174624.26388@diku.dk> krus@rimfaxe.diku.dk (Lars Povlsen) writes:
>Name		: Wollongong TCP/IP
>Manufacturer	: The Wollongong Group
>OEMs		: ?
>Product		: Full TCP/IP implementation
>OS'es supported	: SCO, ATT V.4, VMS
	Also on AT&T SysVr3.2, Intel r3.2, Interactive r3.2, etc.
>Architectures	: i80386, i80486, Vaxen
>Comments	:

Also, a new product:

Name		: Wollongong OSI
Manufacturer	: The Wollongong Group
OEMs		: 
Product		: OSI Upper & Lower layers in STREAMS, can connect directly
		:	to X.25 switches
		: OSI X.400 mailer with UUCP/SMTP & RFC-987/1138/1148 gateway
		: OSI X.500 Directory server
OS'es supported	: SCO/Unix, SCO/ODT, AT&T SysVr3.2, Intel r3.2, Interactive r3.2
Architectures	: i386
Comments	:

Contact sales at (415) 962-7202 for more information.


-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- "bnews must die" -- From:    Rick Adams <rick@uunet.uu.net>
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sat, 15 Dec 90 02:03 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Adnan Yaqub <usenet.ins.cwru.edu!abvax!sgtech!adnan@tut.cis.ohio-state.edu>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: Can Someone Recommend Me a Reliable Datagram Protocol?
If by "reliable datagram protocol" you mean a protocol that is transaction-
oriented, preserves record boundaries, has low-overhead association
establishment but includes reliability mechanisms, then I recommend that you
take a peek at XTP and VMTP.  VMTP is written up in a pair of RFCs; XTP was
described in a recent issue of Computer Communication Review.

- Bob Stine
  bstine@MCIMail.com

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 90 02:55:51 GMT
From:      n8emr!vlink01!sfrazier@tut.cis.ohio-state.edu  (8780)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet Configuration
I finally have a copy of NCSA Telnet and have some questions on the
configuration to my TCP/IP network.  Could some email me their name if
you are willing to help me out.  I have only a couple of questions and
would appreciate some help.

Thanks in advance.

-- 
V-Link                                  | Steven E Frazier
1828 Darrow Drive                       |---------------------------------------
Powell OH   43065-9261                  | Local : sfrazier
614-365-3056                            | Remote: osu-cis!vlink01!sfrazier
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 90 05:09:22 GMT
From:      uflorida!mailer.cc.fsu.edu!sun13!ds1.scri.fsu.edu!curci@gatech.edu  (Raymond Curci)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can Someone Recommend Me a Reliable Datagram Protocol?
In article <62@sgtech.UUCP> adnan@sgtech.uucp (Adnan Yaqub) writes:
>I am looking for a reliable datagram protocol.  Any recommendations?
>I would like something simple like UDP but with reliability.  I want
>to run it on top of IP.
>
>Thanks.
>
>--

As you say, UDP is unreliable.  If you need reliability, you should
use TCP over IP.  I belive that in most peoples' minds, the phrase
"reliable datagram" would be considered an oxymoron.

--
Raymond Curci                     INTERNET: curci@mailer.scri.fsu.edu
Systems Engineer                  UUCP:     ...!uunet!mailer.scri.fsu.edu!curci
Institute of Molecular Biophysics SPAN:     46453::curci -or- SCRI1::curci
Florida State University          BITNET:   curci@fsu.bitnet
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 90 07:49:50 GMT
From:      ichihara@rik835.riken.go.jp
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: FTP server, VMS 5.4 (new password hashing)

> Newsgroups: comp.os.vms,comp.protocols.tcp-ip
> Subject: FTP server, VMS 5.4 (new password hashing)
> Message-ID: <566@phcoms.seri.philips.nl>
> Date: 13 Dec 90 12:03:20 GMT
> Organization: Philips Components - SERI, Eindhoven, The Netherlands
> Lines: 23
> Xref: rkna50 comp.os.vms:13276 comp.protocols.tcp-ip:10256
>
> We recently received VMS 5.4 and found that it introduced a new password
> hashing algorithm. For normal use this is no problem however, a number of
> FTP servers do their own checking of passwords and use the older hashing
> algorithm for that. So whenever a user changes his password under VMS 5.4
> he/she can no longer FTP into that account. We have this problem with the 
> following TCP/IP implementations: FNS version 3.3.7, Novell LAN-service
> version 3.5 (EXCELAN) and CMU 6.5. The other TCP/IP implementations that 
> are used in our company (UCX from DEC and WIN/TCP from Wollongong)
> have solved the problem by using LOGINOUT.EXE for password checking.
>
> Does anyone know if there are solutions for the above three TCP/IP
> implementations and how we can get hold of them?

    Hi

    For the CMU-TEK V6.5, we have already solution.  I have tested 
 following release of FTP and this new FTP works fine in the VMS V5.4 
 after changing passwords.
   			
						T. Ichihara (RIKEN)

==========================================================================
Message-Id: <cbKhYcK00aMeQ=NmpM@andrew.cmu.edu>
Date: Mon,  3 Dec 90 18:00:56 -0500 (EST)
From: "Bruce R. Miller" <bm17+@andrew.cmu.edu>
To: CMU TEK <cmu-tek-tcp+@andrew.cmu.edu>
Subject: FTP
 
 
I forgot to mention something.  I fixed up FTP so that it works
with VMS 5.4.  It requires differant object code though, so I made
up an installation kit (available via anonymous FTP from 128.2.232.20)
which figures out what version of VMS you're running, and links
in the proper password hashing code.  This means that you need
to install the new FTP kit when you upgrade to VMS 5.4.  It won't
work to install it now before you upgrade.  You have to be running
VMS 5.4 in order for the kit to do the right thing.   I know this
is confusing, but the only alternative was to distribute seperate images.
 
On a related note, I'm reconfiguring the package so it will work with
VMS 4.x.  If I can pull this off, Tek 6.6 will run under VMS 4.5 and above.
Hopefully some of the 6.6 beta testers will be running ancient versions
of VMS.
 
-bruce r miller
 CMU NetDev

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Dec 90 20:34:07 GMT
From:      usc!cs.utexas.edu!ut-emx!emx.utexas.edu!mclay@ucsd.edu  (Robert McLay)
To:        tcp-ip@nic.ddn.mil
Subject:   Making [C]SLIP work on SUN SLC and 4/330 ?

I am now the proud owner of a SLC and 660MB at home.  I am trying to
implement SLIP (serial line IP) between the SLC and a SUN 4/330 at
work (all running sunOS 4.1).  I have a pair of telebit T2500's modems
to run between the two machines.  I am interesting in mainly getting
compressed-slip running between the two machines but right now I can't
get even slip running.

The instructions that come with the slip-4.0.tar (from uunet.uu.net
among many other places) is very clear on the modifications to the
kernel and the programs to compile in order to get it to work.
However it is not clear (at least to me :-) how to actual use the thing.
I have read the README's in the distributions and even the rfc's
(rfc1055 (SLIP) and rfc1144 (CSLIP)) but it is not very clear.

Here is what I've done so far:
1) modified the kernel, re-built it and installed it and rebooted
2) compiled sliplogin, install it with setuid set to root.
3) created a file called /etc/hosts.slip:
________________________________________________________________________
mclay normal 97.83.152.29 97.83.152.135  255.255.0.0
________________________________________________________________________

4) then on the machine at home (SLC) I do:

slc> tip tb19200      # tip to Telebit T2500
connected
atdt1234567           # dial T2500 at work connected to sun4/330
...
sun4/330 login: mclay # login to sun4/330
Password:
...
sun4/330> sliplogin   # use /etc/hosts.slip

________________________________________________________________________
 At this point this window will not respond.  In /var/adm/messages (on
the 4/330) I get messages telling me that a sliplogin is happening and
that slip is coming up. 

In other windows on the sun4/330 I try doing ping 97.83.152.135 to
ping the machine at home (SLC) back from the 4/330.  If I do this then
I get junk characters in the window on the SLC with the sliplogin command.

Note also that the 97.83.152.135 for the slc and the 97.83.152.29 for
the 4/330 are fictitious.  I was told that they should not be the same
as the normal IP addresses but I am not sure why.  I assume that I am
missing something.  Do I need to run sliplogin on both machines?  If
so, how?

Assuming that I do get SLIP and CSLIP running,  Has anyone else had to
do all the modifications that Pieter H.A. Venemans (sun-at-home vol3
issue 19) had to go through.

Also on another front.  There are serious complaints against sunOS 4.+
with the streams implementation by Van Jacobson in his note in 12/31/89.
Is there a better way to do this?  I have seen a slip-4.1-beta from
Mark.Andrews@syd.dms.csiro.au but it is not clear at all how to
integrate the cslip stuff in it.  Also it seems to be a streams based
implementation and subject to the same criticism.

If someone could tell where to RTFM, I will be very a happy to read
the manual if I could only find one.

Robert McLay
Manager CFDLAB suns
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Sun, 16 Dec 90 18:59:45 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.arc.nasa.gov>
To:        bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!stealth@bloom-b.eacon.mit.edu  (Mike Pelletier)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing

That's not a bug but a feature!  Late model BIND resolver code has a security 
feature in it which causes this behavior.  Basically, if your code does
a gethostbyaddr call to the DNS, the resolver will query the DNS system for
a PTR record for the address passed to it.  The old code would then return 
the reply, without verification.  The new code goes one step farther by
then additionally doing a gethostbyname call on the returned name, and verifying
the name has the original address as one of the A records associated with it. 
This makes DNS spoofing significantly harder, and thus things that make use of 
.rhosts and such less of a security problem.  

The problem in your case is that whoever runs your DNS configuration accidentally
left out the address in question, or used the wrong name in the PTR record.
Have nslookup check out the A records associated with ccb3.merit.edu, and I
think you'll see the error.  The syslog message basically says that
ccb3.merit.edu does not have 35.1.48.130 as one of it's interface addresses.

If you don't like seeing this message, just change your syslog configuration
to ignore it.  Otherwise, it's telling you about a configuration error in the
DNS...

						Thanks,
						   Milo

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 90 14:52:13 GMT
From:      sdd.hp.com!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!gauss.math.purdue.edu!wilker@ucsd.edu  (Clarence Wilkerson)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet 2.2 bug in mput mget, etc on PC
In the commands that require processing a list sent from
the remote back to the PC, the PC version does not correctly
detect the end of the list, and after performing the asked
for transfers, starts trying to transfer whatever garbage
names are left in the buffer.
  If one originates the connection on the remote machine, and
then ftp's back to the PC, the multiple commands perform as
as expected.
Clarence Wilkerson

The beta copy of Telnet 2.3
I  tried out did not work with my 2,2 configeration file,
so I don't know that the problem is there also
.

3
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 90 18:35:34 GMT
From:      ndsuvm1!mtus5!pecampbe@cunyvm.cuny.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q
The most recent ka9q stuff is released in /pub/ka9q at thumper.bellcore.com
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 90 19:05:49 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   NSFNET rules and forwarding non research/education e-mail/news

On 7 Dec 90 15:07:00 GMT, GD.WHY@FORSYTHE.STANFORD.EDU (Bill Yundt) said:

WHY> I further remind all users of this mail list that it and
WHY> the Internet access to it are intended for support of
WHY> research and education and not purely commercial interests
WHY> of the kind Mr. Booth is pursuing.

Are you sure he was addressing the mailing list and not just the USENET
newsgroup? The kind of query he makes is entirely within the accepted
norms of behaviour for a USENET poster.

There is a large number of equivalent articles in USENET, and so long as
they have some interest for a wider readership (and surely the issue of
KA9Q's copyright status is of interest to many) or they are small, they
are within the bounds of accepted USENET practice.

WHY> I believe his use of USENET-to-Internet mail for this purpose to be
WHY> a violation of the Interim NSFNET use rules and am forwarding his
WHY> communication and this note to NSF authorities for their
WHY> information.

Indeed any _site_ that redistributed this article on NSFNET lines is in
violation of NSFNET rules, and a complaint should be lodged with their
system administrators.  The person involved is posting, I seem to
understand, on a private system, and has no control on the transport
resources chosen by gateways for distributing its postings.

The Path:

    Path: aber-cs!gdt!dcl-cs!ukc!mcsun!sunic!uupsi!rpi
    !zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!jarthur
    !nntp-server.caltech.edu!quotron.com!todd

tells us that it is Caltech that started the chain of violations of the
NSFNET rules by not screening all communications passing thru them to
reject those without education or research content. I would send a
complaint to NSFNET about Caltech's (and subsequent nodes) gross
disregard of the NSFNET rules, not about Mr.  Booth's adherence to
USENET rules, as you well say in:

WHY> Those supplying mail-forwarding for this class of traffic are, in
WHY> my opinion, in technical if not substantive violation of the
WHY> applicable use rules.

Ah yes, definitely yes.  It is probably a duty of sites connected to the
NSFNET to screen all mail and NNTP traffic passing thru them for the
purpose of rejecting any traffic in substantive violation of the NSFNET
guidelines, and the NSF should start immediately an investigation in the
gross waste of federal money involved if this is not done.

If I were in the USA, conforted by your opinion that *forwarding* the
posting you refer to is technically in violation of the NSFNET rules,
and that it has not been dropped by all the intermediate sites that have
used federal funds to propagate it, and that probably none of them does
it, I would write to my Representative Probably this abuse of federal
funds. NSFNET sites that do not screen mail and news passing thru them
and instead forward everything on NSF funded channels probably cost a
large amount of money every year to the taxpayer.

WHY> Bill Yundt
WHY> Executive Director, Bay Area Regional Research Network
WHY> Board Member, Federation of American Research Networks
WHY> Director, Networking and Communication Systems, Stanford University

Ah, just a curiosity, inquiring minds want to know. Are you *absolutely*
sure that none of the Professors at Stanford uses NSFNET bandwidth to
send or receive e-mail connect to private consultancies and similar
purely commercial initiatives?

I am sure that they are very careful about not making use of federally
funded research resources for private gain in general. I am ready to
agree that it is an internal matter for Stanford University to decide
whether or not to screen all traffic originating from their Professors
for possible violations of the NSFNET rules, or to rely on their
unquestioned integrity instead.

But maybe, a mere formality, of course, the NSF should insist (after all
it is federal money -- the Secret Service, or the GAO may well become
interested :->) instead on some auditing of the use of the NSFNET
bandwidth, to make it clear that the traditional University practice
that a certain amount of exploitation of University resources for
private purposes, including for profit ones, is permissible, does not
extend by default to NSFSNET resources, to which different and much
stricter rules apply.

For example, a Professor consulting and contacting his clients by e-mail
from his University workstation, as it may well happen technically, may
(I don't know really, I admit) be in this authorized by the University.

But the University probably must then find alternate non NSFNET funded
tranport channels for such e-mail, e.g.  by using UUCP mail on
commercial phone lines instead of SMTP mail over NSF funded TCP/IP
connections.

In other words, if the University (as I assume) allows staff (limited)
use of its facilities for personal or for profit purposes, it must pay
for this out of its own funds, not offload the expense onto federally
funded resources which are intended for research or education.


I guess that there are many and varied angles on such a simple issue as
respecting the NSFNET guidelines. It would be interesting to explore
tham all.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 90 19:13:45 GMT
From:      bu.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!caen!stealth@bloom-beacon.mit.edu  (Mike Pelletier)
To:        tcp-ip@nic.ddn.mil
Subject:   gethostbyaddr() failing
I'm running a daemon on a Sparcstation here, and it's running into
problems when people connect to it from dial-in ports on the Merit network.
The person connects, but the connection is immediately closed, after
the program logs:


Dec 16 13:47:19 arrakis irciid[5321]: gethostbyaddr: ccb3.merit.edu !=
	35.1.48.130

However:

130.48.1.35.in-addr.arpa	host name = ccb3.merit.edu

but, 

Non-authoritative answer:
Host name:   ccb3.merit.edu
Address:     35.1.48.129

The program is a modified telnetd, I gather.  Any suggestions on how
to get around this difficulty?

-- 
	Mike Pelletier - Usenet News Admin & Programmer
"Wind, waves, etc. are breakdowns in the face of the commitment to getting
 from here to there.  But they are the conditions for sailing -- not
 something to be gotten rid of, but something to be danced with."
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Dec 90 21:45:13 GMT
From:      hpcc05!hpdmd48!brown@hplabs.hpl.hp.com  (Kevin Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Code from Stevens' book

 just got a great book called "UNIX Network Programming," by Stevens.
There are lots of interesting routines and code fragments in the book. 
Does anyone know if they are available somewhere on the net? I'm trying
to avoid the typing.

Thanks
Kevin Brown
Boise Printer Division
Hewlett Packard
brown@hpbsm15.boi.hp.com
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 02:39:55 GMT
From:      agate!shelby!morrow.stanford.edu!root@ucbvax.Berkeley.EDU  (Victor Arnold)
To:        tcp-ip@nic.ddn.mil
Subject:   vt320 term emulation for tcp/ipip
Mike -

Do you UCX (VMS/Ultrix Conection) Version 1.3A or 1.3?
I understand that it is the latest and greatest and has
been out since October. I am currently running 1.2.

Thanks
Vic Arnold
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 02:43:58 GMT
From:      agate!shelby!morrow.stanford.edu!root@ucbvax.Berkeley.EDU  (Victor Arnold)
To:        tcp-ip@nic.ddn.mil
Subject:   vt320 emulation pkg for a PC
Friends -

I am looking for a product which will allow me to have full
VT320 terminal emulation on a PC (ms-dos) over tcp/ip. I only
really need telnet and ftp. Are there any good packages
around.

please respond via e-mail: Ma.VIC@forsythe.stanford.edu

Thanks
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 03:31:14 GMT
From:      EGKIM@KRSNUCC1.BITNET (Postmaster)
To:        comp.protocols.tcp-ip
Subject:   Q:Internet Connection creation.


This mail is from Seoul Korea.
Currently we have BITNET connection only  from abroad.
We donot yet have Internet connection.
On these days, we are going to establish a domestic network, KREN(
Korea Research & Education Network) newly.
KREN is TCP/IP based network.
To utilize KREN efficiently, we have to open a connection to Internet.
We hope to open Internet connection to US directly.
To whom should we contact, at first ?
To which site can we request to open a connection for us ?
Additionally it'll be preferrable if the site has also
a Bitnet connection cause we hope to run VMNET concurrently.

Therefore we are looking for kind approval letting us open
a connection.

Would you please give me favor ?
Any kind of help will be welcome.
Thanks in advance.

-Kim Eunkyung.

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 05:25:35 GMT
From:      uvaarpa!murdoch!murdoch.acc.virginia.edu!dwells@mcnc.org  (Don Wells)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Q:Internet Connection creation.

In article <9012170331.AA20512@ucbvax.Berkeley.EDU>
EGKIM@KRSNUCC1.BITNET (Postmaster) writes:

KE> Date: 17 Dec 90 03:31:14 GMT
KE> X-Unparsable-Date: Mon, 17 Dec 90 11:00:07 EXP

KE> This mail is from Seoul Korea.
KE> Currently we have BITNET connection only  from abroad.
KE> We donot yet have Internet connection.
KE> On these days, we are going to establish a domestic network, KREN(
KE> Korea Research & Education Network) newly.
KE> KREN is TCP/IP based network.
KE> To utilize KREN efficiently, we have to open a connection to Internet.
...
KE> To whom should we contact, at first ?
...
KE> -Kim Eunkyung.

An Internet connection to Seoul, Korea has been operating for many
months. I see that your BITnet node KRSNUCC1 is listed in the BITnet
routing tables as "Seoul Nat'l Univ CC, KR". I suggest that you talk
to the Administrative Contact for the KR domain, who is also in Seoul,
at an institute called "KAIST":

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

whois kr-dom
South Korea Domain (KR-DOM)

   Domain Name: KR

   Administrative Contact:
      Kim, Byung Chun  (BCK2)  bckum@sorak.kaist.ac.kr
      +82 296 23519
   Technical Contact, Zone Contact:
      Byun, Hee Soo  (HSB3)  bckum@sorak.kaist.ac.kr    <===== ERROR AT NIC
                             ^^^^^
                             hsbyun                     <===should be this.
                                                        (from the SOA record)
      +82 296 23519

   Record last updated on 06-Nov-90.

   Domain servers in listed order:

   KUM.KAIST.AC.KR		137.68.1.65
   PUGAK.KAIST.AC.KR		137.68.1.70

whois bck2
Kim, Byung Chun (BCK2)		bckum@sorak.kaist.ac.kr
   KAIST
   CSRC KAIST
   207-43 cheongryongri-dong dongdaemoon-ku
   Seoul
   KOREA
   +82 296 23519

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This computer at KAIST in Seoul is connected:

sorak.kaist.ac.kr = 137.68.1.1

ping -s 137.68.1.1
PING 137.68.1.1: 56 data bytes
64 bytes from 137.68.1.1: icmp_seq=0. time=879. ms
64 bytes from 137.68.1.1: icmp_seq=1. time=879. ms
64 bytes from 137.68.1.1: icmp_seq=2. time=860. ms
^C
----137.68.1.1 PING Statistics----
4 packets transmitted, 3 packets received, 25% packet loss
round-trip (ms)  min/avg/max = 860/872/879

telnet 137.68.1.1 25
Trying 137.68.1.1 ...
Connected to 137.68.1.1.
Escape character is '^]'.
220 sorak.kaist.ac.kr Sendmail 5.51/4.12/08-14-86 ready at Mon, 17 Dec 90 01:49:03+0900
quit
221 sorak.kaist.ac.kr closing connection
Connection closed by foreign host.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Good luck,


--

Donald C. Wells, Assoc. Scientist  |        dwells@nrao.edu
Nat. Radio Astronomy Observatory   |         6654::DWELLS
Edgemont Road                      | +1-804-296-0277      38:02.2N
Charlottesville, VA 22903-2475 USA | +1-804-296-0278(Fax) 78:31.1W
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 13:44:21 GMT
From:      rstevens@noao.edu  (Rich Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Code from Stevens' book
In article <15400001@hpdmd48.boi.hp.com> brown@hpdmd48.boi.hp.com (Kevin Brown) writes:
>
>There are lots of interesting routines and code fragments in the book. 

They're all at uunet.uu.net: pub/netprog.tar.Z

	Rich Stevens
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 14:59:43 GMT
From:      hpfcso!j_rodin@hplabs.hpl.hp.com  (Jon Rodin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NETBIOS/RFCs 1001/1002 Question
Issuing a NetBIOS call to a group name is non-deterministic.  If more than one
holder of the group name has a listen outstanding then the first response will
probably get the session.  If only one listen is out there, that will most
likely be the connected session.  If you need to connect to a specific node, 
don't use calls to a group name.  You could send out a datagram to a group name 
and have the interested parties respond with a datagram containing a unique 
name.  This allows you to descriminate to whom you connect.

Jon
j_rodin@cnd.hp.com
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Dec 90 23:35:03 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        Jason.Nolet@SanDiego.NCR.COM
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: NETBIOS/RFCs 1001/1002 Question
    If a node on the network initiates a call to a NETBIOS
    name which happens to be a group name being used by
    several other nodes on the network, how is the call to
    the group name resolved into a single session with a
    specific member of the group?

The most likely result is "open a TCP connection to the IP address in
the first reply received".  I can't promise you'd get this behaviour
from all available implementations, but it seems to be the easiest to
implement...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 15:15:36 GMT
From:      hpcc05!hpdmd48!brown@hplabs.hpl.hp.com  (Kevin Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Code from Stevens' book
The author, Rich Stevens, replied to my query for the source code from
his book. It is available from uunet.uu.net: pub/netprog.tar.Z
I went and got it without any trouble. It extracts from tar into nicely 
organized subdirectories to make it easy to pick out the pieces you need.

Kevin Brown
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 16:25:11 GMT
From:      uflorida!mlb.semi.harris.com!mintaka.mlb.semi.harris.com!john@gatech.edu  (John M. Blasik)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing
medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
>
>That's not a bug but a feature!  Late model BIND resolver code has a security 
>feature in it which causes this behavior.  Basically, if your code does
>a gethostbyaddr call to the DNS, the resolver will query the DNS system for
>a PTR record for the address passed to it.  The old code would then return 
>the reply, without verification.  The new code goes one step farther by
>then additionally doing a gethostbyname call on the returned name, and verifying
>the name has the original address as one of the A records associated with it. 

I believe this is a SUNism and would dare call it a bug.

What's wrong with doing the extra gethostbyname only when necessary (in rsh
 and friends)?

The way it works now, things like traceroute and netstat break
(no "A" for FOO.ST.NSF.NET, PTR's returned for host-0 names ala rfc 1101)


-- john
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 16:56:45 GMT
From:      psuvm!ysub!msu!cmuvm!34aej7d@psuvax1.cs.psu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q
Thank you all!

I am now up to my ears in ftp sites for KA9Q.

Many thanks to everyone who responded, both privately and on the net.
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 17:09:47 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!uupsi!intercon!news@ucsd.edu  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: vt320 emulation pkg for a PC
In article <1990Dec17.024358.21250@morrow.stanford.edu>,
MA.VIC@forsythe.stanford.edu (Victor Arnold) writes:
> Friends -
> 
> I am looking for a product which will allow me to have full
> VT320 terminal emulation on a PC (ms-dos) over tcp/ip. I only
> really need telnet and ftp. Are there any good packages
> around.
> 
> please respond via e-mail: Ma.VIC@forsythe.stanford.edu
> 
> Thanks

You might try Walker, Ritcher, and Quinn.  I believe that they have vt320
emulation on the PC.  They operate with various TCP/IP stacks, FTP's, SUN's,
etc..

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 17:52:09 GMT
From:      cme!libes@uunet.uu.net  (Don Libes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: FTP enhancements
In article <9012160626.AA14268@ucbvax.Berkeley.EDU> Sam_Coleman.NSD@LCCMAIL.OCF.LLNL.GOV (Sam Coleman) writes:
> We use FTP now and we've looked at Background FTP.  In
>our environment, these seem to fall short in several areas that I'll describe
>below.  I'd appreciate your corrections and additions.

>I'm wondering if anyone has encountered similar problems, developed better
>solutions, or is interested in working with us to develop something better.

Rather than trying to create a BFTP with a gazillion options, and not
knowing if you've solved everyone's special problem, you might try
using an intelligent front-end like 'expect'.  This provides people
with an open-ended way of controlling ftp without having to rewrite
anything.  (In fact, ftp is used in the expect man page as an example.)

Here are some specific comments on how expect address your requirements.

>Passwords - Both FTP and BFTP require clear-text passwords.  Our
>security folks won't allow clear-text passwords to be stored in files.
>Is Kerberos a solution?

Let expect prompt the user for the passwords immediately.  (This is
also described in the man page.)  Expect remembers them, and uses them
when it comes time to connect to the remote system later.

>Persistence -  FTP has none; if a transfer fails, the user has to retry.
>Background FTP has a simple retry mechanism.

Expect can retry however you want.  Every minute, hour, just once, twice,
only during wee hours, whatever.

>Notification - BFTP sends mail to the client when a transfer completes.
>Is this the best way to handle notification in production environments?

Expect can notify you any way you want.  Mail, write, reboot, whatever.

>Synchronous operation - FTP does one thing at a time.  The user can give
>BFTP multiple jobs, but BFTP seems to plug through these synchronously if
>they are invoked using wild cards. Thus you can't take advantage of
>parallelism that might be available in the file system (e.g. mounting
>tapes concurrently).

Expect can run multiple ftps simultaneously (on different machines,
for that matter).  And it can notice whenever one completes and
request the next file immediately.

>Flow control - FTP servers generally have no mechanisms to inhibit file
>transfers during heavy load; file movement slows to a crawl as the load on the
>server increases, then they reject log-ons, and then connections are refused
>(maybe it's a good thing that FTP is synchronous?).  We would like to put flow
>control in the FTP server to delay file transfers when necessary, but allow
>log-ons and short commands (like ls).  Perhaps priority could be given to
>small and/or fast transfers?

If you have another command (like ping for network load) or there is
some port that you can telnet to which reports the load, you can have
expect check that first.  You can order files by size.

>Tape files - FTP doesn't handle well the case where there is a delay accessing
>a file, e.g. when the file is on tape.

FTP needs to be rewritten for this.  Expect can't help you here.

>Should there be a way to configure FTP?  A .FTPRC file to allow the user to
>specify his own defaults.

Trivial.  Have your expect script source your .ftprc file.

>Error reporting in some clients could be improved.

Using expect, you can translate error messages, or report any or all
of the session verbatim.

>Wild cards - FTP provides MGET, MPUT, and MDEL (why not GET *, etc?),
>but functions like chmod don't support wild cards.

You can emulate this.

The rest of your issues (faster transmission, complete file system
functionality) require ftp and protocol to be rewritten.

I don't have scripts that support all the features you have asked for,
but they are easy to write.  And, like I said earlier, you're never
going to be able to think of everyone's need.  For example, one of the
sample expect scripts in the distributions attempts to connect as
"libes" and only if that fails does it try to connect as "anonymous".

Another neat thing capability would be to name a file, and let the
script figure out what directory it is in (possibly by looking in an
"ls-lR" file if it finds one.)  Or make it work with McGill
University's archie system!  The script would telnet to mcgill, find
out what ftp sites have the file and what the full directory paths are,
and then ftp it.  If one site is down, it could go on to the next one.
(I think you'll be surprised how short this script will be.)

I know some people like dedicated tools such as BFTP.  But I suspect
that if it really addresses all the issues you've raised, it's no
longer going to be simple to use as what we all associate with FTP,
and may not satisfy as many people as originally intended.  In any
case, there will always be a tradeoff between simplicity and completeness.

Meanwhile, in the year that its going to take to add all the features
you asked for, try using expect.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 18:21:14 GMT
From:      ub.d.umn.edu!cs.umn.edu!peiffer@rutgers.edu  (Tim Peiffer "The Net Guy")
To:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing
Milo Medin <9012170259.AA06606@nsipo.arc.nasa.gov> writes:
>The problem in your case is that whoever runs your DNS configuration accidentally
>left out the address in question, or used the wrong name in the PTR record.

Merit misconfigured ccb4.merit.edu as ccb3.merit.edu.  This
misadventure within the DNS did actually point out a few possible 
problem areas that I would like to ask about.

	1) What is the correct use of wildcarding within named
	   zone files?
	2) What is the most effective (and correct) method of
	   showing hosts with dynamic addresses within the .rev
	   zone files?

Consider the following:
1) Fastpath Appletalk to TCP/IP gateway.
2) Kstar 8.0+ and PhaseII Appletalk.
3) Base address of 128.101.147.221
4) dynamic addressing from 147.222 to 147.240
$ORIGIN ee.umn.edu.
eecsk4f2	IN	A 128.101.147.221
; glue records like any other gateway ( multiple A records)
		IN	A 128.101.147.222
                [....]
		IN	A 128.101.147.240
		IN	HINFO KFPS-4	Native

$ORIGIN 147.101.128.IN-ADDR.ARPA.
221		IN	PTR	eecsk4f2.ee.umn.edu.
222		IN	PTR	eecsk4f2.ee.umn.edu.
[...]
241		IN	PTR	eecsk4f2.ee.umn.edu.

%nslookup -qt=ptr 128.101.147.240
	240.147.101.128.in-addr.arpa    host name = eecsk4f2.ee.umn.edu
%nslookup eecsk4f2.ee.umn.edu
	Name:    eecsk4f2.ee.umn.edu
	Address:  128.101.147.221

In this case the feature that Milo Medin mentioned would cause a lot
of problems.  With the example shown, the resolver would also
complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240
 

Tim Peiffer
-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 19:20:28 GMT
From:      mcsun!cernvax!chx400!bernina!neptune!inf.ethz.ch!delorenz@uunet.uu.net  (Michele DeLorenzi)
To:        tcp-ip@nic.ddn.mil
Subject:   MacTCP with THINK Pascal

I'm trying to exchange some data between an application on my Macintosh and a
Sun.  I have the MacTCP Evaluation Kit and the MacTCP Programmer's Guide and I
want to call the corresponding driver from THINK Pascal.  I tried to write
myself an interface but it doesn't seem to work.  Who has experience using TCP
together with THINK Pascal?  I would appreciate sample code if possible.
Thank's in advance.

Michele De Lorenzi
delorenz@inf.ethz.ch
-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 19:40:34 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!opal!tmpmbx!netmbx!macbeth@ucsd.edu  (Andreas Pahl)
To:        tcp-ip@nic.ddn.mil
Subject:   Nameserver
A short, but nevertheless tricky question for a newcomer:

How do I install a nameserver on a sun sparc?

My home is VAX/VMS, so I'm not a total newcomer, and I know
a little about IP, but TCP/IP and UNIX together is new for me.

Rgds Rainer
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Dec 90 10:48:56 KST
From:      <moskim@hyuee.hanyang.ac.kr (Myo-Seob Kim)>
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted PPP

Does anyone know the ftp sites for the most current version of the
public PPP software?

Thanks...

Myo-Seob Kim

Dept. of Electronic Engineering
Hanyang University, Seoul, Korea
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 17 Dec 90 11:00:07 EXP
From:      Postmaster <EGKIM%KRSNUCC1.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Q:Internet Connection creation.

This mail is from Seoul Korea.
Currently we have BITNET connection only  from abroad.
We donot yet have Internet connection.
On these days, we are going to establish a domestic network, KREN(
Korea Research & Education Network) newly.
KREN is TCP/IP based network.
To utilize KREN efficiently, we have to open a connection to Internet.
We hope to open Internet connection to US directly.
To whom should we contact, at first ?
To which site can we request to open a connection for us ?
Additionally it'll be preferrable if the site has also
a Bitnet connection cause we hope to run VMNET concurrently.

Therefore we are looking for kind approval letting us open
a connection.

Would you please give me favor ?
Any kind of help will be welcome.
Thanks in advance.

-Kim Eunkyung.
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 Dec 90 20:31:56 GMT
From:      cox@imspw6.UUCP (Ken Cox)
To:        comp.protocols.tcp-ip
Subject:   Re: Hughes Lan System MIB extensions

In article <1990Dec14.093629.43635@vaxb.acs.unt.edu>, snms4@vaxb.acs.unt.edu writes:
>          oh... by the way:  When I got the Cisco MIB, they pointed me
>          to a host that had just TONs of MIB extensions online. 
>          naturally, I lost the address.  Would anyone know where this
>          is?

Summary says it all... anon ftp venera.isi.edu, the ~/mib subdir has 
listings for 10 or 12 vendors-- certainly no tonnage there-- I don't 
remember seeing Hughes in there, either.

Ken Cox                                      imspw6!cox@uunet.uu.net
Integrated Microcomputer Systems
Rockville, MD

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Dec 90 10:55:42 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        john@mintaka.mlb.semi.harris.com (John M. Blasik)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing

>I believe this is a SUNism and would dare call it a bug.
>
>What's wrong with doing the extra gethostbyname only when necessary (in rsh
> and friends)?

>The way it works now, things like traceroute and netstat break
>(no "A" for FOO.ST.NSF.NET, PTR's returned for host-0 names ala rfc 1101)


It's not a SUN'ism.  We had implemented this at NASA Ames a long time before
it showed up in SunOS.  In fact, we may have well turned in a bug report
on this to SUN.  I know went sent the diffs to UCB.  

You can't do the extra gethostbyname only when necessary, since the library
routine can't know this for sure.  You could modify everything that 
would benefit from it, but the most natural place for it seems to be 
in the library routine itself.  And in a system with shared library support,
you can deploy this without having all the system applications which would 
benefit from it be modified, much less applications written by users
and software vendors.  

There is no reason that the DNS configurations, if done thoroughly, break
netstat and traceroute.  Again, if you configure the DNS information to
be completely consistent, things work fine.  

					thanks,
					   Milo
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 08:52:00 EST
From:      "NICOLAS_ZENTELIS" <zentelis@win1.ims.abb.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   FTP between (IBM PS/2 DOS) and (DEC 5400 ULTRIX)
Hi 

My problem is how to send files from a PC, IBM PS/2 running DOS to
an ULTRIX workstation, DEC 5400. Thin wire ETHERNET exists. 

Looking for vendor of Hardware card and TCP/IP Software for the PC.
Main interest FTP.

Bets regards, Nicolas

====================================================================
Nicolas Zentelis 			Voice :  ( +46) 21-323537
Asea Brown Boveri		          FAX :  ( +46) 21-127635
ABB Data AB 			      ABB MEMO:  SEDAT.DATNIZE
S-721 80 Vasteras		  ABB VMS/Mail:  SDAV01::ZENTELIS
SWEDEN                       Internet : nicola@sdau01.dat.abb.com
====================================================================

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 05:37:23 GMT
From:      usc!samsung!munnari.oz.au!uhccux!uhheph.phys.hawaii.edu!tony@ucsd.edu  (Tony Querubin)
To:        tcp-ip@nic.ddn.mil
Subject:   Changing TCP window size on a SUN
I need to change the TCP window size that a SUN advertises to other hosts
that make a connection.  Thinking that it might be a configurable kernel
option, I looked through the various /sys/netinet files for a TCP WINDOW
parameter and found none.  On a second pass through the files I noticed
a definition for TCPOPT_MAXSEG in tcp.h.  

Question:  Can anyone verify for me that this is equivalent to the TCP window
parameter in KA9Q?  I'd like to know this BEFORE I reconfigure the kernel.

Essentially, I want any host making a connection to this SUN to send only one 
TCP packet at a time.  The reason for this is that the path to the SUN goes
through a PC using a 3C501 ethernet board.

Antonio Querubin
querubin@uhunix.uhcc.hawaii.edu
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 06:53:56 GMT
From:      nsipo.arc.nasa.gov!medin@icarus.riacs.edu  (Milo S. Medin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing

What we do here at Ames is that the K-box base address PTR points back to
the K-box, and then each dynamic address has it's own name, and a PTR record
that points back it it.  For example, you have:

n233-edc-gw	IN	A	128.102.18.112
		IN	HINFO	"Kinetics AppleTalk Gateway" "N/A"
n233-edc-1	IN	A	128.102.18.113
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-2	IN	A	128.102.18.114
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-3	IN	A	128.102.18.115
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-4	IN	A	128.102.18.116
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-5	IN	A	128.102.18.117
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-6	IN	A	128.102.18.118
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-7	IN	A	128.102.18.119
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-8	IN	A	128.102.18.120
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-9	IN	A	128.102.18.121
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-10	IN	A	128.102.18.122
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-11	IN	A	128.102.18.123
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-12	IN	A	128.102.18.124
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-13	IN	A	128.102.18.125
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-14	IN	A	128.102.18.126
		IN	HINFO	"AppleTalk Host" N/A
n233-edc-15	IN	A	128.102.18.127
		IN	HINFO	"AppleTalk Host" N/A


The PTR records all point back to the proper names, which are different for
each dynamically assigned address.  It's not that hard to build this with a
shell script or an awk script.  And even if you didn't do this, all that
would happen is the gethostbyaddr would fail.  No big deal, as people shouldn't
be sticking things with dynamically assigned addresses in their .rhosts and the
like.  

No big deal, or perhaps I'm missing something here?  In any case, it's
a big payoff for the security advantages this provides.

						Thanks,
						   Milo
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 08:50:41 GMT
From:      nsipo.arc.nasa.gov!medin@icarus.riacs.edu  (Milo S. Medin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing
In article <1990Dec17.182114.14182@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer "The Net Guy") writes:

...
>eecsk4f2	IN	A 128.101.147.221
>; glue records like any other gateway ( multiple A records)
>		IN	A 128.101.147.222
>                [....]
>		IN	A 128.101.147.240
>		IN	HINFO KFPS-4	Native
>
>$ORIGIN 147.101.128.IN-ADDR.ARPA.
>221		IN	PTR	eecsk4f2.ee.umn.edu.
>222		IN	PTR	eecsk4f2.ee.umn.edu.
>[...]
>241		IN	PTR	eecsk4f2.ee.umn.edu.
>
>%nslookup -qt=ptr 128.101.147.240
>	240.147.101.128.in-addr.arpa    host name = eecsk4f2.ee.umn.edu
>%nslookup eecsk4f2.ee.umn.edu
>	Name:    eecsk4f2.ee.umn.edu
>	Address:  128.101.147.221
>
>In this case the feature that Milo Medin mentioned would cause a lot
>of problems.  With the example shown, the resolver would also
>complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240
> 


BTW, I forgot to point out in this case, you should still be OK, because
unlike your nslookup output, gethostbyname will return a struct with a 
list of all the addresses inside.  The resolver code acting the way I
described will still specify a match provided that ONE of the returned
A records matches the original address.  In the situation you describe,
128.101.147.240 would be one of the A records associated with 
eecskff2.ee.umn.edu, and the call would return sucessfully.

We at Ames prefer to do it in the way I described in my earlier posting,
but both ways are valid, and both work with this resolver behavior.  Now,
I'll contend our way is a bit more robust, as the last BIND code I looked at 
had had some absurdly low maximum number of A records per hostname, and thus
you might not get all 32 of your A record entries back in response to
the query, but in theory, this should be doable.  

You can however discover a whole pile of DNS misconfigurations or oversights
in this way, and that's always a good thing.

						Thanks,
						    Milo
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Dec 90 18:26:20 -0500
From:      George Williams <gwilliam@SH.CS.NET>
To:        Wayne Hathaway <usc!zaphod.mps.ohio-state.edu!mips!ultra!wayne@ucsd.edu>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: BSD sockets question

    Date:    7 Dec 90 17:23:24 GMT
    From:    Wayne Hathaway <usc!zaphod.mps.ohio-state.edu!mips!ultra!wayne@ucs
	      d.edu>
    Subject: BSD sockets question

    Sorry to bother the TCP/IP group with a BSD-sockets-specific question, 
    but it really does relate to protocol behavior.

    Anyway, my question is the following:  For connected stream sockets,
    are there ANY semantic differences between shutdown(2)
>> Generates a TCP level abort. Sent out of band or expedited.
>> Can bypass 'close' and 'data'. Especially in LAN environments.

    and close()?
>> Allows for graceful shutdown i.e. only one half ( sending TCB ) of
>> connection is deleted. Sent on normal data flow, so does not bypass
>> data in transient. Process allowed to receive data already in the
>> pipe.

    If so, can somebody please explain them?  (For example, if multiple
    processes are sharing a connected socket, only the LAST close() will
    have an effect;
>> Really each close has an affect on the socket level. A trick used in
>> BSD UNIX is to obtain a new socket desciptor, pass the options to 
>> a newly forked child, and go back to listening on the original socket
>> for new connection requests. When you close the origional or 'well
>> known port' as you indicated above the (LAST); service is gone or
>> no longer available. There are variation on this scenario due to
>> implementation and system specifics but the rules are essentially the same.
>> In this manner you can achieve concurrency within a single server process.

>> Note: I recall working with some interfaces ( don't now if BSD ) derivatives
>>       or not that turned shutdown into a close for the receiving process.
>>       Don't recall if this was/is a bug or a feature...yes, I know someone
>>       out there is gonna tell me RTFRFC -:)..

   is this true with shutdown(2)?  Is "data in the pipe"
    treated any differently?  Etc ...)
>> Shutdown would be issued when an entire server or process goes away,
>> removing a 'well known port' due to administative or disruptive (error)
>> processing.

    Oh, when I say "shutdown(2)" I mean the shutdown() system call with
    a "how" parameter of "2," meaning shutdown both read and write; I am
    NOT alluding to section 2 of the manual.

    Thanks muchly!

        Wayne Hathaway               domain: wayne@Ultra.COM
        Ultra Network Technologies     uucp: ...!ames!ultra!wayne
        101 Daggett Drive             phone: 408-922-0100 x132
        San Jose, CA 95134           direct: Hey, you!

    PS:  For that matter, can anybody explain what shutdown does with a
         connected DATAGRAM socket?  Thnx again.
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Dec 90 16:35 CST
From:      Act Jaime Iturbe <JAIME@UDLAPVMS.PUE.UDLAP.MX>
To:        TCP-IP@NIC.DDN.MIL
Subject:   TCP and Think Pascal
From:	ACADE::JAIME        "Act Jaime Iturbe" 18-DEC-1990 16:09:25.63
To:	IN%"delorenz@inf.ethz.ch"
CC:	JAIME
Subj:	TCP and Think Pascal

Date sent:  18-DEC-1990 16:02:15 
Hi, I wrote a TCP library in Think Pascal 3.0. I used sample code from
some XCMD's for HyperFTP. I couldn't get the Mac TCP Evaluation Kit so
I guessed a little in how to call the driver. The only thing left is the
Domain Resolver, it is in C and I have to translate it.

The library supports Active and Passive open, Send and Receive strings,
it has its own buffer and the way to use it is very similar to the Serial
Driver. I could send you a copy of the library as it is now, but I prefer
to add the name resolution and clean up some rough edges. If I could have
acces to the MacTCP documentation I could build a full fledged set of TCP
routines.



*-----------------------------------------------------------------------------*
Jaime Iturbe					A.P. 291
Director, Auditoria y Sistemas			Cholula, Puebla, MEXICO 72820
Universidad de las Americas, Puebla	        (52) 22 47 43 21

eMail :
	Bitnet : JAIME@UDLAPVMS
	Internet:JAIME@UDLAPVMS.PUE.UDLAP.MX
*-----------------------------------------------------------------------------*
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Dec 90 20:42:58 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        Sean Mc grath <sean@fiamass.ie>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCPIP ping problem
    Machine A            Machine B                   Result 
    ==========           ==========                  =======
                         ping A                      ARP fails. Host unreach..

Tell me what INET DEBUG says on each machine at this point.  In particular,
how many packets were received, and any non-zero error counts.

    It seems to me that machine A must be caching the ethernet address of B
    after B does "ping A" otherwise its own ping would fail.  If so, why do
    the caches look empty?  Any help would be gratefully received.
    
B broadcasts an ARP request.  A receives it, sends an ARP reply, and cleverly
(courtesy of PCIP) caches B's address, assuming that it will need it soon.
I seem to recall that this optimization is suggested in RFC 826...

My first guess is that the Ethernet card in B is defective, and can't
see broadcast packets.  Compare the number of "unknown types" in INET
DEBUG and the number of "UDP no port listening" errors on A and B.
Most LAN OS file servers and Unix boxes produce some sort of periodic
broadcast, which you'll see in these counts (A & B would be roughly 
equal if both boards were working).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      Tue, 18 Dec 90 13:26:03 GMT
From:      richards@hawk.nstn.ns.ca (Mark Richardson)
To:        tcp-ip@nic.ddn.mil
Subject:   Super TCP by Frontier Tech

Good Day Netters,

Has anyone had any experience with a product by Frontier Technologies
Corporation called Super TCP for DOS. The two or three photocopied
pages of info I have look *very* interesting. I faxed them asking
for more info but they didn't reply. Any help would be greatly appreciated.

BTW--- Some time ago I posted a request for info regarding telnet, ftp,
mail and network news for DOS machines. I got many, many, many,.... replies,
99% of which were "If you find anything useful, let me know..." or words
to that effect. Well, there is a bright side. After many hours of twiddling
I'm almost to the point were I have something useful. I will post my results
here after xmas for all of you who just started salivating. Don't hold your
breath for the quentesential (sp?) report on whats out there. I had limited
information and resources so take what I say with a grain of salt. Speaking
of information, a big THANK YOU to the guys at FTP Software (James and 
Francis). They were the ONLY commercial vendors to reply to my requests.

Don't do anything I'd enjoy...

Mark

Mark Richardson        		                  Software Kinetics Ltd
Project Engineer				  Dartmouth N.S. Canada 
richards@hawk.nstn.ns.ca    Phone (902)468-3680     Fax   (902)468-3679 
---Any opinions expressed are entirely my own ..... aren't they sir?---
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 15:29:52 GMT
From:      ncar.ucar.edu!hpoppe@handies.ucar.edu  (Herb Poppe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: MacTCP with THINK Pascal
In article <18559@neptune.inf.ethz.ch> delorenz@inf.ethz.ch (Michele 
DeLorenzi) writes:
> I have the MacTCP Evaluation Kit and the MacTCP Programmer's Guide and I
> want to call the corresponding driver from THINK Pascal.  I tried to 
write
> myself an interface but it doesn't seem to work.  Who has experience 
using TCP
> together with THINK Pascal?  I would appreciate sample code if possible.

If anyone can provide an answer, please post to the net.

Herb Poppe             hpoppe@ncar.ucar.edu
NCAR                      (303) 497-1296
1850 Table Mesa Dr.
Boulder, CO  80307-3000
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 15:47:01 GMT
From:      umich!sharkey!amara!des@CS.YALE.EDU  (Dave Steinhoff)
To:        tcp-ip@nic.ddn.mil
Subject:   CMU TCP/IP?
My apologies if this is the 100th time this has been asked.  I am
interested in finding out about the CMU implementation of TCP/IP
for VAX/VMS.  Can someone direct me to the right place?

Thanks in advance,
Dave
--
-------------------------------------------------------------------
Dave Steinhoff                              Applied Dynamics, Int'l
des@amara.UUCP                              3800 Stone School Rd.
des@adi.com                                 Ann Arbor, Mi 48108
...uunet!amara!des                          (313)973-1300                 
-------------------------------------------------------------------
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 20:30:22 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!usc!phad.hsc.usc.edu!mcitron@ucsd.edu  (Mark Citron)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 132 column display
Can anyone tell me if tn3270 emulator does 132 column display? If so,
what version am I looking for (and where can I ftp it from).

Thanks

-- 
Mark Citron
mark@neurosci.usc.edu
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 20:36:40 GMT
From:      usc!phad.hsc.usc.edu!mcitron@ucsd.edu  (Mark Citron)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 132 column display for PC DOS

Can anyone tell me if the tn3270 emulator under  DOS does 132 column 
display? If so, what version am I looking for (and where can I ftp it from).

Thanks

-- 
Mark Citron
mark@neurosci.usc.edu



-- 
Mark Citron
mark@neurosci.usc.edu
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 21:45:15 GMT
From:      pilchuck!amc-gw!sumax!ctsx!dms@uunet.uu.net  (Dave Stanhope)
To:        tcp-ip@nic.ddn.mil
Subject:   pcroute
I would like to use 'pcroute' as a gateway for our local ethernet and
appletalk network.  I have a copy of NCSA telnet to use on the mac and
both appletalk and tops flashcards for the gateway.  I can get the hosts
on the ethernet to see the gateway as well as receive the routing for
the appletalk side.  However NCSA telnet running on the mac never gets
to the gateway.  I see messages from the gateway saying that it is
doing localtalk arps to 192.84.23.255.  The gateway address is
192.84.22.20 on the ethernet and 192.84.23.20 on the appletalk.  The
pcroute log says that all starts fine.  When I start a ftp on the ether
side to 192.84.23.30 (the address assigned to NCSA) I see the localtalk
arp messages for it but ftp never gets connected.

Any help would be very much appreciated, I suspect a config problem on
either pcroute or NCSA. Do I need a special version of NCSA telnet to 
work with pcroute?

                         David M. Stanhope
                         dms@nwnexus.wa.com
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Dec 90 23:26:20 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: BSD sockets question


    Date:    7 Dec 90 17:23:24 GMT
    From:    Wayne Hathaway <usc!zaphod.mps.ohio-state.edu!mips!ultra!wayne@ucs
	      d.edu>
    Subject: BSD sockets question

    Sorry to bother the TCP/IP group with a BSD-sockets-specific question, 
    but it really does relate to protocol behavior.

    Anyway, my question is the following:  For connected stream sockets,
    are there ANY semantic differences between shutdown(2)
>> Generates a TCP level abort. Sent out of band or expedited.
>> Can bypass 'close' and 'data'. Especially in LAN environments.

    and close()?
>> Allows for graceful shutdown i.e. only one half ( sending TCB ) of
>> connection is deleted. Sent on normal data flow, so does not bypass
>> data in transient. Process allowed to receive data already in the
>> pipe.

    If so, can somebody please explain them?  (For example, if multiple
    processes are sharing a connected socket, only the LAST close() will
    have an effect;
>> Really each close has an affect on the socket level. A trick used in
>> BSD UNIX is to obtain a new socket desciptor, pass the options to 
>> a newly forked child, and go back to listening on the original socket
>> for new connection requests. When you close the origional or 'well
>> known port' as you indicated above the (LAST); service is gone or
>> no longer available. There are variation on this scenario due to
>> implementation and system specifics but the rules are essentially the same.
>> In this manner you can achieve concurrency within a single server process.
 
>> Note: I recall working with some interfaces ( don't now if BSD ) derivatives
>>       or not that turned shutdown into a close for the receiving process.
>>       Don't recall if this was/is a bug or a feature...yes, I know someone
>>       out there is gonna tell me RTFRFC -:)..

   is this true with shutdown(2)?  Is "data in the pipe"
    treated any differently?  Etc ...)
>> Shutdown would be issued when an entire server or process goes away,
>> removing a 'well known port' due to administative or disruptive (error)
>> processing.

    Oh, when I say "shutdown(2)" I mean the shutdown() system call with
    a "how" parameter of "2," meaning shutdown both read and write; I am
    NOT alluding to section 2 of the manual.

    Thanks muchly!

        Wayne Hathaway               domain: wayne@Ultra.COM
        Ultra Network Technologies     uucp: ...!ames!ultra!wayne
        101 Daggett Drive             phone: 408-922-0100 x132
        San Jose, CA 95134           direct: Hey, you!

    PS:  For that matter, can anybody explain what shutdown does with a
         connected DATAGRAM socket?  Thnx again.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      Wed Dec 19 09:30:17 1990
From:      gd@aprm (Gary Dunn)
To:        tcp-ip@nic.ddn.mil
Subject:   SQL over DDN
Text: 

I've been thinking about how to implement a distributed database with
sites located in Hawaii, Alaska, Japan, and Korea.  I see where ORACLE
(and others) support SQL over tcp/ip networks.  Is there any chance that
this could be done using the DDN to carry the query/response traffic?

Hardware is not known, but assume the following for discussion:

server: ISA or EISA PC running SCO UNIX 386 w/tcpip

client: 286 PC running MS-DOS version of DBMS vendor's SQL access
        software, FTP's PC/TCP

A CISCO box (X.25 router/gateway) would be used at each end.  The one in
Hawaii is up and running (that's how you got this) and the other's have
been purchased.

The alternative would be async modems, but service to the remote locations
is pretty awful.

I've spoken to ORACLE, SCO, and FTP about this, and while they all agree
it's an interesting idea, none could comment on it's technical
viability.

So what do you think?  Would it work?  Is it a dog?  Is there a better
way?

Thanks in advance...
 
Gary Dunn, USARPAC DCSRM IMO                 |
Ft. Shafter LAN: aprm%gd               _   _ |
DDN: aprm%gd@shafter-emh2.army.mil    /.\ /.\|
Work phone:  (808) 438-2716           \_/|\_/
FAX: (808) 438-8954                      |
                                        /
 
        Real programmers don't comment their code.  If it was
        hard to write, it should be hard to understand, and
        even harder to modify.

 --- End of Message -----------

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 00:06:14 GMT
From:      cti1!mpledger@uunet.uu.net  (Mark Pledger)
To:        tcp-ip@nic.ddn.mil
Subject:   Syntax software
Are there any sites out there using Syntax software from FTP?  If so
could you please email me your address.  I have a couple of questions
regarding a particular configuration.



-- 
Sincerely,


Mark Pledger

--------------------------------------------------------------------------
CTI                              |              (703) 685-5434 [voice]
2121 Crystal Drive               |              (703) 685-7022 [fax]
Suite 103                        |              
Arlington, VA  22202             |              mpledger@cti.com
--------------------------------------------------------------------------
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 09:36:40 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        swrinde!zaphod.mps.ohio-state.edu!usc!phad.hsc.usc.edu!mcitron@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  tn3270 132 column display

The tn3270 emulator in PC/TCP will do 132 column display, if your monitor
and video card can handle that. In this mode, it emulates an IBM 3278
model 5. Emulation of the 3277 and 3279 is also included.



Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 01:17:47 GMT
From:      uakari.primate.wisc.edu!aplcen!wb3ffv!fallst!tkevans@ames.arc.nasa.gov  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   Help for Novice in Configuring BIND (Domain Name Service)
Is there someone who'd be willing to correspond with a DNS
novice to look over config files, etc?  Set up is very simple
(we're not connected to the Internet, and have only a single
internal domain).  Thanks.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 09:49:04 -0500
From:      Bob Stewart <stewart@xyplex.com>
To:        medin@nsipo.nasa.gov
Cc:        john@mintaka.mlb.semi.harris.com, tcp-ip@nic.ddn.mil
Subject:   gethostbyaddr() failing
>There is no reason that the DNS configurations, if done thoroughly, break
>netstat and traceroute.  Again, if you configure the DNS information to
>be completely consistent, things work fine.  

Although I admit I haven't been following this thread with full attention, the
idea that to operate reasonably DNS information must be "completely
consistent" sounds pretty scarey to me.  Sounds less than robust.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 10:20:12 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        HARISH%ITIVAX.BITNET@CUNYVM.CUNY.EDU, tcp-ip@nic.ddn.mil
Cc:        fks@ftp.com
Subject:   Re:  3Com's 3C501 card and NetBIOS
We have a NetBIOS for our TCP/IP. It will run over the 3C501, but I've
no idea if it will compensate for the cards deficiencies. It certainly
won't make the card any faster.



Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 02:54:18 GMT
From:      ub.d.umn.edu!cs.umn.edu!peiffer@rutgers.edu  (Tim Peiffer "The Net Guy")
To:        tcp-ip@nic.ddn.mil
Subject:   What does host != addr mean? (Was gethostbyaddr())
One of the departments around here has a machine that consistently
gives error messages nres_gethostbyaddr: host != addr.  I can usually
track problems like this down to misconfiguration in the zone tables
for the nameserver.  This problem is not as simple.  The machine that 
gives this error messageis a Sun 4/60 running SunOS 4.1 using the
Sun libc.so hack recently released.   What does this error message mean??

Tim Peiffer
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
MPLS MN 55455


Dec 11 00:12:52 daphne syslog: nres_gethostbyaddr: ub.d.umn.edu != 131.212.32.6
Dec 11 08:57:28 daphne syslog: nres_gethostbyaddr: mail.unet.umn.edu != 128.101.101.103
Dec 11 11:29:22 daphne syslog: nres_gethostbyaddr: ub.d.umn.edu != 131.212.32.6
Dec 11 11:40:11 daphne syslog: nres_gethostbyaddr: cmx.npac.syr.EDU != 128.230.7.8
Dec 11 12:07:36 daphne syslog: nres_gethostbyaddr: MERIT.EDU != 35.1.1.42
Dec 11 12:08:05 daphne syslog: nres_gethostbyaddr: unet.unet.umn.edu != 128.101.101.1
Dec 11 12:33:00 daphne syslog: nres_gethostbyaddr: mail.unet.umn.edu != 128.101.101.103
Dec 11 13:29:09 daphne syslog: nres_gethostbyaddr: ub.d.umn.edu != 131.212.32.6
Dec 11 14:33:46 daphne syslog: nres_gethostbyaddr: d2.acs.umn.edu != 128.101.62.101
Dec 11 16:13:32 daphne syslog: nres_gethostbyaddr: unet.unet.umn.edu != 128.101.101.1
Dec 11 16:14:41 daphne syslog: nres_gethostbyaddr: mazatzal.merit.edu != 35.1.1.19
Dec 11 17:27:43 daphne syslog: nres_gethostbyaddr: norge.unet.umn.edu != 128.101.101.16
Dec 11 17:38:37 daphne syslog: nres_gethostbyaddr: mail.unet.umn.edu != 128.101.101.103
Dec 12 00:20:22 daphne syslog: nres_gethostbyaddr: ns-mx.uiowa.edu != 128.255.64.3
Dec 12 13:36:54 daphne syslog: nres_gethostbyaddr: milton.u.washington.edu != 128.95.136.1
Dec 12 14:01:39 daphne syslog: nres_gethostbyaddr: PO5.ANDREW.CMU.EDU != 128.2.10.105
Dec 12 15:02:57 daphne syslog: nres_gethostbyaddr: PO5.ANDREW.CMU.EDU != 128.2.10.105
Dec 13 06:27:35 daphne syslog: nres_gethostbyaddr: ns-mx.uiowa.edu != 128.255.64.3
-- 
-----------
Tim Peiffer				peiffer@cs.umn.edu 	or
Computer Science Dept			..!rutgers!umn-cs!peiffer
University of Minnesota
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 11:19:48 -0500
From:      fks@ftp.com (Frances Selkirk)
To:        BIWINE@vaxsar.vassar.edu, TCP-IP@NIC.DDN.MIL
Subject:   Re:  POP protocol
There is nothing in the POP architecture that requires automatic polling.
Our POP clients check for mail when invoked. Look around for another 
implementation.


Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 04:49:36 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!rex!uflorida!mlb.semi.harris.com!sloth.mlb.semi.harris.com!jdr@ucsd.edu  (Jim Ray)
To:        tcp-ip@nic.ddn.mil
Subject:   Fiber link problems
We are currently experiencing problems with a few fiber links between 
buidlings.

The links in question are connected via ODS 291 twisted pair box on
one net in one building to another ODS 291 twisted pair box ( using
a host port twisted pair connection ) which then connects to the remote 
buidling via the fiber network port.  The fiber then connects to the
remote building to a fiber tranceiver ( ODS 234 ) which then goes into
a TCL tranceiver and then to the remote lan.

     ---------------------    net a
         | <-- tcl tranceiver
         |
         |_|-----|
           |     |  ODS 291
           |     |           Acts as a full repeater
         --|     |
        |  -------
        | <------------twisted pair connecting host ports  ( 10 base t )
        |              
        ---|-----|
           |     |
           |     |  ODS 291   Acts as a full repeater
           -------
             |
             | <------------ fiber
            ...
             |
             |
            ---
            |  |  ODS 234 fiber tranceiver
            ----
             |
             |<---  tcl tranceiver
           --------------------   remote lan a

Symptoms:

    1) ping's with normal size packets work fine with about 1% loss
    2) ping's with 500 byte packets have 10 % loss
    3) ping's with 800 byte packets have 20 % loss
    4) ping's with 1500 byte packets have 38 % loss

    5) NFS of course does not like this at all -- since it opts for
       large packet sizes.
    6) Cisco routers connected to either side of lan a go into
       hibernation mode for from 20-40 seconds or so every 5-10 minutes,
       and occationally get interface resets ( keepalive time is 10
       seconds -- so 3 at 10 seconds == 30 ).
    7) Sniffer on either side see nothing out of the ordinary.
    8) hosts pinging and being ping'd don't see high error rate ( in
       netstat ).

This sounds like some type of retiming problem to me.  Anyone have any
ideas?
--
Jim Ray                                Harris Semiconductor
Internet:  jdr@semi.harris.com         PO Box 883   MS 62B-022
Phone:     (407) 729-5059              Melbourne, FL  32901
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 09:32 EDT
From:      Bill Wine <BIWINE@vaxsar.vassar.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   POP protocol
We are interested in implementing a campus-wide e-mail system to link
about 300 Macs and PC's to an smtp host.  (Currently users log in to check
their mail.)  We would like to use pd software to reduce costs, so we
obtained a POP3 server and Eudora client software.  The system seems
to work very well, (with 3 concurrent users) and we especially like
the Eudora user interface.  Our concern is that the POP architecture
may not be sutiable for a large mail system.  It seems inefficient for
the POP client to check for newmail every 5 or 10 minutes.  This would
put a heavy load on the host with 300 clients.  It seems to me that a
better idea would be for a client to log in once, and for the server
to check for newmail periodically, then send it to the client.  
Commercial systems such as QuickMail work this way, using a dedicated
Mac as a server.  One pd system that uses this architecture is MacPost
from Lund University.  We have just begun testing it.  One drawback is
that the user interface is not as nice as Eudora.

Would anyone care to share their experiences with large Mac or PC
e-mail systems (100+ concurrent users).  Is the POP architecture
suitable for large systems?  Is there a better one?

Thanks for your help.

Bill Wine
biwine@vassar.edu

cc: macnet-l@yalevm.bitnet
cc: tcp-ip@nic.ddn.mil
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 10:06:00 GMT
From:      HARISH@ITIVAX.BITNET
To:        comp.protocols.tcp-ip
Subject:   3Com's 3C501 card and NetBIOS

Folks,

I'm trying to establish if there is a NetBIOS stack that compensates for
3Com's 3C501's deficiencies?  I have a zillion of these cards and am
trying to see if I can use existing code to run on them.  The code works
just fine with the 3C503s (Etherlink II). The NetBIOS stack need not be
able to talk to a TCP/IP stack (ie RFC 1001/2) but if it does, so much
the better.  Any pointers?  I've access to 3Com's NBP program (version 1.1)
but my app/code doesn't do too well with that and a 501, but works great
with a 503.  Any pointers?

Thanks and regards,

--
Harish Pillay                     harish@itivax.bitnet
CSA Research Pte Ltd              (soon)...!hp-pcd!orstcs!temasek!harish
12 Science Park Dr #03-01         65-772-0594 (w), 65-777-4554 (fax)
Singapore 0511                    65-278-4191 (h)
Republic of Singapore

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 14:08:53 GMT
From:      rti!dg-rtp!tdc.rtp.dg.com!scott@mcnc.org  (John Scott)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Changing TCP window size on a SUN
In article <10703@uhccux.uhcc.Hawaii.Edu>, tony@uhheph.phys.hawaii.edu (Tony Querubin) writes:
|> I need to change the TCP window size that a SUN advertises to other hosts
|> that make a connection.  Thinking that it might be a configurable kernel
|> option, I looked through the various /sys/netinet files for a TCP WINDOW
|> parameter and found none.  On a second pass through the files I noticed
|> a definition for TCPOPT_MAXSEG in tcp.h.  
|> 
|> Question:  Can anyone verify for me that this is equivalent to the TCP window
|> parameter in KA9Q?  I'd like to know this BEFORE I reconfigure the kernel.
|> 
|> Essentially, I want any host making a connection to this SUN to send only one 
|> TCP packet at a time.  The reason for this is that the path to the SUN goes
|> through a PC using a 3C501 ethernet board.
|> 
|> Antonio Querubin
|> querubin@uhunix.uhcc.hawaii.edu
|> 

You're confusing window size with maximum segment size.  There is nothing you 
can do about the TCP Maximum Segment Size, nor should you want to.  The 
MSS is calculated based on the MTU size of the interface used for communication
(or 576 if communicating through a gateway).  If the version of SunOS you're
using does not use that algorythm then you are out of luck (I'm pretty sure
that SunOS 4.x uses the interface MTU.  Older SunOS's don't.)

The window size is the amount of data a communicating peer may send.  This is
tied to the socket buffer space.  This is controlled using the socket option
SO_RCVBUF (SO_SNDBUF is used to control the socket send buffer space).  As with
TCP MSS, newer SunOS supports this option, older version don't.  With older 
SunOS's you may be able to patch your kernel to use larger send and receive 
windows.  There are two global variables, tcp_sendspace and tcp_recvspace, that
control the amount of buffer space reserved. (If I got the names wrong, don't
flame me just give the right names.)

As for KA9Q, I don't know for sure though I would expect it to do the right thing
(depending on the version you're using).

P.S. Has anyone tried using a server other than a SUN for SUN Sparc stations?  You
may be in for a nasty surprise.  Ask your SUN rep for details.
-- 

John A. Scott			scott@dg-rtp.dg.com
Data General, RTP, NC	<some area of the know world>!mcnc!rti!xyzzy!scott
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 17:25:34 GMT
From:      sdd.hp.com!wuarchive!cs.utexas.edu!milano!uudell!Kepler!mjhammel@ucsd.edu  (Michael J. Hammel)
To:        tcp-ip@nic.ddn.mil
Subject:   gettimeofday() in ISC TCP/IP 1.1.2
I want to time read()'s from a socket.  The code went something like this

	gettimeofday(startime,0)
	read(socket, buf, length)
	gettimeofday(endtime,0)

This didn't work because the granularity was not small enough (starttime
equaled endtime).  I then changed the timing to be outside of a loop
which was reading in a requested amount of data (the read was inside
this loop).  This included a poll() which waited till I had data in the
socket.  This worked a little better and only occassionally were the
time values equal.  However, on nearly every test of this, after some
seemingly random period, its almost guaranteed to give me an endtime
*less* than the starttime!  I put in some debug code which proved this. 
I think its because the gettimeofday() call is reading the sec's and
microsec's at a point where the clock has not updated the sec's value
after the microsecs value has rolled over.  Is this right?  How can the
endtime be less than the starttime?  Is there anyway to prevent this
from happening?  Is there a better way to time what I'm trying to time? 
There's an itimer() call in V4 (I think) but thats apparently not
available in V3.2.

Michael J. Hammel        | mjhammel@{Kepler|socrates}.dell.com
Dell Computer Corp.      | {73377.3467|76424.3024}@compuserve.com
#include <disclaim/std>  | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel
#define CUTESAYING "Your cute quote here"
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 18:28:52 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!anagld!anagld.analytics.com@apple.com  (Diane M. Moss)
To:        tcp-ip@nic.ddn.mil
Subject:   Having Problems with WIN/TCP Functions
I was wondering if there is anyone "out there" that may
have done any programming using the WIN/TCP TLI functions.
Specifically, the functions contained in the Sockets Compatibility
Library.

I have been having a lot of trouble establishing a connection
if I specify both the client address/port and the server
address/port.  Is there any reason why I cannot specify the
specific port on both sides of the connection?  We do a 
socket() and a bind() on both client and server, and then
a listen() and accept() on the server while the client does
a connect().  We have set a timer on the server of five 
minutes and it goes into the listen() according to "netstat".
The client goes into the connect() and hangs until the timer
on the server side goes off at which point it returns with
a bad file descriptor (-1) due to the server error.  Without that
timer, the client side just hangs forever.  Anyone with any
information or ideas, please let me have 'em.  I am getting kind
of desperate for something to try.

I have spoken with AT&T and they sent me a toy which fails in
exactly the same way as our code so that didn't help.

Please reply to:  uunet!anagld!moss
  OR              moss@analytics.com


Thanks.  Diane.
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 18:47:03 GMT
From:      att!watmath!watserv1!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet@ucbvax.Berkeley.EDU  (Peter Whittaker)
To:        tcp-ip@nic.ddn.mil
Subject:   Seeking Info on behavior w, w-o keepalives
I posted this to comp.unix.programmer and got no response, so I thought
I seek the wisdom of readers of comp.protocols.tcp-ip!  advThanksance.

I've described a client/server interaction below, where the server "goes
away" then the client tries to access the socket that had connected them.
What I need to know is what the client should expect from various operations,
with and without SO_KEEPALIVE set as a socket option (on the client side).

The client/server relationship:  server binds, listens, accepts, then 
dies (either host goes down or server crashes/is killed).  Kernel then
attempts to close socket.  (Obv.  it's a TCP socket).

The client connects, then does some other stuff 
(i.e. sleep(until_server_is_dead);).
As I understand it, this is what happens when various functions are used
against the socket (NOTE:  no data transfer is pending:  either all data
has been transferred, or none was transferred, before the server died.).

		without  SO_KEEPALIVE		with SO_KEEPALIVE

read()		retcode==-1, errno==?		retcode==-1, errno==?
		(or maybe retcode 0, EOF read in?)

write()		retcode==-1, errno==?		SIGPIPE raised

select()	?? (readfds set true?,		?? (readfds and excepfds
		    EOF pending?)		    set true, EOF pending?)

close()		socket is closed.		socket is closed (*).

(*)-if implementation is correct:  HP-UX 6.5 clients using SO_KEEPALIVE
    never let the socket be closed.  They ACK the server-side FIN_ACK,
    but keep sending keepalives:  they never send their own FIN_ACK, so 
    server never sends RST (server-side kernel ACKs the keepalives).
    Socket is never closed.

I also have a question related to what exceptional events a 
select(...,&excepfds,....) can look for (I RTFMed, but couldn't find it;
any pointers, anyone?), but I'll leave that 'til later....

Thanks,





--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 19:11:02 GMT
From:      cogsci!ohst@ucsd.edu  (Ronald Ohst)
To:        tcp-ip@nic.ddn.mil
Subject:   10Net Plus experiences
Anyone out there have any experience with a peer-to-peer called
10Net Plus ??

Any comments appreciated, especially if you've used it with a card other
than DCA's 10Net card.  Also, if you've used it in conjunction with
TCP/IP I'd like to hear about your experience, (please!)

Thanks.

Ron Ohst
Department of Cognitive Science
University of California, San Diego
rohst@ucsd.edu
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 21:53:05 GMT
From:      voder!pyramid!infmx!aland@ucbvax.Berkeley.EDU  (Colonel Panic)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: List of streams-based Protocol suites / Communication Packages
In article <8443@gollum.twg.com> david@twg.com (David S. Herron) writes:
>In article <1990Dec11.174624.26388@diku.dk> krus@rimfaxe.diku.dk (Lars Povlsen) writes:
>>Name		: Wollongong TCP/IP
>>Manufacturer	: The Wollongong Group
>>OEMs		: ?
>>Product		: Full TCP/IP implementation
>>OS'es supported	: SCO, ATT V.4, VMS
>	Also on AT&T SysVr3.2, Intel r3.2, Interactive r3.2, etc.

REALLY?!  If so, please tell your support people this!  I have an
outstanding case with kernel panics and strange error messages from a 
driver routine right now.  My environment is a 6386E/33 running AT&T
SVR3.2, and one of the first things I was told was that it was "not a 
supported platform, but we'll do our best."

>Also, a new product:
>
>Name		: Wollongong OSI
>Product	: OSI Upper & Lower layers in STREAMS, can connect directly
>		:	to X.25 switches
>		: OSI X.400 mailer with UUCP/SMTP & RFC-987/1138/1148 gateway
>		: OSI X.500 Directory server
>OS'es supported	: SCO/Unix, SCO/ODT, AT&T SysVr3.2, Intel r3.2, Interactive r3.2
===   is this for sure?                      ^^^^^^^^^^^^^^

>Contact sales at (415) 962-7202 for more information.

--
Alan Denney      aland@informix.com      {pyramid|uunet}!infmx!aland

"When will Apple get socially responsible and offer separate trash can
 icons for glass, aluminum, and paper?"
  - Lincoln Spector
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Dec 90 23:41:36 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Richard Wolski)
To:        tcp-ip@nic.ddn.mil
Subject:   Proxy Arp -- Its Uses and Abuses
Greetings and Salutations,

I have some quick questions about proxy arp and its uses: 

1)  Do most implementations fully implement what is specified in RFC 925, or 
    is a subset of this specification usually implemented (eg. RFC 1027)?

2)  In your experience, how does it work?  That is, does it work 
    well in a tree structured network as well as networks with
    loops?  Are there any limitations to it?

3)  Does anyone have an implementation that is available (for free)?

Any comments will be greatly appreciated.  Please email your opinions, 
objections, I-can-relate-to-that statements, etc. to me and I will 
summarize if there is enough interest.

Thank You most prolifically,

Rich

Rich Wolski
rwolski@lll-crg.llnl.gov
P.O. Box 808, L-306
Livermore, CA 94550
(415)423-8594
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 02:12:36 GMT
From:      bu.edu!cs.bu.edu!ckd@eddie.mit.edu  (Christopher Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: gethostbyaddr() failing
Milo> "Milo" == medin@NSIPO.NASA.GOV
Milo> ("Milo S. Medin", NASA ARC NSI Project Office) writes:

Milo> There is no reason that the DNS configurations, if done
Milo> thoroughly, break netstat and traceroute.  Again, if you configure
Milo> the DNS information to be completely consistent, things work fine.

Care to suggest how I can do this for the NSFNET backbone?  I don't have
authority for *.NSS.NSF.NET, you know.

I suggest that "regular" gethostbyaddr() default to the authentication
behavior (the "SUN/NASA" mode) and that a separate library function
"ugethostbyaddr()" or the like be added for "unauthenticated" PTR
lookups.

--Chris
--
   [ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
    A message destined for delivery in *your* domain is fair game for
  anything you may want to do, up to and including translating the entire
 message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 02:49:59 GMT
From:      sdd.hp.com!spool2.mu.edu!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!gauss.math.purdue.edu!wilker@ucsd.edu  (Clarence Wilkerson)
To:        tcp-ip@nic.ddn.mil
Subject:   LPD daemon for PC
I'm trying to get the binaries from the recent version of LPD for
the PC ( PC based print server ) to work. From my sun to the PC,
the files get downloaded and the proper spool files created. However
the LPD program shows the files as having 0 length, and no action
shows up on the printer.
  Does any one have this going? This is beta release 1.4 by
D. Johnson at Old Miss.
Clarence Wilkerson
 
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 04:03:13 GMT
From:      usc!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!kath@apple.com  (William L. Kath)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LPD daemon for PC
In article <2955@mentor.cc.purdue.edu> wilker@gauss.math.purdue.edu.UUCP (Clarence Wilkerson) writes:
>I'm trying to get the binaries from the recent version of LPD for
>the PC ( PC based print server ) to work. From my sun to the PC,
>the files get downloaded and the proper spool files created. However
>the LPD program shows the files as having 0 length, and no action
>shows up on the printer.
>  Does any one have this going? This is beta release 1.4 by
>D. Johnson at Old Miss.
>Clarence Wilkerson
> 

I would also be interested in any comments.  We've been trying to get the
program to work and have been having trouble, too.  In our case, the files
get downloaded, the spool and control files get created, and then the
program apparently *deletes* the control files before actually doing any
printing.  

I've talked to Mr. Johnson at Ole' Miss, and he's been helping out, but
it's kind of hard for him to debug his code from 1000 miles away (esp. when
on a PC).  I'm not a C programmer, but I may be learning soon :).

In case anyone out there has got this to work, I've tried this on several
machines (286-386, several brands) with the same behavior.  All are on a
Western Digital StarLan (but since the files transfer OK, I didn't think it
would be a networking problem).  Also, NCSA telnet and KA9Q NOS all work
fine with the packet drivers from Clarkson.

I used the default configurations (they seemed OK), put the program and
config files in /spool, and created /spool/lpd for the files to be printed
and for the control files.  Is there something else I'm missing?

This will be a *great* addition to the available PD networking software for
PCs once the bugs are out.

Thanks in advance,

Bill Kath ----------------------- kath@delta.eecs.nwu.edu
             Engineering Sciences and Applied Mathematics
   A Guest of Electrical Engineering and Computer Science
McCormick School of Engineering,  Northwestern University
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 04:49:37 GMT
From:      att!mcdchg!tellab5!mtcchi!levy@ucbvax.Berkeley.EDU  (2656-Daniel R. Levy(0000000)0000)
To:        tcp-ip@nic.ddn.mil
Subject:   Comer/Shein whois server example won't work on Sparcstation
I tried to run the whois server example by Barry Shein in Douglas Comer's
_Internetworking_With_TCP/IP_ on a Sparcstation running SunOS 4.0.3...  bind()
fails with EADDRNOTAVAIL even though the program was run with uid=euid=0.
(Killing inetd, guessing that it might somehow be interfering, did not help.
It did run fine on two SVR2 machines, an Amdahl and a 3B2.  I do not have any
other 4BSD machines for testing.) Below is a listing of the program (with some
debug print statements thrown in) and then the output I get when running it on
the Sparcstation.  Can anyone please assist... thanks much in advance.

-------------------------------------------------------------------------------
/* whoisserver.c - main */

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <pwd.h>

#define BACKLOG		5
#define MAXHOSTNAME	32

main(argc,argv)
char **argv;
{
	int s, t;
	int i;
	struct sockaddr_in sa, isa;
	struct hostent *hp;
	char *myname;
	struct servent *sp;
	char localhost[MAXHOSTNAME+1];

	myname = argv[0];

	if ((sp = getservbyname("whois","tcp")) == NULL) {
		fprintf(stderr,"%s: No whois service on this host\n",myname);
		exit(1);
	}

	printf("service name: %s\n",sp->s_name);
	for (i=0; sp->s_aliases[i]; i++) printf("alias name %d: %s\n",i,
						sp->s_aliases[i]);
	printf("port: %d\n", sp->s_port);
	printf("protocol: %s\n", sp->s_proto);

	gethostname(localhost,MAXHOSTNAME);
	if ((hp = gethostbyname(localhost)) == NULL) {
		fprintf(stderr,"%s: cannot get local host info?\n",myname);
		exit(1);
	}

	printf("host name: %s\n",hp->h_name);
	for (i=0; hp->h_aliases[i]; i++) printf("alias name %d: %s\n",i,
						hp->h_aliases[i]);
	printf("address type: %d [AF_INET=%d]\n",hp->h_addrtype,AF_INET);
	printf("h_length = %d\n",hp->h_length);
	for (i=0; hp->h_addr_list[i]; i++) printf("address %d: %d.%d.%d.%d\n",
		i,
		(unsigned char)(hp->h_addr_list[i])[0],
		(unsigned char)(hp->h_addr_list[i])[1],
		(unsigned char)(hp->h_addr_list[i])[2],
		(unsigned char)(hp->h_addr_list[i])[3]);

	sa.sin_port = sp->s_port;
	bcopy((char *)hp->h_addr,(char *)&sa.sin_addr,hp->h_length);
	sa.sin_family = hp->h_addrtype;

	if ((s = socket(hp->h_addrtype,SOCK_STREAM,0)) < 0) {
		perror("socket");
		exit(1);
	}

	if (bind(s,&sa,sizeof sa) < 0) {
		perror("bind");
		exit(1);
	}

	listen(s,BACKLOG);

	while(1) {
		i = sizeof isa;
		if ((t = accept(s,&isa,&i)) < 0) {
			perror("accept");
			exit(1);
		}
		whois(t);
		close(t);
	}
}

whois(sock)
{
	struct passwd *p;
	char buf[BUFSIZ+1];
	int i;

	if ((i = read(sock,buf,BUFSIZ)) <= 0)
		return;
	buf[i] = '\0';

	if ((p = getpwnam(buf)) == NULL)
		strcpy(buf,"User not found\n");
	else
		sprintf(buf,"%s: %s\n",p->pw_name,p->pw_gecos);
	write(sock,buf,strlen(buf));
	return;
}
-------------------------------------------------------------------------------
Attempt to run program:

ihckpo$ id
uid=0(root) gid=1(daemon) groups=1(daemon)
ihckpo$ ./whoisserver
service name: whois
alias name 0: nicname
port: 43
protocol: tcp
host name: ihckpo
alias name 0: skpo
address type: 2 [AF_INET=2]
h_length = 4
address 0: 135.1.13.44
bind: Can't assign requested address
ihckpo$ ps -axwwu
USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
root         0  0.0  0.0    0    0 ?  D    Dec 16  0:05 swapper
root         1  0.0  0.1   52   16 ?  I    Dec 16  0:03 /sbin/init -
root         2  0.0  0.0    0    0 ?  D    Dec 16  0:00 pagedaemon
levy      6229  0.0  0.0   44    0 p0 IW   20:54   0:00 /bin/ksh
root        98  0.0  0.0  104    0 ?  IW   Dec 16  0:01 /usr/lib/sendmail -bd -q1h
bin         49  0.0  0.5   32   84 ?  I    Dec 16  0:04 ypbind
root        46  0.0  0.0   40    0 ?  IW   Dec 16  0:03 portmap
levy      6171  0.0  0.0   44    0 co IW   19:04   0:00 -ksh (nksh)
root        52  0.0  0.0   36    0 co IW   Dec 16  0:00 keyserv
root        56  0.0  0.0   36    0 ?  IW   Dec 16  0:00 rpc.ypupdated
root        74  0.0  0.0   16    0 ?  I    Dec 16  0:00  (biod)
root        73  0.0  0.0   16    0 ?  I    Dec 16  0:00  (biod)
root        75  0.0  0.0   16    0 ?  I    Dec 16  0:00  (biod)
root        76  0.0  0.0   16    0 ?  I    Dec 16  0:00  (biod)
root        89  0.0  0.0   64    0 ?  IW   Dec 16  0:06 syslogd
root       132  0.0  0.0   12    0 ?  IW   Dec 16  0:05 /usr/bin/screenblank -d 900 -e 1.0
levy      6227  0.0  0.0  232    0 co IW   20:54   0:05 sunview
root       106  0.0  0.0   24    0 ?  I    Dec 16  0:01  (nfsd)
root       107  0.0  0.0   72    0 ?  IW   Dec 16  0:02 rpc.mountd -n
root       134  0.0  0.4   92   56 ?  S    Dec 16  0:17 automount /auto auto.master
root       112  0.0  0.0   24    0 ?  I    Dec 16  0:00  (nfsd)
root       113  0.0  0.0   24    0 ?  I    Dec 16  0:00  (nfsd)
root       114  0.0  0.0   24    0 ?  I    Dec 16  0:00  (nfsd)
root       115  0.0  0.0   24    0 ?  I    Dec 16  0:01  (nfsd)
root       116  0.0  0.0   24    0 ?  I    Dec 16  0:01  (nfsd)
root       117  0.0  0.0   24    0 ?  I    Dec 16  0:01  (nfsd)
root       118  0.0  0.0   24    0 ?  I    Dec 16  0:01  (nfsd)
root       119  0.0  0.0   60    0 co IW   Dec 16  0:00 rpc.lockd
root       146  0.0  0.1   12    8 ?  S    Dec 16  6:43 update
root       123  0.0  0.0   48    0 co IW   Dec 16  0:00 rpc.statd
levy      6234  0.0  0.8  372  124 co S    20:54   0:06 mailtool -Wp 0 0 -Ws 1152 900 -WP 1088 0 -Wi -i 30
root       150  0.0  0.0   76    0 ?  IW   Dec 16  0:24 cron
levy      6629  0.0  0.2   48   28 p3 S    22:27   0:02 ihcgf
root       169  0.0  0.0   52    0 ?  IW   Dec 16  0:00 /usr/lib/lpd -L /var/spool/lpd/err.log
levy      3041  0.0  0.0   40    0 co IW   Dec 18  0:01 selection_svc
root      1386  0.0  0.0   48    0 ?  IW   Dec 17  0:00 rpc.rquotad
levy      6238  0.0  0.0  104    0 p2 IW   20:54   0:00 shelltool -Wp 260 192 -Ws 650 567 -WP 832 0 -Wi -Wg
levy      6237  0.0  1.9  100  284 co S    20:54   0:02 clock -Wp 942 853 -Ws 210 47 -WP 1088 825 -Wi -f -r -d amy -s -Wg
root      6565  0.0  0.0   32    0 ?  IW   22:19   0:00 - Auto-baud ttyb (getty)
levy      6239  0.0  0.0   44    0 p2 IW   20:54   0:00 /bin/ksh
levy      6242  0.0  0.0   52    0 p3 IW   20:54   0:01 /bin/ksh
levy      6244  0.0  2.7  128  412 p4 S    20:54   0:28 shelltool -Wp 387 318 -Ws 650 567 -WP 960 0 -Wi -Wg
levy      6228  0.0  0.0  144    0 p0 IW   20:54   0:01 cmdtool -Wp 0 0 -Ws 670 71 -WP 0 0 -Wl << CONSOLE >> -WL console -C
levy      6241  0.0  4.1  128  628 p3 S    20:54   0:47 shelltool -Wp 321 256 -Ws 650 567 -WP 896 0 -Wi -Wg
levy      6245  0.0  0.0   52    0 p4 IW   20:54   0:04 /bin/ksh
levy      6232  0.0  0.0   44    0 p1 IW   20:54   0:01 /bin/ksh
levy      6248  0.0  1.5  100  232 co S    20:54   0:03 perfmeter -Wp 1024 0 -Ws 64 48 -WP 1024 0 -Wi -Wg
root      6249  0.0  0.6   36   88 ?  S    20:54   0:00 rpc.rstatd
levy      6235  0.0  0.0  104    0 co IW   20:54   0:04 Mail -N -B -f /tmp/MTda06234
levy      6567  0.0  0.0   48    0 p2 IW   22:19   0:00 ttbcad
root      6662  0.0  2.0  128  312 p4 R    22:41   0:00 ps -axwwu
root      6600  0.0  1.2   60  184 p4 S    22:25   0:01 ksh
levy      6566  0.0  0.0   48    0 p2 IW   22:19   0:00 ttbcad
levy      6231  0.0  0.0  120    0 p1 IW   20:54   0:59 shelltool -Wp 195 128 -Ws 650 567 -WP 768 0 -Wg
root      6616  0.0  0.4   44   64 ?  I    22:26   0:01 /usr/etc/inetd
levy      6628  0.0  0.2   48   24 p3 S    22:27   0:00 ihcgf

-------------------------------------------------------------------------------
-- 
* Daniel R. Levy *  uunet!tellab5!mtcchi!levy *                             |
* These views are live; they are not Memorex' *                           --+--
Praise the Lord, Praise the Lord, let the earth hear His voice;             |
Praise the Lord, Praise the Lord, let the people rejoice.  [F. Crosby]      |
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Dec 90 13:33:04 -0500
From:      vcerf@NRI.Reston.VA.US
To:        tcp-ip@nic.ddn.mil, ietf@venera.isi.edu
Subject:   An ACM request for participation (ACM Members Only)
I hope you will forgive the "broadside" but this seemed the most effective 
way to deliver this request for volunteers from among the members of the
Association for Computer Machinery. I expect many of you are members
of ACM SIGCOMM, but a lot of you are members of other special interest
groups as well (such as operating systems, graphics, and so on).

If anyone finds this of interest, please respond to Borman.chi@xerox.com


Thanks,

Vint Cerf
SIGCOMM Chairman

------- Forwarded Message

Date: Thu, 20 Dec 90 10:55 CDT
From: LOR04207@nuacc.acns.nwu.edu
Subject: ACM DataPlan: Call for EGIS Participants


acm/DATAPLAN
Gathering Data for Planning
                                         
December 20, 1990                                                               
                                     
 
 
                           CALL FOR PARTICIPANTS
 
 
     1. ELECTRONIC GROUP INTERACTIVE SESSION (EGIS) WITH ACM SIG MEMBERS
 
     2. ELECTRONIC GROUP INTERACTIVE SESSION  (EGIS) WITH ACM STUDENT MEMBERS
 
There's a great deal of excitement within ACM lately as a result of the
adoption, by ACM Council, of a "Strategic Plan for the 1990's".  A summary
of the plan appears in the December 1989 issue of COMMUNICATIONS.  The
plan calls for, among other things, a major effort to gather information
about the needs and desires of members of ACM and its sub-units (and
non-members) in order to make ACM more responsive to the needs of these
individuals and to set ACM's future directions.  Information will be
gathered via traditional mail surveys, face-to-face focus groups, and an
experimental concept called EGIS (Electronic Group Interactive Session).
An EGIS is a discussion group conducted over a period of time using
electronic mail.
 
We are currently forming two EGIS groups made up of approximately 20-30
members each.  The first group will consist of members of ACM SIGs (who
may or may not be members of ACM).  Please note that for this particular
part of the project, we are primarily interested in SIG members who have
not recently held leadership positions in their SIGs.  The second group
will consist of Student members of ACM.  From both groups, we are
interested in hearing views on current and future ACM
programs, products, and services.  

The questions to be discussed by the groups will primarily be in regard to the
professional needs participants have and whether or not those needs are
currently being met by ACM or any other organization or service.
 
The groups will run over a two-week period (April 2 - April 15, 1991).
Selection will be based on certain criteria (e.g.,  location, length of
membership, etc.) with the aim of having the group represent, to the
extent possible, the relevant ACM population.  The protocol and process
for managing the groups are currently under review and will be explained
in future communications.  

If you are interested in participating in one
of the groups, (YOU MUST BE COMMITTED TO USING E-MAIL REGULARLY, i.e.,  we
expect that participants will read and respond to discussion group mail
on a daily basis), send the following information to the group's
coordinator, Lorraine Borman,  (email is preferred, but US mail is OK; see
address at the end of this memo) by March 15, 1991.  Individuals selected to
participate will be notified by March 22, 1991.
 
    Name
    Mailing Address
    Telephone Number(s)
    E-mail Address
    EGIS in which you'd like to participate (SIG or Student members)
 
Please answer the following questions (to help us form a balanced group),
noting the question numbers in your response:
 
FOR THE EGIS WITH MEMBERS OF ACM SIGS:
 
1. To which SIG(s) do you belong?
 
2. How long have you been a SIG member?
 
3. Do you currently hold a major office or position in the SIG (Chair,
   Vice-Chair, Secretary, Treasurer, Newsletter Editor, Advisory Board
   member) or have you held such an office or position within the past
   year?  If so, which one?
 
4. Are you a member of ACM?  Category? (Voting, Associate, Student)
 
5. Are you a member of an ACM Chapter, Student Chapter, Local SIG?
 
6. Are you primarily an educator? researcher? practitioner? manager?
   student?
 
FOR THE EGIS WITH STUDENT MEMBERS OF ACM:
 
1. Are you an undergraduate or graduate student?
 
2. How long have you been a student member of ACM?
 
3. Are you a member of ACM SIGs?  Which one(s)?
 
4. Are you a member of an ACM Chapter, Student Chapter, Local SIG?
 
5. Do you currently hold a major office or position in a SIG, Chapter,
   Student Chapter, Local SIG (Chair, Vice-Chair, Secretary, Treasurer,
   Newsletter Editor, Advisory Board member) or have you held such an
   office or position within the past year?  If so, which one?
 
 
We appreciate your interest in ACM and expect that your participation in
our project will be rewarding for you as well as beneficial for ACM.  It's
your chance to say what you want from your computing society...and be part
of an interesting process!
 
Thank you.
  
Lorraine Borman
Email:  Borman.chi@xerox.com
US mail:  1865B Tanglewood Drive, Glenview, IL 60025 


------- End of Forwarded Message

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Thu, 20 Dec 90 13:36:25 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        aprm%gd@shafter-emh2.army.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SQL over DDN
    I've been thinking about how to implement a distributed database with
    sites located in Hawaii, Alaska, Japan, and Korea.  I see where ORACLE
    (and others) support SQL over tcp/ip networks.  Is there any chance that
    this could be done using the DDN to carry the query/response traffic?

There are two main issues: throughput required, and response time. Things
one would need to know in order to evaluate it are:  How many clients will
be talking to one server?  What's the transaction rate you want to provide
to a single client?  How many data exchanges (and thus round-trip-times)
does a single transaction require?  For what fraction of a transaction will
the database need to be locked against other clients?  What are the minimum,
maximum and average round-trip times you expect the net to provide?  The
major pitfall would appear to be long round-trip-times leaving the files
locked for much longer per transaction than you might initially guess, and
this could greatly reduce the overall transaction rate.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Wed, 19 Dec 90 18:06 U
From:      <HARISH%ITIVAX.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   3Com's 3C501 card and NetBIOS
Folks,

I'm trying to establish if there is a NetBIOS stack that compensates for
3Com's 3C501's deficiencies?  I have a zillion of these cards and am
trying to see if I can use existing code to run on them.  The code works
just fine with the 3C503s (Etherlink II). The NetBIOS stack need not be
able to talk to a TCP/IP stack (ie RFC 1001/2) but if it does, so much
the better.  Any pointers?  I've access to 3Com's NBP program (version 1.1)
but my app/code doesn't do too well with that and a 501, but works great
with a 503.  Any pointers?

Thanks and regards,

--
Harish Pillay                     harish@itivax.bitnet
CSA Research Pte Ltd              (soon)...!hp-pcd!orstcs!temasek!harish
12 Science Park Dr #03-01         65-772-0594 (w), 65-777-4554 (fax)
Singapore 0511                    65-278-4191 (h)
Republic of Singapore
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 14:33:03 GMT
From:      mcsun!ukc!icdoc!syma!nickw@uunet.uu.net  (Nick Watkins)
To:        tcp-ip@nic.ddn.mil
Subject:   Cherokee WORM (DOS) & HP 9000 cluster (longish) ???
I will shortly have a Cherokee M610 WORM drive with Adaptec SCSI host
adapter & DOS driver software, which I need in order to read data which
will be sent to me on DOS format WORM disks. I will be able to do this
locally on a Vectra QS/20 running DOS 4.0 & can, if necessary, transfer
whole files to our HP 9000 cluster using NCSA Telnet 2.2.

What I *can't* do is access the WORM drive directly from the HP cluster to
,e.g., find *part* of a file (I can ftp the whole file, but some are 18 Mb
or so ) and read it for analysis on the HP. I also can't connect the
WORM drive directly to the HP & still read the DOS format. In fact until
HP support SCSI on the 835 I can't connect it, period.

Is there any way round this (I can always use the Vectra for most of the
work, I'd just prefer to use the 9000 for obvious reasons) ?

In particular, could I run Unix (SCO ? Interactive ?  ...) on the PC,
and NFS mount the PC to our HP, while still being able to see the DOS WORM
drive (on the PC) as as a DOS file system. Would this solve the problem
& would it work on a 40 Mb, 2Mb RAM Vectra (no money for hardware
upgrades) ... :-( If not, how much more RAM & disk do I need ? 

[ SCO In UK seem to differ on whether it's possible, has
anybody actually done it ? ]

Any other solutions : Running OS/2 on Vectra ? Some kind of portability
software ? (Quickstart has been mentioned, what is it ?) Can the HP
CD-ROM 9000 driver be adapted to handle a WORM drive ?

All ideas welcome, esp. from HP, SCO, Cherokee or anyone who  has actually done
something like this ? 

Nick
-- 
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 16:38:02 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!intercon!news@apple.com  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  POP protocol
In article <9012191619.AA12643@ftp.com>, fks@FTP.COM (Frances Selkirk) writes:
> There is nothing in the POP architecture that requires automatic polling.
> Our POP clients check for mail when invoked. Look around for another 
> implementation.

You are assuming that you can not set up Eudora to check only on demand.
I believe you can.  And this does not answer the question asked by the ONW.

What you want probably does not exsist, at least not using a standard TCP/IP
application.  You could just have Eudora or whatever POP client you end up 
with just check when the user wants to see if there is mail.  The assumption 
made with POP is that there is no garuntee that the PC/Mac/Whatever is up 
and running on the network.  I supposed that you could have the server query 
the client and if it doesn't find the client it stops trying to send until 
it is tickled again.  That would be a way to handle what you want.  I am
unaware of any PD software that does what you want (other than something
like MacPost, which, if I am right, uses its own protocol for sending to
the individual Macs, but talks SMTP to the world?).

What someone needs to do is to extend the POP spec to handle this.  It might
be something worthwhile.  Adding the ability to have the server, once tickled,
query the client only when it has mail.

On another note, I estimate that there are about 30 60byte packets that go
out for every client query, that's not a whole lot.

Hope this helps.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 17:15:46 GMT
From:      pete@wvus.wciu.edu (Pete Gregory)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   telnet terminal emulators

Hi - we have purchased Sun PC-NFS-51 (Version 3.0.1) for several MS-DOS
machines that are connected (via 10BT) to a Unisys 6000/70 (Sequent S27)
via NFS and Telnet.

Telnet emulates vt100 which, as you may know, only has four function keys.
PC-NFS does not provide any other terminal emulation or keyboard mapping
facilities.  We need function keys F1-F10 for use with some UNIX-based
office-automation software we're using (Uniplex).

Anyone know of other Telnet/NFS products that provides more flexible 
keyboard mapping and/or terminal emulation?

Thanks...
 
Pete Gregory, UNIX SA  |  pete@wvus.wciu.edu                  |
World Vision USA/ISD   |  wciu!wvus!pete                   ___|___
919 W. Huntingon Dr.   |  Voice: 818/357-7979 x3347           |
Monrovia, CA  91016    |  FAX:   818/303-6212                 |
                                                              |
Romanian orphans need our help!  Call 1-800-777-1229

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 22:09:40 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sparta!lbrandt@ucsd.edu  (Lawrence R. Brandt)
To:        tcp-ip@nic.ddn.mil
Subject:   ES-IS on IP ?
Hi,
  I wonder if anyone has heard of using the ISO ES-IS routing protocol
on a 'base' of IP. Does one need a full blown ISO or is there a IP/ISO
interface. I seem to remember something that allows ISO applications
(i.e. FTAM) to use IP as a medium for transport. But this would most 
likely not work. 
  Any help you could give would be helpful.

  Thanks,

  Larry
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 23:25:17 GMT
From:      mips!wdl1.wdl.loral.com!wdl51!wrl@apple.com  (Bill Lewandowski)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SQL over DDN
I don't see why it would not work as long as all the
SQL servers were on the DDN. Data seems to move between
DDN sites fine. Its when you have DDN-Internet that
the mailbridges (as their called) seem to screw things
up.

Just remember that their are packet charges on the DDN and
you need to figure out how much data you are going to
be generating. DCA might not appreciate it if you
swamp there network. I'm not sure but I still think most
oveseas circuits between switchs are 9.6 (I could be wrong).

Bill
===========================================================

-- 
Bill Lewandowski		LORAL Western Development Labs
(408) 473-4362			Internet: wrl@wdl1.wdl.loral.com
FAX: (408) 473-7926		UUCP: wdl1!wrl
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      20 Dec 90 23:27:29 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!attcan!lsuc!maccs!kevinb@ucsd.edu  (Kevin Boyes)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip and osi
Hello,

I was reading an article in Computing Canada (Dec. 6) called
"Migration to OSI requires look at alternative strategies"; in
it they say
	...
	"The top-down method is most popularly for OSI
	 applications over TCP/IP networks since TCP/IP
	 network services are closely related to OSI
	 networks (TCP/IP was derived from OSI as OSI
	           ----------------------------------
	 was evolving in the 70s)."
	 -----------------------

Maybe I've been living under my rock for too long, but I did
not realize this.  The simularities are obvious but TCP/IP being
derived from OSI and not the other way around hadn't occurred to me.

Is this statement accurate?

					Kevin Boyes
-- 
-- 
Kevin Boyes                                     kevinb@maccs.dcss.McMaster.CA
McMaster University                         ...!uunet!utai!utgpu!maccs!kevinb
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Dec 90 10:33:06 -0500
From:      H. Craig McKee <mckee@community-chest.mitre.org>
To:        cogsci!ohst@ucsd.edu (Ronald Ohst)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: 10Net Plus experiences
Ron - 10NET Plus was selected for the Air Force ULANA contract.
(Unified Local Area Network Architecture). Hopefully you will get some
comments from MILNET sites.  Please summarize to the list.

Regards - Craig
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 08:29:33 GMT
From:      agate!linus!nixbur!nixpbe!peun33!liesert@ucbvax.Berkeley.EDU  (Hansi)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP-MIB for unix systems?
Hi out there,

maybe I'm asking a FAQ - if so please forgive me.
In a german computer magazine I read about snmp and its MIB. I was told,
that there a standard for unix-MIBs is developed. Can anyone tell me
more about this? Is there a RFC? Where can I get it?

Thanks in advance
--
| Hans Joachim Liesert, Dep. STO-SI 35   | Email:  liesert.pad@sni.de      |
| Siemens-Nixdorf Informationssysteme AG | Outside Europe:                 |
| Pontanusstrasse 55                     |         liesert.pad@nixdorf.com |
| W-4790 Paderborn, Germany              | Disc.: I don't speak for SNI!!! |
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 08:58:44 GMT
From:      sgi!oilean!joe@ucbvax.Berkeley.EDU  (Joe McGuckin)
To:        tcp-ip@nic.ddn.mil
Subject:   Help w- ethernet device

I'm building a piece of communications hardware and I'd like it to have an ethernet interface. I`ve seen
Imagen laser printers like this - so I know that it's been done before. 

My problem is that I don't have a clear idea of how a program running on a Sun will establish a connection
with the device. Can the hardware make an unsolicited connection across the ethernet & start up it's
control software?

Does anyone out there in netland know about this sort of thing? Please send mail as I don't normally
read these groups.

Thanks,

  Joe


-- 
Joe McGuckin             oilean!joe@sgi.com
Island Software          joe@parcplace.com
(415) 969-5453
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 12:17:39 GMT
From:      dsac.dla.mil!dcsc.dla.mil!drezac@tut.cis.ohio-state.edu  (Duane L. Rezac)
To:        tcp-ip@nic.ddn.mil
Subject:   PCIP and 3com 3c503

Hello: 

I am trying to get the pcip package compiled and running, but I have
had some problems.  I have not been able to get any response from
the package. netdev.sys has been customized for the settings on my
card, and I have compiled the 3com versions. 

My system is as follows: 

computer: Zenith 248 , 286 based with co-processor
op-system: dos3.21 or 4dos  (I've used both) 
compilers: Quick C 2.0 and the arrowsoft masm 3.0 clone
ethernet card: 3Com 3c503 eithernet card 
                       dma 1
                       address 0x300
                       interrupt 3

Any suggestions/tips/help would be appreciated


Duane L. Rezac

--
Verse of the Hour:
But whosoever shall deny me before men, him will I also deny before my 
Father which is in heaven.
    Matt. 10:33
-- 
+-----------------------+---------------------------------------------------+
| Duane L. Rezac |These views are my own, and NOT representitive of my place|
| dsacg1!dcscg1!drezac    drezac@dcscg1.dcsc.dla.mil      of Employment.    |
+-----------------------+---------------------------------------------------+
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Fri, 21 Dec 90 12:33:39 +0100
From:      Craig Partridge <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   re: Code from Stevens' book

In article <15400001@hpdmd48.boi.hp.com> brown@hpdmd48.boi.hp.com (Kevin Brown)
writes:
>
> just got a great book called "UNIX Network Programming," by Stevens.
>There are lots of interesting routines and code fragments in the book.
>Does anyone know if they are available somewhere on the net? I'm trying

One caution about the code -- the error handling tends to be pretty simple.
Rich was interested in illustrating the basic techniques and avoided getting
into deep error handling issues -- as a result, some of the code is probably
not production quality...

Craig
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 16:46:44 GMT
From:      swrinde!cs.utexas.edu!oakhill!nddsun1!markm@ucsd.edu  (Mark Monninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  POP protocol
I have seen references to Eudora a couple times here. Can anyone tell
me where to find it? We're looking for something to do what Eudora
apparently does so I'd like to try it. I was told it was on
ux1.cso.uiuc.edu but I couldn't find it there. Maybe I wasn't looking
for the correct file name. Any help will be appreciated.

Thanks.

Mark
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 18:40:19 GMT
From:      motcsd!mcdcup!mcdchg!tellab5!mtcchi!levy@apple.com  (2656-Daniel R. Levy(0000000)0000)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Comer/Shein whois server example won't work on Sparcstation
I wrote

>I tried to run the whois server example by Barry Shein in Douglas Comer's
>_Internetworking_With_TCP/IP_ on a Sparcstation running SunOS 4.0.3...  bind()
>fails with EADDRNOTAVAIL even though the program was run with uid=euid=0.
>(Killing inetd, guessing that it might somehow be interfering, did not help.
>It did run fine on two SVR2 machines, an Amdahl and a 3B2.  I do not have any
>other 4BSD machines for testing.) Below is a listing of the program (with some
>debug print statements thrown in) and then the output I get when running it on
>the Sparcstation.  Can anyone please assist... thanks much in advance.

>main(argc,argv)
>char **argv;
>{
	...
>	struct sockaddr_in sa;
>	struct hostent *hp;
>	int s;
	...
>	sa.sin_port = sp->s_port;
>	bcopy((char *)hp->h_addr,(char *)&sa.sin_addr,hp->h_length);
>	sa.sin_family = hp->h_addrtype;
>
>	if ((s = socket(hp->h_addrtype,SOCK_STREAM,0)) < 0) {
>		perror("socket");
>		exit(1);
>	}
>
>	if (bind(s,&sa,sizeof sa) < 0) {
>		perror("bind");
>		exit(1);
>	}
	...
>}

A public thanks to Stuart Levy at the University of Minnesota, who pointed out
the problem:  a struct sockaddr_in has a char sin_zero[8] member which is
supposed to be zeroed; but if a struct sockaddr_in variable is declared auto,
this member is, of course, not guaranteed to be zeroed.  Either declaring sa to
be static or bzero()ing it fixes the problem.  As an experienced C programmer,
I feel kind of sheepish about not catching this sooner, though I could possibly
be excused in that I was not yet familiar with the structures involved....
-- 
* Daniel R. Levy *  uunet!tellab5!mtcchi!levy *                             |
* These views are live; they are not Memorex' *                           --+--
Praise the Lord, Praise the Lord, let the earth hear His voice;             |
Praise the Lord, Praise the Lord, let the people rejoice.  [F. Crosby]      |
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 19:14:03 GMT
From:      sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!quotron.com!todd@ucsd.edu  (Todd_Booth)
To:        tcp-ip@nic.ddn.mil
Subject:   What is kernel parm for KEEP_ALIVE timeout?
I'm trying to change the default time that a keep_alive packet is sent
from rlogind under Interactive unix and can't find out how.  I believe
it's a kernel parm.  I have looked in AIX, BSD, Interactive manuals
without luck.  Any suggestions before I look through bsd source?

-- 
todd (booth) 

todd@quotron.com 213 302-4368
..!uunet!quotron.com!todd
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Dec 90 19:44:17 GMT
From:      car@trux.UUCP (Chris Rende)
To:        comp.sys.pyramid,comp.protocols.tcp-ip
Subject:   Trouble with telnetd

Nixdorf Targon M35/50 TOS 3.3.03 (Pyramid 9810 OSx 4.4?)

I'm having trouble with telnet'ing into this machine. Here's a sample script:

$ telnet trux
Trying...
Connected to trux.
Operating in line-by-line mode.
Escape character is '^]'.


TARGON /35 (trux)

telnetd: /dev/init: Invalid argument
.
Connection closed by foreign host.

Sometimes the telnetd message doesn't come up.
When another host tries to access this machine it simply echos what is typed.
It does manage to open a pseudo-tty in /dev. When I "echo hello>/dev/ttyp0"
it sends to the screen of the remotly connected screen.
FTP works OK; telnet from trux to a remote host works OK...

I'm using the System V init/getty/login stuff.
$ ls -l /dev/init
crw-rw-rw-   1 root     root      26,  0 Aug 11  1988 /dev/init
$ fgrep telnet /etc/serv*
/etc/servers:telnet	stream	tcp	nowait	root	/usr/etc/in.telnetd	telnetd
/etc/services:telnet		23/tcp

Any ideas?

Thanks,

car.
-- 
Christopher A. Rende           Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3)
uunet!edsews!rphroy!trux!car   Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1
trux!car@uunet.uu.net          Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF
trux!ramecs!car     "I don't ever remember forgetting anything." - Chris Rende

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Sat, 22 Dec 90 09:21 EDT
From:      Bill Wine <BIWINE@vaxsar.vassar.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re:  POP protocol
>I have seen references to Eudora a couple times here. Can anyone tell
>me where to find it? We're looking for something to do what Eudora
>apparently does so I'd like to try it. I was told it was on
>ux1.cso.uiuc.edu but I couldn't find it there. Maybe I wasn't looking
>for the correct file name. Any help will be appreciated.

It's there, under mac/eudora.

Bill
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Sun, 23 Dec 90 03:12:18 -0800
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        tcp-ip@nic.DDN.MIL
Subject:   Has anyone successfully installed the Clarkson async PPP software?
After fighting code that wouldn't compile, missing instructions in the
installation steps, absolutely no documentation whatsoever on how to run it,
and (finally) Segmentation faults when feeding it IP addresses that are
more than 12 digits long (e.g. `128.149.1.97:128.149.1.95' works, but
`128.149.180.1:128.149.180.2' gets a SIGSEGV), I could never getting the damn
thing to work right even when I could get it to run (the ppp0 interface gets
configured, seemingly correctly, but even though on the remote host there
is a host route from the local IP addr fed to `ppp' to the remote, a `ping'
of the local addr yields `Host unreachable' - !!! - and a `ping' of the
remote hosts sees packets going out over the modem, but no response from the
remote end )^: ).

Has *anyone* successfully installed the Brad Clements asynchronous version of
the CMU PPP code between 2 post-4.0 Suns?!?  If so, would you care to share
your wisdom?  I've been banging my head on this for 2 days now ...

--
	- Greg Earle			| "This is Kraft.  It uses a blue box.
	  Sun Microsystems, Inc.	|  This is Stouffer's.  It uses red.
	  JPL on-site Software Support	|  The choice is yours."
	  earle@poseur.JPL.NASA.GOV	| Pretty damn convincing argument, eh?
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 90 15:31:12 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   The end of the DDN NIC as a useful resource?
DDN Information Bulletin #80 contains:

	RFC 1174 recommended eliminating the distinction between "connected"
	and "unconnected" networks, i.e. between those networks connected to
	the DDN and Internet, and those that are not.  Although the NIC had
	made some procedural changes in order to comply with the
	recommendations of RFC 1174, it is now necessary to reinstate the
	previous IP network number registration polices.  This reinstatement
	of the former methods is taken to provide time for a more thorough
	investigation into the impact and cost of such changes.  In order to
	accomplish this reinstatement, the distinction of "connected" and
	"unconnected" networks must be re-established.  The following changes
	are being made to restablish this distinction:
	
	1. Effective immediately, applicants wishing to obtain IP network
	   numbers must use the application dated 7/90 (later applications will
	   be returned to the applicants with a request for further information).
	   This application is online on the NIC.DDN.MIL host as
	   NETINFO:INTERNET-NUMBER-TEMPLATE.TXT.  Applicants wishing connected
	   status for their networks must identify a government sponsor
	   authorizing their connection.
	
	2. Information regarding unconnected networks and Autonomous System
	   Numbers (ASNs) will no longer be available through WHOIS.
	
	3. The NIC will contact people who registered networks or inverse
	   addressing (IN-ADDR) information from the end of September to the
	   present in order to ascertain their status according to the change
	   in policy.  If such networks are unconnected or do not have
	   government sponsors, their data will no longer be available via
	   WHOIS.
	(more)

Unless I've missed something, this will essentially end the usefulness of
the DDN NIC WHOIS as a network information resource, at least for info about a
significant number of the networks attached to the greater internet.

That is, there will no longer be a single authoritative source of
information.  One will have to consult several places to find out what's
going on, or so it seems.

It also seems as though there will be some impact on the ability to do
DNS PTR lookups.  Can this be true?

What other resources will exist to fill this void?
	- Brian
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      22 Dec 90 18:05:53 GMT
From:      bu.edu!bbn.com!mckenzie@uunet.uu.net  (Alex McKenzie)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip and osi
In article <277148E1.19535@maccs.dcss.mcmaster.ca>
kevinb@maccs.dcss.mcmaster.ca (Kevin Boyes) writes:

                                    ... since TCP/IP
	 network services are closely related to OSI
	 networks (TCP/IP was derived from OSI as OSI
	           ----------------------------------
	 was evolving in the 70s)."
	 -----------------------

Maybe I've been living under my rock for too long, but I did
not realize this.  The simularities are obvious but TCP/IP being
derived from OSI and not the other way around hadn't occurred to me.

Is this statement accurate?

========================================================================

No, the statement is in no way accurate.  TCP/IP and the movement for
OSI both grew out of the work of IFIP Working Group 6.1 ("Protocols for
Network Interconnection", or something similar) beginning in 1972, so
they are related.  

TCP/IP developed from a paper written by Vint Cerf and Bob Kahn in 1974.
ISO began work on OSI in 1978.  In the early 1980s the US Government
(National Bureau of Standards) mounted a major effort to get ANSI and
ISO to adopt TCP and IP as protocols for the Transport and Network
layers.  The results were TP4 and CLNS.

Alex McKenzie
 
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 90 16:43:03 GMT
From:      barker@wd0gol.WD0GOL.MN.ORG (Bob Barker)
To:        comp.sys.mac.apps,comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Macintosh Appletalk TCP/IP

I've got a bunch of Macintosh machines networked via Appletalk and I'd
like for them to communicate with a 386 machine which is running Interactive
Unix version 2.2.  I'd like to use TCP/IP, with Telnet, FTP, etc. which
I wouldn't imagine would be too bad if the Macs had ethernet cards but
they don't and can't due to lack of slots.

Is there any software for the Mac that would allow Macs on an Appletalk
network to access my Unix machine via TCP/IP (NFS would be a nice bonus!).

Any help would be greatly appreciated!

-Bob
-------------------------------------------------------------------------------
Bob Barker                                 ...!uunet!jhereg!tcnet!wd0gol!barker 
Robert Barker & Associates                                 barker@wd0gol.MN.ORG

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      24 Dec 90 19:50:58 GMT
From:      midway!midway!chas@handies.ucar.edu  (Charles Blair)
To:        tcp-ip@nic.ddn.mil
Subject:   File sharing across TIPs


Can someone point me to a source of information about TIPs? For
example, can file-sharing be implemented over a TIP? (I imagine if it
could, speed would be slow.) The scenario I have in mind is a bunch of
PCs going out over COM1 connected to a TIP that is then connected to
a Sun Sparcstation via Ethernet.

Some people here seem to think that TIPs in an asynchronous
environment are the panacea granting access to all the goodies that a
networked environment has to offer. I have my doubts. I think the
easier way to go is to put Ethernet boards in the PCs and have them do
TCP/IP directly, but maybe I'm wrong.

Please reply to me and I'll summarize to the net if there is
sufficient interest.
--
Bitnet:                 pmrcjdb@uchimvs1
Internet:       cjdb@midway.uchicago.edu
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Tue, 25 Dec 90 11:16:11 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   Where Eudora lives
In response to a note from nddsun1!markm@ucsd.edu -

I was told that Eudora is available from ux1.cso.uiuc.edu in the net/ph
subdirectory.

Note to the original requestor -  I tried mailing directly to you at the
address in your note, but ucsd.edu said it could not find your system.

Richard
rlg@desktalk.com

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      25 Dec 90 06:52:55 GMT
From:      cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!hoffman!akira!tana@tut.cis.ohio-state.edu  (Yoshiyuki Tanaka)
To:        tcp-ip@nic.ddn.mil
Subject:   Network Simulations

Are there any good public domain network simulation applications? An
undergraduate student in my lab is thinking of making some simulations
of our network but isn't sure where to start. Any information is
appreciated.

------------------------------------------------------------------------
 Name:  Yoshiyuki "Yoshi" Tanaka            | Age: 24
 School:Sophia University, Tokyo Japan.     | Sex: Male
 Dept:  Electrical & Electronic Engineering | Workstation: Sparcstation1
 Lab:   Deiters  Laboratory.                | Project: NFS on a DAT
 Email: tana@bob.ee.sophia.ac.jp            | Hobbies:guitars,synth,ski
------------------------------------------------------------------------




--
                                            $B>eCRBg3X(J $BEE5$!&EE;R9)3X2J(J  
$B!I%/%j%9%^%9$O%[%F%k$8$c$J$/$F(J$B652q$G(J...$B!I(J   Robert Deiters $B8&5f<<(J    
                                            $B#M#2(J   $BEDCf4n9T(J            
                                            tana@bob.ee.sophia.ac.jp       
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Dec 90 18:33:35 PST
From:      David Doll <davidd@hitl.vrnet.washington.edu>
To:        cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!hoffman!akira!tana@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Network Simulations
Here at the University of Washington, we've used MIT's network simulator. It
has some short comings but we've and a lot of other people have done some 
workarounds...I just got a copy of CACI (the company that's been on the inside
cover of Comm of ACM for a while) NETsim11. Just got it out of it's tar file
but so far it looks llike it covers everything...Bad thing is it costs $$$. the
MIT sim is on prep.ai.mit.edu I believe...

David Doll
Programmer/Analyst
Human Interface Technology Lab
University of Washington
M/S: FU - 20
Seattle, WA 98195 
(206) 543-5075
davidd@hitl.vrnet.washington.edu
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Wed, 26 Dec 90 15:48:09 GMT
From:      Andrew Hardie <omega!ash@relay.EU.net>
To:        info-unix@brl.mil, tcp-ip@nic.ddn.mil
Subject:   Time servers
I know that there are ways of making UNIX boxes connected to a TCP/IP
network set their clocks from a single point, but does anyone know a way
for DOS boxes to set their time from a UNIX host over TCP/IP. DOS boxes
will be PC/TCP and UNIX box will be SCO UNIX.
Suggestions gratefully received before I attempt a solution myself.
Thanks
Andrew

-- 
Andrew Hardie
London, England
ash@omega.uucp
ukc!cctal!omega!ash
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 90 19:27:02 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sending from Internet (MIT) to UUCP (Ireland)

Note followups are redirected to "comp.mail.misc".

On 18 Dec 90 14:22:13 GMT, lws@comm.wang.com (Lyle Seaman) said:

lws> It's worth noting that the world is still pretty split about how to
lws> handle the % hack, with some sites giving it precedence over ! and
lws> others not.  This is an unfortunate situation.  The only solution
lws> is to avoid mixing % and !  if at all possible.

Oh again. % should *never* be expanded by other than the target machine
of a mail exchange. The rule is that if the local part of an address
contains a %, the rightmost % is turned into a @ and the MTA is
reinvoked. This is perfectly unambiguous.

I would like to point out that on a UUCP based mail system, only !
exists, and BOTH @ and % are meaningless; on an RFC822 based mail
system, only @ exists, and ! and % (before conversion into @) are
meaningless.

Example: a!b!c%d.e.f

    on a UUCP machine: route this to the 'b' site which is a
    neighbour of the 'a' site, and on 'b' deliver mail to
    'c%d.e.f'.  When the mail arrives on 'b', the delivery software
    looks at the delivery name, 'c%d.e.f'. ONLY AT THIS POINT the
    '%' may assume special meaning, if 'b' is an UUCP-to-Internet
    gateway, then the UUCP MTA converts the delivery name 'c%d.e.f'
    to 'c@d.e.f' and resubmits the message to the Internet MTA. If
    'b' is a pure UUCP site, then the message will be delivered to
    local address 'c%d.e.f', e.g.  by appending to mailbox
    '/usr/mail/c%d.e.f'.

    on a RFC822 machine: this is a local address. If the '%' hack
    has been enabled, this is converted to 'a!b!c@d.e.f', the MTA is
    reinvoked, and it will deliver the mail to host 'd.e.f', which
    will deliver the message to local address 'a!b!c', e.g.
    appending to mailbox '/usr/spool/mail/a!b!c'.  If 'd.e.f' is an
    Internet-to-UUCP mail gateway, the Internet MTA will instead
    pass the message with an envelope of 'a!b!c' to the UUCP MTA,
    and it will eventually be delivered to local address 'c' on site
    'b', a neighbour of 'a'.

Example: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk

    on a Janet machine: this is in error. There is no site called
    'nsfnet-relay.ac.uk' on Janet.

    on an Internet machine: the mail is delivered to
    'nsfnet-relay.ac.uk' (a valid but illegal DNS address :->), and
    the Internet MTA there will get the local delivery address of
    'pcg%uk.ac.aber.cs'. Since 'nsfnet-relay.ac.uk' is an
    Internet-to-Janet gateway, and this mail comes from the Internet
    side of the gateway, this is interpreted should be a Janet
    address, substituting the '%' for a '@', getting
    'pcg@uk.ac.aber.cs', which is a valid (and legal) Janet name,
    and the message is delivered to 'pcg' in the 'uk.ac.aber.cs'
    domain.

Example: lws%comm.wang.com@uk.ac.nsfnet-relay

    On a Janet machine: 'uk.ac.nsfnet-relay' is a Janet domain, so
    the mail is delivered there for 'lws%comm.wang.com'. Since it is
    a Janet-to-Internet gateway, '%' is turned to '@' and since the
    message arrived from the Janet side it is presumed to be
    intended for the Internet. 'lws@comm.wang.com' is exmained,
    'comm.wang.com' is a valid (and legal) Internet domain, and the
    mail is forwarded to it for delivery to the 'lws' local
    address.

    On an Internet machine: thsi is in error. There is no site
    called 'uk.ac.nsfnet-relay' in the Internet.

I hope this is very clear -- the precedence of '%' does not matter at
all. The rule is that the rightmost '%' is turned into a '@' only when
considering the local part of an address, and only on machines that are
gateways.

Final example: a roundtrip from Janet to Internet and backwards:

    pcg%uk.ac.aber.cs%nsfnet-relay.ac.uk%comm.wang.com@uk.ac.nsfnet-relay

This should result in a rountrip, because each stage is only authorized
to resolve to '@' the *rigthmost* '%'. Ah if only this were common
practice!


Incidentally, here is a good occasion to repeat my lament for Internet
(and Janet) standards for addressing other naming domains. In the
examples above the gateway was always between two domain. What if the
gateways relays between more than two domains? For example, consider the
following address (remember, it is not a route! none of the examples
above involved routes!) from an UUCP site:

	a!b!c::d%e.f

and 'b' is a gateway between from UUCP to the Internet and DECnet. When
the UUCP MTA of 'b' sees a local delivery address of 'c::d%e', will it
be resubmit the message to the Internet MTA as 'c::d@e.f', for delivery to
local address 'c::d' on host 'e.f', or to the DECnet MTA for delivery to
local address 'd%e.f' on host 'c'?

The ambiguity here is inescapable, as when requesting the services of a
gateway we should have some way to indicate which output MTA to use for
forwarding the message; parsing the syntax of the address is not enough.

For a more common example, consider a gateway from UUCP to Internet or
Janet; the ambiguity here is inescapable, because addresses under both
the Internet DNS and the Janet NRS have exactly the same syntax.

So far ambiguity resolution has been haphazardly been done by UUCP to
Janet or Internet gateways (like ...!mcsun!ukc, a.k.a. uk.ac.ukc, a.k.a.
ukc.ac.uk) by looking at which of the extremities of the domain name
looked like an NRS or DNS top domain; now that 'cs' may validly occur as
a top domain name in the DNS, 'mistery.cs' can be interpreted both as
'the Czech machine mistery' or 'the machine of the computer science
department of the mistery UK company or university or defense
establishment'.

It is possible to informally anchor domain names in the DNs by using '.'
as root indicator, so that 'mistery.cs.' is surely (but really?) a DNS
name, but this is narrow escape. The problem out to be solved, not
fudged.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 90 19:47:08 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Has anyone successfully installed the Clarkson async PPP so
My experience in installing and using Brad Clements Async PPP from
Clarkson was the same.  The 'usage: ...' message was wrong and,
when testing with a DOS KA9Q PPP version, a core dump would result
when executed.  The fact that this code was developed on a Sun
386i might be part of the problem.

I would suggest either using a Sun 386i (aka doorstop) to install
and test the code released through omnigate.clarkson.edu, OR 
create a SunOS (4.0.x/4.1) version using Drew Perkins' BSD4.3
PPP code (lancaster.andrew.cmu.edu).  If someone has gotten this
code to work in a SunOS 4.0.x or 4.1 system, I would also like to
know.  I tried with a Sun 3/60 SunOS 4.1 system.

===============================================================================
Cerafin E. Castillo                       ||      //\\  ||\\  ||
Network Consultant                        ||     //__\\ || \\ ||  Los Altos
Los Altos Networks                        ||    // ---\\||  \\||  Networks
340 Second St. #6                         ||___//      \ |   \ |
Los Altos, CA  94022
(415) 941-8031      UUCP:     {apple,sun,uunet}!portal!cup.portal.com!cec
                INTERNET:     cec@cup.portal.com

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 90 22:35:22 GMT
From:      excelan!murthy@ames.arc.nasa.gov  (M.D. Srinivas Murthy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Can a receiving application change window size?
In article <87439@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>
>btw, I had previously asked how it was possible for bind() to return EADDRINUSE
>once SO_REUSEADDR had been set on a socket.  Unfortunately, nobody has been able
>to provide (what I consider to be) a satisfactory answer.  I'd still really like
>to know...

It is possible for bind() to return EADDRINUSE evenif the SO_REUSEADDR option 
is set for the socket if the address is already bound to another socket which 
is not in connected state. Once the socket is connected you can bind the same 
address to another socket using SO_REUSEADDR option.

murthy
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Dec 90 23:39:41 GMT
From:      mstar!mstar.morningstar.com!bob@uunet.uu.net  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Has anyone successfully installed the Clarkson async PPP so
Starting with 4.3 code from Drew Perkins <ddp@andrew.cmu.edu>, Brad
Clements <bkc@omnigate.clarkson.edu> ported the PPP drivers to a
Sun386i under SunOS 4.0.2 and added STREAMS support.  Karl Fox
<karl@morningstar.com> ported that to a SPARC under SunOS 4.0.3, then
worked with Dave Alden <alden@shape.mps.ohio-state.edu> to fix a few
STREAMS bugs and some other problems you describe under SunOS 4.1.  We
run the results daily over Telebits and generic V.32 and 2400bps
modems, between SPARCs running 4.0.3c and 4.1, with reasonable
satisfaction.

Get omnigate.clarkson.edu:pub/sun/ppp.tar.Z for starters.  I have
placed a copy of Karl's stuff in tut.cis.ohio-state.edu:pub/ppp/*.
That shar file contains not only the SPARC and SunOS4.1 patches, but
also some READMEs and a few scripts that we have found convenient for
managing a few intermittent connections.
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 05:37:26 GMT
From:      shakti!shri@uunet.uu.net  (H.Shrikumar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP spoofing
-----------------------
[For comp.protocols.tcp-ip-ers ...
   There is this thread in Comp.dcom.modems talking about PPP and TCP/IP
spoofing on Telebit modems. I am cross posting this for info ... all
followups directed to comp.dcom.modems.]
-----------------------

In article <BOB.90Dec26112824@volitans.MorningStar.Com> bob@MorningStar.Com 
  (Bob Sutterfield) writes:
>
>Correct.  But I was talking about uucico (the program that typically
>implements UUCP-g and can be considered the protocol layer "above"
>UUCP-g), which knows only about complete files.

  Thanx Bob Sutterfield, for the much needed long post ... hopefully
this will clear all doubting minds on this group.

>An application based on TCP assumes a reliable, sequenced data stream.
>[...] A TCP application assumes that any portion
>of a transmission that has been ACKed has reached its destination, and

[...deleted...]

>If such a guarantee were possible, then your conclusion would be
>correct.  But a modem cannot guarantee packet delivery.  If a modem
>has ACKed a packet to the sender and continues to hold it in its
>on-board memory buffer while it attempts to re-establish a connection,

  This is very correct. You hit the problem on the head.

  However, some spoofing is still possible. When TCP sees the
long turnaround of ACKs via the slow (or delayed) PEP reverse channel,
it may prefer to set rather inappropriate window sizes etc. However, by
spoofing these packets, the two modems can tune their PEP packets to
the IP packet size, the TCP window to the PEP window, which inturn will
depend on line conditions and retransmission rates, and this can be
dynamic. This will be at no extra (transmission) cost since surely
the modems are already doing dynamic PEP adaptation already.

  Of course, this will make the line look error free to TCP, but my
uneducated guess is that would not affect TCP too much. If it would,
then some errors need to be spoofed as well to keep the algorithms in
TCP happy. Would some C.P.TCP-IP-guru correct, if I am wrong ?

  The modem can also spoof VJ Header Compression, so plain vanilla
slip can give good performance over the line. This is another
spoofing possible.

  Thus, while the modem *should* *not* ACK any TCP packets, it
can do other things to increase thruput.

  Howmuch of this does the Netblazer do ?

  Now howabout this ... the modem can also generate IP packets,
and mix them into the stream coming from the telco side into the
local host. These TCP or UDP packets could tell the computer about the
health of the modem, and the local host can reply back and perhaps
change modem settings etc. Each modem will need an IP address too, though.
(This can be done with PPP, 'cos PPP is point to point).

  Sigh! but since as netBelief goes, Telebit does not read this
group anymore ... so would they listen to this idea ?  ( 1/2 :-)

>I'm having trouble imagining at what level of the stack in-modem
>protocol spoofing might be useful for IP or ISO internetworks, above
>the data link layer.  I haven't gotten around to testing synchronous
>PPP over T2500s in PEP SDLC mode - has anyone?  Is its performance
>enough better than asynch PPP over asynch PEP to be worth the trouble?

  These results would be interesting ... has anybody any ?

-- shrikumar ( shri@ncst.in )
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 05:52:36 GMT
From:      zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!turnkey!crystel!ronnie@tut.cis.ohio-state.edu  (Ron Schnell)
To:        tcp-ip@nic.ddn.mil
Subject:   Ultrix/slip

Could someone who is successfully using SLIP on a DECstation over
dialup lines please give me a call?  I would like to discuss
performance and installation problems.

Thanks,

#Ron
(800) 321 - 1767
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 06:22:45 GMT
From:      apctrc!zjat02@uunet.uu.net  (Jon A. Tankersley)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP implementation questions
We're looking at SLIP for connecting remote PC systems with our UNIX boxes
and I've got some questions on implementation:

Setting up the UNIX hosts with sliplogin (from slip4.0) is not a big problem,
but SunOS 4.0.3 doesn't allow it easily from ttytab.  This isn't a big problem
either, but I have a limited number of ports to connect to via slip.  Has
anyone tried to implement sliplogin as part of the cycle on the getty baud
rate cycle?  I was thinking of having sliplogin first, then break for the
different speeds of getty.

On a PC, in this case with an MNP modem (19200/9600/...) running PC/TCP
software, starting up slip, how do I get the modem to dial the proper number?
I also have some special commands and passwords to get through some security
to set up the connection.  Is that possible?  I tried using procomm to
call, then try and connect, but either dropping or not dropping procomm didn't
let slip work.  And none of the PC/TCP utilities work without a connection in
place.  Any ideas?

Is there any way to assign the SLIP IP addresses on the fly for the remote
connections.  We're going to have N PC's and only M connections (M<N) but
not everyone will be calling in at the same time.  I'd rather not have to
have the users know M IP address to try, I'd rather let them establish a
connection and get the IP address of the SLIP login.  Is that possible or
against the protocol?

Is there a better way?  PPP doesn't seem to be fully operational on SunOS
4.0.3 or 4.1* yet, at least not without source license.

Please email and I'll post a summary of the responses.

Thanx
-- 
-tank-
#include <std/disclaimer.h>		/* nobody knows the trouble I .... */
tank@apctrc.trc.amoco.com    ..!uunet!apctrc!tank
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Thu, 27 Dec 90 23:08:28 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        Andrew Hardie <omega!ash@relay.EU.net>
Cc:        info-unix@brl.mil, tcp-ip@nic.ddn.mil
Subject:   Re: Time servers
PC/TCP's SETCLOCK.EXE will query timeservers over the net (something
makes me think the RFC was 768 - a simple UDP query/response).  The
MIT-CMU-Harvard PCIP distribution has the ancestral SETCLOCK.  As far as
I know, both programs require unaesthetic tinkering to deal with all the
world's daylight savings algorithms...

There is a p-d time server for 4bsd Unix, which we distribute on our
PC-800 freeware collection diskette.  I don't know how much effort would
be required to port it to streams, but the original program is only
about 200 lines of C.  

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 18:39:43 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@ucsd.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Problem with NCSA Telnet closing connections

	I'm running NCSA Telnet 2.3 on a Mac-IIcx with system 6.0.5 and
Multifinder, connecting to a Sun-3/50 running SunOS-3.5.2.  The Mac is on
LocalTalk, and is connected to the ethernet segment the Sun is on with a
FastPath-2 running KIP.  If I leave a connection idle for a while (say, an
hour or more, I havn't exactly pinned it down), the connection gets broken.
The window is still there while it is idle, but as soon as I activate the
window by clicking in it, it goes away.  I'm running tcsh 5.9 beta 1 (Ohio
State) 11/10/88 Patch level 0 on the Sun.  It feels like it's doing auto
logout, but I have "unset autologout" in my .cshrc file, so I don't think
that's it.  Anybody have any ideas what might be going on?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 19:31:43 GMT
From:      pa.dec.com!dcrocker.pa.dec.com!dcrocker@decuac.dec.com  (Dave Crocker)
To:        tcp-ip@nic.ddn.mil
Subject:   Network Operations discussion group
At Interop, this Fall, a birds-of-a-feather session about network management
surfaced a general desire for an online forum for discussing the realities
of operating TCP/IP (and other) networks.  Such a forum is pointedly
different from technology-related discussions, such as the ones for SNMP,
which focus on one or more components or tools.

We have established a mailing list at NET-OPS@DECWRL.DEC.COM, to support
this.  To have yourself or a local redistributor added to the list,
please send a note to NET-OPS-REQUEST@DECWRL.DEC.COM.

The list is unmoderated.  It is intended for professional use, among those
in the Internet attempting to operate actual open systems networks, such as 
those using TCP/IP, and those attempting to understand the process of
operating 
such networks.  The inclusion of "commercial content" is assumed to be
inappropriate, unless the group discussion develops a desire to hear about
product features.

Dave
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 20:25:56 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP spoofing
In article <1211@shakti.ncst.ernet.in> shri@ncst.ernet.in (H.Shrikumar) writes:
   However, some spoofing is still possible... by spoofing these
   packets, the two modems can tune their PEP packets to the IP packet
   size, the TCP window to the PEP window, which inturn will depend on
   line conditions and retransmission rates, and this can be dynamic.

It might be useful to allocate a few DAMQAM carriers or the HST
"reverse channel" for use by ACKs and the like, or to fit the MTU to
the characteristics of the line (or vice versa); but I wouldn't call
it spoofing, only accomodation and tuning.  The modem wouldn't know
anything about TCP, only that it's allocating bandwidth to packets of
certain sizes and characteristics.

   Of course, this will make the line look error free to TCP, but my
   uneducated guess is that would not affect TCP too much.  If it
   would, then some errors need to be spoofed as well to keep the
   algorithms in TCP happy.

While TCP can handle line problems admirably, there's certainly no
need to introduce them except perhaps for performance tuning.  No need
to spoof a flat tire by shooting it, just to keep me on my toes while
I'm driving :-)

   The modem can also spoof VJ Header Compression, so plain vanilla
   slip can give good performance over the line.

Hmmm...  I'll have to think about that one a while longer before I'm
convinced.  Something doesn't feel right.

   Thus, while the modem *should* *not* ACK any TCP packets, it can do
   other things to increase thruput.

Right, but that's not spoofing in the same sense that Telebit modems
use the term in their handling of other protocols.  It's just tuning.

   How much of this does the Netblazer do ?

None, except VJ header compression (computed on the PC, not in the
modem) across serial links it manages.  It's a conventional enough IP
router, with no intermediate-system protocol spoofing at all.

   ... the modem can also generate IP packets ... tell the computer
   about the health of the modem, and the local host can reply back
   and perhaps change modem settings etc...

Link quality monitoring is among the purposes of the proposed PPP MIB
for SNMP.  Rather than have the modem generate IP packets, I suppose
the contents of the Trailblazer's S7[02] (for PEP) or S78 (for V.32)
or various other status registers could be acquired via the secondary
DTE channel, and digested for broadcast as a pppLinkQualityEntry.  But
that secondary DTE was turned off in the standalone T2500 v7.00 ROMs,
so slightly more cleverness would be required.
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Dec 90 21:24:12 GMT
From:      shell!redwood!qureshi@tmc.edu  (Fawad Qureshi)
To:        tcp-ip@nic.ddn.mil
Subject:   Conferences/seminars/classes/exhibitions
Any information on coming up conferences/exhibitions/seminars/classes
pertaining to X-Windows, TCP/IP, DOS-UNIX integration, UNIX server access
from PC's, Microsoft's Lan Manager/X, will be greatly appreciated.
Geography is of no consequence. Thanks.
 
-- 

Fawad Qureshi
Shell Oil Company
(713)795-3772       internet: qureshi@shell.com
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 90 01:35:37 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!spectrum.cmc.com!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   AF_X25 - What does it look like ?
I need to implement an X.25 address format version of the socket address
structure. In scanning my header files, I notice an AF_X25 definition;
but I don't think I have a structure definition of the actual layout.

(1) Since an X.25 address is typically at most 14 digits long, it would be
    possible to just have 14 ASCII digits in the structure, with NULLs
    at the end, if the address is shorter.

(2) Since an X.121 address can actually be 15 digits, it might be
    useful to have either a byte or a short with the number of digits,
    and then have the address in packed BCD code.

Can anyone tell me what the INTENDED use of AF_CCITT or AF_X25 is ?
I would hate to invent my own structure that was incompatible with
everyone else's.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Dec 90 10:18:24 GMT
From:      bushell@hawk.nstn.ns.ca (Tom Bushell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP implementation questions
tank@apctrc.trc.amoco.com (Jon A. Tankersley) writes:

>We're looking at SLIP for connecting remote PC systems with our UNIX boxes
>and I've got some questions on implementation:
> .........
>On a PC, in this case with an MNP modem (19200/9600/...) running PC/TCP
>software, starting up slip, how do I get the modem to dial the proper number?
>I also have some special commands and passwords to get through some security
>to set up the connection.  Is that possible?  

We recently had a similar problem when we needed to offer dial up Internet access
for some of our NSTN (Nova Scotia Technology Network) customers.  We were
forced to write some C programs that dialed the phone and handled the logon
sequence to our terminal server.


>I tried using procomm to call, then try and connect, but either dropping or not
>dropping procomm didn't let slip work.  And none of the PC/TCP utilities work
>without a connection in place.  Any ideas?

I'm surprised this didn't work for you.  I've successfully connected with both
NCSA Telnet and Phil Karn's KA9Q software using Procomm.

Also, it turns out that KA9Q has a dialer.  We discovered this by looking at the
source code - nowhere is it mentioned in the documentation.


>Is there any way to assign the SLIP IP addresses on the fly for the remote
>connections.  We're going to have N PC's and only M connections (M<N) but
>not everyone will be calling in at the same time.  I'd rather not have to
>have the users know M IP address to try, I'd rather let them establish a
>connection and get the IP address of the SLIP login.  Is that possible or
>against the protocol?

We handled the dynamic assignment of IP addresses by having our C program
capture the address assigned by the terminal server during the login sequence, and
used an AWK script to modify the configuration files for the applications before
we ran them.  We used Rob Duff's pc AWK, which is available from SIMTEL.


Hope this helps.

-Tom

******************************************************************
*  Tom Bushell                            Software Kinetics Ltd  *
*                                         101 Ilsley Ave         *
*  E-mail - bushell@hawk.nstn.ns.ca       Suite 5                *
*  Phone (902)468-3680                    Dartmouth N.S., Canada *
*  Fax   (902)468-3679                    B3B 1S8                *
******************************************************************
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Fri, 28 Dec 90 14:54:18 +0100
From:      Craig Partridge <craig@sics.se>
To:        tcp-ip@nic.ddn.mil
Subject:   papers on computer networking courses

Hi folks:

    ACM SIGCOMM Computer Communication Review is looking for a couple
of papers which describe graduate or undergraduate courses on computer
networking and distributed systems.  (Note that these papers would be
published in regular issues of CCR, *not* the SIGCOMM Conference Proceedings).

    The goal of this call is to stimulate some thinking in the computer
networking community about how we educate prospective computer scientists
about our field.

    Papers should be no more than 15 pages long, and should include
a description of the scope of the course and its lectures, target audience
(i.e. graduates or undergraduates and pre-requisite courses), and a
recommended reading list.  Preference will be given to papers which
reflect actual experience teaching the course described.

Papers can be sent to the CCR Editor at the address below -- electronic
submissions (PostScript or plain ascii) are preferred.

    SICS
    attn: Craig Partridge
    Box 1263
    S-164 28 Kista
    SWEDEN

    (craig@sics.se)
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 90 19:55:56 GMT
From:      cs!samadams.princeton.edu@princeton.edu  (Tom Reingold)
To:        tcp-ip@nic.ddn.mil
Subject:   replacement for rwhod and ruptime?
I seem to remember mention of it somewhere, but is there a replacement
for rwhod and ruptime?  Having something that more efficiently used
CPU's and networks would be nice.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 90 21:04:54 GMT
From:      usenet.ins.cwru.edu!slc6!lim@tut.cis.ohio-state.edu  (Hock-Koon Lim)
To:        tcp-ip@nic.ddn.mil
Subject:   MacTCP....

  I have came across some problems running MacTCP v1.1.  The Mac is connected
to the campus ethernet with an ethernet Interface.  MacTCP is install for 
application like Stanford Mac/IP V4.0.  The address assignment for the
Mac is provided by a bootp server running CMU`s bootpd.  The MacTCP is
configured to get the address from "server".  When I start the
Mac/IP, the mac send out the  BOOTP Request to the network.  It received
a  BOOTP Reply from the server.  In the reply packet, it get its IP address 
and the Gateway address which is set to the Bootp server address(this work
find if the Mac is on the LocalTalk but not on the ethernet).   I have to 
enter the default gatway address in the MacTCP configuration.

   After the Mac get the BOOTP Reply, it will send out an 

	ICMP C Get address mask packet.

   This packet will cause some problem on the network.  Now all the IP hosts 
on the network will try to reply the Address mask request.  If the Mac is
not in the IP hosts ARP table, they will also send an ARP request packet packet
for this mac.  Every IP hosts will send the ICMP R Address mask = [255.255.0.0]
 to this poor Mac.  

  So my question is why the Mac has to send out the Get address mask packet?
Is they any MacTCP configuration I did wrong to cause this problem?

   The following is the Caputure file from the sniffer which so this problem.

Thanks,

Hock-Koon Lim, Information Network services
Case Western Reserve University; Cleveland, Ohio, USA  44106
(216) 368-2982        lim@ins.cwru.edu

   
-----------------------------------------------------------------

Sniffer Network Analyzer data from 27-Dec-90 at 10:51:42, file C:\CAPTURE\MACTCP.ENC, Page 1


SUMMARY  Delta T     Destination   Source        Summary

    42    3.9915  Broadcast    Mac-Test  BOOTP Request
    43    0.0084  Mac-Test U-B   030A36  BOOTP Reply
    44    0.0012  Broadcast    Mac-Test  ICMP C Get address mask
    45    0.0004  Mac-Test Sun   09FA67  ICMP R Address mask = [255.255.0.0]
    46    0.0004  Mac-Test Sun   02A20E  ICMP R Address mask = [255.255.0.0]
    47    0.0001  Mac-Test Sun   02AB5C  ICMP R Address mask = [255.255.0.0]
    48    0.0004  Mac-Test Sun   02A2AF  ICMP R Address mask = [255.255.0.0]
    49    0.0003  Mac-Test Sun   02A1D9  ICMP R Address mask = [255.255.0.0]
    50    0.0004  Mac-Test U-B   03091E  ICMP R Address mask = [255.255.0.0]
    51    0.0003  Mac-Test U-B   030A2B  ICMP R Address mask = [255.255.0.0]
    52    0.0005  Mac-Test Sun   0A04F0  ICMP R Address mask = [255.255.0.0]
    53    0.0002  Mac-Test Sun   095BBA  ICMP R Address mask = [255.255.0.0]
    54    0.0005  Mac-Test Sun   095BCD  ICMP R Address mask = [255.255.0.0]
    55    0.0002  Mac-Test Sun   02974C  ICMP R Address mask = [255.255.0.0]
    56    0.0005  Mac-Test DEC   1AFD82  ICMP R Address mask = [255.255.0.0]
    57    0.0003  Mac-Test U-B   030AB2  ICMP R Address mask = [255.255.0.0]
    58    0.0006  Mac-Test U-B   0308D6  ICMP R Address mask = [255.255.0.0]
          delete a lot of ICMP reply for Address mask here 
   189    0.0001  Broadcast    DECnet000BA4  ARP C PA=[129.22.8.87] PRO=IP
   204    0.0002  Broadcast    DECnet000BA4  ARP C PA=[129.22.8.87] PRO=IP
   205    0.0001  Broadcast    DECnet000BA4  ARP C PA=[129.22.8.87] PRO=IP
   206    0.0002  DECnet000BA4 Mac-Test  ARP R PA=[129.22.8.87] HA=00001D00DB99 PRO=IP
   207    0.0029  Broadcast    Mac-Test  ARP C PA=[129.22.8.87] PRO=IP
   208    0.0004  Mac-Test Sun   02A0C5  ICMP R Address mask = [255.255.0.0]
   209    0.0011  Mac-Test DECnet000BA4  ICMP R Address mask = [255.255.0.0]
   210    0.0019  Mac-Test DECnet002FA4  ICMP R Address mask = [255.255.0.0]
-- 
Hock-Koon Lim, Information Network services
Case Western Reserve University; Cleveland, Ohio, USA  44106   
(216) 368-2982        lim@ins.cwru.edu
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 90 23:26:00 GMT
From:      dynasys!jessea@rutgers.edu  (Jesse W. Asher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Operations discussion group
In article <1990Dec27.193143.29173@pa.dec.com>, dcrocker@dcrocker.pa.dec.com (Dave Crocker) wrote the following:
>At Interop, this Fall, a birds-of-a-feather session about network management
>surfaced a general desire for an online forum for discussing the realities
>of operating TCP/IP (and other) networks.  Such a forum is pointedly
>different from technology-related discussions, such as the ones for SNMP,
>which focus on one or more components or tools.

I definitely agree and have thought this was needed for some time.  I have
even posted a few articles in news.groups to see if anyone was interested
in creating a newsgroup for this purpose.  I didn't get any responses, but
that really shouldn't be too suprising considering that I didn't cross-post
to this newsgroup.  There is a large difference between discussing the 
inards of the tcp-ip suite and discussing how to set up bind or how slip
should be set up.  These things have been discussed in this group, but I 
don't think they belong here.  They also don't belong in comp.unix.admin
(another group that such subjects get posted to) - at least the non-unix
specific parts don't.  What about creating a newsgroup for this type
of posting instead of a mailing list?

-- 
      Jesse W. Asher                             Phone: (901)382-1609 
               6196-1 Macon Rd., Suite 200, Memphis, TN 38134
                UUCP: {fedeva,chromc,rutgers}!dynasys!jessea
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Dec 90 23:55:00 GMT
From:      asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for network administrators for article
I'm doing a story for Unix World about the new crop of network
management systems, such as SunNet Manager, Silicon Graphics'
NetVisualizer, and similar products from DEC and Synoptics.  I'm
looking for users of these products who can talk to me about how well
these products solve the network management problems you're having.
If you're willing to be interviewed over the phone for this story,
please leave me email at sharon@asylum.sf.ca.us or call me at (415)
664-8845.

Also, I'm looking to compile a list of the "Ten Largest Problems Faced
in Network Management."  Feel free to email or post suggestions.  I
won't quote anybody in this list; I'm just looking for the
suggestions, so feel free to post even if you don't want to be quoted;
I won't use your name.

Thanks!
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 90 00:04:40 GMT
From:      cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!hydra!serifos!syrjanen@tut.cis.ohio-state.edu  (Seppo Syrjanen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA Telnet 2.2 bug in mput mget, etc on PC
In article <2825@mentor.cc.purdue.edu> wilker@gauss.math.purdue.edu.UUCP (Clarence Wilkerson) writes:
>In the commands that require processing a list sent from
>the remote back to the PC, the PC version does not correctly
>detect the end of the list, and after performing the asked

This is a genuine bug. Unfortunately fixing it introduces another (mget
works ONCE, then hangs).  The problem is in lower layers of code (TCP
etc), so I switched to CUTCP, which seems to accept our old configuration
file and works ok.

>Clarence Wilkerson

  Seppo Syrjanen                      Internet : syrjanen@cc.Helsinki.FI
  Computing Centre                    BITNET   : syrjanen@finuha.bitnet
  University of Helsinki              Phone    : +358 0 708 4132
  Finland  "...well, cyborg's gotta do what cyborg's programmed to do..." -ABC
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 90 00:05:20 GMT
From:      usc!wuarchive!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!npd.novell.com!excelan!george@apple.com  (George Powers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Questions on TCP shutdown and RFC-793
> In article <1990Dec10.131116.19393@jarvis.csri.toronto.edu>, thomson@hub.toronto.edu (Brian Thomson) writes:
> > 
> > I think the original question was about the TCP shutdown procedure, not the
> > BSD shutdown() system call, but this answer caught my attention because it
> > seems to contradict everything I thought I knew about the BSD routine.
> > My understanding is as follows:
> > 	shutdown(s, 0)	- flushes data queued for receive, and shrinks
> > 			  my receive window to zero.  Succeeding reads will
> > 			  fail.
> > 	shutdown(s, 1)	- data already queued will be delivered, followed
> > 			  by a FIN.  Succeeding writes will fail.
> > 	shutdown(s, 2)	- equivalent to { shutdown(s, 0); shutdown(s, 1); }
> > ...
> > 
> > And, to top it off, my manual pages (Sun) say nothing about loss of
> > buffered data pending.

Having read the 4.3BSD source and tested SUNOS 4.0, I agree with
Brian.  Shutdown is typically useful when applied to the send
direction.  The application program can then keep reading until it gets
an EOF, meaning that the peer application has seen the EOF which
shutdown caused, and has closed in response.  Therefore the application
which initiated the shutdown can be sure that all data has been
delivered in both directions.  If an application has no other way of
confirming delivery and closes without the shutdown method, it cannot
tell whether enqueued send data is lost after close detaches the socket
from its file descriptor.

--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!novell!george  George Powers
Internet: george@novell.com 
--
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 90 09:17:58 GMT
From:      cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!hoffman!akira!tana@tut.cis.ohio-state.edu  (Yoshiyuki Tanaka)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Simulations
In article <9012270233.AA16819@hitl.vrnet.washington.edu> davidd@HITL.VRNET.WASHINGTON.EDU (David Doll) writes:

 ||
 ||Here at the University of Washington, we've used MIT's network simulator. It
 ||has some short comings but we've and a lot of other people have done some 
 ||workarounds...I just got a copy of CACI (the company that's been on the inside
 ||cover of Comm of ACM for a while) NETsim11. Just got it out of it's tar file
 ||but so far it looks llike it covers everything...Bad thing is it costs $$$. the
 ||MIT sim is on prep.ai.mit.edu I believe...

  Thanks for the followup. But I can't seem to find the network
simulator at that MIT site. Does anyone know the exact name of the
simulator and its availability with ftp?

------------------------------------------------------------------------
 Name:  Yoshiyuki "Yoshi" Tanaka            | Age: 24
 School:Sophia University, Tokyo Japan.     | Sex: Male
 Dept:  Electrical & Electronic Engineering | Workstation: Sparcstation1
 Lab:   Deiters  Laboratory.                | Project: NFS on a DAT
 Email: tana@bob.ee.sophia.ac.jp            | Hobbies:guitars,synth,ski
------------------------------------------------------------------------


--
                                            $B>eCRBg3X(J $BEE5$!&EE;R9)3X2J(J  
$B!I(J$B%/%j%9%^%9$O%[%F%k$8$c$J$/$F652q$G(J...$B!I(J   Robert Deiters $B8&5f<<(J    
                                            $B#M#2(J   $BEDCf4n9T(J            
                                            tana@bob.ee.sophia.ac.jp       
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      29 Dec 90 15:39:14 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Jan Engvald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Time servers
In article <27790c89@omega.UUCP> Andrew Hardie <omega!ash@relay.EU.net> writes:
>I know that there are ways of making UNIX boxes connected to a TCP/IP
>network set their clocks from a single point, but does anyone know a way
>for DOS boxes to set their time from a UNIX host over TCP/IP. DOS boxes
>will be PC/TCP and UNIX box will be SCO UNIX.
>Suggestions gratefully received before I attempt a solution myself.
>Thanks
>Andrew
>
>-- 
>Andrew Hardie
>London, England
>ash@omega.uucp
>ukc!cctal!omega!ash

For MSDOS machines I suggest you try PDCLKSET, available by anonymous
FTP from Pollux.lu.se:/pub/network/pdclkset/pdclk088.zip . It requires
a packet driver, is very small (7 kbyte) and fast (can be included in 
AUTOEXEC.BAT without noticeble delay). It knows a lot about daylight
saving algorithms all over the world, but in the case of UK the
implemented algorithm may not be true every coming year, lacking an
officially defined dls rule.

It requires an UDP/IP Time server, available on most Unix hosts.

                                             
Jan Engvald, Lund University Computing Center
________________________________________________________________________
   Address: Box 783                E-mail: Jan.Engvald@ldc.lu.se
            S-220 07 LUND     Earn/Bitnet: xjeldc@seldc52
            SWEDEN           (Span/Hepnet: Sweden::Gemini::xjeldc)
    Office: Soelvegatan 18         VAXPSI: psi%2403732202020::xjeldc
 Telephone: +46 46 107458          (X.400: C=se; A=TeDe; P=Sunet; O=lu;
   Telefax: +46 46 138225                  OU=ldc; S=Engvald; G=Jan)
     Telex: 33533 LUNIVER S
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Dec 90 08:39:48 EST
From:      hsw@sparta.com (Howard Weiss)
To:        cs!samadams.princeton.edu@princeton.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  replacement for rwhod and ruptime?
You can turn off the rwhod daemon and use the rusers and rup commands
which do effectively the same thing as rwho and ruptime, but on a
demand basis.  They send off a broadcast over the net whenever you ask
for the info and on the down side, unlike rwho or ruptime, you have to
wait for all the hosts on the cable to respond which can take some
amount of time.  Rwho and ruptime provide instantaneous response
because the user and host info has been passed around on a periodic
basis in the background.

Howard Weiss
SPARTA, Inc.
Columbia, Md.



-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Dec 90 14:17:43 PST
From:      David Doll <davidd@hitl.vrnet.washington.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   followup on ftp site for net sim

The ftp site address I have for the MIT network simulator is:

allspice.lcs.mit.edu and go to directory pub/netsim. 

David Doll
Programmer/Analyst
Human Interface Technology Lab
University of Washington
M/S: FU - 20
Seattle, WA 98195 
(206) 543-5075
davidd@hitl.vrnet.washington.edu
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 31 Dec 90 15:34:33 PST
From:      rlg@desktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   A way to tell Lotus what you think of their personal info database
A gentleman at Lotus was kind enough to send me the email address of the 
CEO of Lotus, Mr. Jim Manzi.  I thought I would post it to the net so anyone
who has an opinion about Lotus' plan to sell unconfirmed, anonymously gathered
demographic information about YOU to just about anyone who wants it, can
send their letters where they count.

Here it is...

> From lotus!lotus.com!bthomas@uunet.UU.NET Mon Dec 31 06:47:26 1990
> To: bobf@lotus.com, rlg@desktalk.desktalk.com
> Subject: Internet mail for Jim Manzi
> Cc: bthomas@lotus.com
> 
> 
> Please address your message as follows:
> 
> 	To:  jmanzi@lotus.com
> 
> If you have any problems with lotus.com mail
> please call me at (617)577-8500 ext. 8147
> 
> 

Keep those cards and letters coming folks..

Richard
(rlg@desktalk.com)
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 90 16:25:58 GMT
From:      usenet.ins.cwru.edu!george!rck@tut.cis.ohio-state.edu  (Robert Knauerhase)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/Connect II (Mac) and MultiNet (VMS)
Hello all.

    Has anyone gotten the FTP in TCP/Connect II for the Macintosh to work
with a VAX running VMS and MultiNet TCPIP?  We connect just fine, but
don't get any filenames in the VMS side of the Font/DAmover-style interface.
If we ftp form the VAX back to the Mac, everything works fine.

    I know it worked with Wollongong's TCPIP for VMS, but Wollongong had
other (much more serious) problems so now all the Vaxen are running
Multinet.

    Any information or experiences will be appreciated.

Rob Knauerhase
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Robert C. Knauerhase
   knauer@scivax.lerc.nasa.gov           NASA Lewis Research Center
   knauer@cs.uiuc.edu                    U of Illinois @ Urbana-Champaign
   rck@scl.cwru.edu                      Case Western Reserve University

 "<esc> : q ! <return> emacs <return>" -- all the vi you need to know...
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      31 Dec 90 18:13:37 GMT
From:      kxb@einstein.mpccl.ksu.edu (Karl Buck)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.unix.msdos,comp.sys.ibm.pc.misc
Subject:   NCSA Telnet with PC-NFS and Clarkson pktd.sys

Greetings. I am trying desperately to get NCSA Telnet, PC-NFS to work
with the Clarkson packet drivers in our lab. Everything works great until:

	1. You exit Telnet
	2. You attempt to shell out (Alt-e)
	3. You exit FTP

In each instance the client machine locks up with the Network activity light
staying on constantly. 

After exiting telnet the following error comes up:
"run-time error R6001
 - null pointer assignment"

After some time dos comes back with:
"Not ready reading drive H" etc..

The client pc must then be rebooted.

The hardware/software is: 
	
	Server: Sun Sparc1 (SunOS 4.1)
	Clients: Fifteen 386 pc's with VGA running DOS3.3 and PC-NFS 3.0.1

Our configuration files follow (sorry for the length):

The config.tel file:

keyboard=off
termtype="vt100"
myip=RARP
netmask=255.255.0.0		# subnetting mask

#hardware=packet	# network adapter board (packet driver interface)
hardware=wd800		# network adapter board (Western Digital WD8003EB)
address=d200		# Remember to run the 'SETUP' program
ioaddr=280		#	provided by Western Digital to enable
interrupt=3		#	the board correctly!
tek=no			# enable tektronix graphics
video=vga50		# type of video screen
bios=no				# don't use slow BIOS screen access
ftp=no				# do you want ftp enabled?
rcp=no		 		# do you want rcp enabled?
capfile=h:\tel.cap		# default name for capture file
domain="mpccl.ksu.edu"
arptime=8			# arp timeout in seconds
name = default			# Session name, "default" is a reserved name
host=einstein.mpccl.ksu.edu	# Our host, a Sparc1
hostip=129.130.31.1		# IP address of host
scrollback=400			# number of lines of scrollback per session
color=025070			# color code for specific session
erase=backspace			# use delete code or backspace code for <- key?
vtwrap=yes			# should VT100 be in wrap mode or not?
crmap=4.3BSDCRNUL		# map of the CR key for compatibility
contime=20			# timeout in seconds to try connection
retrans=7			# starting retransmit time out in ticks
mtu=512				# maximum transmit unit in bytes
maxseg=512			# largest segment we can receive
rwin=512			# most bytes we can receive without ACK
name=einstein.mpccl.ksu.edu hostip=129.130.31.1; nameserver=1 
name=hilbert hostip=129.130.30.2; nameserver=2
name=proteon hostip=129.130.1.5; gateway=1


Our config.sys follows:

files=40
buffers=20
DEVICE=A:\NFS\PCNFS.SYS
DEVICE=A:\NFS\SOCKDRV.SYS
device=a:\nfs\pktd.sys                                              
device=a:\ansi.sys
shell=a:\command.com /e:2048 /p
LASTDRIVE=V

Autoexec.bat on a:....

@echo off
echo Setting up PC/NFS environment.  Please Wait.
set path=a:\;a:\nfs
pause
a:\nfs\wd8003e 0x60 0x3 0x280 0xd200
pause
set tz=cst6cdt
SET NFSDRIVE=A
PRT -T10 *
NFSRUN
cls
g:
g:autoexec

Which goes to the NFSDRIVE ...g:...

set NFSDRIVE=g
set COMSPEC=g:\command.com
prompt $p$g
set path=g:\bin\pcnfs;g:\bin\util;g:\bin\start;g:\bin\derive;g:\bin\spacetim;g:\bin\wf77;g:\bin\emtex;h:\
NET PCNFSD einstein
NET YPDOMAIN +mpccl.ksu.edu
NET YPSET einstein
NET ROUTE proteon.ksu.ksu.edu
NET UMASK 007
rdate einstein
NET NAME *
NET USE h: \\einstein\$HOME /sh
NET USE LPT1: \\einstein\hpljet
SET TERM=ansi
SET TEMP=h:\
SET LIB=g:\bin\msf\lib
SET LIBRARY=g:\bin\wf77\watfor;g:\bin\wf77\;g:\bin\wf77\lib\
cls
if exist g:\motd.txt type g:\motd.txt
h:
if exist h:\autoexec.bat h:\autoexec.bat

Thanks in advance for *any* suggestions. (Happy New Year!)
--
 Karl Buck
 Dept. of Mathematics              email: kxb@einstein.mpccl.ksu.edu    
 Kansas, State University
 Manhattan, KS 66502               Phone: (913)532-6750

END OF DOCUMENT