The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for May 1991 (433 messages, 246574 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/05.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 May 91 00:29:32 GMT
From:      cmo@pogo.WV.TEK.COM (Christine Olsen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Protocol Tests

I would like to get some information on public domain or commercially
available test suites and benchmarks for the TCP/IP protocol suite.

Does anyone know where I can get it?

Also, does anyone know of any companies that run TCP/IP conformance
tests on your implementation? 

Thanks for any help,

Christine Olsen

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 02:43:49 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet driver over NDIS

mock@watt.support.Corp.Sun.COM (Joseph Mocker) writes:


.In article <1991Apr26.195757.47576@cc.usu.edu> jrd@cc.usu.edu writes:

.   I'd suggest you try the next iteration of the dis_pkt routine, version
.   1.6, which can be found on my VMS VAX netlab.usu.edu 129.123.1.11 in
.   directory [anonymous.netwatch] as file  dis_pkt.asm (a uuencoded archive).
.   The top of the .asm file shows example config.sys and protocol.ini files.
.	   Joe D.


.I just tried this version of dis_pkt, and I saw something strange happening.
.I have a Ethernet Packet watcher program that I wrote, and when using
.DIS_PKT, I would say the first 14 bytes of the ethernet frame are zeroed out.
.(which would be the source ethernet addr, destination ethernet addr, and
.type fields).  It does display what appears to be valid packet lengths,
.but that is about it. Anyone have an explanation for this?

At least you got a connection with this version, 1.06 (not 1.6).
Running CUTCP on the computer, we got the "remote host or gateway not
responding" error.  Switching back to the older one, 1.01 (or 3), the
program worked properly.

While I have the opportunity, I'd like to thank all the people who offered
me advice on the problems with the computer with the Ungermann-Bass NIUps
card.  We're all thrilled that we don't have to use UB's lame, old Telnet.

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

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 03:45:22 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   An informal survey [slide-locks]


   From: decwrl!uunet.UU.NET!lanai!ron (Ron Holt)
   Date: Tue, 30 Apr 91 12:21:09 MDT
   X-Mailer: ELM [version 2.3 PL0]

   Byte magazine mentioned his email address for reference and so did I in
   my message.  I think most people would realize it would be rather pointless

Byte mentioned an email address off BIX? That's a first! In an article
I co-wrote for them recently, I put my email address in my bio, they
removed it, I put it back in in the proofs, and they took it out
again...they were very closed minded about telling their readers about
how to reach anyone off BIX.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 10:08:07 GMT
From:      VANCE@TGV.COM (Icarus)
To:        comp.protocols.tcp-ip
Subject:   Re: SEND et al in the SMTP mail spec

>#I was wondering, does anybody know what implementations of SMTP
>#support the following commands:
>#	SEND FROM:
>#	SOML FROM:
>#	SAML FROM:
># 
>#I know that MRC's TOPS-20 Mailer does, and the ITS and WAITS mailers
>#do.  Are there any others?
>
>	TGV Inc.s MultiNet TCP/IP for VMS supports these.
>	You can probably get more info from sales@tgv.com...

Well, if you TELNET to the SMTP port of a system running MultiNet and type
HELP, it will indeed list SAML and SOML as valid commands.  They will, however,
only send mail, and not interactive messages.  And, if you try SEND FROM:,
the SMTP server will cheerfully tell you "502 Command not implemented".

A question.  What should an SMTP server that supports the SEND/SAML/SOML do
if RCPT TO: specifies a non-local user?  I just took a (very) quick glance 
through RFC 821 and didn't see anything...

Does anyone see much interest in this functionality being supported? 
Particularly in the SMTP server?

Regards,
-----Stuart

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 11:36:42 GMT
From:      carson@darwin.ntu.edu.au
To:        comp.protocols.tcp-ip
Subject:   Re: Wolongong e-mail address

In article <9104302200.AA21278@ucbvax.Berkeley.EDU>, LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes:
> Does any one has the Wolongong e-mail. I would like to ask someone about TCP/IP
> and NFS products line.
> Thanks in advenace for any help.
> Liane Tarouco

Try Wolfen.cc.uow.edu.au the postmaster there should be able to help.-- 


________________________________________________________________________
 *__ |\  John Carson                   \   Ph:       (089)466207
 -  -  \  Northern Territory University \  Fax:      (089)466454
/       \ PO Box 40146,CASUARINA,NT,0811 \ Inter: Carson@post.ntu.edu.au
\_.--.__/ Australia.  			  \or: Carson@darwin.ntu.edu.au
       v            "Darwin the Paradise of the North"	
________________________________________________________________________

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 12:57:22 GMT
From:      steve@cs.uow.edu.au (Stephen Cliffe)
To:        comp.protocols.tcp-ip
Subject:   Re: Wolongong e-mail address

carson@darwin.ntu.edu.au writes:

>In article <9104302200.AA21278@ucbvax.Berkeley.EDU>, LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes:
>> Does any one has the Wolongong e-mail. I would like to ask someone about TCP/IP
>> and NFS products line.
>> Thanks in advenace for any help.
>> Liane Tarouco
 
>Try Wolfen.cc.uow.edu.au the postmaster there should be able to help.-- 

Umm, I think you have the wrong Wollongong. Liane I think is after the 
Wollongong Group. The machine wolfen.cc.uow.edu.au is Wollongong University.
The two are in no way related (except for a long time ago).

Steve,

Stephen Cliffe,				| Phone:    +61 42 213810
Dept. of Computer Science,		| Fax:      +61 42 213262
University of Wollongong,		| ACSnet:   steve@cs.uow.oz
Wollongong NSW 2500,			| UUCP:     ..!munnari!wolfen.oz!steve
Australia.				| Internet: steve@cs.uow.EDU.AU

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 12:58:24 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   10Base-T hubs

The discussion on 10Base-T and its advantages seems to be a hot topic: so
far I've had about 30 requests for copies of the summary.

-- If you missed it the first time around, I make the offer again. I can
e-mail the summary of opinions I've collected (ca. 70K, in 3 parts);

-- If you did request it, but didn't receive it, please e-mail me again.
There were a few days when our mailer was acting up, so I may have lost
some letters.


-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 13:04:10 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet


    From: bu.edu!icad!goethe!arena@bloom-beacon.mit.edu  (mike arena)
    Subject: Connecting to the Internet
    
    Are there other organizations that provide Internet access in the 
    Boston area?  If so, are the charges comparable to the above?
    
About a year and a half ago I looked into Internet connectivity on
behalf of a former employer.  I checked out Alternet, NEARNet and
PSInet for pricing.  At the time NEARNet was the cheapest.  Since
then, both PSInet and Alternet have established geographical point 
of presence within Boston, so I can imagine that their pricing was
reduced in proportion to their costs.

Other interesting developments in this area:  Alternet, PSInet, along
with CERFnet recently signed an agreement to carry commercial traffic
generated by one anothers customers.  NEARnet also recently followed
suit with a commercial traffic exchange agreement with PSI.  Relavent
players will probably waste no time clarifying the above mud...

but anyway...

PSI:  info@psi.com  or  (703) 620-6651
Alternet:  "home" host is uunet.uu.net, local point of presence is
           at world.std.com  (Software Tool & Die, Brookline).

Hope this helps,

== Gordon Lee                 FTP Software Inc
== voice: (617) 246-0900      26 Princess St
== fax:   (617) 245-7943      Wakefield, MA  01880

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 14:12:14 GMT
From:      jim@crom2.uucp (James P. H. Fuller)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet


in comp.protocols.tcp-ip robert@swanee.ee.uwa.oz.au (Roberto Togneri)
writes:

> Is it possible to transfer files to and from a PC from the unix side?
> We have PC-NFS but this only allows transfers to be made from the PC side.
>
> Can some sort of program be run on the PC that would allow a unix host to
> mount a hard disk on a PC? We have a Magneto-Optical-device on one
> of our PC's which allows up to 1.2 Gb of storage. It would be marvellous
> if this could be accessed from a unix host either for users or even just
> for backups. At the moment it can only be used for archival purposes. 

     This question is of general interest.  If anyone knows a good answer,
PLEASE respond to the newsgroup!

     We're trying to use a CD-ROM reader under Interactive Unix 2.2 without
much success.  ISC doesn't know how to mount ISO-9660 CD-ROMS as Unix file-
systems (though I hear SunOS can mount them as type hsfs, envy envy.)  The
particular CD-ROM drive/card we have uses DMA so it can't be registered in
VP/ix as a DDA device, and though it could conceivably be registered as an
IEM device this requires an "installable emulation module" (ISC-speak for
a device-specific piece of software to integrate the device into VP/ix)
and though such a thing may exist for our (Hitachi/scsi) combo we certainly
don't have one.

     So Unix is out and VP/ix is out.  Our next thought was to run the CD-ROM
off an old DOS box and network it to the Unix machine, which brings us to
Dr. Togneri's question.  Is it possible to have a resource on the dinky little
DOS machine and access it from the Unix end of the network?  There are two
levels of access:

    1) OS-level -- turn the drive on, get a directory of what's on it, copy
       files to the Unix machine's HD.

    2) Application-level -- run the CD-ROM's (DOS-specific) searching/retrieval
       software *on the DOS machine* and get the output over to the Unix side.


Thanks very much for anyone's bright ideas.

------------------------------------- -----------------------------------------
 crom2 Athens GA Public Access Unix  |  i486 AT, 16mb RAM, 600mb online
                                     |  AT&T Unix System V release 3.2
 Molecular Biology                   |  Tbit PEP 19200bps  V.32  V.42/V.42bis
 Population Biology                  |     
 Ecological Modeling                 |  Admin: James P. H. Fuller
 Bionet/Usenet/cnews/nn              |  {jim,root}%crom2@nstar.rn.com
------------------------------------- -----------------------------------------

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 14:53:11 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]


In article <1991Apr30.010639.1288@Eyring.COM> ron@Eyring.COM (Ron Holt) writes:
>In article <1991Apr23.172533.20781@athena.mit.edu> jstahlhu@athena.mit.edu (Julie Kozaczka Stahlhut) writes:
>
>>Who invented those slide latches, anyway?  I'd like to meet this person,
>>maybe shake his or her throat ..... :-(
>


What is a slide latch? The Ethernet cable connects to most all the computers
I have ever seen with a BNC T connector. My particular one sits
at the end of the line so it has a 50 ohm terminator instead of a T.


I know this has little to do with TCP-IP but..........


Doug McDonald

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 16:05:03 GMT
From:      rauscher@romulus.rutgers.edu (Rich Rauscher)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY:  Re: active tcp ports and process id's

Thanks to following people who replied to my message:

>Is there any way to find out what active tcp ports
>are associated with which process id's?  I'm on a Sun 4/110
>running the latest release of SunOS.  

us267388@web.mmc.mmmg.com (Bradley D. Rhoades)
shj@ultra.com (Steve Jay)
smb@ulysses.att.com

The gist of what they said was that Gary Nebbett (grn@stl.stc.co.uk)
had written a program called ofiles which produces exactly the
results I was seeking.  'ofiles` was already installed at Rutgers and
is available at many ftp sites.

Here's a sample output:

15 tubes:/ug/u2/rauscher >ofiles tcp.
user     process command        type    port(s)
root     117     inetd          s       21 23 514 513 512 79 13 37
ingres   275     iigcn          s       1036
root     42      portmap        s       111
root     45      ypbind         s       1029
root     81      rpc.lockd      s       684 689 696 699
root     80      rpc.statd      s       683
rauscher 1626    tcsh           s       514 514 514
rauscher 1592    rsh            s       1015 1014
rauscher 1575    Xsun           s       6000 6000 6000 6000 6000 6000 6000
ingres   331     iigcc          s       18584 1043
rauscher 1657    xterm          s       514
rauscher 1658    telnet         s       1139
rauscher 1596    rsh            s       1019 1018
root     1624    in.rshd        s       1021
rauscher 1594    rsh            s       1017 1016
rauscher 1623    rsh            s       1023 1022
rauscher 1631    twm            s       514 514

Thanks again..
-Rich
-- 
-------------
rauscher@rutgers.edu                RPO 5997 PO 5063, New Brunswick, NJ 08903
rauscher@PISCES                          Shakespeare learns Discrete Math:
{backbone site}!rutgers!rauscher                (2B | not (2B)) <=> TRUE

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 16:38:04 GMT
From:      Craig_Everhart@TRANSARC.COM
To:        comp.protocols.tcp-ip
Subject:   Re: SEND et al in the SMTP mail spec

I'd return an error message with code 551, myself.  RFC 821 lists this as:
	551 User not local; please try <forward-path>
Yes, I know this isn't listed as an explicit possibility under the SEND
command.  One of the few holes in RFC 821.

		Craig

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 17:01:44 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Connecting to the Internet

You may also want to check out Alternet and PSI (Performance Systems
International). We use a link to Alternet in the San Francisco area
and it works well; Barry Shein works with them in Boston. PSI also has
a good reputation. You can reach Alternet at info@uunet.uu.net or
703 876-5050. I don't have the number for PSI, but I imagine you can
try emailing info@psi.com and see if that's a valid email address.

A little while back, Alternet, PSI and CERFnet announced that they
were interconnecting, and Alternet also announced that they were
linking up with NEARnet. That leaves us with a commercial Internet
running parallel to the NSFNET, without the restrictions.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 18:23:30 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   SEND et al in the SMTP mail spec


   Date: Wed,  1 May 1991 03:08:07 -0700 (PDT)
   From: VANCE@tgv.com (Icarus)

   A question.  What should an SMTP server that supports the SEND/SAML/SOML do
   if RCPT TO: specifies a non-local user?

The ITS mailer will forward as requested and use the SEND/SAML/SOML on
the next hop as well.  This was used to support interactive messaging
between Chaos only and IP only hosts.  It will even drop SOML back to
MAIL if the next hop says "Not supported", it will bounce a SEND, I'm
not sure about SAML, probably will MAIL and bounce the SEND half.

            __
  /|  /|  /|  \         Michael A. Patton, Network Manager
 / | / | /_|__/         Laboratory for Computer Science
/  |/  |/  |atton       Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 18:39:19 GMT
From:      pww@bnr.ca (Peter Whittaker)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY:  Re: active tcp ports and process id's

In article <May.1.12.05.00.1991.11274@romulus.rutgers.edu> rauscher@romulus.rutgers.edu (Rich Rauscher) writes:
>The gist of what they said was that Gary Nebbett (grn@stl.stc.co.uk)
>had written a program called ofiles which produces exactly the
>results I was seeking.  'ofiles` was already installed at Rutgers and
>is available at many ftp sites.
>
>Here's a sample output:
>
>15 tubes:/ug/u2/rauscher >ofiles tcp.
>user     process command        type    port(s)
>root     117     inetd          s       21 23 514 513 512 79 13 37
>ingres   275     iigcn          s       1036
etc...

Wow - this would have saved me many headaches sometime ago....   Could
you (or some other benevolent sole  - if there are any fish on USENET)
provide the names of a few of these ftp sites.  I *want* this tool!

--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [       DSA's'R'Us!        ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 19:40:21 GMT
From:      rauscher@remus.rutgers.edu (Rich Rauscher)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY:  Re: active tcp ports and process id's

pww@bnr.ca (Peter Whittaker) writes:
>>root     117     inetd          s       21 23 514 513 512 79 13 37
>>ingres   275     iigcn          s       1036
>etc...
>Wow - this would have saved me many headaches sometime ago....   Could
>you (or some other benevolent sole  - if there are any fish on USENET)
>provide the names of a few of these ftp sites.  I *want* this tool!

Sure thing.
Here's a couple:
 uxc.cso.uiuc.edu 
 warchive.wustl.edu 
 dsrbg2.informatik.tu-muenchen.de

---
Rich
-- 
-------------
rauscher@rutgers.edu                RPO 5997 PO 5063, New Brunswick, NJ 08903
rauscher@PISCES                          Shakespeare learns Discrete Math:
{backbone site}!rutgers!rauscher                (2B | not (2B)) <=> TRUE

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 20:15:03 GMT
From:      phil@brahms.amd.com (Phil Ngai)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey [slide-locks]

jbvb@FTP.COM (James B. Van Bokkelen) writes:
>IEEE/ISO.  They're the current
>owner of the standard, and they seem quite willing to issue addendums long
>after the initial standard came out...

No kidding! Standards? We got lots of em! A new one every year...

--

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 20:47:56 GMT
From:      kdenning@genesis.Naitc.Com (Karl Denninger)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.mail.misc
Subject:   POP Mail Clients for IBM PCs with Source or for B&W TCP/IP

Hello!

I while back I asked if anyone had a POP Mail client for the PC which had
source code.  I got few replies.

I'm still looking... actually, the reason is that I want to run it over
B&W's TCP/IP implementation, and can't do that without someone either
providing source or having built it for that transport.

Again, all pointers appreciated!  I will summarize.

-- 
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning@nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 20:49:17 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Telnet From Xterm To Host Is Dropped By Host Immediately


   Date: 30 Apr 91 18:28:51 GMT
   From: tester@nyu.edu  (L Testerville)

     The cause of the problem I mentioned a while back is apparently due to
   the fact that there are no /dev/ttyp[0-n] entries on the 3B2!  (Yes, its
   now painfully obvious)   Does anyone out there know what the major and
   minor node numbers should be for a 3B2/600 running 3.2.1 and Wollongong
   3.0 TCP/IP?  Better yet, is there some way that I can create these in an
   automated fashion?  I should know enough to RTFM, but in this case TFMs
   are long gone...

I don't remember the major/minor node numbers, but I *do* remember
that 3.0 was incredibly bug-ridden. I'd suggest that you upgrade to
3.0.1, or 3.1, if it's available now.

I faced a significant number of intermittent TCP/IP problems with 3.0,
ranging from the annoying to the destructive.

Bob Stratton           | 
Stratton Systems Design| SMTP: strat@gnu.ai.mit.edu, c_bstratton@hns.com
Alexandria, Virginia   | PSTN: +1 301 428 5500 x3298(W), +1 703 823 6463 (H)
"Personally, I think the DNS administrative interface was designed by the IRS."
							--Mark Beyer

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 22:20:41 GMT
From:      seven@FTP.COM (Benjamin M. Levy)
To:        comp.protocols.tcp-ip
Subject:   Re: SEND et al in the SMTP mail spec


    From: csn!stan!imp@handies.ucar.edu  (Warner Losh)
    Subject: SEND et al in the SMTP mail spec
    To: tcp-ip@nic.ddn.mil
    
    I was wondering, does anybody know what implementations of SMTP
    support the following commands:
            SEND FROM:
            SOML FROM:
            SAML FROM:
    
    I know that MRC's TOPS-20 Mailer does, and the ITS and WAITS mailers
    do.  Are there any others?
    
    Warner
    -- 
    Warner Losh             imp@Solbourne.COM


  FTP Software's SMTP server for MS-DOS supports SEND, SOML, and
SAML.  If someone connects to our SMTP server and uses SEND it will
print the message to the screen as it's received.  If they use SAML
or SOML, the server will print the message to the screen and then
send a copy of the message to the recipients.

   ---Ben Levy            FTP Software Inc.            seven@ftp.com    
-----------------------------------------------------------------------
   Member of the International Ameoba Society: 
                              "United We Stand, Divided We Multiply"

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 23:26:39 GMT
From:      enger@seka.scc.com (Robert M. Enger)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip for WANG VS85 without an Ethernet board


Hello Wang TCP/IP Users:

Some folks here have a Wang 85 with the TCP/IP software package.
They would like to be connected to the network, but don't want
to spend the $10K+ to put an Ethernet adapter onto the VS85.

Instead, they would like to use an outboard device to ROUTE (bridge?)
IP packets between an Ethernet and a 'Wang 928 link'.  They would like
to use a PC as a router/bridge by placing a 'WLOC card' into the PC
along with an Ethernet card, and running some sort of ROUTING/BRIDGING
software on the PC.  

Is this possible?  Will the Wang TCP/IP package successfully function
over the '928 Link/WLOC' connection?  And if so, what type of software
is available for a PC to acomplish the IP packet conveyance 
(Ethernet to '928/WLOC')?  Are there other alternatives?

Thanks in advance,
Robert M. Enger
CONTEL Federal Systems
enger@seka.scc.com  (Internet)

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 May 91 23:48:00 GMT
From:      kellerd@GAR.UNION.EDU ("DIANE KELLER")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP info

Please add me to the mailing list for Q/A's on TCP/IP
				Diane

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 00:29:05 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        comp.protocols.tcp-ip
Subject:   Why a packet size limit of 512 for SOSS?


Hi,
   I just gotten SOSS installed and running on one of our PC's. For
of those of you interested SOSS allows a PC to act as a nfs server.
The executables,etc. can be obtained from soe.sun.clarkson.edu in
/pub/ka9q. However due to the packet limit of 512 bytes writing to
our MOD drive is excruciatingly slow.

Why is there a limit of 512 on the packet size? This seems to come
from the PC/IP stuff. Is there a way of recompiling pcip so that
the maximum packet size is greater than 512 (by changing some defines)?
Or is there a reason for the maximum packet size being 512?
For what its worth I have the sources to soss,rpc and pcip.

If anybody can help I'd appreciate it.
--
Dr. Roberto Togneri                         Phone: +61-9-380-2535
Dept. of Electrical & Electronic Engineering
The University of Western Australia         Fax:   +61-9-380-1065
NEDLANDS WA 6009 Australia                  Email: robert@swanee.ee.uwa.oz.au

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 01:21:59 GMT
From:      andrew@megadata.mega.oz.au (Andrew McRae)
To:        comp.protocols.tcp-ip
Subject:   LAT vs telnet

I read in UnixWorld about various arguments concerning the
pros and cons of LAT as opposed to telnet, with the main
argument for LAT being it is a LOCAL transport protocol designed
to achieve less host load, less network load and overall a
much better protocol for connecting terminals to a host on a local
net. Various analyses have been seen on the net that attempt to
quantify the telnet overhead compared to LAT overhead, and
it seems a valid point is made (that telnet overhead is excessive for
what it does). Telnet of course is a TCP based protocol and so can
be routed through gateways etc. which LAT can't be (though lots
of people talk about bridging LAT).

It strikes me that the fundamental idea of LAT is sound, and it makes
good sense to lower the host overhead for local terminals (especially
when we talk about larger scale commercial sites running data entry etc.).
What people balk at is perhaps not the concept of LAT, but the fact that
it is a proprietary protocol, and while DEC licences LAT to others,
it is still not openly available i.e. lots of strings ($$) attached.

My real question is: If the concept of LAT is good enough, and the
advantages great enough, why doesn't someone define a protocol that
does the same job, but is part of TCP/IP; in other words a local telnet
protocol. I guess the biggest problem (as with some many other protocols)
is that LAT got there first, and no one is going to support any MORE
terminal protocols; but if an RFC was written, and an implementation
done, and the bugs ironed out....

Has anyone attempted to define or build a public domain LAT-style
local terminal protocol? If DEC would loosen up on LAT, that would
solve the problem, but is that likely?

Just wondering...

Andrew McRae (andrew@megadata.mega.oz.au)
Megadata Pty Ltd., North Ryde, Sydney, Australia.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 03:36:32 GMT
From:      ebersman@uunet.UU.NET (Paul Ebersman)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet

In <9105011304.AA08438@ftp.com> gordon@FTP.COM (Gordon Lee) writes:

>Other interesting developments in this area:  Alternet, PSInet, along
>with CERFnet recently signed an agreement to carry commercial traffic
>generated by one anothers customers.  NEARnet also recently followed
>suit with a commercial traffic exchange agreement with PSI.  Relavent
>players will probably waste no time clarifying the above mud...

I hadn't heard about PSI hooking to NEARnet, but we did announce a
direct connection between Alternet and NEARnet. This should be up fairly
shortly.

-- 
                   Paul A. Ebersman @ UUNET Communications
                   uunet!ebersman or ebersman@uunet.uu.net
       The difference between theory and practice in practice is greater
           than the difference between theory and practice in theory.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 05:52:59 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: SEND et al in the SMTP mail spec

I did a hack to sendmail a long time ago to make it support SEND. I believe
the diffs are in the archives of comp.sources.unix on uunet.uu.net.

Greg Satz
cisco

PS. It is in volume5/

smtp_send               SMTP SEND command for Sendmail

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 08:54:18 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

I pick this subject for a question about a strange DNS behavior.
The NIC has introduced our
165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
with no A-records for these servers. "be" is delegated to other servers,
so there's no hint to our servers off the root otherwise.
Name servers often reply that 1.32.165.139.in-addr.arpa, for one, doesn't exist
the first time they are queried, but reply correctly afterwards, until cached
data disappeared (query examples below).
Is a resolver compelled to enter forward resolution to complete a reverse one?
Or are A-record mandatory hints with NS replies and should I ask the NIC?
I hope only this detail causes the problem. My servers seem to reply
correctly indeed.

VM1.ULG.AC.BE 139.165.32.1 (primary)
=============
Question:
  1 1.32.165.139.in-addr.arpa PTR IN
Answer(s):                             (ie. Primary Results of the Query)
  1 1.32.165.139.IN-ADDR.ARPA PTR IN 84900 VM1.ULG.AC.BE
                                                  Elapsed time  0.07 sec.

A query of a non-recursive server shows there are no A-records:

NS.NIC.DDN.MIL 192.67.67.53 (root, non recursive)
==============
Question:
  1 1.32.165.139.IN-ADDR.ARPA PTR IN
Authority:                                (ie. Authoritative Nameservers)
  1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
  2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
                                                  Elapsed time  1.60 sec.

I think the problem occurs when a recursive server is queried.
As shown below, when cached data do not exist, these servers successively
give 3 kind of replies:
1) does not exist
2) answer only
3) answer+authority+additionals
x) idem until cache expiration:

TERP.UMD.EDU 128.8.10.90 (root, recursive)
============
--- Query Name: 1.32.165.139.IN-ADDR.ARPA  Qtype: PTR
    Server 1/1:  128.8.10.90 128.8.10.90
Question:
  1 1.32.165.139.IN-ADDR.ARPA PTR IN
Name Does Not Exist.  RC=3
                                                  Elapsed time  1.16 sec.

Question:
  1 1.32.165.139.IN-ADDR.ARPA PTR IN
Answer(s):                             (ie. Primary Results of the Query)
  1 1.32.165.139.IN-ADDR.ARPA PTR IN 86400 VM1.ULG.AC.BE
                                                  Elapsed time  2.81 sec.

Question:
  1 1.32.165.139.IN-ADDR.ARPA PTR IN
Answer(s):                             (ie. Primary Results of the Query)
  1 1.32.165.139.IN-ADDR.ARPA PTR IN 86385 VM1.ULG.AC.BE
Authority:                                (ie. Authoritative Nameservers)
  1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
  2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
Additional:                                    (ie. A records for others)
  1 VM1.ULG.AC.BE A IN 86366 139.165.32.1
  2 GEORGES.MONTEFIORE.ULG.AC.BE A IN 86366 139.165.16.1
                                                  Elapsed time  1.97 sec.

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 10:27:41 GMT
From:      S.Chuang@CS.UCL.AC.UK (Shaw Chuang)
To:        comp.protocols.tcp-ip
Subject:   Re: 10Base-T hubs



   >The discussion on 10Base-T and its advantages seems to be a hot topic: so
   >far I've had about 30 requests for copies of the summary.
 
   >-- If you missed it the first time around, I make the offer again. I can
   >e-mail the summary of opinions I've collected (ca. 70K, in 3 parts);

Could I have a copy of the summary please ?

Thanks in advance


Shaw

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 12:49:43 GMT
From:      rob@cc.mcgill.ca (Robert Macfarlane)
To:        comp.protocols.nfs,comp.protocols.tcp-ip
Subject:   <None>

Subject: Windows-compatible lifeline mail?
Reply-To: pickles@mpr.ca

** I'm posting this for a friend, so please reply to him at pickles@mpr.ca

Does anyone have knowledge of a Windows 3.0 based mail program that will
run under PC-NFS?  I'm looking for a Windows-replacement for Sun's
Lifeline Mail, without the 32K limit on encoded files.
 
Thanks,
Rob Macfarlane
McGill University

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 13:04:54 GMT
From:      keith@spider.co.uk (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO's TCP/IP:  "out of streams resources"


> > We're running SCO Xenix 2.3.2 with SCO TCP/IP and have been getting
> > error messages "out of streams resources".  These generally come
> > when a series of rcp's are executed in a short time--i.e., a
> > backup via the network.
> >
> > Can anyone suggest a workaround, or a fix that might be available?
> >
>
> Run the "crash" command. 

Unfortunately, there is no "crash" command in SCO *Xenix*. It only exists
in SCO Unix. Instead, there is a command in SCO Xenix Streams/TCP called
/usr/bin/sw, which just (dynamically) outputs the stream block usage.
(I don't recall this being documented anywhere).

Once you can see what it is running out of, you can go down the custom
menus and rebuild the kernel with tweaked-up values.

Keith Mitchell                  (postmaster)

Spider Systems Ltd.             Spider Systems Inc.
Stanwell Street                 12 New England Executive Park
Edinburgh, Scotland             Burlington
Phone: +44 31-554 9424          MA 01803
Fax:   +44 31-554 0649          +1 (617) 270-3510

keith@spider.co.uk              keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith      zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uk

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 13:12:53 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   PPP for 386 unixes.

I posted a request for information on where I could find PPP for a
couple of platforms.   All the responses I got were about PPP for the
SparcStation 1+.  What about PPP for 386 unix boxes?  I'm running Esix
and I'd like to run PPP on these 386s, but I can't seem to find it
anywhere.  Does anyone have any suggestions on where I can ftp or uucp
the PPP code for a 386 based unix?  


-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 14:19:56 GMT
From:      gd@aprm (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey [slide locks]

Text: 

My solution to the slide lock "challenge" involves two methods.  For the
file servers, transceivers, and fanout boxes, which have reasonably
solid slide locks and don't move much, I use cable ties to act as strain
relief.  That is, the connection only has to support about one foot of
cable.  Our PCs all use Intel's PCLINK2 board, and their use of the
slider is *awful*.  The board has threaded holes, and they give you a
clip shaped like a slider and two little screws with silly little
do-hickies that slip over the ends of the clip.  Getting this all put
together is a real test of fine motor coordination.  The first time the
user moves their PC the clip bends and the cable falls out, and it will
never stay put after that.  What I have found works best is to leave the
clip off and crimp the cable's d-shell *slightly*, just enough to ensure
a tight push-in fit.  I also try to use transceiver cable that is much
thinner and more supple than the old "standard" stuff (I think we got it
from Cabletron).  Since doing it this way, trouble calls due to pulled
out cables have gone way down, almost to zero.
 
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                      |
                                        /
 
        Democracy is based upon the conviction
        that there are extraordinary possibilities
        in ordinary people.
                  Harry Emerson Fosdick

 --- End of Message -----------

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 14:56:57 GMT
From:      tcpip@ASTERIX.KPH.UNI-MAINZ.DE (TCP/IP User)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Mailing LIst

Please add me to the TCP/IP Mailing List.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 15:02:32 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip
Subject:   Re: FTP directories

In article <1991Apr29.203050.8621@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>In article <3549@beguine.UUCP>, mpaf1216@med.unc.edu (Matthew Sean Pardo) writes:
>|> Is there a way to FTP a directory or subdirectory
 
>  No.  You can use "mget" to tell it to get multiple files in a directory, but
>there is no way to do recursive retrievals of a directory.

rftp (for "recursive ftp") is an expect script that ftps directories.
It comes with the expect distribution.  (Email "send pub/expect.shar.Z"
to library@cme.nist.gov or anonymous ftp same from durer.cme.nist.gov.)

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 15:38:10 GMT
From:      andchan@niven.cc.umanitoba.ca (Andrew Chan)
To:        comp.protocols.tcp-ip
Subject:   PPP on Sun OS 4.1.1 - yet another question

I tried to avoid sending this but I think I've spent enough time on it.  I
saw someone posted a similar question about 2 weeks ago but never saw any
response.

I HAD got PPP running succesfully on Sun OS 4.1 before, now I am reinstalling
the same package (from tut.cis.ohio-state.edu/patch level 4) on Sun OS 4.1.1.
but keep getting this "ppp: tcsetpgrp()" error when invoking the program
"ppp".

I have also installed patch 100149-03 and am running C2 security on my machine.

Any help will be most grateful.
-- 
Andrew Chan <andchan@ccu.umanitoba.ca> | 3rd year computer engineering student
Unix Group, Computer Services          | Lately learning the application of
University of Manitoba                 | packet radio technology in computer
Winnipeg, Manitoba, Canada             | networking.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 16:11:24 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   re: LAT vs telnet


Andrew McRae (andrew@megadata.mega.oz.au) writes:
[summarized]
1. LAT has less overhead than TCP, and is more efficient for local terminal
  traffic.
2. LAT doesn't work through routers, but so what.
3. LAT is DEC proprietary, and is not really readily available.
4. Why doesn't someone do a lightweight termianl protocol?

In response, all I'd point out is that LAT-like protocols make building
general purpose wide area networks or any size internetwork a problem.
Somewhere, we have to figure out that a user wants a distant site *and* it's
for terminal traffic *and* it has to be handled different from most all the
other site to site traffic.  And when we build mixed protocol sites, we 
can't just route, but have to make allowances for LAT traffic.  So DEC
pushes FDDI bridges (instead of routers).

One can always make things simpler by restricting the areas your solution
covers.  But the real world generally provides you with more than toy
problems.

Cheers,
-------------------------------------------------------------------------------
 Willis F. Marti		Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
 	---Not an official document of Texas A&M---

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 16:18:20 GMT
From:      fin@UNET.UNET.UMN.EDU ("Craig A. Finseth")
To:        comp.protocols.tcp-ip
Subject:   LAT vs telnet


   I read in UnixWorld about various arguments concerning the
   pros and cons of LAT as opposed to telnet, with the main
   argument for LAT being it is a LOCAL transport protocol designed
	...
   It strikes me that the fundamental idea of LAT is sound, and it makes
   good sense to lower the host overhead for local terminals (especially
   when we talk about larger scale commercial sites running data entry etc.).
	...
   My real question is: If the concept of LAT is good enough, and the
   advantages great enough, why doesn't someone define a protocol that
   does the same job, but is part of TCP/IP; in other words a local telnet
   protocol. I guess the biggest problem (as with some many other protocols)
   is that LAT got there first, and no one is going to support any MORE
   terminal protocols; but if an RFC was written, and an implementation
   done, and the bugs ironed out....

Actually, I balk at the concept of LAT.  In the "olden days" (i.e.,
2-4 years ago), a campus would be a (possibly) bridged Ethernet.
These days, it may well be a heavily routed network, incorporationg
Ethernet, token ring, FDDI, and other transmission paths.

For example, there is a department on my campus that is currently
using LAT quite nicely to communicate on a single Ethernet segment.
They were just told that half of their operation would move.  The new
location is 4 router hops away from the old (yes, it is still the same
campus: total distance is about 1/2 mile).  We are trying to help the
user salvage as much equipment as possible for use in the new
environment.

The problem is that LAT are designed assuming that (1) networks are
small (tiny) and (2) host cycles are of major importance.  These days,
networks are very large and host cyles are not terribly important.

In particular, LAT gains most of its benefits only when the local
users are using terminals to local mainframes.  It is of little
benefit when the user has a computer (PC, Mac, etc.), when the user is
using non-terminal protocols (FTP, NFS, etc.), or when the user is
making remote connections ("remote" = "off the floor").

Craig A. Finseth			fin@unet.umn.edu [CAF13]
University Networking Services		+1 612 624 3375 desk
University of Minnesota			+1 612 625 0006 problems
130 Lind Hall, 207 Church St SE		+1 612 626 1002 FAX
Minneapolis MN 55455-0134, U.S.A.

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 16:19:16 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey [slide-locks]

Don't worry about e-cursing Rich Siefert.  He has a thick skin and can e-curse
right back if necessary.  He might even like to get a few messages from people
with an interest in Etherhistory.

	Bob

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 16:49:11 GMT
From:      mra@searchtech.com (Michael Almond)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet

So what areas does NEARNet cover?
-- 
Michael R. Almond (Georgia Tech Alumnus)          mra@srchtec.uucp (registered)
search technology, inc.				            mra@searchtech.com
4725 peachtree corners cir., suite 200		             uupsi!srchtec!mra
norcross, georgia 30092				        (404) 441-1457 (office)

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 17:06:44 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet


    From: ebersman@uunet.uu.net  (Paul Ebersman)
    Subject: Re: Connecting to the Internet
    
    In <9105011304.AA08438@ftp.com> gordon@FTP.COM (Gordon Lee) writes:
    >NEARnet also recently followed
    >suit with a commercial traffic exchange agreement with PSI.  Relavent
    >players will probably waste no time clarifying the above mud...
    
    I hadn't heard about PSI hooking to NEARnet, but we did announce a
    direct connection between Alternet and NEARnet. This should be up fairly
    shortly.
    
Oh wow, major wipeout, mea culpa, faux pas, my foot rests on my tongue...

As I predicted, I stand corrected, my apologies for the misinformation.

== Gordon Lee                 FTP Software Inc
== voice: (617) 246-0900      26 Princess St
== fax:   (617) 245-7943      Wakefield, MA  01880

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 18:07:37 GMT
From:      xcaret@csn.org (Xcaret Research)
To:        comp.protocols.tcp-ip
Subject:   NetFind and its Internet load


Some concerns have been raised in various news groups about the
potential Internet load and legal propriety of NetFind, a white pages
tool sold and distributed by Xcaret Research, Inc.  Xcaret Research
appreciates the concern of individuals and organizations who keep
network resources from being abused, and we would like to make it clear 
that we are also concerned about such abuse.  In fact, the authors of
NetFind were very careful to consider the load imposed by NetFind and 
conducted a six month study to gather information about about the 
usage of NetFind and the load imposed on the Internet. 

In this message we overview NetFind, and then address these concerns.

Given the name of a person on the Internet and a rough description of
where the person works (such as the name of the institution or the
city/state/country in which it is located), NetFind searches for
electronic mailbox information about the person.  NetFind uses a unique
method to actively search the Internet for the person.  It does not
attempt to keep a database of users across the Internet; such a database
would be quite large, difficult to populate completely, and constantly
out of date.  Instead, NetFind uses the natural database of the Internet
itself: it sends multiple parallel requests across the Internet to
machines where it suspects the person may reside.  The whole process is
surprisingly fast, because NetFind sends searches out in parallel.
NetFind can locate over 1.4 million people in 2,500 different sites
around the world, with response time on the order of 5-30 seconds per
search.

The primary concern that arose about NetFind was its potential load on
the Internet.  Clearly, any tool that uses parallel searches to descend
from the top of the Domain tree and search each server would be
unreasonably costly.  NetFind does not do this.  The NetFind search
procedure uses several mechanisms that significantly limit the scope of
searches.  First, the user selects at most 3 domains to search (an
example of one domain being "colorado.edu"), from the list of domains
matching the organization component of the search request.  Next,
NetFind queries the Domain Naming System to locate authoritative name
server hosts for each of these domains.  The idea is that these hosts
are often on central administrative machines, with accounts and/or mail
forwarding information for many users at a site.  Each of these machines
is then queried using the Simple Mail Transfer Protocol, in an attempt
to find mail forwarding information about the specified user.  If such
information is found, the located machines are then probed using the
"finger" protocol, to reveal more detailed information about the person
being sought.  The results from finger searches can sometimes yield
other machines to search as well.  A number of mechanisms are used to
allow searches to proceed when some of the protocols are not supported
on remote hosts.  Ten lightweight threads are used to allow sets of
DNS/SMTP/finger lookup sequences to proceed in parallel, to increase
resilience to host and network failures.  The tool enforces a number of
other restrictions on the cost of searches, such as the total number of
hosts to finger.

NetFind began as a research prototype, designed and implemented by
Michael Schwartz and Panagiotis Tsirigotis at the University of
Colorado.  Before becoming a commercial product, the research prototype
was deployed at approximately 50 institutions world wide, and extensive
measurements were collected over a period of 6 months of use, about the
cost of searches, time distribution of searches, etc.

The average search uses 136 packets.  While this is larger than typical
directory services (like X.500), NetFind has significantly larger scope
and better timeliness properties than these other services, since it
gets information from the sources where people do their daily computing,
rather than from auxiliary databases.  To put the cost into perspective,
it is equivalent to a very short telnet or moderate size FTP session.

We estimate that if NetFind were to be used by one hundred people at
each site on the Internet where NetFind can find people, it would
increase the NSFNET load by approximately 1.4% above its current load of
4 billion packets per month.  In comparison, FTP currently accounts for
23% of the NSFNET packets.  Moreover, the load generated by NetFind
represents the addition of a significant new type of service.  Providing
new services necessarily will increase network load.

A detailed discussion of the research that led to the NetFind product is
available in the paper "Experience with a Semantically Cognizant
Internet White Pages Directory Tool", Journal of Internetworking:
Research and Experience 2, 1 (March, 1991).

As for the legal issue: Some people have expressed concern that NetFind
represents an inappropriate use of the Internet, because it is
commercial software.  This is a misinterpretation of network appropriate
use policy, which simply regulates the type of traffic that traverses
the network (as opposed to the type of software that generates this
traffic).  There are many pieces of commercial software that generate
packets on the Internet, such as Sun's TCP implementation.  As with
these other pieces of software, appropriate use responsibility rests in
the hands of the user.  Just as it would be inappropriate to use FTP to
transfer commercial data across the Internet, it would be inappropriate
to use NetFind for commercial purposes.  Yet, there are many appropriate
uses for FTP, and for NetFind.

If you have further questions about NetFind, please contact:

	Xcaret Research, Inc.
	2060 Broadway, Suite 320
	Boulder, CO  80302
	(800) 736-1285
	netfind@xcaret.com

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 18:30:09 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

In article <1991May2.012159.23962@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>
>Has anyone attempted to define or build a public domain LAT-style
>local terminal protocol? If DEC would loosen up on LAT, that would
>solve the problem, but is that likely?
>
    How about just adding a block or full screen mode option to
    Telnet?   tn3270 is somewhat what I mean, but not quite.

    User input would be edited, parsed, etc. at the entry point,
    then forwarded into the network only when an Enter key is
    pressed...or a Function key.   

    Unfortunately then you would have to teach all the Unix
    programmers how to deal with REAL terminals rather than
    keystrokes.. >:-)

    No real reason why this would be a local terminal only, a
    decent "routable" block mode terminal transport would do a
    lot to reduce LAN/WAN congestion.

    (Yeah, I know, put 3270 datastreams in IP
    packets....blechhh.)

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 18:40:47 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet


    My real question is: If the concept of LAT is good enough, and the
    advantages great enough, why doesn't someone define a protocol that
    does the same job, but is part of TCP/IP; in other words a local telnet
    protocol....

LAT as a protocol is really bare-bones.  It uses the Ethernet FCS as
its only error control, it is absolutely dependent on the network not
re-sequencing packets, it assumes the round-trip-time is bounded at a
rather small high limit, and, like most other DECNet family protocols,
it is tied to Ethernet multicast concepts (which don't map well to 802.5,
for instance).

If you were to do a lightweight remote login protocol as "part of TCP/IP",
you'd necessarily use IP packets, and IP addresses.  NETBIOS over TCP/IP
provides us with a lesson here: even though the NETBIOS namespace is
designed around "broadcast on a single LAN", people wanted the IP version
to go through routers, span the globe on lossy, badly-behaved networks
and generally leap tall buildings in a single bound.  If you want flow
control, end-to-end error detection, protection against resequencing and
packet loss, and adaptive timeouts, you're going to either use TCP for
your "lightweight" protocol or re-invent it.  Not very lightweight, then...

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

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 20:01:47 GMT
From:      hubert@CAC.WASHINGTON.EDU (Steve Hubert)
To:        comp.protocols.tcp-ip
Subject:   re: SUMMARY: Re: active tcp ports and process id's

Has anyone done an ULTRIX4 version of ofiles?

Steve Hubert
Univ. of Washington, Seattle
hubert@cac.washington.edu

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 20:55:02 GMT
From:      cclow@helios.tcs.com (Chin-Chai Low)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement


In article <1991Apr24.140256.23754@jhereg.osa.com>,
andrew@jhereg.osa.com (Andrew C. Esh) writes:
|> Lately I have been reviewing SNMP managers and agents. I have also found
|> the related RFCs. What I have not found is the newsgroup where SNMP and
|> similar net management protocols are discussed. Do we need to create one?
|> -- 
|> Andrew C. Esh			andrew@osa.com
|> Open Systems Architects, Inc.
|> Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
|> (612) 525-0000			Punch down, turn around, plug it in and go ...

I second that.

Chin-Chai Low
Teknekron Communication Systems

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 22:14:17 GMT
From:      hughes@bronze.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

In article <1991May01.141214.2241@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes:
>
>in comp.protocols.tcp-ip robert@swanee.ee.uwa.oz.au (Roberto Togneri)
>writes:
>
>> Is it possible to transfer files to and from a PC from the unix side?
>> We have PC-NFS but this only allows transfers to be made from the PC side.
>>
>> Can some sort of program be run on the PC that would allow a unix host to
>> mount a hard disk on a PC? We have a Magneto-Optical-device on one
>> of our PC's which allows up to 1.2 Gb of storage. It would be marvellous
>> if this could be accessed from a unix host either for users or even just
>> for backups. At the moment it can only be used for archival purposes. 
>
>     This question is of general interest.  If anyone knows a good answer,
>PLEASE respond to the newsgroup!

I don't know the details, but I've seen SOS (which I believe stands
for Stan's Own Server), a DOS NFS server.  I'm pretty sure it's
public domain.

Stan, are you out there?

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||          hughes@indiana.edu          ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      2 May 91 22:37:12 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet

In article <1991May2.164911.17750@searchtech.com> mra@searchtech.com (Michael Almond) writes:
>So what areas does NEARNet cover?

NEARnet is the New England Academic & Research Network, covering most of
New England.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 00:09:01 GMT
From:      jalsop@seachg.uucp (John Alsop)
To:        comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   Telnet Port Numbers - NCSA Telnet

Does anyone know if there is a way to configure NCSA Telnet on a Mac, so
that it will request a telnet connection on a specified port other than the
default?

Thanks,
-- 
John Alsop

Sea Change Corporation
6695 Millcreek Drive, Unit 8
Mississauga, Ontario, Canada L5N 5R8
Tel: 416-542-9484 Fax: 416-542-9479
UUCP: ...!uunet!attcan!seachg!jalsop

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 03:51:28 GMT
From:      john@loverso.leom.ma.us (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

Don't be give in so easily to those harping LAT as the savior for
terminal connectivity.  The "expensive" TCP and TELNET protocols
only exist in old or poor implementations.  In particular, the
usually sited "excessive overhead" of TELNET is nothing more than
the result of user-level character swtiching in the 4BSD UNIX
implemention of telnetd.  Changing this design flaw drops almost
all the overhead of a TELNET connection such that a typical UNIX
host could have 3-4 times as many incoming TELNET connections and
still end up with additional free CPU cycles.  How do I know?  I've
tested it!!! (see below)

A kludge to the telnetd socket/pty character switching problem was
put together back in 1985 or so.  The context diffs (from 4.2BSD)
are readily available and apply to almost any 4BSD-based OS.
Several UNIX vendors actually use the scheme in their product.

The correct way to solve the telnetd problem is to re-architecture
the means in which ptys and network connections mesh to avoid having
a user-space character switch.  One such approach involves having
both STREAMS-based tty and network code.  In this case, a
psuedo-terminal STREAMS module just gets pushed on top of the
STREAMS stack of the network connection.  I know of at least one
UNIX vendor doing so already.  Mike Karels has said that such a
scheme (using bstreams) is in the future for 4BSD.

To see the test results yourself, ftp to xylogics.com and grab
the files "news.article" and "results.ps.Z" from the directory
"annex/unsupported/in-kernel".

John
-- 
John Robert LoVerso <john@loverso.leom.ma.us>
John & Sue's House, Leominster MA
[to reach the corporate puppet: loverso@syn.westford.ccur.com]

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 04:46:20 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10Base-T hubs collection

Wow! the response was (to say the least) overwhelming. I set up a little
script to handle the mailing, but it breaks often, and my carpal tunnel
syndrome has been accelerated by at least a month. Over the past week I've
had about 120 requests for copies!

Two comments:

i) since it does look hot, how about a volunteer who could provide some
disk space for ftp access? I would, but the only Unix box within 10 miles
is not - alas - under my command... A lot of people are interested in
opinions and experiences. If you have something to add in this area
(10Base-T in general, I guess, vendor recommendations, management software,
etc.), please mail it to me, and I'll keep it (and e-mail it on request)
until a suitable ftp site is found.

ii) Mike Tarrani - please phone home! Mail bounced, and I deleted your
request - so I can't play with the address to see what works...

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 07:22:35 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load


I'll believe all of the quantitative measurements about NetFind being
sparing of Internet resources, carefully sending out as few packets as
possible and not doing anything stupid.  Think of it as an expert
system, where the expert modeled is the "expert internet user".
From the description of it, I think that an expert internet user like
myself could do a better job, though perhaps not as quickly, because I
have access to more specialized and better databases than just
DNS/SMTP/finger, and more tricky and unobvious ways of looking.

My major problem with tools like NetFind is that although they address
the "resource discovery" problem for a single user, they don't have
any positive side-effects for the rest of the internet.  Nothing about
NetFind adds to any Internet infrastructure; it doesn't make the
problem any easier for the next person down the line or somewhere
else who has the same problem.  In comparision, the efforts of the
various X.500 projects produce something tangible that the rest of the
network can consume later.  

Systems which consume Internet resources and don't have any positive
benefits for the rest of the network are Evil and Rude, no matter how
small the resources are that they consume.  Things which have been
placed into this category at various times are email-based archive
servers (because of their accidental and heavy loads on transit mail
systems), network management by means of pinging random machines,
"mail throughput testers" which send mail through a congested system
to see how congested the mail system is (!?), and rebroadcasting huge
binaries to usenet newsgroups upon the request of one or two people
who missed it.  A badly implemented NetFind could fall into this
category; there's no sign that it actually does.

In this particular case, however, since the research has been
published, the prospective user of NetFind can look up the algorithms
involved and see just how clever the product is before buying.  Since
most of the ad hoc expert systems for Internet user location haven't
been written down, codified, and studied, this is useful information
which deserves a closer look.   See also
	latour.colorado.edu:/pub/RD.Papers/White.Pages.ps.Z
a preprint of the NetFind paper in the Journal of Internetworking.

If I read the paper the right way, users of NetFind are
expected to monitor usenet news and store a database of hostname /
organization pairs on disk, like the following MH scan would do:
	scan -format '%{Organization} %{From}' 
and keep this around for a while (after trimming out user names).
Modulo a few goofy things you'll see with people putting their own
headers (scan alt.sex.pictures to see that) and bland usenet-internet
gateways (see this newsgroup for that) that information's rather good.  
Keep it for a few months, for the newsgroups you expect to care about,
and your ability to find people should be substantially enhanced.

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	emv@msen.com

"(6) The Plan shall identify how agencies and departments can
collaborate to ... expand efforts to improve, document, and evaluate
unclassified public-domain software developed by federally-funded
researchers and other software, including federally-funded educational
and training software; "
			High-Performance Computing Act of 1991, S. 218

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 08:51:37 GMT
From:      apb@kernel.co.uk (Andy Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet


> Date: 2 May 91 01:21:59 GMT
> From: andrew%megadata%dmssyd.syd.dms.cSIRO.au%metro%munnari.oz.au%uunet.uu.net@ukc.ac.uk (Andrew McRae)
> Organization: Megadata P/L, North Ryde, Sydney, Aust.
> Original-Sender: tcp-ip-relay@mil.ddn.nic
> Original-Sender: tcp-ip-request@uk.ac.nsfnet-relay
> Sender: tcp-ip-request@ulai.uucp
> Resent-Date: Fri, 03 May 91 09:35:03 +0100
> 
> I read in UnixWorld about various arguments concerning the
> pros and cons of LAT as opposed to telnet, with the main
 [ stuff deleted ]
> My real question is: If the concept of LAT is good enough, and the
> advantages great enough, why doesn't someone define a protocol that
> does the same job, but is part of TCP/IP; in other words a local telnet
> protocol. 

[ more stuff deleted ]
 
> Just wondering...
> 
> Andrew McRae (andrew@megadata.mega.oz.au)
> Megadata Pty Ltd., North Ryde, Sydney, Australia.
> 

All very well. I'm not going to embark on a telnet-is-ace-LAT-is-crap type
discussion. All I have to say is that to provide a "local" telnet, without
the overheads of the real thing, makes the Internet Protocol redundant
anyway. The IP layer is there to provide one huge worldwide (!) network,
over which standard(ish) protocols can run without worrying about the
underlying physical network. 

As soon as you try to bypass the IP layer, you start to reduce that
connectivity. Extrapolated to its fullest extent, you'd end up with a Local
Area FTP, Local Area SMTP....... etc. just for "efficiency"'s sake. Then to
talk to the rest of us, you'd have to run the real protocols anyway.
Where's the efficiency in that???


Andy Brown

 Kernel Technology Ltd, |  email: apb@kernel.co.uk 
 Kernel House,          |  janet: apb@uk.co.kernel 
 Killingbeck Drive,     |  uucp: ..!ukc!kernel!apb 
 Leeds,                 |                          
 LS14 6UF,              |  phone: (+44) 532 484844
 West Yorkshire, UK     |  fax:   (+44) 532 404164
(Did I miss something??!?)

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 09:12:30 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Why Fewer Buffers (was Changing TCP port)

On Mon, 11 Feb 91 02:33:35 GMT Rick Jones said:
>>In a different string, it was asked why cisco might suggest using
>>fewer buffers on slower links...
>
>There is probably a more fundamental reason for cisco's statement
>about using fewer buffers on slow-links:
>
>Keeping response time (RTT/SRT/etc) small.
>
>If you give a TCP the space, it will use it in an effort to maximize
>thruput - perhaps not 'consciously' ;-) but by always sending as many
>packets at a time as it can/is 'allowed.' While this is desirable for
>your file transfers, it might very well make the telnet/vt users a
>triffle peeved ;-)
>[...]

I still wonder about cisco's reason.
On one hand, they seem to have gone the TOS-faking way with heuristics for
response time. On the other, I don't think they believe many hosts respond to
source quench and throwing interactive packets on top of a full queue doesn't
help much, does it (but organizing queues by datagram size may help a bit).
The only reason I can think of for a small amount of buffers is avoiding
the duplicate datagrams thrashing plague (hence queue proportional to max
throughput), but a mixed limit seems coarse, per host seems unfair to
multiuser machines and per TCP connection incomplete and badly layered.

Finally, on grounds of what came in must go, I wonder if the most drastically
effective heuristics wouldn't be to detect and drop duplicate queued packets,
with the excuse of unreliability for rare mistakes.

Layers, layers...

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 12:01:45 GMT
From:      frank@escape.radig.de (Frank Segner)
To:        comp.sys.amiga.misc,compsys.amiga.datacom,comp.protocols.tcp-ip
Subject:   Re: Once again... ka9q help for Amiga


i don't know which version you are using, but my ka9q 
(net.amiga -> 120120 Bytes) works well with a
startup-file named net.start (located where you've assigned 'tcpip:').
this file contains:

hostname franky
ip add 100.0.0.3
att asy 100.0.0.1 slip sl0 1024 512 9600
route add 100.0.0.1 sl0
start telnet
start ftp
start smtp



i hope this will work; but using telnet as a terminal is much slower
than a term prog (also the file transfer compared with z-modem)

in my case			100.0.0.3	means: amiga1000 
					100.0.0.1	means: unix host

                                     frank

p.s.:    it's usefull to create in 'tcpip:' :  hosts.net and ftpusers


--
frank segner, homburger Str. 26, 6000 frankfurt/m. 90
frank@escape.vsse.in-berlin.de 
*net working or not working*
-- 
frank segner, homburger Str. 26, W-6000 frankfurt/m. 90
EMAIL: frank@escape.vsse.in-berlin.de 
*network or notwork*

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 12:54:59 GMT
From:      mmorse@Z.NSF.GOV ("Michael H. Morse")
To:        comp.protocols.tcp-ip
Subject:   Escape sequences over Telnet/TCP


   We have a public information system (a bulletin board) that anyone
on the Internet can log on to.  The user interface is full screen
and makes use of cursor control keys, function keys, and keypad
functions such as pageup/pagedn.  It also uses the Escape key to mean
"exit this function."

   Like curses, we use a timer to distinguish between an
escape-sequence and the escape-key.  Dispite dire warnings, we have
found that this works across the Internet for *most* people.  The
reason it works, from my inspection of packets, is that, most of the
time, Telnet/TCP puts the entire escape sequence into a single packet,
so no matter how long it spends traversing the network, our timer
works.

   We have recently run into a system that seem to purposely break the
escape sequence up.  First it sends a packet with just the Escape
character, then it sends a packet with the remainder of the escape
sequence.  Obviously, a lot of the time this doesn't work on our
system, as the timer runs out before the rest of the escape sequence
arrives.  I assume it is doing this on purpose because it *always*
puts an escape in a single packet, but other packets sometimes contain
multiple characters.

   My question is:  How common is this?  Where did this "feature" come
from?  Are more or fewer systems going to behave like this in the
future?  Any information from folks familiar with this area would be
appreciated.  Is the feature implemented in Telnet or in TCP?  I would
think that most Telnet/TCP implementations would want to put closely
typed characters into a single packet to save overhead, and what could
be more closely typed than an escape sequence?

   Thanks in advance.

--Mike

p.s.  Please don't flame me for the choice of using the Escape
key.  I understand the technical limitations, and the fact that
there is probably nothing in the TCP/IP specs that guarantee that the
entire escape sequence should arrive together.

-- 

Michael Morse                           Internet: mmorse@note.nsf.gov
National Science Foundation               BITNET: mmorse@NSF
1800 G St. N.W. Room 401               Telephone: (202) 357-7659
Washington, D.C.  20550                      FAX: (202) 357-7663

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 13:27:12 GMT
From:      keith@spider.co.uk (Keith Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet


In <1991May2.012159.23962@megadata.mega.oz.au>, 
Andrew McRae (andrew@megadata.mega.oz.au) writes:

> My real question is: If the concept of LAT is good enough, and the
> advantages great enough, why doesn't someone define a protocol that
> does the same job, but is part of TCP/IP; in other words a local telnet
> protocol. I guess the biggest problem (as with some many other protocols)

This has always struck me as a good idea. Some time ago there was
dicussion of why rlogin was a "better" protocol than telnet. It
turned out that it is no such thing, it is not the telnet *protocol*
that was lacking, just most *implementations*. I believe the IETF
Telnet WG has addressed most of these issues now, if not all vendors.

Unfortunately, for LAT vs, Telnet, it is rather different. There are
some fundamental differences in the nature of the protocols that
mean LAT functionality cannot just be glued onto Telnet, as implied by
lstowell@pyrnova.pyramid.com (Lon Stowell) in <154113@pyramid.pyramid.com>:

>     How about just adding a block or full screen mode option to
>     Telnet?   tn3270 is somewhat what I mean, but not quite.
> 
>     User input would be edited, parsed, etc. at the entry point,
>     then forwarded into the network only when an Enter key is
>     pressed...or a Function key.

I don't know much about tn3270, but I think I know enough about LAT
to say you have missed the point here. It sounds to me that you are
proposing something like Telnet Line Mode, i.e. buffer the input
from a user up until some trigger character before forwarding it in
a packet, instead of forwarding a single-charater per TCP packet.
This is not really why LAT is more efficient.

What makes LAT more efficient than telnet (over single LANs at least) are:

- It multiplexes all the user sessions between one terminal server
and host into a single virtual circuit, instead of one circuit per
user. This amortises per-packet processing over many users.

- There are fixed time-slots for when packets are forwarded from server
to host. With Telnet these are generally variable.

The other thing about LAT that is nice is the concept of "services"
rather than hosts. You can have multiple services per host, or multiple
hosts per service. In theory you can do this stuff using TCP/IP,
in practice many implementations are not up to. To emulate this
properly over TCP/IP, you would probably need to do what LAT does
and multicast service advertisements. How many vendors ship IP with
Multicast capability ? Other LAT pluses include service access control,
and well-defined remote printing.

Despite these diffculties, I still think something like this is do-able,
and desirable if "we" (the Internet *open* systems people) are to fight
back "them" (the properiatary DECNet, Novell, Appletalk *closed* systems
people). 

The most common argument I hear against open systems is - 
"Yes, but if I buy all my kit from vendor X, it can do feature Y..."
These are valid complaints, and we need to look at why our current
systems can't do Y. LAT is a major case in point here. 

Back to <andrew@megadata.mega.oz.au>:

> protocol. I guess the biggest problem (as with some many other protocols)
> is that LAT got there first, and no one is going to support any MORE
> terminal protocols; but if an RFC was written, and an implementation
> done, and the bugs ironed out....
>
> Has anyone attempted to define or build a public domain LAT-style
> local terminal protocol? If DEC would loosen up on LAT, that would
> solve the problem, but is that likely?

I would have thought this was something our ISO friends should be
looking at. I doubt that DEC are likely to put LAT into the public
domain, when there are so many patents etc attached to it. 

I don't think VTP can do this, and I have not heard of any LAT-like open
standard. The only the other procotol I know remotely like LAT is
Prime's LTS, which although still proprietary, at least runs over
LLC2.

Keith Mitchell                  (postmaster)

Spider Systems Ltd.             Spider Systems Inc.
Stanwell Street                 12 New England Executive Park
Edinburgh, Scotland             Burlington
Phone: +44 31-554 9424          MA 01803
Fax:   +44 31-554 0649          +1 (617) 270-3510

keith@spider.co.uk              keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith      zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uk

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 13:54:07 GMT
From:      jdarcy@seqp4.ORG (Jeff d'Arcy)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

andrew@megadata.mega.oz.au (Andrew McRae):
>My real question is: If the concept of LAT is good enough, and the
>advantages great enough, why doesn't someone define a protocol that
>does the same job, but is part of TCP/IP; in other words a local telnet
>protocol.

This question probably arises from a very common misconception that LAT is part
of DECnet.  In fact, the DECnet equivalent of telnet is CTERM; LAT is a direct
Ethernet client which just happens to coexist with DECnet but can coexist with
TCP/IP just as easily.  In other words, LAT is *already* a sort of local telnet
protocol as much as it can be without changing its architecture in ways that
would negate its advantages (such as by making it run on top of IP or any other
routing protocol).
-- 

Jeff d'Arcy, Generic MTS, Sequoia Systems Inc. <jdarcy%seqp4@m2c.org>
         Time flies like an arrow; fruit flies like a banana

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 13:57:11 GMT
From:      bob@MORNINGSTAR.COM (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   PPP on Sun OS 4.1.1 - yet another question


   From: andchan@niven.cc.umanitoba.ca (Andrew Chan)
   Date: Thu, 2 May 91 15:38:10 GMT

   I HAD got PPP running succesfully on Sun OS 4.1 before, now I am
   reinstalling the same package (from tut.cis.ohio-state.edu/patch
   level 4) on Sun OS 4.1.1.  but keep getting this "ppp: tcsetpgrp()"
   error when invoking the program "ppp".

That's the major outstanding bug that nobody's had time to fix yet.
The cheap way to get packets flying is to simply gouge the offending
code out of ppp.c, something like:

	# if defined(sun) && defined(SUNOS) && SUNOS >= 41
	    if ((pgrpid = setsid()) < 0)
		pgrpid = getpgrp(0);
	# if FALSE
	    if (tcsetpgrp(fd, pgrpid) < 0) {
	      TIMESTAMP(stderr);
	      perror("ppp: tcsetpgrp()");
	      exit(1);
	    }
	# endif /* FALSE */
	# else
	    if (ioctl(fd, TIOCSPGRP, &pid) < 0) {
	      TIMESTAMP(stderr);
	      perror("ppp: ioctl(TIOCSPGRP)");
	      exit(1);
	    }
	# endif

This means that signals (e.g. SIGHUP) won't properly get passed to the
ppp process, which is inconvenient, but at least the thing will run.

If you're using that PPP code, get in touch with other fellow
travellers by writing to ppp-interest-request@poseur.jpl.nasa.gov.

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 15:34:11 GMT
From:      Ronald_Coleman.DlosLC@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   re-10Base-T hubs

Please send me a copy of 10base-T hubs to Rcole:dloslc:Xerox.
Thank you.
Ron Coleman

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 17:38:00 GMT
From:      MANAGER@JHUIGF.BITNET
To:        comp.protocols.tcp-ip
Subject:   Mac telnet sessions dying on VAX 8530 (VMS 5.3/CMU 6.5)


Greetings, netppl. I'm having a problem with our network. We have a number
of Localtalk networks here connected to our ethernet thru fastpath boxes,
and so the macs on the localtalk can access our VAX 8530 (vms 5.3, CMU-TEK
TCP/IP version 6.5). All of them can connect using NCSA telnet, but after
5 or 10 minutes of connect time, they are killed, logging the following
error into INTERNET.LOG:

12:28:07.87 TCB 0009F808 killed by ICMP Dest Unreachable
12:28:07.97 TCB 0009F808 state change from 4 to 12
12:28:08.07 TCB 0009F808 inactivated, reason=140738746

Mark Shannon from CMU has told me that this is due to the fastpath's somehow
losing the IP number of the calling Mac. Now, what I'd like to know is this:

1) How can we make this not happen? We've tried the fastpath with static
and dynamic addressing, as well as a number of physical connections.

2) What is reason 140738746?

Thanks a whole lot for any help...

Damian Hammontree    DAMIAN@JHUIGF.BITNET        (301) 327-2959
                    MANAGER@JHUIGF.BITNET        (301) 327-2959

John Meehan          MEEHAN@JHUIGF.BITNET        (301) 955-1097

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 18:48:47 GMT
From:      jchen@manticore.Berkeley.EDU (Jason Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking dfor a book on SNMP ????????

"The Simple Book"

C. Jason Chen
jchen@ctt.bellcore.com

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 19:54:28 GMT
From:      asbjorns@uit.no
To:        comp.protocols.tcp-ip
Subject:   tn3270


Is there a public domain/shareware version of tn3270 for Unix System V
available out there somewhere?

Asbjoern Saetran, asbjorns@stud.cs.uit.no

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 20:09:57 GMT
From:      Steve.Ackerman@MSG.UVM.EDU (Steve)
To:        comp.protocols.tcp-ip
Subject:   Which is best: PPP or CSLIP?


Greetings and apologies in advance if this is a FAQ!
	
	I currently have my boss's Sun3/50 (located at his house) tied
into our network via a SUN 4.  They are both running SunOS 4.1 with
SLIP.  He's using the line mainly for rlogining to our various
machines to keep an eye on things when he's at home ;-).  I would like
to see if I can get better interactive performance for him.  A friend
recommended CSLIP for this.  However, I'm wondering if it would be
better to use PPP?  I'm not familiar with the trade-offs between the
two.  Some of my concerns are robustness, performance, and
expandability.  I believe that in the near future (i.e., probably this
summer), other people will want to tie in to the network as well.  If
so, we would like the option of moving PPP/CSLIP from the Sun 4 to a
router.  

	To sum up my ramblings: for interactive response (quick rlogin
response), should I choose PPP or CSLIP?  Which is better for over-all
general performance?

	Thanks!
--
Steve Ackerman                      (steve@uvm.edu || uunet!uvm-gen!steve)
"It makes me angry that in order to get anything published it has to be of
 0 value to the programmer"  --D.E.Knuth

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 20:55:15 GMT
From:      BILLW@MATHOM.CISCO.COM (William Chops Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Escape sequences over Telnet/TCP


       Like curses, we use a timer to distinguish between an
    escape-sequence and the escape-key.  Dispite dire warnings, we have
    found that this works across the Internet for *most* people.  The
    reason it works, from my inspection of packets, is that, most of the
    time, Telnet/TCP puts the entire escape sequence into a single packet,
    so no matter how long it spends traversing the network, our timer
    works.

       We have recently run into a system that seem to purposely break the
    escape sequence up.  First it sends a packet with just the Escape
    character, then it sends a packet with the remainder of the escape
    sequence.  Obviously, a lot of the time this doesn't work on our
    system, as the timer runs out before the rest of the escape sequence
    arrives.  I assume it is doing this on purpose because it *always*
    puts an escape in a single packet, but other packets sometimes contain
    multiple characters.


       My question is:  How common is this?  Where did this "feature" come
    from?  Are more or fewer systems going to behave like this in the
    future?  Any information from folks familiar with this area would be
    appreciated.  Is the feature implemented in Telnet or in TCP?  I would
    think that most Telnet/TCP implementations would want to put closely
    typed characters into a single packet to save overhead, and what could
    be more closely typed than an escape sequence?

I suspect that what you see is an implementation of the "Nagle algorithm"
(RFC896), which is a method of conserving network bandwidth, by logically
setting the data collection time of the transmitting host to the TCP RTT.
What you do essentially, is send any data you have, but don't send any more
until you receive an ACK for the first packet (or have a full datagram to
send).  Nagle algorithms wreck havoc with anything that tries to base
decisions on the timing between characters.

Quite a while ago, cisco proudly implemented this useful sounding
algorithm, and prompt started running into the most obscure problems with
Function keys.  The cisco terminal server always put "all" of the available
data in each TCP packet - hwoever, since they were rather fast, we usually
noticed and sent a packet with the first byte of a function key sequence
before the next character had made its way through the uart.  Then we
waited for the ACK, but since pressing a function key usually does not
recult in any characters coming back until the whole sequence is received,
we hit the delayed ack code, so the ack was held up for an additional 200
mS in the remote host.  Where this got really bad was when using back to
back terminal servers in "milking machine" mode - the algorithm got envoked
in both directions (once on function key, again on the escape sequence to
move the cursor) resulting in total delays from keypress to actual movement
of almost a full second.

The users were not happy.  The Nagle algorithm is now optional on cisco
terminal servers.

The latest Van Jacobson TCP degenerates nicely to the Nagle algorthm for
an idle connection, which might be a sign that this sort of thing will
become more common in the future.  I don't know if the average unix system's
response to a keypress is fast enough for it to matter most of the time,
but such things tend to keep getting faster...

Bill Westfield
cisco Systems.
-------

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:08:37 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Why Fewer Buffers (was Changing TCP port)


    >If you give a TCP the space, it will use it in an effort to maximize
    >thruput - perhaps not 'consciously' ;-) but by always sending as many
    >packets at a time as it can/is 'allowed.' While this is desirable for
    >your file transfers, it might very well make the telnet/vt users a
    >triffle peeved ;-)

Well, not if it's a good (Van Jacobson Slow start) TCP.  In that case, it
will try to source packets at a continuous bandwidth equal to the bandwidth
of the path, rather than sending out bursts of data at a bandwidth equal
to the local interface.  See Van's paper on congestion avoidance.


    I still wonder about cisco's reason....  On the other, I don't think they
    believe many hosts respond to source quench...

Even hosts that don't listen to source quench have been known to slow down
their transmissions in the face of lost packets.  In fact, it is a matter of
current debate whether sending a source quench has any advantage over merely
dropping the packet (and it has the obvious disadvantage of generating extra
traffic on an already congested path).


    The only reason I can think of for a small amount of buffers is avoiding
    the duplicate datagrams thrashing plague (hence queue proportional to max
    throughput), but a mixed limit seems coarse, per host seems unfair to
    multiuser machines and per TCP connection incomplete and badly layered.

Avoiding duplicate datagram thrashing (DDT?) is THE major reason for using
smaller queues.  This is unfortunately still very prevalent in TCP/IP, even
though the algorithms have been developed to help prevent it.  Many other
protocols are much dumber, and don't even have any facility for slowing
down in the presence of congestion.  If you believe that ANY queue with
an average size of greater than one represents a congested link, the actual
queue sizes on routers don't have to be very big.


    Finally, on grounds of what came in must go, I wonder if the most
    drastically effective heuristics wouldn't be to detect and drop duplicate
    queued packets, with the excuse of unreliability for rare mistakes.

Sure, given infinite CPU resources on the routers, one can do anything...

Bill Westfield
cisco Systems.
-------

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:12:39 GMT
From:      sfb@NCoast.ORG (Stephen F. Bush)
To:        comp.protocols.tcp-ip
Subject:   Application management with SNMP


Can SNMP be used for managing applications as well as
network entities or is application management better
handled by another protocol?

As an SNMP novice, I could see adding MIB types for
application information, and proxy-agents for
applications. 

What I am looking for is something which will monitor/control
applications running anywhere on a network. Relevent information
would be:

(1) who is using which application
(2) which version of an application is being run
(3) ability to control access to the application

Is there a standard for an APPLICATION management protocol (in ASN.1) ?
or am I nuts. Is this already included in any SNMP implementation, or
is it discouraged?

Please let me know if any such protocol exists (IP or otherwise).

				Steve Bush
				GE Information Services
					

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:17:45 GMT
From:      woods@ncar.ucar.edu (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   traceroute and SunOS 4.1.1

A while back I asked this group about third-party traceroute and got very
positive results; we now have it running here and it has proven extremely
useful for debugging network routing problems. The problem now is that
it does not seem to work on SunOS 4.1.1 (we have it working on 4.0.3
and 4.1 systems). Other things using the NIT driver work fine under 4.1.1, 
such as "tcpdump". The message I get is:

traceroute: nit output socket: Protocol not supported

Did I leave out a needed kernel option that would explain "etherfind" and
"tcpdump" working but not "traceroute"? (It doesn't work with the GENERIC
kernel either). Did Sun break the NIT driver in 4.1.1? Does anyone have 
traceroute running on SunOS 4.1.1? We get the same message on both Sun-3 
and Sun-4 architectures under 4.1.1.

AdvTHANKSance,

--Greg

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:17:50 GMT
From:      scottp@se-sd.SanDiego.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   netbios

Excuse me for asking, but where does one go to talk/read about NetBIOS on the
net?
-Scott

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:47:25 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet


    I read in UnixWorld about various arguments concerning the pros
    and cons of LAT as opposed to telnet, with the main argument for
    LAT being it is a LOCAL transport protocol designed to achieve
    less host load, less network load and overall a much better
    protocol for connecting terminals to a host on a local net.

You'll be able to find many people to argue about whether the supposed
advantages of LAT actually exist.  The only thing that is surely true is
that the common LAT host implementation (kernal resident in VMS) is much
more efficient than the common implementation of Telnet (process resident
in unix "telnetd"), which is not at all surprising.  The implementation
details in these cases FAR outweigh the nature of the protocols.  On
the other side of the connection, our experience is that terminal servers
tend to be limited by uart interrupt processing rather than by protocol
processing for either protocol.

Bill Westfield
cisco Systems.
-------

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 21:53:59 GMT
From:      ade@clark.edu (Adrian Miranda)
To:        comp.protocols.tcp-ip,comp.terminals
Subject:   Telnet 3270 for UNIX.

We are in the process of setting a new program whereby students at our
school will access a computer running VM/SP, CMS etc at another
school via the internet.  At present, we use TN3270 on a PC to allow
them to access this other system.  But, to do this, they must be at
school, on one of the PCs with internet access.  We would like to
permit them to also access this remote mainframe by modem.  We thought
perhaps they could login to our UNIX system, then telnet to the remote
machine.  But, when we do this, the remote system seems to be in some
kind of line mode, and no screen oriented commands work.

So, is there some kind of telnet 3270 for the UNIX that we can use?
The only one I've heard of seems to require X-windows, which isn't
really what we had in mind.  Failing that, is there some way we can
convince a mainframe running VM/SP and CMS to allow use of a vt100
instead of 3270?

Adrian Miranda
uunet!clark!ade  or  ade@clark.edu

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 23:38:40 GMT
From:      andy@xwkg.Icom.Com (Andrew H. Marrinson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

jim@crom2.uucp (James P. H. Fuller) writes:


>in comp.protocols.tcp-ip robert@swanee.ee.uwa.oz.au (Roberto Togneri)
>writes:
 
>> Is it possible to transfer files to and from a PC from the unix side?
>> We have PC-NFS but this only allows transfers to be made from the PC side.
 
>     We're trying to use a CD-ROM reader under Interactive Unix 2.2 without
>much success.  ISC doesn't know how to mount ISO-9660 CD-ROMS as Unix file-
>systems (though I hear SunOS can mount them as type hsfs, envy envy.)

Actually, I believe SCO Unix will also allow High Sierra format
CD-ROMS to be mounted as file systems.  It has been a long time since
I tried this, but I think it worked just fine.  Of course, it is
probably too late since you already bought Interactive, but others
might benefit from this info.

As has been mentioned elsewhere, Stan's Own Server, an NFS server for
DOS should also allow this, though I haven't tried it.  The last time
I looked at that it required Sun's PC-NFS development library to
compile, that was also a while ago.  I know it is on uunet.uu.net and
probably other places as well.

Hope this helps...
--
		Andrew H. Marrinson
		Icom Systems, Inc.
		Wheeling, IL, USA
		(andy@icom.icom.com)

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      3 May 91 23:40:06 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Nagle's algorithm (Was: Escape sequences over Telnet/TCP)

>  ...we use a timer to distinguish between an
>escape-sequence and the escape-key.  Dispite dire warnings, we have
>found that this works across the Internet for *most* people.  The
>reason it works, from my inspection of packets, is that, most of the
>time, Telnet/TCP puts the entire escape sequence into a single packet,
>so no matter how long it spends traversing the network, our timer
>works...
>   We have recently run into a system that seem to purposely break the
>escape sequence up...
>   My question is:  How common is this?  Where did this "feature" come
>from?  Are more or fewer systems going to behave like this in the
>future?...

Bad news.  As more and more well behaved TCPs are fielded, you will see
systems exhibiting this behavior become more common.  What you are running
into is a combination of Nagle's algorithm for TCP writes and a telnet which
is sending the escape sequence character by character to the network.
Basically, Nagle's algorithm says 'Don't clog the network the network with
little packets.  If you have data pending acknowledgement (in your case the
ESC) and don't have a MTU-full of data queued (in your case the rest of the
escape sequence) don't send anything.'

So, not only is the telnet breaking the escape sequence into different
packets, the TCP is saying don't send the rest of the sequence until the
ESC is acknowledged.

enjoy,
leo j mclaughlin iii
ljm@ftp.com

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 00:19:59 GMT
From:      em@topgun.ucsb.edu
To:        comp.protocols.tcp-ip
Subject:   Scripted Telnet's?

What's your favorite way to automate a segment of a telnet session?
That is, say you have a tedious, repetitive, and error-prone procedure
(aren't they all? :->) that you have to go through each time you want
to log in to a remote host?  What have you done to automate this?

Machine-specific gizmos like Mac QuickKeys don't count.

I'll summarize given sufficient interest.

Thanks,

-- Ed

 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Ed Mehlschau                                         Internet: em@hub.ucsb.edu
 Center for Computational Sciences                BITNET: em%hub@ucsbuxa.bitnet
  and Engineering (CCSE)              UUCP: ...{ucbvax,sdcsvax,cepu}!ucsbcsl!em
 U. C. Santa Barbara                                      Voice: (805) 893-3221
 3111 Engineering I
 Santa Barbara, CA  93106     Quote: "A clever saying proves nothing", Voltaire

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 02:08:44 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Escape sequences over Telnet/TCP

I may be wrong; however, from your description I would suspect that the system
in question is either a PDP11 or VAX running almost any of the DEC proprietary
operating systems--IAS, RSX, RSTS/E, TSX, VMS, etc.  Standard handling of an
<ESC> by the terminal driver is to terminate the current read when received.
The remainder of the escape sequence will be the inserted as the first bytes in
the next buffer.  If this is the case, the fault lies in the implementation of
the TELNET client software which is not handling escape sequences correctly in
this particular environment.

Merton Campbell Crockett

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 03:02:27 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Re: active tcp ports and process id's

In article <MailManager.673214507.213.hubert@kamba.cac.washington.edu> hubert@CAC.WASHINGTON.EDU (Steve Hubert) writes:

   Has anyone done an ULTRIX4 version of ofiles?

Yes, Jeff Mogul from DEC did one.  Here's his reference from
comp.archives in December of last year.

Archive-name: unix/admin/ofiles/1990-12-04
Archive: gatekeeper.dec.com:pub/DEC/ofiles.tar.Z [16.1.0.2]
Original-posting-by: mogul@bacchus.pa.dec.com (Jeffrey Mogul)
Original-subject: Re: Showing files a process has open.
Reposted-by: emv@ox.com (Edward Vielmetti)

In article <1990Nov10.225213.2706@chinet.chi.il.us> garret@chinet.chi.il.us (Garret Toomey) writes:
>
>We need a way to list the names of files that a process
>has open.  We are running Ultrix 4.0 on Decstations (2100, 
>3100, 5000), and on DECsystems (5400, 58x0).
>
>I know a program "fuser" could do this under SVR3 or so.
>Does an Ultrix version exist ?

....
There is a program called "ofiles", written a bunch of people over
the years, that I have ported to Ultrix 4.0 (MIPS and Vax).  Or,
at least I think my port works.  I haven't tested the "feature"
that allows you to run ofiles on a crash dump; I've only tried
it on a live system.  Anyway, the sources are available on
	gatekeeper.dec.com:pub/DEC/ofiles.tar.Z

-Jeff

--- end of message ---

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	emv@msen.com

"(6) The Plan shall identify how agencies and departments can
collaborate to ... expand efforts to improve, document, and evaluate
unclassified public-domain software developed by federally-funded
researchers and other software, including federally-funded educational
and training software; "
			High-Performance Computing Act of 1991, S. 218

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 03:18:00 GMT
From:      THUMB@TWNAS886.BITNET (CHUN-CHANG LEE)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking dfor a book on SNMP ????????

Hi, John,

You can get RFC's papers.  The SNMP and its relative information are

   RFC1155  ---  SMI
   RFC1156  ---  MIB
   RFC1157  ---  SNMP
   RFC1158  ---  MIB-II


Thumb Lee
Computing Center                        Thumb@Twnas886.bitnet
Academia Sinica                         TEL: 886-2-7826432
Taipei, Taiwan                          FAX: 886-2-7836444
R.O.C.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 03:45:36 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute and SunOS 4.1.1

woods@ncar.ucar.edu (Greg Woods) writes:

>Does anyone have traceroute running on SunOS 4.1.1?

Yes - nothing special to make it work, it just did (hadn't tried it
till a few seconds ago, and just copied the traceroute binary from 4.0.3,
but I doubt that matters).

kernel config that I use (relevant bits) ...

options INET
options TCPDEBUG		# I don't imagine that this is it
pseudo-device   ether
pseudo-device   loop
pseudo-device   snit
pseudo-device   pf
pseudo-device   nbuf
pseudo-device   clone

These bits are basically all the same as a GENERIC kernel has I believe.
This is an SS2.

kre

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 03:52:01 GMT
From:      cs445101@umbc5.umbc.edu (cs445101)
To:        comp.protocols.tcp-ip
Subject:   FTP to a printer

This may not be the right newsgroup to post to, but it's the only one
I can think of.  Does anyone know if there are any products available
like FTP (File Transfer Protocol) but that will transfer a file
directly to a printer instead of to a file?  Any and all help will be
appreciated.

-- 
###############################################################################
#  Mike Reese  #  Mail:  mzr@detrick-hsc.army.mil  #  "Make it so!"           #
#  US Army     #  Phone: (301)663-2081             #       --Jean Luc Picard  #
###############################################################################

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 04:02:42 GMT
From:      david@ccvr1.ncsu.edu (David Joyner)
To:        comp.protocols.tcp-ip
Subject:   Mailing list

Please add me to the mailing list.  Thanks.

--
+===========================================================================+
|                  David Joyner (David_Joyner@ncsu.edu)                     |
|        North Carolina State University Computing Center - Systems         |
 +===========================================================================+

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 04:58:06 GMT
From:      karl@ddsw1.MCS.COM (Karl Denninger)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

In article <1991May01.141214.2241@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes:
>
>in comp.protocols.tcp-ip robert@swanee.ee.uwa.oz.au (Roberto Togneri)
>writes:
>
>> Is it possible to transfer files to and from a PC from the unix side?
>> We have PC-NFS but this only allows transfers to be made from the PC side.
>>
>     This question is of general interest.  If anyone knows a good answer,
>PLEASE respond to the newsgroup!

Yes.  Get SOSS (Son of Sam's Server?) which is a NFS server for MSDOS.  Run
that on the DOS machine.

Then mount the drive using NFS from the Unix system.  Should work just fine.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200]
Anon. arch. (nuucp) 00:00-06:00 C[SD]T, req: /u/public/sources/DIRECTORY/README

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 05:12:33 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: Which is best: PPP or CSLIP?

Steve.Ackerman@MSG.UVM.EDU (Steve) writes:


>	To sum up my ramblings: for interactive response (quick rlogin
>response), should I choose PPP or CSLIP?  Which is better for over-all
>general performance?

CSLIP is an implementation of SLIP that has Van Jacobson's compression
algorithms.  Most PPP implementations do not have VJ header
prediction/compression.  Bottom line is that you are probably better
off performance-wise with CSLIP unless you can find a PPP
implementation with VJ compression.

There have been some recent changes to the PPP spec re VJ compression
so be sure what you get conforms to the latest changes.

-- 
Brian Lloyd, WB6RQN                              Telebit Corporation
Network Systems Architect                        1315 Chesapeake Terrace 
brian@napa.telebit.com                           Sunnyvale, CA 94089-1100
voice (408) 745-3103                             FAX (408) 734-3333

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 07:10:44 GMT
From:      skip@skipsun.UUCP (Skip Gilbrech)
To:        comp.protocols.tcp-ip
Subject:   Re: PPP on Sun OS 4.1.1 - yet another question

>From: Bob Sutterfield <fsg!njin!morningstar.com!bob>
 Date: Fri, 3 May 91 09:57:11 -0400
>
>   From: andchan@niven.cc.umanitoba.ca (Andrew Chan)
>   Date: Thu, 2 May 91 15:38:10 GMT
>
>   I HAD got PPP running succesfully on Sun OS 4.1 before, now I am
>   reinstalling the same package (from tut.cis.ohio-state.edu/patch
>   level 4) on Sun OS 4.1.1.  but keep getting this "ppp: tcsetpgrp()"
>   error when invoking the program "ppp".
>
>That's the major outstanding bug that nobody's had time to fix yet.
>The cheap way to get packets flying is to simply gouge the offending
>code out of ppp.c, something like:
>
>	# if defined(sun) && defined(SUNOS) && SUNOS >= 41
>	    if ((pgrpid = setsid()) < 0)
>		pgrpid = getpgrp(0);
>	# if FALSE
>	    if (tcsetpgrp(fd, pgrpid) < 0) {
>	      TIMESTAMP(stderr);
>	      perror("ppp: tcsetpgrp()");
>	      exit(1);
>	    }
>	# endif /* FALSE */
> ...

I didn't realize that was a major bug.. thought I must have gotten an
old copy of ppp...  It happened that when I was trying to install ppp, I
had just read the section on setsid() in Chapter 7 of the SunOS 4.1
Release Manual (p.52).

>From that it looked like adding a setpgrp(0,0) before the device was opened
should work, and it seems to have done the trick -- I've been using the
code with no problems for several weeks between a 3/50 running 4.1.1 and
a 4/260 w/4.1.

Here's the patch:

*** ppp.c-dist	Wed Jan 16 15:21:30 1991
--- ppp.c	Sat Apr 13 05:06:20 1991
***************
*** 293,298 ****
--- 293,303 ----
  	}
      }
  
+     /* Added Skip Gilbrech - Sat Apr 13 05:04:02 EDT 1991
+      * Without this, the tcsetpgrp() below fails.
+      */
+     (void) setpgrp(0, 0);
+ 
      /*
       * Initialize state.
       */


-Skip

-- 
Skip Gilbrech			email:	skip@fsg.com
Fusion Systems Group			uupsi!fsg!skip
225 Broadway, 35th Floor		uupsi!skipnyc!skip
New York, NY 10007		phones:	212-285-8001 (work)
					201-825-8732 (home)

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 11:26:43 GMT
From:      fargo@iear.arts.rpi.edu (Irwin M. Fargo)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

Son of Stan's Own Server (SOSS) is the latest release of an NFS server for
MS-DOS based IBM PCs and compatibles.

SOSS supports the Clarkson packet drivers, which means that you should be
able to get it running over any kind of network you like (except SneakerNet
(tm)).

I was able to use Sun's PC-NFS package to access exported files from SOSS.
But I wasn't able to execute any programs off of the server.

SOSS is a public domain package.  It's available at a number of sites, one
of which includes sun.soe.clarkson.edu in the pub/ka9q directory.

If you're looking into commercial packages, you might want to take a look at
Novell's Netware NFS.  Basically, you set up your PC as a Netware server and
run Netware NFS on your UNIX host.

Hope some of this helps!

-- 
Thank you and happy hunting!		Actually: Ethan M. Young
					Internet: fargo@iear.arts.rpi.edu
Please press 1 on your touch tone	Bitnet (??): userfp9m@rpitsmts.bitnet
phone to speak to God...		Disclaimer: Who said what?

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 13:00:04 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

In article <7s4gak-@rpi.edu> fargo@iear.arts.rpi.edu (Irwin M. Fargo) writes:

   SOSS is a public domain package.

No it isn't!  It's freely copyable, but copyrighted using the GNU GPL.
Public domain has a perfectly acceptable legal meaning that doesn't
apply to copyrighted software.

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
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.

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      4 May 91 21:34:37 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re:  Escape sequences over Telnet/TCP

In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM>
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
>IAS, RSX, RSTS/E, TSX, VMS, etc.  Standard handling of an
><ESC> by the terminal driver is to terminate the current read when
>received.

I don't recall the other operating systems well enough to comment, but
this IS *NOT* the case under VMS.  The terminal driver "knows" about
VT100 escape sequences so it can do command line editing.  Since these
escape sequences start with ESC, the terminal driver CAN'T abort the
read.  Now if it gets <ESC><ESC>, then it will abort the read with a
bad escape sequence.  (Or maybe this is an RMS level function, it has
been a while....)

Warner
-- 
Warner Losh		imp@Solbourne.COM
God is an Iron

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 May 91 06:00:23 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re:  Escape sequences over Telnet/TCP

Thanks to Glen Overby, the 10Base-T articles are now ftp-able. Here is
Glen's article from comp.dcom.lans:

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

Article 4706 of comp.dcom.lans:
From: overby@plains.NoDak.edu (Glen Overby)
Subject: Re: 10Base-T hubs collection
Summary: ok, here it is...
Organization: Tea & Ching labs

In article <1991May03.044620.12865@rs6000.cmp.ilstu.edu> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes:
>i) since it does look hot, how about a volunteer who could provide some
>disk space for ftp access? I would, but the only Unix box within 10 miles

Ok, time for me to contribute a little bit back to the net.  You can find
this on plains.nodak.edu [134.129.111.64] in

	pub/gpo/10Base-T-hubs

if you don't have ftp access, ask archive-server@plains.nodak.edu.
-- 
		Glen Overby	<overby@plains.nodak.edu>
	uunet!plains!overby (UUCP)  overby@plains (Bitnet)
-----------------------

-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 May 91 15:07:53 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Escape sequences over Telnet/TCP

Warner:

-In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM>
-mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
->IAS, RSX, RSTS/E, TSX, VMS, etc.  Standard handling of an
-><ESC> by the terminal driver is to terminate the current read when
->received.

-I don't recall the other operating systems well enough to comment, but
-this IS *NOT* the case under VMS.  The terminal driver "knows" about
-VT100 escape sequences so it can do command line editing.  Since these
-escape sequences start with ESC, the terminal driver CAN'T abort the
-read.  Now if it gets <ESC><ESC>, then it will abort the read with a
-bad escape sequence.  (Or maybe this is an RMS level function, it has
-been a while....)

Are you confusing observed behaviour with actual behaviour?  Its been a 
number of years since I've looked at the VMS sources and at that time there
was no command line editing; however, it would seem inappropriate to add
command line editing into the terminal port driver (maybe its class--I keep
getting confused as to which deals with the physical interface and which
deals with the logical interface).

I would suspect that there is no logic in the terminal driver that is check-
ing to determine if the I/O request was issued by DCL.  The usage of escape
sequences are application dependent and in this case DCL is the application.
If the terminal driver were interpreting escape sequences, receipt of a cursor
up sequence would reposition the cursor one line up on the display and not
display the previous command line on the current line.

Terminal drivers for all of the above operating systems know about ANSI and
DEC proprietary escape sequences.  Except in the case of <ESC><ESC>, the
read completes with a successful status with the reason that an <ESC> had
been received.  Assuming that the application had been using multi-byte buffers
for its read operations, the status that an <ESC> had been received can be
used to switch to single byte reads until the entire escape sequence has
been read.  The application, at this point, performs whatever operations
are appropriate for the escape sequence--perhaps, display the previous command
line on the current line.

Depending on the mode associated with the read, some of the terminal drivers
will return a secondary status that is an encoded value that is a translation
of the entire escape sequence.  Some modes such as read-pass-all (essentially
equivalent to Unix "raw" mode) ignore escape sequences in their entirety
and only return a completed status when the receive buffer is exhausted.

Having been involved in porting a TELNET client from a Unix environment some
years ago, the interface to the terminal driver was, perhaps, the most
difficult aspect of the port.

Merton Campbell Crockett
GTE Contel Federal Systems

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      5 May 91 15:18:49 GMT
From:      dhansen@amiganet.chi.il.us (Dave Hansen)
To:        comp.protocols.tcp-ip
Subject:   Re: Does FTP Define A C Level Protocol?

>The FTP specification defines only the protocol. In general, Internet
>protocol specifications define the actual protocol, and sometimes list
>requirements of an API for the protocol, but don't actually specify
>the API. Most FTP implementations jumble together the actual protocol
>implementation, the API to FTP (if there's even one) and the interface
>to the OS.
>
>The only specific API for FTP that I know of is for an FTP library
>that I wrote for FTP Software a long time back. It's specified in the
>documentation for FTP (Software)'s dev kit, which includes the
>library. I think you can buy the dev kit manuals separately if you
>want. I know FTP Software considers the API to be non-proprietary.
>		- john romkey			Epilogue Technology
>USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141
For a simple user interface, the demand for API is not there.  Unless you're
host is non-multitasking, the easiest solution is to pipe <stdin and >stdout
to FTP.  The most challenging part of this is to get a password into the
login, as many FTP's break out of stdin for the password prompt.  Depending on
the application, this may not be a big deal, after all, it's what security is
all about.  With my Encore (nee:Gould, nee: SEL) hosts, we developed such a
pipe of FTP commands.  The user gets one prompt, Password:, then the stdin
pipe continues with the transfer list.  Our Amiga workstations connected to
these Encore hosts use the Rexx language to interface an Amiga screen editor
with the ethernet FTP and send the user and password without this
intervention.  You can parse FTP's stdout for errors/success and translate
into a user friendly message.

voice: (708)691-4747             Internet:dhansen@amiganet.chi.il.us

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 May 91 19:55:32 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Packet Driver over ODI sources


	Sources for the PD/ODI converter are now availablefor anonymous
ftp from husc6.harvard.edu in pub/odipkt.

				Dan Lanciani
				ddl@harvard.*

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 May 91 22:25:51 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking dfor a book on SNMP ????????

In article <17180.281d9bc3@ul.ie> bourkej@ul.ie writes:
>Can anyone point me towards a good book or parer on SNMP ?

Marshall Rose's "The Simple Book" published by Prentice Hall.
ISBN: 0-13-812611-9

Good, readable book.

-- 
Phil Trubey                     |  Internet: phil@shl.com      
SHL Systemhouse Inc.            |  UUCP:     ...!uunet!shl!phil
50 O'Connor St., Suite 501      |  Phone:    613-236-6604 x667
Ottawa, Ontario, Canada         |  Fax:      613-236-2043

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 06:42:08 GMT
From:      ronnie@sos.com (Ron Schnell)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   A different SLIP problem


I am running ULTRIX 4.0.  I have been successfully SLIPping for
a few months now, but I wanted to try something new.  Since the
DECstation 3100 cannot function at 19,200 baud, I decided to use
tcpcon and tcpserv in order to connect my modem to an IRIS and
pipe the output to a PTY on the decstation.  Everything works fine,
and I can "tip" to the modem and login places, etc.  However,
when I attempt to run slattach, it tries to attach to "sl7" instead
of "sl0", and, of course, that is not configured into the kernel.

Any idea why the TIOCGETD is returning 7 instead of 0 in the case
of a PTY as opposed to a TTY?

#Ron
(ronnie@sos.com)

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 13:20:41 GMT
From:      palter@cs.Buffalo.EDU (Bill Palter)
To:        comp.protocols.tcp-ip
Subject:   Re: Wolongong e-mail address


In article <9104302200.AA21278@ucbvax.Berkeley.EDU>, LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU writes:
|> Does any one has the Wolongong e-mail. I would like to ask someone about TCP/IP
|> and NFS products line.
|> Thanks in advenace for any help.
|> Liane Tarouco
|> University Federal of Rio Grande do Sul
|> Porto Alegre - RS - Brazil


	You can mail to support@twg.com and your question should be answered,
 if not let me know.


Bill Palter
The Wollongong Group
Palter@twg.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 13:34:39 GMT
From:      bt@sleaze.meteor.wisc.edu (Bill Taylor)
To:        comp.protocols.tcp-ip
Subject:   Novell v3.11 to Unix Internet for MAIL exchange


We have an administrative network of about 90 ps/2's  and PC's
on a token ring network(s). We also have a series of systems with
Ethernet controllers also. There are people like me who can't
get at this mail because we work on Unix work stations. We are about to 
upgrade the Novell network to the v3.11 which allows tcp/ip and the token
ring protocul to co-exist. Given That we set up a formal gateway
between the token-ring networks and Ethernet, How do we get
mail to merge, or even just access for those on Unix.

Ideally the token ring mail would send "Unix Type" mail which
could be delt with by things like "elm".

Oh yeah, we are also real concerned about security probelms
associated with such.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 13:40:35 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Escape sequences over Telnet/TCP


    The users were not happy.  The Nagle algorithm is now optional on cisco
    terminal servers.
    
Our PC/TCP for DOS always uses the Nagle algorithm, so we chose to make our
full-screen Telnet and Rlogin clients pass the whole escape sequence to TCP
in one write.  It may cause trouble when INT 14h redirection is used, though.

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

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 13:54:30 GMT
From:      fjr@ULANA.MITRE.ORG (Frank J. Robey)
To:        comp.protocols.tcp-ip
Subject:   SLIP for SunOS4.1


I am looking at running SLIP between a Sun Sparcstation2 running SunOS 4.1 and
a VAX 11/785 running WIN/TCP 5.1.

I believe that WIN/TCP includes a SLIP Server. What I need is the SLIP
client for the Sun. Does anyone know of any available PD or commercial
implementations for a Sparcstation?

Also, once I have SLIP running between these two systems, will other users that
are on the same LAN as the Sun be able to access the VAX over this line??


Thanks in advance for your help!!

Frank J. Robey

fjr@mitre.org

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 14:00:42 GMT
From:      dms@tiger.ai.mit.edu (David M. Siegel)
To:        comp.protocols.tcp-ip
Subject:   Re: Which is best: PPP or CSLIP?

In article <1991May4.051233.7420@telebit.com>, brian@telebit.com (Brian Lloyd) writes:
|> CSLIP is an implementation of SLIP that has Van Jacobson's compression
|> algorithms.  Most PPP implementations do not have VJ header
|> prediction/compression.  Bottom line is that you are probably better
|> off performance-wise with CSLIP unless you can find a PPP
|> implementation with VJ compression.

I thought that the current PPP version for Suns (available on uunet) has
VJ header compression.  I'm running that version, and it works well. 
The performance also seems very good.

-Dave

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 14:23:41 GMT
From:      dengholm@IASTATE.EDU (Engholm Daniel M)
To:        comp.protocols.tcp-ip
Subject:   Re: Scripted Telnet's?

In article <11040@hub.ucsb.edu>, em@topgun.ucsb.edu writes:
> What's your favorite way to automate a segment of a telnet session?
> That is, say you have a tedious, repetitive, and error-prone procedure
> (aren't they all? :->) that you have to go through each time you want
> to log in to a remote host?  What have you done to automate this?
> 
> [stuff deleted]

Along the same lines, I want to connect to a certain Telnet "port" every
time (as opposed to the standard 23).  If I type:

% telnet 129.186.99.23 1001  (to connect to port 1001)

I get connected alright, but the session is in line mode.  I tried to
automate
the process of setting the mode to "character" with little luck.  I
haven't found
a way to specify mode from the command line either.

Any ideas for this one?
--
From my Unix (tm) work-   | Stuck out here in the middle of Iowa with
the
station to yours.         | 'buttaters.  ..or is this Idaho? Ohio????
__________________________|_____________________________________________
________
Don't take life too seriously or you'll never get out of it alive.
--Bugs Bunny

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 14:41:00 GMT
From:      gd@aprm (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   Sun TI-RPC

Text: 

(Please note that my From: line is broken.  Reply directly to me at
aprm%gd@shafter-emh1.army.mil)

The April 8 edition of PC WEEK carried a story about Sun's
Transport-Independent Remote Procedure Call (TI-RPC) tool.  It is
supposed to allow developers to create applications for Sun ONC networks
based on either tcp/ip or OSI.

I'm surprised that I haven't seen any mention of it here.  Did I miss
something?

Although we currently use Intel's OpenNET at Ft. Shafter, we have
embraced GOSIP as the standard to migrate to.  In the meantime, I want
to build client/server database applications, and am hamstrung by the
lack of support for OpenNET and GOSIP.  I put together a proposal based
on tcp/ip, but getting approval will be an uphill battle, and as a tax
payer I don't like the idea of building a system that requires buying a
bunch of hardware that may very well become obsolete in a few years. 
(I'm not knocking tcp/ip, just accepting the reality that DoD and the
Army insist on using GOSIP.)

According to the article, source code is available on Internet.  Anybody
know where?

Is there anybody familier with this stuff who can comment as to its
applicability in my situation?  In particular, is there any hope of
getting it to work with OpenNET, which we could use until GOSIP comes on
line here?  Is it reasonable to assume that the "OSI" Sun refers to is
compatible with GOSIP (or is it the other way 'round)?  Any SQL database
vendors supporting this thing?

Thanks in advance for all replies.  And don't forget to use my correct
address.
 
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                      |
                                        /
 
        Democracy is based upon the conviction
        that there are extraordinary possibilities
        in ordinary people.
                  Harry Emerson Fosdick

 --- End of Message -----------

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 15:53:22 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking dfor a book on SNMP ????????

In article <1991May3.184847.20446@bellcore.bellcore.com> jchen@ctt.bellcore.com writes:
>"The Simple Book"
>
>C. Jason Chen
>jchen@ctt.bellcore.com

Yes, that would be "The Simple Book, Managing TCP/IP Internetworks", by
Marshall Rose (no relation to Axel), published by Prentice-Hall. The cover
is mostly yellow, in case you're scanning the bookshelf.
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 16:29:28 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Need ethernet address to Vendor mapping.

I got a couple of them (sort of):

	ab-00-00	Some DEC multicast not in their old documentation
	ab-00-04	DECnet routing layer end nodes

In general, the 01 and 09 ones are multicast (low bit of first byte is on)
and the 00 and 08 are unicast.

	Bob

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 17:39:23 GMT
From:      schwartz@latour.colorado.edu (Mike Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load

In article <EMV.91May3032230@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes:

> My major problem with tools like NetFind is that although they address
> the "resource discovery" problem for a single user, they don't have any
> positive side-effects for the rest of the internet.  Nothing about
> NetFind adds to any Internet infrastructure; it doesn't make the problem
> any easier for the next person down the line or somewhere else who has
> the same problem.  In comparision, the efforts of the various X.500
> projects produce something tangible that the rest of the network can
> consume later.

Maybe this is too simplistic of an interpretation, but it seems your
argument boils down to the fact that NetFind is basically a client of
existing services, rather than a new service in its own right (like
X.500).  But from a user's perspective, this distinction is irrelevant.
What counts is whether the user can find the information they need, how
easily, and at what cost to the network.

It's true that keeping information in a server would allow that
information to be cached for future searches, but I have found that if
someone is "reachable" by NetFind, it is usually pretty easy to find
them with NetFind.  There isn't much need to look at what someone else
did to search for that person.  As an aside, searching for more general
types of resources (like anonymous FTP files) is a harder problem, and
the architecture I use for that project does utilize the results of
previous users' searches in facilitating future users' searches.

I think your objection to a tool only helping one user at the time of
use, without contributing to other users by its specific use, is really
wrong.  If this were the standard against which all software was
compared, we would get rid of most of the software in the world.

I also think your view of what is "tangible" is biased by your role as
moderator of comp.archives.  This is a nice contribution to "network
infrastructure", but as I see it, generating information collections
(which is what both comp.archives and X.500 do, in a general sense) is
only one way for users to get and share information.

In fact, I believe it makes more sense to search for some types of
resources where they naturally reside than it does to build a database
about them, since the database needs to be populated and kept up to date.
I see at least 3 cases where this can be true:
	1.  Dynamic, timely data.
        2.  Data with problems of transfer of authority (i.e., where people
            may not be willing to relinquish control of their data to
            relatively centralized administration, like a server per site).
        3.  Large information spaces of the nature that only a small
            fraction of the data will ever be needed (and hence the effort
            to populate a database will not be effectively amortized).
Internet white pages fits at least (1), since users move around, and
tracking their movements in a database presents administrative problems.
I believe it fits (2) and (3) as well.

 - Mike Schwartz
   Dept. of Computer Science
   Univ. of Colorado - Boulder

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 19:09:19 GMT
From:      rizzo@eng.wayne.edu (Frank F. Rizzo)
To:        comp.protocols.tcp-ip
Subject:   Ethertalk via Ethernet


A few days ago [last weeek] someone spoke of a modified CAP program which

allowed Unix boxes, Suns were the primary concern, to talk Appletalk over
Ethernet to communicate directly with Macintosh computers with Ethertalk

cards.  
This software also allowed printers hanging off Unix servers to be used by the

Macintoshes.

I think...

Can anyone provide me with the real name of that software and possiblly an FTP
site?

Thanks

-- 
+-----------------------------------------------------------------------------+
| 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    |
| WSU-PROFS: frizzo                               Detroit, Michigan  48202    |
| Internet: Frank_Rizzo@eng.wayne.edu             USA                         |
+-----------------------------------------------------------------------------+

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 19:17:24 GMT
From:      perand@admin.kth.se (Per Andersson)
To:        comp.protocols.tcp-ip
Subject:   Enhancements to tftpd anyone ?


Hi.

I have been thinking about the way standard BSD tftp works, and I am 
thinking about implementing some sort of access control.  One possible,
and for me satisfying solution would be to implement two access tables,
in one or two files, specifying which hosts who may read, and which hosts
who may write.  For example:

foo.bar.dom
bar.bar.dom write

would mean that both of them can read my tftp directory, but only bar would
be able to write. 

Has anybody done this already ?
Am I considering something fundamentally wrong ?

Per
-- 
Per Andersson (perand@admin.kth.se, perand@stacken.kth.se)
Now working at Bofors Electronics, managing networks,
still reading news at the Royal Institute of Technology

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 19:34:46 GMT
From:      JLENNIE@VM.UOGUELPH.CA (Jim Lennie)
To:        comp.protocols.tcp-ip
Subject:   Re: Port Numbers & NCSA


  Does anyone know if there is a way to configure NCSA Telnet on a Mac, so
  that it will request a telnet connection on a specified port other than the
  default?

  Thanks,
  --
  John Alsop

Try starting up the telnet program without specifying the host you want to
connect to. Next, type ALT-A to open a new session then enter the hostname or
IP address followed by the port number. That is how I do it with the version
running on my IBM PC.

===========================================================
Jim Lennie                           jlennie@vm.uoguelph.ca
Communications Services              519-824-4120  Ext 2588
University of Guelph
Guelph, Ontario
===========================================================

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 20:13:41 GMT
From:      jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey

In article <5634@eastapps.East.Sun.COM> ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston) writes:
>The Ethernet spec was apparently written by someone who either was not
>a mechanical engineer, or did not have any experience with automated
>manufaturing.  The reputation of the slide lock will probably never
>recover from that oversight.

The use of the slide lock also predates the "pizza box" and personal
computer designs.  All the old systems that I have seen use an internal
cable to go from the board to the chassis and the connector is mounted
on the outside of the mounting plate.  Under those conditions it is OK
though I always try to strain relief it where I can.

Even the case where the connector is soldered to the board it would be
easy to correct the problem.  Just mount the connector to (the outside
of) a small metal plate before soldering it to the board.  That metal
plate can then be screwed to the chassis where the connector would have
been.  The DB15 and slide lock assembly can then protrude tru a larger
hole in the chasis.  A 10 cent fix.  A smart connector manufacturer
would start selling the PC mount versions with a mounting bracket
already attached.  Having the slide lock come pre-assembled would
please those "automated manufacturing" types.

Are those "mechanical engineer"s deliberately violating the design spec
to cut costs or are they just ignorant of it?  That should be the real
question being asked here!

Screws are not perfect either.  When was the last time you removed a
cable and had the barrel nut come out with it?  Maybe we need a new
spec.  Anyone for a modular transceiver cable?

				Jerry Aguirre

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 20:38:05 GMT
From:      THIER@ORCAD2.dnet.ge.com
To:        comp.protocols.tcp-ip
Subject:   Host Lockup During Socket Transfers



   In attempting to run TCP socket transfers between two processes
residing in the same SPARCstation host, I am experiencing system 
lock-up after some number of transfers have taken place (the number
of transfers varys; it's usually between 950 and 2850 with 30 ms. 
intermessage spacing). Message sizes are 4446 octets. System 
configuration is:

                  SPARCstation 1+
                  SunOS 4.1
                  GENERIC Kernel.
                  16 MB memory.
                  210 MB disk.
                  56MB swap.
                  Send/Receive Queues = 4096


   I appear to be running out of some system resource that is reclaimed
after time, as the transfers can be extended somewhat by stopping the
transmit process prior to the lockup, waiting awhile, then restarting.
I've tried upping MAXUSERS to 16, with no effect. pstat -s shows no
appreciable inpact on swap, just prior to the lockup. Netstat shows the
many closing connections in TIME_WAIT, but nothing that seems wrong.
A typical netstat -m (at the 750 message mark) shows:

244/448 mbufs in use:
        7 mbufs allocated to packet headers
        96 mbufs allocated to socket structures
        135 mbufs allocated to protocol control blocks
        2 mbufs allocated to routing table entries
        2 mbufs allocated to socket names and addresses
        2 mbufs allocated to interface addresses
0/16 cluster buffers in use
72 Kbytes allocated to network (42% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

streams allocation:
                                         cumulative  allocation
                      current   maximum       total    failures
streams                    11        11         193           0
queues                     38        38         508           0
mblks                      15        39       57043           0
dblks                      15        39       57043           0
streams buffers:
external                    0         0           0           0
within-dblk                 0         4       29675           0
size <=    16               1        25       25725           0
size <=    32               0         3        1256           0
size <=   128              14        16         387           0
size <=   512               0         0           0           0
size <=  1024               0         0           0           0
size <=  2048               0         0           0           0
size <=  8192               0         0           0           0
size >   8192               0         0           0           0


   Any insight into what I'm doing wrong would be GREATLY appreciated (see
source below). TIA.


/* SERVER PROGRAM
   --------------

This routine creates a TCP socket and binds to the port number given
from argv [1]. It executes the following functional loop:

   Create Connection Socket
   Fetch Port Number from command line.
   BIND Connection Socket to port.
   LISTEN for connections.
   Loop:
      Test for connections with SELECT.
      ACCEPT Connection.
      Test for Data with SELECT.
      Loop until 4446 bytes received:
         RECV data.
      End Loop;
   End Loop;

   For every fifty complete messages received, the current message
   count is printed to the screen.

*/

#include <sys/types.h>;
#include <sys/time.h>;
#include <sys/socket.h>;
#include <stdio.h>;
#include <netdb.h>;
#include <netinet/in.h>;
#include <sys/uio.h>;
#include <strings.h>;
#include <stdio.h>;

main(argc, argv)
int argc;
char *argv[];

{

#define   BUFFER_SIZE   0xb000
#define   COUNT   50

   extern   errno;
   int    server_sd;
   int    msg_sd;
   int    char_count = 9; 
   char   buf[BUFFER_SIZE];
   int    rx_port;
   int    message_count;
   int    last_count;
   int    selectability;
   char   hostname[7];
   int    octets_received;
   struct timeval   *timeptr;
   fd_set readmask;
   fd_set writemask;
   fd_set exceptmask;
	
	struct	sockaddr_in	 	server;

   struct   hostent   *server_ent;


   /******************/
   /* Initialization */
   /******************/

   FD_ZERO (&writemask);
   FD_ZERO (&exceptmask);		
   timeptr = 0;
			
   message_count = 0;
   last_count = 0;

					 
   /*********************************************/
   /* Create and name Server INET STREAM socket */
   /*********************************************/
					
   printf ("\n\n\Server: Creating  INET STREAM socket.\n\n");
	
   server_sd = socket(AF_INET, SOCK_STREAM, 0);
	
   if (server_sd == -1)
   {

      perror("Server: Error creating socket.");

   }
	else
	{		
			
      sprintf (hostname,"loghost");

      server_ent = gethostbyname (hostname);

      if (server_ent == 0)
      {

         perror("Server: Unknown host.");

      }
      else
      {		

         printf("\n\Server: Hostname is %s\n",server_ent->h_name);

         /**************************/
         /* Bind Address to Socket */
         /**************************/

         bzero( (char *)&server, sizeof(server));
			
         server.sin_family = server_ent -> h_addrtype;
					
         bcopy ( (char *)server_ent -> h_addr,
                 (char *)&server.sin_addr,
                 server_ent -> h_length);

         printf("\n\Server: Internet Address is %s",inet_ntoa(server.sin_addr)); 
								

					 
         rx_port = atoi( argv[1] );

         server.sin_port = (short)rx_port;

         printf ("\n\n\Server: Local Port Number is  %i\n\n",server.sin_port);		

         if (bind	(server_sd, 
                  (struct sockaddr_in *)&server,
                   sizeof(struct sockaddr_in) ) == -1)
            {

               perror("Server: Error binding socket");
				
            }
            else
				{
             
               printf ("\n\n\Server: Socket bound to name 'server_sock'\n\n");


               /***************************/
               /*  Listen for Connections */
               /***************************/
	
               listen(server_sd, 5);

               printf ("\n\n\Server: Listening for connection.\n\n");


               /************************/
               /* Execute Receive Loop */
               /************************/

               while (1)
               {

                  /*******************************/
                  /* Pend on Connection Attempt. */
                  /*******************************/

                  FD_ZERO (&readmask);		
                  FD_SET (server_sd, &readmask);

                  selectability = select (FD_SETSIZE,
                                          &readmask,
                                          &writemask,
                                          &exceptmask,
                                          timeptr);

                  if (selectability > 0)
                  {

                     if FD_ISSET (server_sd, &readmask)
                     {

                        msg_sd = accept (server_sd, 
                                        (struct sockaddr_in *)0,
                                         sizeof(struct sockaddr_in) );

                        if (msg_sd == -1)
                        {

                           perror("Server: Error accepting connection");

                        }
                        else
                        {
					
                           /*****************/
                           /* Pend on Data. */
                           /*****************/

                           FD_ZERO (&readmask);		
                           FD_SET (msg_sd, &readmask);

                           selectability = select (FD_SETSIZE,
                                                   &readmask,
                                                   &writemask,
                                                   &exceptmask,
                                                   timeptr);

                           if (selectability > 0)
                           {

                              if FD_ISSET (msg_sd, &readmask)
                              {
   
                                 message_count = message_count + 1;
                                 octets_received = 0;

                                 while (octets_received < 4446)
                                 {
                                    char_count = 1;

                                    char_count = recv(msg_sd,
                                                      buf,
                                                      BUFFER_SIZE,
                                                      0);

                                    if (char_count == -1)
                                    {
                           
                                       perror("Server: Error receiving data.");

                                    }; /* End RECV Check */

                                    octets_received = octets_received +
                                          char_count;

                                 };   /* End Receive Loop. */		

                                 close (msg_sd);

                                 if (message_count - last_count == COUNT)
                                 { 
                                    printf ("\n\n%i", message_count);
                                    printf ("\ messages received.\n\n");                                              last_count = message_count;

                                 };   /* End Periodic Message. */

                              };   /* End Data Readability Check. */

                           }
                              else 
                           {

                              perror("Server: Error on Data Select.");
  
                           };   /* End Data Select Check. */

                        };   /* End Accept Check */

                     };   /* End Connection Check. */
				
                  };   /* End Connection Select Check. */

               }; /* End Input Loop */

					close (server_sd);

				};	/* End Bind Check */
 
			};	/* End Gethostname conditional */
 
		};	/* End Socket Create Conditional */

		printf ("\n\n\Server: Terminating.\n\n");

	  exit();

  } /* end main */



/* CLIENT PROGRAM
   --------------

This routine creates a TCP socket and connects to the host and port given
from argv [1] and [2], respectively. It executes the following functional 
loop:

   Fetch Server hostname and port number from command line.
   Loop for CONNECTION_LOOPS (currently set to 3000):
      Create socket.
      CONNECT to Server.
      Test for writability of socket with SELECT.
      SEND data (4446 bytes of ASCII 5's).
      Close socket.
   End Loop;
*/


#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <netdb.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/time.h>

main(argc, argv)
int argc;
char *argv[];
{
#define   BUFFER_SIZE   4446
#define   CONNECTION_LOOPS   3000

	extern	errno;
	int		client_sd; 
   int		output_cnt;
	int		i;
	int		cntd; 
	int 		rx_port;
   int      selectability;
   int      unix_call_status;

   struct   timeval   current_time;
   struct   timeval   previous_time;

   struct   timezone      system_time_zone;
   long     delta_seconds;
   long     delta_microseconds;
 
	struct	sockaddr_in	 	server;
	struct	sockaddr_in		client;


   struct   hostent   *server_ent;
   struct   hostent   *client_ent;


   char   buf_out[BUFFER_SIZE];
   char   hostname[25];

   fd_set readmask;
   fd_set writemask;
   fd_set exceptmask;
   struct timeval timeout;

   /******************/
   /* Initialization */
   /******************/

   for (i = 0; i < BUFFER_SIZE; i++)
   {
   
      buf_out[i] = '5';

   };

   cntd = 1;

   FD_ZERO (&readmask);
   FD_ZERO (&exceptmask);		

   timeout.tv_sec = 2;
   timeout.tv_usec = 0;

   system_time_zone.tz_minuteswest = 0;
   system_time_zone.tz_dsttime = DST_GB;

   /********************************************/					
   /* Fetch Client Host Data from '/etc/hosts '*/
   /********************************************/
		
   sprintf (hostname,"loghost");
   client_ent = gethostbyname (hostname);
			
   if (client_ent == 0)
   {
      perror("Client: Unknown local host.");
   }
      else
   {		

      printf("\n\Client: Hostname is %s\n",client_ent->h_name);
      printf("\n\Alias is %s\n",*((char *)client_ent->h_aliases)); 
		

      /*******************************************************/		
		/* Load Client Socket Structure with Host information. */
      /*******************************************************/	
		
      bzero( (char *)&client, sizeof(client));
		
      client.sin_family = client_ent -> h_addrtype;
      printf ("\n\Client: Domain Type is  %i\n\n",client.sin_family);
				
      bcopy ( (char *)client_ent -> h_addr,
              (char *)&client.sin_addr,
              client_ent -> h_length);
      printf("\n\Client: Internet Address is %s",inet_ntoa(client.sin_addr)); 
								


      /*********************************************************/
      /* Load Client Socket Structure with Server information. */
      /*********************************************************/

      server_ent = gethostbyname (argv[1]);
		
      if (server_ent == 0)
      {
         perror("Client: Unknown server host.");
      }
      else
      {		
         printf("\n\Client: Server hostname is %s\n",server_ent->h_name);

         bzero( (char *)&server, sizeof(server));
			
         server.sin_family = server_ent -> h_addrtype;
					
         bcopy ( (char *)server_ent -> h_addr,
                 (char *)&server.sin_addr,
                 server_ent -> h_length);

         printf("\n\Client: Server Address is %s",inet_ntoa(server.sin_addr));

         rx_port = atoi(argv[2]);

         server.sin_port = (short)rx_port;

         printf ("\n\n\Client: Server Port Number is  %i\n\n",server.sin_port);							

         /********************************/
         /* Commence Connect & Send Loop */
         /********************************/

         /**********************/
         /* Connect to Server. */
         /**********************/		

         for (i = CONNECTION_LOOPS; ( (0 < i) && (cntd != 0) ); i--)

         {
            /************************/
				/* Create client socket */
            /************************/

            if ( (client_sd = socket(AF_INET, SOCK_STREAM, 0) ) == -1)
            {
               perror("Client: Error creating socket.");
            }
            else
            {
					
               /****************************/			
               /* Connect to parent socket */
               /****************************/

               cntd = connect (client_sd,
                               (struct sockaddr_in *)&server, 
                               sizeof (struct sockaddr_in) );
               if (cntd == -1)
               {

                  perror("Client: Error connecting to Server");
                  printf("\n%i\n",errno);

               }
               else
               {
							
                  /***************************************************/
                  /* Test Writability of Socket for up to 2 Seconds. */
                  /***************************************************/

                  FD_ZERO (&writemask);		
                  FD_SET (client_sd, &writemask);

                  selectability = select (FD_SETSIZE,
                                          &readmask,
                                          &writemask,
                                          &exceptmask,
                                          &timeout);

                  if (selectability > 0)

                  {

                     if FD_ISSET (client_sd, &writemask)
                     {

                        /*************************/
                        /* Write data to socket. */
                        /*************************/
											
                        output_cnt = send (client_sd, 
                                           buf_out, 
                                           sizeof(buf_out),
                                           0);

                       if (output_cnt == -1)
                       {

                          perror("Client: Error sending data.");

                       }
                       else
                       {

/*                          sprintf(print_buf_1, "Client: Output buffer transmitted.");*/
							
                       };   /* End Send  Confirmation. */

                     };   /* End Writability Check. */

                  }
                  else if (selectability == 0)
                  {
                  
                     printf ("\n\n\Select Timeout.\n\n");
                  
                  }
                  else
                  {
                     printf ("\n\n\Select Failure.\n\n");
                    
						};   /* End Select Confirmation */

               };   /* End Connect Confirmation. */
					
               /****************/
               /* Close Socket */
               /****************/ 
               
               close (client_sd);
               cntd = 1;
						
            };   /* End Socket Create Confirmation. */
							
            /**********************/
            /* Intermessage Delay */
            /**********************/

            delta_microseconds = 0;

            unix_call_status = gettimeofday
                               (&previous_time, 
                                &system_time_zone);

            while (delta_microseconds < 30000)
            {
            
               unix_call_status = gettimeofday
                                  (&current_time, 
                                   &system_time_zone);


               delta_seconds = current_time.tv_sec
                             - previous_time.tv_sec;

               delta_microseconds = current_time.tv_usec
                                   - previous_time.tv_usec;

               if (delta_seconds < 5)
               {

                  delta_microseconds = (delta_seconds*1000000) 
                                      + delta_microseconds;
               };

             };

         };   /* End Transmission Loop. */
					
      };   /* End Remote Host conditional. */
		
   };   /* End Local Host conditional. */
		
   printf ("\n\n\Client: Terminating.\n\n");
   perror("Errno is ");
   exit (0);

}




John Thier
GE Defense Systems Division
Pittsfield MA
thier@orcad2.dnet.ge.com

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 21:47:29 GMT
From:      daviddes@twg.com (David Desko)
To:        comp.protocols.tcp-ip
Subject:   Re: Wolongong e-mail address


	The International Sales representative for Brazil is Graeme Vanderstoel
(g.vanderstoel@twg.com).  The local distributor in Brazil for Wollongong 
products is Brazil Software (voice: 21 240 2143 -or- 533 1726).

	Post sales technical Support can be reached at support@twg.com.

Enjoy!

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 23:42:02 GMT
From:      Andy.Linton@comp.vuw.ac.nz (Andy Linton)
To:        comp.protocols.tcp-ip
Subject:   Re: Scripted Telnet's?


In article <1991May6.092341@IASTATE.EDU>, dengholm@IASTATE.EDU (Engholm
Daniel M) writes:
|> In article <11040@hub.ucsb.edu>, em@topgun.ucsb.edu writes:
|> > What's your favorite way to automate a segment of a telnet
 session?
|> > That is, say you have a tedious, repetitive, and error-prone
 procedure
|> > (aren't they all? :->) that you have to go through each time you
 want
|> > to log in to a remote host?  What have you done to automate this?
|> > 
|> > [stuff deleted]
|> 
|> Along the same lines, I want to connect to a certain Telnet "port"
|> every
|> time (as opposed to the standard 23).  If I type:

You might like to look at 'expect' writen by Don Libes, National
Institute of Standards and Technology. It provides facilities for doing
this sort of thing.

Extracts from the README follows:

This is the README file from "expect", a program that performs
programmed dialogue with other interactive programs.  It is briefly
described by its man page, expect(1).  More examples and further
discussion about implementation, philosophy, and design are in
"expect: Curing Those Uncontrollable Fits of Interaction" by Don
Libes, Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA,
June 11-15, 1990.  Even more examples and discussion, specifically
designed for system administrators, are in "Using expect to Automate
System Administration Tasks" by Don Libes, Proceedings of the 1990
USENIX Large Systems Administration Conference (LISA) IV, Colorado
Springs, CO, October 17-19, 1990.

...

expect may 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".  Once you have retrieved the system, please read
the INSTALL file.  The papers mentioned above can be retrieved
separately as pub/expect.ps.Z and pub/expect-sysadm.ps.Z.



	

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 23:48:45 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey

jerry@olivey.ATC.Olivetti.Com (Jerry Aguirre) writes:
> Screws are not perfect either.  When was the last time you removed a
> cable and had the barrel nut come out with it?

	Some screws are better than others.  The problem you are referring
to is again the fault of stupid designers who use screws to attach the
mounting sockets for the connector screws; i.e. an implementation problem,
not a concept problem.  I remember the lowly ADM-3/3a/5 terminals which had
moulded-in screw sockets.  I've never had one of those come off with the
cable when I unscrewed the hold-down screws.

	The after-the-fact fix to connectors which have screwed-on-sockets
is a dab of epoxy on the inner nut to keep it from comming off.  We've got
lots of terminals/printers/etc with dabs of epoxy inside, but people
shouldn't have to resort to such antics to keep a cable connected.

	And, the answer to not having a screwdriver handy, is to make
cables with thumbscrews, like Apple used to use for the old-style LocalTalk
connectors (Mac-512 and LaserWriter).
--
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!"

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 May 91 23:52:44 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

>Andrew McRae (andrew@megadata.mega.oz.au) writes:
>[summarized]
>1. LAT has less overhead than TCP, and is more efficient for local terminal
>  traffic.

      Highly dependent on the implementation of IP.  

>2. LAT doesn't work through routers, but so what.
      
      This is a MODERN real-world protocol?  Ever think about
      the poor guy paying the bills for the high speed links
      that a bridge requires compared to the savings available
      when routing at a higher layer?  

      If you are rich enough to afford T-3 links, lets talk
      about the response time delays.  Or perhaps
      transcontinental access, satellite circuits, etc. are not
      a part of modern networks?

>3. LAT is DEC proprietary, and is not really readily available.
      
      Nothing wrong with a proprietary protocol...as long as it
      is well documented and works in a REAL network...

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 04:42:54 GMT
From:      michael.macdonald@canrem.uucp (michael macdonald)
To:        comp.protocols.tcp-ip
Subject:   easy question on tcp

The company I work for is currently looking into the use of TCP-IP to
allow users of their Novell network to access a Unix box.  I was
wondering if anyone could supply me with the names of a few books that
would explain a little more about the protocol works.  And if possible
information on what exactly is required to make a project like this
work.

Our system currently consists on a 110 IBM ATs, 4 386 Novell file
servers (running 386 V3.0 or greater), and a 386 running SCO UNIX 386
with the TCP server libraries.

Thanks alot,
Michael MacDonald
michael.macdonald@canrem.uucp
michael.macdonald%canrem@lsuc.on.ca
--
Canada Remote Systems.  Toronto, Ontario
NorthAmeriNet Host

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 07:40:39 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load

In article <1991May6.173923.174@colorado.edu> schwartz@latour.colorado.edu (Mike Schwartz) writes:

   > My major problem with tools like NetFind is that although they address
   > the "resource discovery" problem for a single user, they don't have any
   > positive side-effects for the rest of the internet.  

   Maybe this is too simplistic of an interpretation, but it seems your
   argument boils down to the fact that NetFind is basically a client of
   existing services, rather than a new service in its own right (like
   X.500).  

It may be just a matter of terminology; if NetFind were billed as just
a souped-up version of finger, then it could be evaluated in the
context of being basically a client of other services.  But with the
claims of it being a "Semantically Cognizant Internet White Pages
Directory Tool" with the ability to reach "1,147,000 users in 1,929
administrative domains", when it's mentioned in the same breath as
X.500 projects and as an alternative to them, something about it calls
for a more critical examination.

Just to qualify the numbers -- 1,147,000 reachable users is 1,929
reachable domains, each with an average of 119 hosts (mean based on
sample size of 75), with each of those hosts containing a
"conservative estimate" of 5 users per host.  I don't see any
breakdown of success rate by type of domain; notably, the only success
numbers I could find (80+% hit rate by day, 70+% by night) don't
attempt to measure success to the 40% of the database that's not in
the USA.  Perhaps there are a million people out there; I'm not
convinced of how many people you can find.

The performance figures didn't correct for sample bias in the
observer; it would be expected that the author would look for people
in a field related to his (computer science).  Since computer science
departments are often those in charge of running the name servers on
campus, the particular happy accident of the search algorithm relying
on SMTP lookups to the primary name servers may work overly well for
CS dept.  searches.  It is less likely to work well for lookups on
people who are more peripheral to the campus network infrastructure.
An interesting exercise would be to run NetFind against the names of
10 senior librarians, 10 junior physics faculty members, 10
mathematics graduate students, and 10 undergraduate French majors,
suitably scattered about; I have some guesses as to how well your
results will turn out.

(In truth none the numbers tossed around in the paper are especially
convincing; it would have been appropriate to qualify estimated packet
counts and user counts with estimated error ranges.  It's not possible
for me to justify 1,147,000 users any more than 1,146,000 users; a
more plausible figure is "on the order of a million users". That's
especially true without a good rationale for picking 5 users per host,
a figure which appears out of the blue with absolutely no
references....)

I note that your paper shows (fig 3) that usage of your NetFind
prototype tapers off to an average of one use every two weeks.  There
is no indication from the study whether usage dropped so sharply from
the original high average of 7 uses in the first day, or why it drops
so far below the estimated 10 searches per week (quoted from RFC
1107).  Given the expectation of relatively static communities of
interest and the ready availablity of e-mail address information of
potential colleagues by alternative access methods (business cards,
telephone calls, private mailing lists, netnews) it's not surprising
to me that the need for zero-prior-knowlege user lookup information is
lower than 1/day.  But given that the usage trails off to almost nil
after 200 days of use, it would seem to call into question the
long-term usability of your product.  Have you done any retrospective
work on determining why user usage levels dropped to such low levels?

   ... I have found that if someone is "reachable" by NetFind, it is
   usually pretty easy to find them with NetFind.

That's hard to argue with.  But it doesn't yield any insight into what
makes people hard to locate, or how to design campus and corporate
information systems so that people can easily be found without
resorting to extraordinary sleuthing measures.  You casually write off
(in section 5, Related Work) the efforts of campuses to provide local
X.500 services which are accessable via finger; though it's not
directly germane to your research, it would have at least been useful
to point out that X.500 servers can be deployed within the existing
system to good effect.  Stick an X.500 system at yourdomain.org with
a big pile of user names in it, make it so finger@yourdomain.org does
the right thing, and for large institutions like UIUC, UMich, MIT you
have a larger problem solved than trying to chase pointers through a
domain hierarchy.  Granted, the information is somewhat more stale and
less likely to be exactly true; but I think it's arguable that
zero-knowlege searches are looking more for a pointer to information
than an exact match.  (e.g. finger vielmetti@umich.edu and you'll get
something, but you might have to chase it down a bit to find out from
a human that I've moved recently.)

   As an aside, searching for more general types of resources (like
   anonymous FTP files) is a harder problem, and the architecture I
   use for that project does utilize the results of previous users'
   searches in facilitating future users' searches.

Yes, I've read the paper; can't say that it compares with a service
like "archie", though, even if the software were available.  My
reactions to that paper can wait for another message. I'm not
impressed with the amount of effort you've spent on seeing how people
have really addressed the problem;  in particular, your success rates
for scanning the net for interesting information are skewed because
i'm doing it for you already....

   I think your objection to a tool only helping one user at the time of
   use, without contributing to other users by its specific use, is really
   wrong.  If this were the standard against which all software was
   compared, we would get rid of most of the software in the world.

    - Mike Schwartz
      Dept. of Computer Science
      Univ. of Colorado - Boulder

I think my point is valid.  For me to want to let you accomplish a
particular task on the Internet (a shared, finite resource) you need
to justify to me that it's worth it to let you interpose your packets
in the way of my packets on the way to their destination.  I will be
unwilling to do this unless I'm generous or unless I can see some
benefit (or very low cost) from you doing so.  Remember that your use
of the net is generally going to make my use of the net marginally
slower, less convenient, and more risky, unlike e.g. your use of an
editor on your local system.  That's the story of negative
externalities and the "tragedy of the commons"; everyone does a little
thing that's convenient for them but which causes the playground to be
littered.  (e.g. the cutoff of nudie pictures on USA FTP sites causing
the saturation of the USA-Finland internet link, and the subsequent
barrage of traffic in alt.sex.pictures).  Provide me with something
useful, a scrap of code I can use or a good idea to work with, and
I'll let you go about your business

NetFind does seem to pose certain risks to the rest of the net; you
could be very efficiently bombarding my slow links on a wild goose
chase trying to find someone somewhere else.  In truth, I'm sure that
the tradeoff is positive, and that I would be quite happy if just one
person somewhere used NetFind to find me.  A more salient risk is that
successful efforts like NetFind would lead people to believe that
generating queryable information collections a la X.500 is not
necessary in the long run and that we'd be content with ad hoc
solutions.

[
The paper I'm making references to is ftp'able as
	latour.colorado.edu:/pub/RD.Papers/White.Pages.ps.Z
]

-- 
Edward Vielmetti, vice president for research, MSEN Inc. 	emv@msen.com

"often those with the power to appoint will be on one side of a
controversial issue and find it convenient to use their opponent's
momentary stridency as a pretext to squelch them"

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 08:14:03 GMT
From:      dfk@NIC.EU.net (Daniel Karrenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Enhancements to tftpd anyone ?

perand@admin.kth.se (Per Andersson) writes:
>I have been thinking about the way standard BSD tftp works, and I am 
>thinking about implementing some sort of access control.  

You might want to look at mcsun.eu.net:~ftp/network/tftpd.shar.Z
This implements read access control and a tftp spool directory.

Daniel
-- 
Daniel Karrenberg                    Future Net:  <dfk@cwi.nl>
CWI, Amsterdam                        Oldie Net:  mcsun!dfk
The Netherlands          Because It's There Net:  DFK@MCVAX

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 10:08:41 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Why Fewer Buffers (was Changing TCP port)

On Fri 3 May 91 14:08:37-PDT you said:
>Avoiding duplicate datagram thrashing (DDT?) is THE major reason for using
>smaller queues.  This is unfortunately still very prevalent in TCP/IP, even
>though the algorithms have been developed to help prevent it.  Many other
>protocols are much dumber, and don't even have any facility for slowing
>down in the presence of congestion.  If you believe that ANY queue with
>an average size of greater than one represents a congested link, the actual
>queue sizes on routers don't have to be very big.

Glad to know why you recommend small queues, and the underlying theories.
Unhappily, I still don't know how bigger than 1 they should be and I guess
no one can tell. Indeed not all TCPs are good. I've seen one transmitting
4 times what's needed when doing FTP alone on a slow link. So, even 0 maybe.
Routers can help when this link is not on the culprit's interface itself.

>    Finally, on grounds of what came in must go, I wonder if the most
>    drastically effective heuristics wouldn't be to detect and drop duplicate
>    queued packets, with the excuse of unreliability for rare mistakes.
>
>Sure, given infinite CPU resources on the routers, one can do anything...

I doubt it would spend much CPU on mismatches, especially if the line is
slow anyway and this feature used only on them. The larger expense on
matches would be pure benefit.
But indeed the transport level helping the others a bit would sure help.

>Bill Westfield
>cisco Systems.

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 13:54:41 GMT
From:      scottp@se-sd.SanDiego.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Re: active tcp ports and process id's

In article <EMV.91May3230224@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes:
>In article <MailManager.673214507.213.hubert@kamba.cac.washington.edu> hubert@CAC.WASHINGTON.EDU (Steve Hubert) writes:
>
>   Has anyone done an ULTRIX4 version of ofiles?
>
>Yes, Jeff Mogul from DEC did one.  Here's his reference from
>comp.archives in December of last year.

 Has anyone done a SysV version?



-Scott

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 14:35:22 GMT
From:      cole@etonic.gsg.dco.dec.com (Larry Cole)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Accessing a DOS disk from unix over ethernet

ULTRIX Version 4.2 includes support for ISO 9660 and High-Sierra CDROMs. 
It is implemented as a 'cdfs' file system type.  On my DECstation, I can
mount a CDROM at mount point /cdrom, bring up SoftPC, point SoftPC's
logical MSDOS drive E: at /cdrom and run MSDOS applications off of the
CDROM !  Needless to say, I can also access /cdrom from ULTRIX in standard
manner.  I also export /cdrom so other's may NFS mount it.  In addition,
local VAX's (VMS-type) can access /cdrom via DECNET .


larry cole
Digital Equipment Corporation
Govt Technical Support Center
Landover, MD
email:	cole@dco.dec.com

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 14:59:36 GMT
From:      kline@ux1.cso.uiuc.edu (Charley Kline)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load

emv@ox.com (Ed Vielmetti) writes:

> Stick an X.500 system at yourdomain.org with
> a big pile of user names in it, make it so finger@yourdomain.org does
> the right thing, and for large institutions like UIUC, UMich, MIT you
> have a larger problem solved than trying to chase pointers through a
> domain hierarchy.  Granted, the information is somewhat more stale and
> less likely to be exactly true; but I think it's arguable that
> zero-knowlege searches are looking more for a pointer to information
> than an exact match.  (e.g. finger vielmetti@umich.edu and you'll get
> something, but you might have to chase it down a bit to find out from
> a human that I've moved recently.)

Since you mentioned UIUC...

We're not an X.500 shop here, but we do have a campus-wide "white
pages" service which users can update themselves, and it has an
interface to sendmail as well as finger. You can find me with
"finger 'charley kline'@uiuc.edu", and you can send mail to people's
full names, as in  "mail stacy-forsythe@uiuc.edu". People who move
can change their own entries, so information is never out of date
as long as the person cares enough to keep their information up
to date.

I think the point is that organizational white-pages databases are
already in great supply. I wonder if the "Semantically Cognizant White
Pages Service" understands the semantics of the various ones in use. If
so, it would make the search for people that much less intensive.

________________________________________________________________________
Charley Kline, KB9FFK, PP-ASEL                          c-kline@uiuc.edu
University of Illinois Computing Services            Packet: kb9ffk@w9yh
1304 W. Springfield Ave, Urbana IL  61801                 (217) 333-3339

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 16:22:13 GMT
From:      ken@dali.cc.gatech.edu (Ken Seefried iii)
To:        comp.protocols.tcp-ip
Subject:   More secure ftpd (was: Re: Enhancements to tftpd anyone ?)

In article <1991May6.191724.25254@kth.se> perand@admin.kth.se (Per Andersson) writes:
[ speculating about a more secure tftpd ]

I'd like to see a much enhanced regular ftpd that allowed access
control and connection auditing.   I'm aware of a few versions that do
something like this, and one person posted some time ago that he and
his people were working on the be-all, end-all ftpd.  In any case, I'd
love some pointers to a very secure ftpd.  

Many thanks...

--

	ken seefried iii	"I'll have what the gentleman 
	ken@dali.cc.gatech.edu	 on the floor is having..."

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 16:26:03 GMT
From:      shane@VM.UTDALLAS.EDU (Shane Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

Annex terminal servers can speak with Encore Multimax machines with some
sort of login protocol which presumably reduces host load. This is the
protocol used by the Annex "call" command. Supposedly, the Annex runs the
tty drivers for the Multimax, acting as a FEP and passing data to the host
only when whatever quantum of data the host desires is entirely available (e.g.
a line-mode operation such as a shell command isn't passed until newline).
The protocol is proprietary, like LAT, but is done via TCP/IP, unlike LAT.

--Shane Davis
  Network Systems Software
  Univ. of Texas at Dallas, Academic Computer Center
  (214) 690-2637        shane@utdallas.edu        SHANE@UTDALLAS.BITNET

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 18:11:05 GMT
From:      fierro@uts.amdahl.com (Doug Fierro)
To:        comp.misc,comp.lang.c++,comp.protocols.misc,comp.protocols.tcp-ip,comp.databases
Subject:   volunteers requested for server project


  (this is going out to relevant computer groups.  Sorry if you get
   this twice.)

  This is a request for volunteers to work on a server project that
will be used by USENET.  There used to be a sever at UMass affectionately
known as the lyrics server which was used to retrieve/contribute lyrics of
any kind.  It has been down for some time now, and there is an effort
underway to revive it and also improve the performance and features it
will offer.

  This project touches a lot of areas, like databases, C++, protocols,
and UNIX stuff.  It would be good for a resume, or even if you want 
something to do over the summer.  The whole world would use this server
once it is complete (no joke!).

  People interested should contact Niall Emmart at 

   Niall.Emmart@saturn.ucc.umass.edu

All questions/suggestions/etc. should go directly to him.  I'm just sort
of the facilitator/coordinator.  You can still contribute to the design
specs. since I don't think actual coding has begun yet.  Below is mail
I recieved from Niall which outlines the project.

  Thank you for your time,


  Doug

********************************************
>From apple!saturn.ucc.umass.edu!Niall.Emmart Tue May  7 07:42:06 1991
>Return-Path: <apple!saturn.ucc.umass.edu!Niall.Emmart>
>Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.7)
 id <m0jaTEr-00000KC@amdahl.uts.amdahl.com>; Tue, 7 May 91 07:42 PDT
>Received: from saturn.ucc.umass.edu by apple.com with SMTP (5.61/25-eef)
	id AA03744; Tue, 7 May 91 07:30:45 -0700
	for fierro
>Received: from US*UMASSMAIL*UMASS by saturn.ucc.umass.edu via QTFS with X.400;
> Tue, 7 May 91 10:31:00 -0400
>X400-Trace: US*UMASSMAIL*UMASS; arrival Tue, 7 May 91 10:30:50 -0400 action
> Relayed
>Date: Tue, 7 May 91 10:30:50 -0400
>Message-Id: <910507101930674-MTASATURN*Niall.Emmart@saturn.ucc.umass.edu>
>P1-Message-Id: US*UMASSMAIL*UMASS; 910507101930674-MTASATURN
>Ua-Content-Id: 910507101930674-
>From: apple!saturn.ucc.umass.edu!Niall.Emmart
>Subject: The Lyrics Server
>To: amdahl!fierro@apple.com
>Status: R
>
>Hello..
>   I got both of your messages (The test message and the one forwarded
>from Judy). I have already gotten one reply from the net. From
>Afoiani@NMSU.edu. Thanks for your help...
>
>   Niall Emmart
>
>Here is a copy of the message I send Afoiani. It details the current
>state of the project.
>
>Hello...
>   I got your message about the Lyrics Server port.
>   I hadn't given the server much thought until the other day when
>I got a message from Doug Fierro. The Lyrics Server has some pretty
>severe limitations - no text search ability, the musicn't grouped
>by catagories, no way for the user to figure out what's new, a lot of
>work for the manager to add albums, and finally a lot of CPU time to
>process simple requests.
>   All of the above makes a port of the server undesirable. I've
>talked to Matson a lot. He used to run the server. We're going
>to try to do a total rewrite. With radical changes. We would like to
>write the server in two parts. First as a general database program
>followed by customizations as a Lyrics Server. Because of the e
>of the project, we're considering using C++. Probably GNU's G++.
>   Are you still interested in working on a piece of the project?
>I see it breaking into four main parts.
>   1) Design
>   2) Coding class libraries
>   3) Coding the server
>   4) Cod mail and other interfaces. We've kicked around the
>         idea of a TCP interface, maybe even an IRC interface.
>
>   We'd welcome any assistance in any of the above areas.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Thanks very much,
>    Niall Emmart
>
>********************************************
-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
                                                      Doug Fierro
 <<The only guarantee in life is that you will die>>  fierro@uts.amdahl.com
                                                      UNIX division
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 21:02:05 GMT
From:      davec@rock.concert.net (David Cohen -- DBLinx)
To:        comp.protocols.tcp-ip
Subject:   Out-of-band, 0 length msgs

I'm trying to set up a gateway between a Sybase front-end on a
Sun and a Sybase server on a VAX. Without going into details, 
I decided to test some stuff locally on the Sun:

    S   front-end---------->
    U                     gateway
    N   server<-------------+                                                  

This is just for simulation purposes - I'm sending Sybase client stuff
to the gateway's socket, which simply pumps it out to
the Sybase server. Also, server messages go in the gateway's socket and
get pumped out to the front-end. In this test, the gateway is a surrogate
for the Sybase server. Without getting into DECnet stuff, I'm having
some problems:

    The gateway is cranked up by inetd. It uses a select() statement:
  select(32,&mask,NIL,&oobmask,NIL);
with mask and oobmask set to the client and server fds. Everything's
fine until the client sends an exception (out-of-band) data. Since
I just want the gateway to be  a dumb pass-thru, I don't do anything
special - just pass it on to the server. But, after this happens,
the select() keeps waking up thinking the client has sent data to
the gateway's socket. However, ioctl says that 0 bytes are available.
This select() woke up on the exception mask for the client.

Anyway, does anyone have a clue as to why the select() keeps waking
up with 0 client bytes to send after an out-of-band condition had
been handled?

thanks
-dave

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 21:58:03 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: SUMMARY: Re: active tcp ports and process id's

In article <MailManager.673214507.213.hubert@kamba.cac.washington.edu> hubert@CAC.WASHINGTON.EDU (Steve Hubert) writes:
> Has anyone done an ULTRIX4 version of ofiles?

My pff (process-file-file) program, which merges and improves upon the
available versions of ofiles and fstat, has been tested on each of the
following systems:

	SunOS 4.0.3, Sun 4/280
	SunOS 4.1, lots of Suns (thanks Seth Robertson)
	Ultrix 4.1, DECsystem 5820
	Ultrix 2.2, VAX 8800 (thanks Vic Abell)
	BSD 4.3-Tahoe, VAX 11/780 (thanks Vic Abell)
	Convex UNIX 9.0, Convex-C1-XP
	DYNIX 3.0.17 (modified), Symmetry S81 (thanks Vic Abell)

pff should be generally easier to port than ofiles. It's part of the
kstuff package, version 0.18 of which I just posted to alt.sources. You
can ftp version 0.18 from pub/hier/kstuff:/18 on stealth.acf.nyu.edu.
The package also includes a history of various ofiles versions, in case
you're interested in knowing who did what.

As extra bonuses, kstuff includes lots of kernel-reading libraries you
can use in various applications, as well as updated versions of my RFC
931 server program and client library, as well as a utility to do a fast
mapping from (device,inode) back to filename. This gets back to the
ofiles track---if you install findinode, pff will give you open files by
name! But enough advertising for now.

---Dan

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 22:02:27 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re:  Escape sequences over Telnet/TCP

In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
> If this is the case, the fault lies in the implementation of
> the TELNET client software which is not handling escape sequences correctly in
> this particular environment.

No. The fault lies entirely in a keyboard code convention that produces
streams that can't be uniquely decoded without timing information. In a
better world, no valid key combination would produce a proper prefix of
another, and these problems would disappear.

(One would think that a virtual terminal protocol would address these
issues. SUPDUP does, anyway.)

---Dan

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 22:24:47 GMT
From:      ddean@rain.andrew.cmu.edu (Drew Dean)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load


	There are some interesting points here.  If the person you're trying
to find has (a) been on the net for a long time, (b) works for the military
or a military contractor, or (c) is the technical or administrative contact
for a domain, a whois query to nic.ddn.mil will usually get an answer.  But
yet even relatively well known people such as Ed Vielmetti aren't in that
database.
	Stanford runs a whois server on stanford.edu that has a campus
database in, so that's useful if you know a person is there; as Ed points
out UMich, MIT, and UIUC; at CMU finger name@andrew.cmu.edu will do the same
thing; if you know they're in CS, finger name@cs.cmu.edu will also work.
However, most of the net isn't setup like this, although I'd say it would
probably be a good thing. If you know where a person is, (and you're lucky
:-)), a nice note to postmaster is another reasonable approach.  If not,
nslookup and fingering main machines (ie. not every workstation in a
cluster, just the fileservers & time-sharing machines) will usually work.
For those who are SMTP literate, the VRFY command is also worth trying,
although certain SMTP servers don't support it.
	So if a person is in the NIC database, or you know where they are,
you can find them without too much work.  The big problem is if neither of
these cases apply.  Would someone like to donate a machine to run a really
big whois database ?  Even so, you still have aliasing problem; the current
whois database at nic.ddn.mil has 2 "Adams, Rick" entries for example.
(It gives email addresses and phone numbers for both, so if you (think) you
know where they are, it's easy to get the right one, but in this networked
age I might not know where they are -- if I can reach them via the net, who
cares ?)  The NIC (& CMU) solution of 4 character alphanumeric IDs seems a
bit impersonal, at best, although I won't complain because I don't have a
better idea....:-)  This is the case that NetFind may be good for; I haven't
seen it so I can't comment.  However, if you don't have a good idea where to
start, I don't see how it can avoid traversing the country on (costly)
backbones -- which is the problem if a lot of people use it.  It seems we're
no closer than when we started, but with a machine generating the finger's
and VRFY's rather than a person.  Sigh....


	
-- 
Drew Dean
Drew_Dean@rain.andrew.cmu.edu
[CMU provides my net connection; they don't necessarily agree with me.]

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      7 May 91 23:03:37 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

->Andrew McRae (andrew@megadata.mega.oz.au) writes:
->[summarized]

->2. LAT doesn't work through routers, but so what.

      Works here!  Must be something wrong with your router.

Merton Campbell Crockett

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 00:33:46 GMT
From:      cantie@acsu.buffalo.edu (Operator, get me the number for 911)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Dial-in SLIP -> Packet Ethernet?

I am looking for something that will allow me to perform the following 
(and please tell me if I am barking up the wrong tree here :-):
	
	-  Using a dial-in line I wish to provide a remote system runnig
	   SLIP on a phone line to have access to the campus Internet (TCP/IP).
	   The type of setup I am looking for is:

		-  9600 modem line on a PC/AT type system using either a 
		   3C501 or a 3C503 running with a packet driver loaded at
		   0x7e. 

	-  It should simply allow blind conversion of the SLIP to TCP/IP.

What I wish to accomplish is a way for either a Macintosh running a SLIP 
version of Telnet or a PC with the same to be able to dial-in and then have
the same access to the Internet that it would have if it was connected
directly to it.

Thanks much for your time...

	Bruce N. Cantie
-- 
Bruce Cantie          Internet:  cantie@cs.buffalo.edu    | I speak only for me
LAN Systems           Internet:  bruce@fs1.cc.buffalo.edu | U.B. has nothing to
301A Computing Center BITNET:    LSBRUCE@UBVM.BITNET      | do with it.
(716) 636-3817        BITNET:    LSBRUCE@UBVMS.BITNET     |

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 01:11:39 GMT
From:      kendaly@netcom.COM (Kendal Yee)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP with Arcnet

I am looking for a software that will provide tcp-ip protocol with the
arcnet card.  If anyboday have any information, please send me a mail.
my mail address is kendaly@netcom.COM.  Thanks.

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 03:15:44 GMT
From:      pete@cosc.canterbury.ac.nz (Pete Glassenbury)
To:        comp.protocols.tcp-ip
Subject:   Slip wanted for 88K


Does anyone know of an implementation of serial line IP for the
Data General Aviion ( an 88K machine running DG's unix DGUX)?
Has anyone ported it ??

Please mail and I'll summarize -- Thanks
Peter Glassenbury			Computer Science dept.
pete@cosc.canterbury.ac.nz		University of Canterbury
					New Zealand
--
Peter Glassenbury			Computer Science dept.
pete@cosc.canterbury.ac.nz		University of Canterbury
					New Zealand

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 03:20:11 GMT
From:      HENRYM@SACWMS.MP.USBR.GOV
To:        comp.protocols.tcp-ip
Subject:   Need info on NQS software


	I have been asked to research the NQS protocol for spooling
jobs across the network.  The only reference that I have been able to
dig up is that it uses port 607 (from ASSIGNED-NUMBERS.TXT).  It is my
understanding that this protocol is used by CDC machines.

	What we would like is a copy of code if one is available.  C is
preferred, but we are not fussy.  If that is not possible, a copy of the
specification would suffice.  Any and all help will be appreciated.

-HWM
----------
Henry W. Miller
Assistant Systems Manager, Mid Pacific Region
U.S. Bureau of Reclamation
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
Inet:	"henrym@sacwms.mp.usbr.gov"
BITNET:	"hmiller@scu"
UUCP:	"...caldwr!sanj!henrym"

"Bad guys abuse public land, good guys save it."

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 04:22:58 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Summary of SMTP SEND, et al commands


Here are the systems that support the SEND and friends command:
	TOPS-20
	Multics
	FTP Software
	Symbolics lisp machine
	TGV's Multinet for VMS
	Some people sent me pointers to patched sendmails

however, most preduction unix systems don't support it.  Many thanks
to all those who replied.

Warner
-- 
Warner Losh		imp@Solbourne.COM
God is an Iron

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 04:37:15 GMT
From:      ade@clark.edu (Adrian Miranda)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   BIND for System V streams/TLI

Has anyone done a port of BIND to a system V machine with streams/TLI
based tcp/ip?  The version on ucbarpa has support for System V, but
still expects a working sockets library, which ESIX does not have.

Thanks in advance,
Adrian Miranda
uunet!clark!ade  or  ade@clark.edu

PS: If anyone is interested, I have ported smail 3 and nslookup to
    ESIX.

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 08:41:55 GMT
From:      bellamy@covax.commerce.uq.oz.au
To:        comp.protocols.tcp-ip
Subject:   Re: Port Numbers & NCSA

In article <9105080326.AA20629@ucbvax.Berkeley.EDU>, JLENNIE@VM.UOGUELPH.CA (Jim Lennie) writes:
> 
>   Does anyone know if there is a way to configure NCSA Telnet on a Mac, so
>   that it will request a telnet connection on a specified port other than the
>   default?
> 
>   Thanks,
>   --
>   John Alsop
> 
> Try starting up the telnet program without specifying the host you want to
> connect to. Next, type ALT-A to open a new session then enter the hostname or
> IP address followed by the port number. That is how I do it with the version
> running on my IBM PC.

Easier still just include the port number in the session name field of the 
open connection dialog.  Eg. ucbvax.Berkeley.EDU 119   will open the 
connection on port 119 at host ucbvax.Berkeley.EDU

-- 
David E. Bellamy        Email: bellamy@covax.commerce.uq.oz.au
Dept. Commerce, University of Queensland, St. Lucia, AUSTRALIA

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 09:40:36 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:

>->2. LAT doesn't work through routers, but so what.
>      Works here!  Must be something wrong with your router.

Are you sure?   That is, are you sure you're not bridging LAT?
If so, you can say 'works through a bridge' but not 'works
through a router'.

kre

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 10:15:56 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

The News Manager)
Nntp-Posting-Host: na
Reply-To: donp@novell.com (don provan)
Organization: Novell, Inc., San Jose, California
References: <1991May2.012159.23962@megadata.mega.oz.au>
Date: Thu, 2 May 1991 19:34:50 GMT

In article <1991May2.012159.23962@megadata.mega.oz.au> andrew@megadata.mega.oz.au (Andrew McRae) writes:
>My real question is: If the concept of LAT is good enough, and the
>advantages great enough, why doesn't someone define a protocol that
>does the same job, but is part of TCP/IP; in other words a local telnet
>protocol.

From my point of view, networking is rapidly moving away from the
primitive terminal-to-mainframe connectivity that spawned LAT.  It
makes little sense to develop an optimized protocol for what is now an
obsolete application.

When LAT was developed, DEC and its customers had a very large
investment in terminal-to-mainframe technology.  That made LAT
economical, both finacially, because it saved money for customers by
allowing them to get more mileage out of their terminals, and
technologically, because there were enough terminal-to-mainframe
packets flying around to allow session multiplexing optimizations.

I don't think there's ever been any where near as much terminal
traffic on TCP/IP networks, and there's destine to be much less in the
future.  Consequently, a LAT-like protocol in the TCP/IP suite
wouldn't be cost effective when compared to telnet.
							don provan
							donp@novell.com

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 12:21:47 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Connecting to the Internet

In article <1991May2.164911.17750@searchtech.com> mra@searchtech.com
(Michael Almond) writes:  So what areas does NEARNet cover?

NEARNet is the New England Academic and Research Network, and covers the
New England area. 

Alex McKenzie
  

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 12:52:52 GMT
From:      gd@aprm (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   accessing DOS disks from unix

Text: 

Several postings in this thread have explained how to use SOSS or
Netware to mount an MS-DOS disk under NFS.  We use Intel's OpenNET, and
it can do the same thing.

There are some additional factors to be concerned with, beyond network
connectivity.  MS-DOS and UNIX do not store text files the same way.  An
MS-DOS text file terminates lines with CRLF, whereas UNIX just uses LF. 
More significant is the case where the data on the PC requires
specialized application software to be useful.  In particular, someone
said they wanted to be able to access CD-ROMs, and those use special
reader programs. 

I suppose you could mount the PC's CD-ROM, then launch an MS-DOS
emulator, and from there run the reader software, but then you loose
most of the benefits of using UNIX.
 
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                      |
                                        /
 
        Democracy is based upon the conviction
        that there are extraordinary possibilities
        in ordinary people.
                  Harry Emerson Fosdick

 --- End of Message -----------

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 14:23:16 GMT
From:      mcneill@udel.edu (Keith McNeill)
To:        alt.security,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   SUMMARY: Need firewall telnet/ftp gateway

Many people asked for a summary on the responses that I got on my proxy
telnet/ftp query.

First my original note:

]
]
]We are setting up an internet gateway at work.  Currently, we're going
]to set it up as a firewall system.  A problem with this setup is that
]anybody in the company who wants to telnet/ftp to the internet has to
]have an account on the firewall system, an administration nightmare.  I've
]heard about some software that you put on the gateway that acts as a
]telnet/ftp intermediary.   The software consists of a modified telnet/ftp
]for inside our network which connects to intermediary software that is put
]on the firewall gateway.  The intermediary software then makes the telnet/ftp
]connections out on the internet.
]

Now the "answer":

If your firewall is a Sun & you have lots of Sun's in your organization then
you are all set.  Sun has a (or is about to release) a Consulting Special
called Itelnet/Iftp which is a proxy telnet/ftp server.  Call your local Sun
office for information on "Consulting Specials".  If you don't have Sun's I
heard from somebody at Sun that the consulting group ***may*** be willing to
port...for a price.

Some people mentioned AT&T's paper on their Internet gateway.  I still haven't
been able to relocate my copy but if memory serves me I think that their
setup is specific to AT&T & their Datakit network.  Please correct me if I
am wrong.

Many, many people mentioned using a router (most people mentioned Cisco) to
do packet filtering.  A couple people had an interesting firewall/router
debate going on for awhile, but I don't think that there is a correct
answer.  As with most computer/network configurations it all depends on the
structure & people of your company/organization as to which is the better
solution.

If you decide to go the router "route" some people suggested that among the
obvious ports to restrict that you restrict UDP packets to block Sun RPC's
(including yellow pages & NFS) and TCP port 6000 to block X11.

There is also some software that enables you to disallow connections from
certain hosts/domains at certain ports.  You can get it via anonymous ftp at
cert.sei.cmu.edu in pub/network_tools.

Many thanks to:

Richard Cower <cower@csli.stanford.edu>
mo@messy.bellcore.com
Bill Lewandowski <wrl%wdl51@wdl1.wdl.loral.com>
"Jerry M. Carlin" <jmcarli@srv.pacbell.com>
"Timothy G. Smith" <tgsmith@east.sun.com>
smb@ulysses.att.com
William Clare Stewart <wcs@erebus.att.com>
Michael O'Connor <mikeoc@boilermaker.west.sun.com>
"Anthony A. Datri" <datri@concave.convex.com>
"Randal L. Schwartz" <merlyn@iwarp.intel.com>
"Kenneth R. van Wyk" <krvw@cert.sei.cmu.edu>
Tp Brisco <brisco@pilot.njin.net>
Brent Chapman <brent@napa.telebit.com>
fec@mhuxo.att.com
David Pipes x4552 <srg!dpipes@uunet.uu.net>
David Richardson <cs4304ak@cse.uta.edu>
Sean Kelly <kelly@jupiter.nmt.edu>
"Ted R. Doty" <dotytr@nscultrix1.network.com>
Chris Sherman <sherman@unx.sas.com>
David Neal <uunet!sun.rice.edu!dan@cbmvax.uucp>
rodk@germania.corp.sun.com
Phil Meyer <phil@arco.com>


and all the other people who responded.  I got close to 40 responses within
24 hours!  Once again the Internet proves its worth!!


Keith

--
    Keith McNeill                 |   1131 North Broom Street
    mcneill@udel.edu              |   Wilmington, Delaware, 19806
                                  |   (302) 427-0101

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 14:38:06 GMT
From:      jbreeden@netcom.COM (John Breeden)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

In article <9105072303.AA00610@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
>->2. LAT doesn't work through routers, but so what.
>
>      Works here!  Must be something wrong with your router.
>

Wow, Puff The Magic Router !!! (-: I think you mean it works through a
bridge (and that's prob what you've got). LAT has no network layer (it's
just a MAC frame stuffed with data) and therefore has no info in the
datagram that will allow routing.

-- 
 John Robert Breeden, 
    jbreeden@netcom.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."

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 15:08:29 GMT
From:      jackson@bdrc.bd.com (Gene Jackson)
To:        comp.protocols.tcp-ip
Subject:   SMTP POP Sever wanted

We are in need of a POP server in order to provide SMTP mail to MAC users in

our building from a SUN server.  I have seen that there are several public

domain servers available via FTP but we do not have direct internet access.  Is

their a list server available that would have source code for either a POP2 or

POP3 server available by email?  Thanks for any assistance.



Gene Jackson

jackson@bdrc.bd.com

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 15:45:32 GMT
From:      blamer@frith.egr.msu.edu (Tracey L Blamer)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   VMS TCP/IP Alternatives


I am the administrator of a VAX 6310 used mainly for medical records in a 
veterinary hospital.  I appologize if I am posting this inappropriately.

Currently, we are funning FUSION TCP software, but with the upgrade 
to VMS 5.4 and our support contract with IDX (the company from which
we got both the VAX and FUSION) FUSION has been nothing but problems.  
So, I am look at alternatives to FUSION.  

I know of some other VMS TCP software (Carnige Mellon, Multinet, Wolongong,
TCPware) and I have requested information from the companies, but I really
want to know what other VMS administrators recommend.  What do you like/dislike
about the software you are running.  Pros/Cons type of stuff.  I'd also like 
to know where you got your TCP software from (Carnige Mellon is free, I 
understand, but how do I get it; what is the phone number of Multinet; etc.).
Feel free to include comments on FUSION.

Please e-mail responses to me, rather than posting.  If there is enough
interest, I will post the highlights of these mailings.  
Thanks in advance for your time.


Tracey Blamer

VAX Manager                       blamer@frith.egr.msu.edu
Veterinary Teaching Hospital      tracey@vthnw.cvm.msu.edu
Michigan State University         TLB%VTHVAX.decnet@decmail.msu.edu

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 15:55:09 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

In article <9105072303.AA00610@WLV.IMSD.CONTEL.COM>, mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
> ->Andrew McRae (andrew@megadata.mega.oz.au) writes:
> ->[summarized]
> 
> ->2. LAT doesn't work through routers, but so what.
> 
>       Works here!  Must be something wrong with your router.
 
I suspect you have one of the new generation of brouters (bridge/routers).
That's what we use here. (cisco) It is configured to route selected, routable
protocols like IP and DECnet and bridge any others with filters to control
things in finer detail.

I can state absolutely that LAT is NOT routable, but that doesn't mean that it
won't work through a brouter. cisco even has special compression software just
for LAT over low-speed links.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov		(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything. Especially
anything gnu.

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 16:54:40 GMT
From:      graham@netwrx1.NW1.COM (James M. Graham)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   SNMP on AT&T 3B2 with WIN/3B


Does anyone know of a commercial product which performs SNMP client services
on an AT&T 3B2 SVR3.2 box running the Wollongong TCP/IP software WIN/3B 3.0?
Also, does anyone know of any public-domain SNMP offerings which have been
ported to my platform?

Thanks

==============================================================================
  James M. Graham		Usenet:	  uunet!netwrx1!graham
  Open Networks, Inc.		Internet: graham%netwrx1@uunet.uu.net
  Reston, Virginia		Voice:    (703) 648-0013

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 17:11:03 GMT
From:      woods@ncar.ucar.edu (Greg Woods)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute and SunOS 4.1.1

After hearing from several people who said they had copied over binaries
from older versions of SunOS, I did this, and it worked fine. Others claimed
to have successfully compiled traceroute sources under SunOS 4.1.1, but I
still get the "protocol not supported" message when I do this. At any rate,
by using the old binaries my problem is solved, for the moment. Thanks to
all who responded.

--Greg

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 18:14:59 GMT
From:      prasert@seas.gwu.edu (You Got the RIGHT one! Baby!!)
To:        comp.protocols.tcp-ip
Subject:   suip.HELP

From SEAS Computing Facilty at George Washington University,

We have the su/ip version 3.01 running with Western Digital Ethernet
card model 800E. Recently Western Digial released a new Ethernet card model,
which is WD Ethernet card plus Elite Lan Adapter. Unfortunately, It can't
run with su/ip 3.01.
	
Stanford University doesn't support su/ip anymore, so do you 
know who are supporting?
	
Any suggestions would be appreciated.
 
Please send E-mail to	mpw@seas.gwu.edu

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 20:26:21 GMT
From:      ted@NADC.NADC.NAVY.MIL (T. Calkins)
To:        comp.protocols.tcp-ip
Subject:   DEC DSB32-M WAN Board..


 
Hi,
     I realize that this is NOT a TCP/IP question, but with the wealth of
experiences and knowledge of this list I can't resist asking.  Is there
anyone who has or is aware of the DEC DSB32-M board (and its DEC-provided 
driver) running under the ULTRIX Operating System on a DEC VAX 8800 series 
computer?
     Please respond directly to me.
     Thanks, in advance, for any inputs,
 
                        Ted Calkins, Naval Air Development Center
                        ted@NADC.NADC.NAVY.MIL

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 21:19:30 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   CD-ROMs under Interactive

Not quite sure why this is in tcp-ip list, but still ...

>      This question is of general interest.  If anyone knows a good answer,
> PLEASE respond to the newsgroup!

I agree - I'm having trouble too!

> We're trying to use a CD-ROM reader under Interactive Unix 2.2 without
> much success.  

I'm having no success at all.

> ISC doesn't know how to mount ISO-9660 CD-ROMS as Unix file-systems 

I'm not even getting this far. My setup is Intel 403E (33MHz 486), 16M RAM,
with two 1.2G SCSI, SCSI WangDAT and SCSI CD-ROM hung off Adaptec 17xx (EISA)
controller, with Interactive. The SCSI-Express software offered by the 
supplier doesn't work and they don't seem to have any real ideas about what 
to do next. I certainly have not tried using the VP/IX (a) because I have
heard "bad things" about VP/IX, (b) because I did not buy a UNIX box to have
it pretend to be a PC, and (c) because I want to mount the CD-ROM as a 
single 600MB partition (or, I accept, three or four, if the 2E16 - 2 inode
maximum rears its ugly head).

> Actually, I believe SCO Unix will also allow High Sierra format
> CD-ROMS to be mounted as file systems.  It has been a long time since
> I tried this, but I think it worked just fine.  Of course, it is
> probably too late since you already bought Interactive, but others
> might benefit from this info.

Annoyingly, I have a SCO box as well, but it's only a COMPAQ and does not
have SCSI at all. A *real* solution for Interactive is preferred.

All net wisdom welcome ...

Andrew
-- 

+----------------------------------------------------------------------------+
|  Andrew Hardie                                             ash@omega.uucp  |
|  London, England                                      ukc!cctal!omega!ash  |
+----------------------------------------------------------------------------+

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 21:23:03 GMT
From:      cws@deimos.caltech.edu (CURT SEELIGER)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP on VAXi(VMS) & Suns (unix)  - books

Folks,
	I'm hoping to find a good tcp/ip reference text.  We're running
MultiNet on our Vaxs to talk tcp/ip to our Suns and an offsite internet 
gateway.  Someone suggested "Internetworking with TCP/IP: Principles,
Protocols, and Architechture" by D. Comer.  Has anyone used this text - 
and would it be usable in a primarily VMS environment?  Might there be
something better?

	Reply to me directly, and I will summarize to the net if sufficient
responses are made.  Thanks

		Curt Seeliger
		cws@deimos.caltech.edu
		cur@caltech.bitnet

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      8 May 91 22:06:10 GMT
From:      jeg@zorch.SF-Bay.ORG (John E. Girard)
To:        comp.protocols.tcp-ip
Subject:   Telnets that 'do' 3270


IBM's telnet with the RS/6000 does a real nice 3270 terminal
emulation.  How many other Telnets are available that can do
this?

THanks,

John Girard
jeg@zorch.SF-Bay.ORG


-- 
John Girard   New Science Associates, Inc.  jeg@zorch.SF-Bay.ORG
VOICE: 415-968-3324 ************************** FAX: 415-968-0862

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      9 May 91 02:42:01 GMT
From:      chris@ec.uwa.oz.au (Christoph Uloth)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

andrew@jhereg.osa.com (Andrew C. Esh) writes:

>Lately I have been reviewing SNMP managers and agents. I have also found
>the related RFCs. What I have not found is the newsgroup where SNMP and
>similar net management protocols are discussed. Do we need to create one?
>-- 

I would welcome a net management protocols etc group....

--
Christoph Uloth      Division of Commerce Economics Law & Education
Systems Networks Officer            University of Western Australia
Phone: +61-9-380 2198 || +61-9-364 7181         Fax: +61-9-380 XXXX
email: chris@ec.uwa.oz.au                                       :-)

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      9 May 91 13:34:43 GMT
From:      dwight@ibmpcug.co.uk (Dwight Ernest)
To:        comp.protocols.tcp-ip,connect.audit
Subject:   NetBlazer Users' Mailing List?

I'd be very interested to learn of any existing mailing list for
users of Telebit's NetBlazer. In the absence of one, I'd be interested
in either asking Telebit to support a list reflector for its discussion,
or in maintaining such a list reflector myself.

Is there already such a list?

If not, I'd like to hear from other NetBlazer users to gauge its
viability and to provide some mutual support.

Regards,
		--Dwight Ernest
		  Hyphen Editorial Systems Ltd.
		  Diss, Norfolk, England
			dwight@hyphen.co.uk
-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      9 May 91 16:39:50 GMT
From:      hirchert@ncsa.uiuc.edu (Kurt Hirchert)
To:        comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   Re: Telnet Port Numbers - NCSA Telnet

In article <1991May3.000901.10215@seachg.uucp> jalsop@seachg.UUCP (John Alsop) writes:
>Does anyone know if there is a way to configure NCSA Telnet on a Mac, so
>that it will request a telnet connection on a specified port other than the
>default?
>
>Thanks,
>-- 
>John Alsop
>
>Sea Change Corporation
>6695 Millcreek Drive, Unit 8
>Mississauga, Ontario, Canada L5N 5R8
>Tel: 416-542-9484 Fax: 416-542-9479
>UUCP: ...!uunet!attcan!seachg!jalsop

For one-shot connections, you can just type the port number after the machine
name in the Open Connection... dialog.  For recurring usage, there is a
port= parameter that can be used in the config.tel file.  You can apply it
either to a specific host or to the "default" host.  See chapter 8 of the
NCSA Telnet manual for more details.
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      9 May 91 20:34:20 GMT
From:      john@loverso.leom.ma.us (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: LAT vs telnet

In an article, Shane Davis talks about the Annex/Encore Multimax "call/RDP"
protocol for "offloading" the host by running the UNIX tty driver on the Annex.
> The protocol is proprietary, like LAT, but is done via TCP/IP, unlike LAT.

Thankfully, this belish is all by dead and buried.  Whereas the idea might
have been good, the implementation was horrible and very expensive (espeically
on the Annex end!).  And, whereas cooked mode operations may have been cheaper
on the host, in cbreak/raw mode (i.e., editting, etc) the overhead was much
greater.  The protocol was actually RPC based (over UDP), btw.  It never
performed well and didn't provide "full UNIX tty semantics".  It was an
endless source of headaches.

The only good thing was that the protocol was kept proprietary (it still is,
to Encore) and thus never spread anywhere.  This means it is enjoying a
slow, easy death (too easy by my standards).

John

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      9 May 91 21:21:00 GMT
From:      lware@doctor.attmail.com
To:        comp.protocols.tcp-ip
Subject:   SNMP for SYSV on 3B2

Hi folks,
	Anyone know where I could get a PD or low cost version of the
SNMP manager software for UNIX SYSV R3.2.X running on 3B2's?
Binary or source is fine, I'm willing to pay copying costs for a tape.
Or if someone would be so kind as to pack/compress and E-mail it.
Even a uucp path to somewhere would do, (T/B 19.2 I hope :-).
I don't have direct internet access so an FTP site won't help much.
I do have access to uunet if it's currently available through them.

Thanks in advance...

Larry Ware
AT&T PBS Project
warelr@attmail.att.com OR
attmail!doctor!lware
(407)660-7709

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 02:57:43 GMT
From:      mah@nestroy.wu-wien.ac.at (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   TOS queuing or sorting by datagram size


How effective is 'sorting by datagram size' as a means of preferring
interactive traffic over say, ftp? I can imagine this gets keystrokes
through fast, but the responses which are typically larger would'nt get
preferred treatment.

Given that most host implementations  dont fill in the TOS field in 
a usable manner, what's the most simple and effective approach? Looking at
the port numbers at the gateway and queuing telnet and rlogin segments before
batch style traffic? 

Should one  use a single queue, and sort in segments according to a strategy,
or use several queues with different priorities?

-michael
-- 
Michael Haberler	mah@wu-wien.ac.at, mah@awiwuw11.bitnet
University of Economics and Business Administration 
Augasse 2-6,  A-1090 Vienna, Austria		
Tel: +43 (222) 313-36 x4796 (9-18 CET) 	Fax 347-555

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 05:48:16 GMT
From:      kory@avatar.com (Kory Hamzeh)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP, SNMP, and Bridges


If I have a TCP/IP stack running on a MAC layer bridge to support SNMP, must the
ethernet interfaces have unique IP addresses?

What if the device was an IP bridge or router?

Thanks,
Kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 06:26:50 GMT
From:      fair@APPLE.COM ("Erik E. Fair", Your Friendly Postmaster)
To:        comp.protocols.tcp-ip
Subject:   Case of the Replicated Errors: An Internet Postmaster's Horror Story


This Is The Network: The Apple Engineering Network.

The Apple Engineering Network has about 100 IP subnets, 224 AppleTalk
zones, and over 600 AppleTalk networks. It stretches from Tokyo, Japan,
to Paris, France, with half a dozen locations in the U.S., and 40
buildings in the Silicon Valley. It is interconnected with the Internet
in three places: two in the Silicon Valley, and one in Boston. It
supports almost 10,000 users every day.

When things go wrong with E-mail on this network, it's my problem.
My name is Fair. I carry a badge.

[insert theme from "Dragnet"]

The story you are about to read is true. The names have not been
changed so as to finger the guilty.

It was early evening, on a Monday. I was working the swing shift out of
Engineering Computer Operations under the command of Richard Herndon.
I don't have a partner.

While I was reading my E-mail that evening, I noticed that the load
average on apple.com, our VAX-8650, had climbed way out of its normal
range to just over 72.

Upon investigation, I found that thousands of Internet hosts were trying
to send us an error message. I also found 2,000+ copies of this error
message already in our queue.

I immediately shut down the sendmail daemon which was offering SMTP
service on our VAX.

I examined the error message, and reconstructed the following sequence
of events:

We have a large community of users who use QuickMail, a popular
macintosh based E-mail system from CE Software. In order to make it
possible for these users to communicate with other users who have
chosen to use other E-mail systems, ECO supports a QuickMail to
Internet E-mail gateway. We use RFC822 Internet mail format, and RFC821
SMTP as our common intermediate E-mail standard, and we gateway
everything that we can to that standard, to promote interoperability.

The gateway that we installed for this purpose is MAIL*LINK SMTP from
Starnine Systems. This product is also known as GatorMail-Q from
Cayman Systems. It does gateway duty for all of the 3,500 QuickMail
users on the Apple Engineering Network.

Many of our users subscribe, from QuickMail, to Internet mailing lists
which are delivered to them through this gateway. One such user, Mark
E. Davis, is on the unicode@sun.com mailing list, to discuss some
alternatives to ASCII with the other members of that list.

Sometime on Monday, he replied to a message that he recieved from the
mailing list. He composed a one paragraph comment on the original
message, and hit the "send" button.

Somewhere in the process of that reply, either QuickMail or 
MAIL*LINK SMTP mangled the "To:" field of the message.

The important part is that the "To:" field contained exactly one "<"
character, without a matching ">" character. This minor point caused
the massive devastation, because it interacted with a bug in sendmail.

Note that this syntax error in the "To:" field has nothing whatsoever
to do with the actual recipient list, which is handled separately, and
which, in this case, was perfectly correct.

The message made it out of the Apple Engineering Network, and over to
Sun Microsystems, where it was exploded out to all the recipients of
the unicode@sun.com mailing list.

Sendmail, arguably the standard SMTP daemon and mailer for UNIX,
doesn't like "To:" fields which are constructed as described. What it
does about this is the real problem: it sends an error message back to
the sender of the message, AND delivers the original message onward to
whatever specified destinations are listed in the recipient list.

This is deadly.

The effect was that every sendmail daemon on every host which touched
the bad message sent an error message back to us about it. I have
often dreaded the possibility that one day, every host on the Internet
(all 400,000 of them) would try to send us a message, all at once.

On monday, we got a taste of what that must be like.

I don't know how many people are on the unicode@sun.com mailing list,
but I've heard from Postmasters in Sweden, Japan, Korea, Australia,
Britain, France, and all over the U.S. I speculate that the list has
at least 200 recipients, and about 25% of them are actually UUCP sites
that are MX'd on the Internet.

I destroyed about 4,000 copies of the error message in our queues here
at Apple Computer.

After I turned off our SMTP daemon, our secondary MX sites got whacked.
We have a secondary MX site so that when we're down, someone else will
collect our mail in one place, and deliver it to us in an orderly
fashion, rather than have every host which has a message for us jump on
us the very second that we come back up.

Our secondary MX is the CSNET Relay (relay.cs.net and relay2.cs.net).
They eventually destroyed over 11,000 copies of the error message in
the queues on the two relay machines. Their postmistress was at wit's
end when I spoke to her. She wanted to know what had hit her machines.

It seems that for every one machine that had successfully contacted
apple.com and delivered a copy of that error message, there were three
hosts which couldn't get ahold of apple.com because we were overloaded
from all the mail, and so they contacted the CSNET Relay instead.

I also heard from CSNET that UUNET, a major MX site for many other
hosts, had destroyed 2,000 copies of the error message. I presume that
their modems were very busy delivering copies of the error message
from outlying UUCP sites back to us at Apple Computer.


This instantiation of this problem has abated for the moment, but I'm
still spending a lot of time answering E-mail queries from postmasters
all over the world.

The next day, I replaced the current release of MAIL*LINK SMTP with a
beta test version of their next release. It has not shown the header
mangling bug, yet.


The final chapter of this horror story has yet to be written.

The versions of sendmail with this behavior are still out there on
hundreds of thousands of computers, waiting for another chance to bury
some unlucky site in error messages.

Are you next?

[insert theme from "The Twilight Zone"]

	just the vax, ma'am,

	Erik E. Fair	apple!fair	fair@apple.com

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 08:51:47 GMT
From:      aets-kja-a-ao3@ansbach-emh1.army.mil ("Thomas F. Pockberger")
To:        comp.protocols.tcp-ip
Subject:   traceroute ????

I know this is a "silly" question but still ....

Can somebody explain me what traceroute is and how it works?

Please don't revere me to the SA here, she doesn't know.

Thanks for all your kind help.

Pocky

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 10:02:49 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: traceroute ????

In article <9105100850.AA13983@ucbvax.Berkeley.EDU> aets-kja-a-ao3@ansbach-emh1.army.mil ("Thomas F. Pockberger") writes:
>I know this is a "silly" question but still ....
>Can somebody explain me what traceroute is and how it works?
>Please don't revere me to the SA here, she doesn't know.

System administrators should always be revered :-)

I won't refer you to your SA, but I will refer you to the man page.  The
one we have contains a fairly complete description of how it works.

If you don't have the man page, send me mail and I'll forward it to you.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 12:44:05 GMT
From:      steve@UMIACS.UMD.EDU (Steve D. Miller)
To:        comp.protocols.tcp-ip
Subject:   Re:  Case of the Replicated Errors: An Internet Postmaster's Horror Story


   I had this same sort of error happen to me in the early days (only 500 or
so people on the list, thank goodness) of the Sun-Nets mailing list.  The
resulting errors trashed a VAX 8600 here for twelve hours or so.  In self-
defense, I added a hack to the software I use to run the Sun-Nets list:  it
checks several important header lines to be sure that they aren't too badly
botched, and if it detects an error it bounces the mail to the list
maintainer with a note that says, "the header is messed up, you'd better
take a look at this."  From what Erik said, it sounds like my software would
have kept this problem from happening.  (If someone can give me a copy of
the headers off the original mail, I can check this out.)

   The software also:

	- sets the Sender:  line and the from address in the envelope to say
	something reasonable

	- optionally trims Received:  lines (good for times when a message
	takes 9 hops to come in and another 9 to make it back out, and thus
	would otherwise trigger sendmail's fake-o loop detection)

	- allows an optional header and/or footer to be added to the body of
	the message

	- has some limited smarts (shamelessly borrowed from the mail2news
	program) that attempts to filter out ``please add/delete me'' mail
	mistakenly sent to the list readership rather than to the
	administrivia address.

   I'm sure it's not perfect (the administrivia filter is too trusting, and
in particular doesn't catch LISTSERV stuff), but if you want it, anonymous
FTP out to ftp.umiacs.umd.edu and grab pub/distribute.tar.Z.  The man entry
should be enough to get you started.  Distribute should be fairly portable
(but it will require hacking to be used with something other than sendmail).
If you make changes to this software, I'd be interested in seeing them.

	-Steve

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

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 12:47:37 GMT
From:      mmorse@Z.NSF.GOV ("Michael H. Morse")
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: Escape sequences and Nagle

To paraphase my original question:  Why can't my system tell the
difference between 1) an escape sequence and 2) just an escape key,
typed by some people who use my system?  For certain people who Telnet
to my system (fewer than 5%), escape sequences are interpretted as just
an escape.

Leo McLaughlin put it most succinctly:

| Bad news.  As more and more well behaved TCPs are fielded, you will see
| systems exhibiting this behavior become more common.  What you are
| running into is a combination of Nagle's algorithm for TCP writes and a
| telnet which is sending the escape sequence character by character to
| the network.  Basically, Nagle's algorithm says 'Don't clog the network
| the network with little packets.  If you have data pending
| acknowledgement (in your case the ESC) and don't have a MTU-full of
| data queued (in your case the rest of the escape sequence) don't send
| anything.'
| 
| So, not only is the telnet breaking the escape sequence into different
| packets, the TCP is saying don't send the rest of the sequence until the
| ESC is acknowledged.

Bill Westfield filed this report from cisco:

| Quite a while ago, cisco proudly implemented this useful sounding
| algorithm, and prompt started running into the most obscure problems
| with Function keys. 
| ...
| The users were not happy.  The Nagle algorithm is now optional on cisco
| terminal servers.

James B VanBokkelen reported that FTP Software experienced a similar
problem with their Telnet product after implementing the Nagle
algorithm.

The writers of RFC 1122 (Requirements for Internet Hosts) were
apparently aware of this kind of problems, because they gave SHOULD
status to the Nagle Algorithm, and MUST status to letting an application
turn it off.  However, turning off the Algorithm, assuming the
implementor has allowed it to be configured, is not really a solution for
my users, since many of them are quite naive about computers in general
and Telnet and TCP/IP in particular.

Based on the responses I received, I would suggest the following
additions to RFC1122/1123:

 1. Where a terminal emulator is running on a workstation directly
    on the Internet, the system SHOULD ensure that escape sequences are
    transmitted in a single TCP packet.  This is the solution FTP
    software implemented for their Telnet, thus preserving the Nagle
    Algorithm.  I'm not too sure how easy this is to implement on other
    systems.  FTP has a problem in that other terminal emulators can
    run on top of their Telnet, in which case Telnet sees only a
    character at a time, and probably Nagles them.  What makes me
    optimistic is that 95% of workstations seem to be working this way
    now (but perhaps they don't Nagle.)

 2. For terminal servers, escape sequences should be
    exempt from the Nagle algorithm.  Preferably, they should be
    transmitted in a single packet, but probably sending them off
    as fast as possible would also work.  Unfortunately, I have
    a feeling that most terminal server implementors will choose simply
    not to Nagle (or let their customers configure), thus putting
    you back with the problem Nagle was designed to solve.

This leaves the situation of real terminals connected to hosts, where
the user logs on to the host, and then Telnets to my system.  I don't
really see a good solution for this.  An elegant solution might be to
define the common escape sequences (cursor movement and function keys)
as part of the NVT, but I don't think there would be any enthusiasm for
this, since it would require major changes and most of the excitement
these days seems to be in GUI's and X terminals.

I would remind implementors that RFC1122 says they MUST allow an
application to turn off Nagle.  Does anyone know how this is done in
practice?  I don't think a site configuration option really meets this
requirement, but perhaps I misinterpret the spec.

How about it implementors?  Are these things doable?  I don't think users
will give up their Escape keys without a fight.  These days, even vi (in
most implementations) accepts function keys (escape sequences) and the
Escape key, and uses a timer to distinguish the two.

Thanks again to all that responded:

   Leo McLaughlin, ljm@ftp.com
   Merton Crockett, mcc@wlv.imsd.contel.com
   James VanBokkelen, jbvb@ftp.com
   Lars Poulsen, lars@cmc.com
   Hal Murray, murray@src.dec.com
   Ted Doty, dotytr@nscultrix1.network.com
   Bill Westfield, billw@mathom.cisco.com
   Don Provan, donp@novell.com

--Mike

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 12:54:42 GMT
From:      steinour@cc.gettysburg.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  traceroute ????

Dear Pocky,

Please do me a favor, when you find out send the information to me if
it is not on the list. I would greatly appreciate it....


Thanks,

***********************************************************************
Dave Steinour
Gettysburg College
steinour@gburg.bitnet
steinour@gettysburg.edu

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 15:07:00 GMT
From:      TOMIII@MTUS5.BITNET (Thomas Dwyer III)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   nameserver reverse map?

I'm not quite sure where this should be posted but here goes:

It's a real pain to update two maps for the nameserver (ie - the hosts map
and the reverse map) every time I add a machine, so I wrote a program to
generate the reverse map given the hosts map.  This program isn't the
greatest, but it seems to be working.  My problem is that now I want to
split the maps into several files, one per domain.

The question is, has someone already written a program to generate multiple
reverse maps from multiple host maps?  Is there an FTP site with nameserver
utilities?   Any pointers would be appreciated.  :-)


Thomas Dwyer III                        Email: tomiii@mtu.edu
Network Programmer                             tomiii@mtus5.BITNET
Computing Technology Services           Voice: (906) 487-2110
Michigan Technological University       Fax:   (906) 487-2787

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 20:22:11 GMT
From:      derrick@zaphod.UUCP (Derrick Nagy)
To:        comp.protocols.tcp-ip
Subject:   TCP flow control query


I have a very fundamental question.  We had a tcp package that exhibited
what I believe to be a variety of SWS.  So we changed it.  The new version
of the package seems to have problems, too, however.  The symptoms can be
seen, for example, when we try to list a file (via a TELNET interface).  The
data will intermittently pause for a few seconds on one of the hosts (pausing
host), and will pause and stay paused until a character is entered on the
receiving terminal on another host (stalling host).

The problems seem to lie at the TCP level when the receiving end advertises
a zero window.  It does not appear to turn flow control on again on its own
initiative.  The pausing host will send a datagram with one byte of
garbage data as a probe after a few seconds, to which the receiving end
responds with an ACK with the current window size (usually wide open).  The
stalling host only sends ACKs, and the receiving end never responds to them.

Questions:  are the ACKs from the stalling host probes?  Are they valid
probes?

What criteria should the receiving end use to advertise when its window opens?

We have read all of the TCP RFC's that we can find, and a couple of texts
besides (eg. Comer's), and cannot find anything that specifies the proper
means of flowing on data again.  

-- 
    |\/\/|	Derrick Nagy,  Mgr., Software Engineering, Develcon Electronics
_|\ |    | /|_  Ltd., 856-51 St. E, Saskatoon, SK. Canada,  S7K 5C7
>_ DEVELCON _<       "Innovative High-Performance Internetworking Systems"
  >________<    derrick@zaphod.uucp | Ph: (306) 931-1388 | Fax: (306) 931-1386

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 20:48:39 GMT
From:      kgo@comm.wang.com (Kirk Olsen)
To:        comp.protocols.tcp-ip
Subject:   Incrementing sequence number

Can anyone tell me definitively whether or not the sequence number should
be incremented to create the acknowledgement number when acknowledging
the final FIN of the three way close?


-- 
Kirk                    WANG LABS                  kgo@comm.wang.com
(508)967-2076  in beautiful Lowell Massachusetts   uunet!comm.wang.com!kgo

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 21:10:52 GMT
From:      jim@crom2.uucp (James P. H. Fuller)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs,alt.cd-rom
Subject:   Re: CD-ROMs under Interactive


ash@omega.UUCP (Andrew Hardie) writes:

> Not quite sure why this is in tcp-ip list, but still ...

    The thread was started by someone asking a networking question: is
it possible to have a DOS machine act as a file server and have a Unix
box as client?  Things are usually done the other way around, after all.
The need would arise if you have a peripheral like a CD-ROM that is
supported by DOS but is not supported by your flavor of Unix.  Comp.
protocols.nfs and comp.protocols.tcp-ip seem like likely places to pick
up leads on a question like this. 


> > We're trying to use a CD-ROM reader under Interactive Unix 2.2 without
> > much success.  
>
> I'm having no success at all.
>
> > ISC doesn't know how to mount ISO-9660 CD-ROMS as Unix file-systems 

    Interactive is supposedly working on a driver to support ISO-9660
filesystems and make them mountable, but this isn't even promised Real
Soon Now .... just Someday.  I need those files off that CD-ROM before
then (assuming then ever arrives at all) so I'm investigating other
ways to access the drive other than direct mounting under Unix.
    ONE possible arrangement seems to be something like this:

    ISC Unix machine                     DOS machine ---------- CD-ROM
    ethernet card ---------------------- ethernet card
    ISC NFS                              Clarkson packet driver
                                         soss NFS server for DOS

There may be more to it than that; I've seen conflicting messages about
whether soss requires the MIT PC/IP package.  Also this kind of lashup
requires a fair amount of money since ethernet cards aren't free and
neither is ISC's NFS.  You could probably work up a similar rig with ISC
TCP/IP and ka9q.
   
    In my case all I have to do is get files off the CD-ROM and onto my
hard drive, so a much cheaper method (though it won't impress Flash Gordon)
is
    Unix                                 DOS -----------CD-ROM
    serial port ------------------------ serial port
    zmodem                               zmodem

To do this at a respectably high speed all I'd need to buy is a couple of
16550 UARTS for the serial cards.  But I gather in your situation you
want your data to *stay* on the CD-ROM.  For that, barring an unexpected
deus ex machina from ISC probably some form of networking is what you'll
have to do.

------------------------------------- -----------------------------------------
 crom2 Athens GA Public Access Unix  |  i486 AT, 16mb RAM, 600mb online
                                     |  AT&T Unix System V release 3.2
 Molecular Biology                   |  Tbit PEP 19200bps  V.32  V.42/V.42bis
 Population Biology                  |     
 Ecological Modeling                 |  Admin: James P. H. Fuller
 Bionet/Usenet/cnews/nn              |  {jim,root}%crom2@nstar.rn.com
------------------------------------- -----------------------------------------

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 21:37:23 GMT
From:      lr@cs.brown.edu (Luigi Rizzo)
To:        comp.protocols.tcp-ip
Subject:   Network configuration problem

Hi there, we have the following configuration problem.
This is our network structure (all Ethernet running TCP/IP):

   global internet
      |
      R
      |    net1
   ------------------------------------------
	       |        |             |
	       A        B             C
	       |        |             |
   --------------  ------------  ------------
      net2           net3          net4

net1 will be connected to the global internet in the near future, via a
router (R).
The assigned Internet addresses for our department are 131.114.9.*,
and this appears to be the main source of problems.

Machines A, B and C are Unix boxes (HP9000 and others) with two
Ethernet interfaces. net2, net3, net4 are used to support communication
between groups of (disk/diskless) X workstations and their servers. Our
problem is to configure the network, especially the routing nodes
(A,B,C), so that each machine on each subnet can see the other and the
external world.
	Don't know about the router R, but apparently I can only use a
byte-aligned netmask on the Unix nodes. Thus each node on 'net1'
should be given a 'route' command for each node on the subnetworks,
instead of a unique 'route' for each subnetwork. Also, configuration of
the nodes on net2..net4 appears to be a problem (lots of 'route add'
for them, too).

Any ideas other than substituting A, B and C with bridges ?

	Thanks
	Luigi
==================================================================
Luigi Rizzo                Brown University & Univ. di Pisa
e-mail: lr@cs.brown.edu, luigi@iet.unipi.it
==================================================================

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 22:08:45 GMT
From:      jim@crom2.uucp (James P. H. Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: accessing DOS disks from unix

gd@aprm (Gary Dunn) writes:

> Several postings in this thread have explained how to use SOSS or
> Netware to mount an MS-DOS disk under NFS.  We use Intel's OpenNET, and
> it can do the same thing.
>
> There are some additional factors to be concerned with, beyond network
> connectivity.  MS-DOS and UNIX do not store text files the same way.  An
> MS-DOS text file terminates lines with CRLF, whereas UNIX just uses LF. 
> More significant is the case where the data on the PC requires
> specialized application software to be useful.  In particular, someone
> said they wanted to be able to access CD-ROMs, and those use special
> reader programs. 

    CRLF<->LF is quite an easy problem to fix; I wish that were the worst
of my problems.  Many Unix flavors come with filter programs to do the
conversions (utod, dtou, lef) or you can use a text editor's global search-
and replace for shortish files or something like

   sed 's/<ctrl-M>//'

for huge ones.
    As for special reader programs required to access the CD, some have 'em
and some don't.  I'm trying to read the National Institute of Health's
GenBank gene-sequence database, and they just use CD-ROMs for distribution;
you extract the files from the CD-ROM, put 'em on your hard disk, and do your
reading, searching or other processing there, using software you write your-
self or else one of the zillions of programs that geneticists or biochemists
have written to analyze this particular dbase.  Some of this software runs
under DOS, some under Mac OS, some under Unix.  A lot of it comes with make-
file entries that will build the program *either* for Unix/C or DOS/TurboC.

    But you still have to make your machine acknowledge the presence of the
CD-ROM and turn it on and read in the files.  ISC SysV doesn't seem to sup-
port CD-ROMs at all, you can't register scsi-driven CD-ROMs with vpix as
DDA devices because they use direct memory access, and you can't register
them as IEM devices unless your vendor included a specific IEM device driver
to integrate your particular card/drive combo into vpix, and mine didn't.
So Unix is out and vpix is out, and that leaves some form of Unix-DOS net-
working.  (Or else the cheapnoid solution, which I'm probably going to use --
sending the files over the serial ports with zmodem.)

------------------------------------- -----------------------------------------
 crom2 Athens GA Public Access Unix  |  i486 AT, 16mb RAM, 600mb online
                                     |  AT&T Unix System V release 3.2
 Molecular Biology                   |  Tbit PEP 19200bps  V.32  V.42/V.42bis
 Population Biology                  |     
 Ecological Modeling                 |  Admin: James P. H. Fuller
 Bionet/Usenet/cnews/nn              |  {jim,root}%crom2@nstar.rn.com
------------------------------------- -----------------------------------------

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      10 May 91 23:16:01 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, SNMP, and Bridges

In article <1991May10.054816.3039@avatar.com> kory@avatar.com (Kory Hamzeh) writes:
>
>If I have a TCP/IP stack running on a MAC layer bridge to support SNMP, must the
>ethernet interfaces have unique IP addresses?
>
>What if the device was an IP bridge or router?

If the device is BRIDGING IP datagarams, then the device should act as
if it was a host somehow attached to the bridged network.  In this mode,
the device has a single IP address on the logical IP network being
run over the bridged network.  If more than one logical IP net is being
run on the bridged net, then the node MAY have more than one IP address.
It is up to the bridging software to properly forward any internally
generated packets out the correct MAC level port(s).

If the device is ROUTING IP datagrams, then each MAC level interface
should have one (or more) IP addresses associated with the logical IP
nets defined separately on each MAC level network.

If the device is ROUTING on SOME ports and BRIDGING on the OTHER ports,
then a mix of both above mechanisms is used (and the details get very
messy).

Art

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      11 May 91 02:51:35 GMT
From:      PPAPAD@GREARN.BITNET
To:        comp.protocols.tcp-ip
Subject:   (none)

Received: by GREARN (Mailer R2.07) id 5936; Fri, 10 May 91 16:32:52 HMT
Received: by GREARN (Mailer R2.07) id 5934; Fri, 10 May 91 16:32:52 HMT
Date:         16:22:44  HMT  FRIDAY  05/10/91
From:         PPAPAD@GREARN
subject:      FORWARDER NAME SERVER
to:           TCP-IP@NIC.DDN.MIL

Can you please tell me what exactly happens when a Forwarder Name Server
boots up? Does it load its database into the cache???
  What}s the relationship between a Forwarder & a Stub Resolver???
Please reply to PPAPAD@GREARN.BITNET

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      11 May 91 06:04:36 GMT
From:      kazz@harem.osk.mac.mei.co.jp (Kazuyuki Ienaga)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   How do get CSLIP ?


does anyone knows where i can get CSLIP for sunos4.0.3 or later ?

if it is a small patch for slip4.0, someone posting it is available ?

--
Kazzyuki Yenaga
	Matsushita Computer Systems Co. Ltd., Osaka, Japan
	Product support staff

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      11 May 91 14:58:11 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnets that 'do' 3270

There are a number of tn3270 implementations.  BSD tn3270 (Unix) and
NCSA Telnet tn3270 (MS-DOS) come to mind - they are publically available.

If you want an OS/2 or MS/DOS shrink-wrapped version, FTP Software sells
a very nice version in it's PC/TCP product line.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714-6066	
----------------------------------------------------------------------
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      11 May 91 20:00:20 GMT
From:      brian@NAPA.TELEBIT.COM (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   pop usage survey

Telebit corp uses POP.  We run POP on our Sun fileservers and the
Macintosh users run eudora to read mail.  Total users of POP?  About
75.

Brian Lloyd, WB6RQN                              Telebit Corporation
Network Systems Architect                        1315 Chesapeake Terrace 
brian@napa.telebit.com                           Sunnyvale, CA 94089-1100
voice (408) 745-3103                             FAX (408) 734-3333

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      11 May 91 20:05:56 GMT
From:      asp@UUNET.UU.NET (Andrew Partan)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load

> From: csn!xcaret  (Xcaret Research)
> Subject: NetFind and its Internet load
 
> .... NetFind queries the Domain Naming System to locate authoritative name
> server hosts for each of these domains. ....
> .... Each of these machines
> is then queried using the Simple Mail Transfer Protocol ....
> .... located machines are then probed using the
> "finger" protocol ....

I assume that you have thought about domains that are not on the
Internet & only have MX records; about nameservers that do not run SMTP
servers; about hosts that do not run finger; about firewalls & gateways
that do not permit some protocols or hosts to be reached?

We run a nameserver for 1000+ domains that are not on the Internet;
said nameserver does not run SMTP or finger.  We are a MX forwarder for
about 900+ domains.  I don't want my mail servers hit with more load -
at times every cycle counts.

	--asp@uunet.uu.net (Andrew Partan)

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 May 91 00:09:36 GMT
From:      DAGNEAUX@FRLURE51.BITNET
To:        comp.protocols.tcp-ip
Subject:   RE:       pop usage survey


        LURE (CNRS FRANCE) use POP3 for VMS-Mail distribution to 60
MAC's users with Eudora. POP3 server is IUPOP3 (from Indiana University)
modified for UCX 1.3, SMTP server (for reply) is MX ( from RPI ) or SMTP Mailer
(from CMU-TCP).

Daniel Dagneaux.
LURE.
Universite Paris-Sud
Orsay France

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 May 91 04:00:35 GMT
From:      74360.3202@CompuServe.COM (Hiroshi Kubo)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Mailing-List

Please delete 74360.3202@compuserve.com from TCP/IP mailing-list.
Alternatively add hkubo@fhl.fujitsu.co.jp to the mailing=list.
 
Hiroshi Kubo
 
 

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      12 May 91 16:57:46 GMT
From:      schwartz@latour.colorado.edu (Mike Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: NetFind and its Internet load

In article <9105112005.AA04828@uunet.uu.net> asp@UUNET.UU.NET (Andrew Partan) writes:

> I assume that you have thought about domains that are not on the
> Internet (...)  I don't want my mail servers hit with more load - at
> times every cycle counts.

NetFind does not probe servers that are in different domains than the
institutions being searched.  So, if a site has mail forwarding through
uunet (for example), NetFind will tell the user the site isn't on the
Internet, and not probe that domain further.
 - Mike

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 May 91 19:44:40 GMT
From:      rmccask@seas.gwu.edu (Randy McCaskill)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   cap 6.0 on sun

I am trying to figure out if I need to get a hardware gateway to run
CAP.  I have RTFM and they seem to say that I don't need one if I am
running SunOS using Native EtherTalk support or UAB.  I cannot find
anything in the Sun manuals talking about Ethertalk support.  I don't
know where else to look.  I would really rather know if it supposed to
work or not before I try and install it.

Thanks,
-Randy

---------------------------------------------------------------------
Randy McCaskill				George Washington University
rmccask@seas.gwu.edu			Computer Science NUT

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 05:14:35 GMT
From:      randall@Virginia.EDU (Randall Atkinson)
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   RFD: comp.protocols.snmp


  Christoph Uloth <chris@ec.uwa.oz.au>, Andrew C. Esh <andrew@jhereg.osa.com>,
and others have raised the notion that a newsgroup is needed for discussions
of the Internet Simple Network Management Protocol (SNMP) and discussions
of software managers and agents for use with SNMP.

  There have been a number of postings outside the news.groups arena supporting
creating such a newsgroup.  I suspect that this is actually a case where what
is needed is to get someone to create an "inet" distribution newsgroup, but
to cover things all the way round, I am posting a formal USENET
Request for Discussion.

  The formal proposal follows.  Please post followups to news.groups
[[per the guidelines; the original request was for both news.groups
and comp.protocols.tcp-ip -- tale ]]

FORMAL PROPOSAL

NAME: comp.protocols.snmp  (unmoderated)

CHARTER:
  Discussions of the Internet SNMP protocol and software agents and managers
  for use with SNMP.  Discussions of SNMP-based network management.
-- 
Randall Atkinson
randall@Virginia.EDU

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 06:31:20 GMT
From:      J0S@psuvm.psu.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Broadband Backbone Adapter, Again?

I've had several respondees to my initial posting request additional
details.  So, here goes.

My sponsor has wired his facility with broadband coax including
frequent service drops.  He has a Hughes model 8233  Ethernet
to Broadband Backbone Bridge at his head end on MAP channel 3
which leads to the Internet.

Our research proposal suggests connecting a PC to the sponsor's
backbone LAN and then feed experimental data from his facility
to our lab over the Internet.

The one problem we have with this approach is connecting the PC
to the LAN.  Another bridge at the PC end is expensive when
compared to the cost of a PC which leads to this inquiry:
Are there PC adapter cards which will allow us to directly
connect to this backbone LAN?  Next, are there TCP/IP packet
drivers which talk with this adapter?

If all goes well with our initial research, we want to replace
the PC with a small VAX computer.  What products are available to
connect it to this backbone LAN for similar use?

Thanks, Jack Sharer, Penn State

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 13:26:50 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP, SNMP, and Bridges


 > From tcp-ip-RELAY@nic.ddn.mil Sat May 11 11:47:48 1991
 > From: dog.ee.lbl.gov!hellgate.utah.edu!caen!sdd.hp.com!usc!srhqla!quad1!avatar!kory@ucsd.edu  (Kory Hamzeh)
 > Organization: Avatar Consultants
 > Subject: TCP/IP, SNMP, and Bridges
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > 
 > If I have a TCP/IP stack running on a MAC layer bridge to support SNMP, must the
 > ethernet interfaces have unique IP addresses?
 > 
 > What if the device was an IP bridge or router?
 > 
 > Thanks,
 > Kory
 > 
 > 
 > -- 
 > -------------------------------------------------------------------------------
 > Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
 >                     INTERNET: kory@avatar.com 
 > 

Kory,

Assuming that the device is JUST a bridge it need only have one
IP address (Though you could implement it with many if you so chose).

An IP router MUST have different IP addresses on its interfaces. Remember,
the purpose of an IP Router is to forward packets between different
IP networks and different IP Networks have different IP Network/Subnetwork
numbers, therefore the addresses will be different.

Frank Kastenholz
Clearpoint Research Corp.

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 13:59:35 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP flow control query

In article <4238@zaphod.UUCP> derrick@zaphod.UUCP (Derrick Nagy) writes:
...
   The problems seem to lie at the TCP level when the receiving end advertises
   a zero window.  It does not appear to turn flow control on again on its own
   initiative.  The pausing host will send a datagram with one byte of
   garbage data as a probe after a few seconds, to which the receiving end
   responds with an ACK with the current window size (usually wide open).  The
   stalling host only sends ACKs, and the receiving end never responds to them.

   Questions:  are the ACKs from the stalling host probes?  Are they valid
   probes?

The ACK from the stalling [client] host is in response to the zero-window probe
sent by the pausing [server] host.  The ACK in the packet isn't as important as
the window size that the packet contains -- this is what allows the pausing
host to resume sending data.

   What criteria should the receiving end use to advertise when its window
   opens?

When the stalling host's receive window changes from zero to non-zero, it should
be sending out an ACK at that time, rather than waiting for the zero-window
probe from the pausing host.
--
			-- Frank Solensky / Clearpoint Research Corp.
Red Sox magic number: 132

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 16:31:08 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, SNMP, and Bridges

In article <9105131326.AA01179@europa.clearpoint.com> kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) writes:

   An IP router MUST have different IP addresses on its interfaces. Remember,
   the purpose of an IP Router is to forward packets between different
   IP networks and different IP Networks have different IP Network/Subnetwork
   numbers, therefore the addresses will be different.

I don't think that necessarily follows -- seems to me that KA9Q NOS
gets by (if you so desire) with one IP address for the whole box, and
routing done on a per interface basis.  Or am I missing something ?

--Ed

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 17:10:33 GMT
From:      jaj@sactoh0.sac.ca.us (Jelle A. Jorritsma)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc
Subject:   Running TCP/IP on Novell workstations(Netware 3.1)

We are starting a project to network our Novell workstations to
other hosts(Unisys A-series,IBM AS400, Unix servers,etc) via
TCP-IP. We've got an evaluation package from FTP and all we want to
do initially is just to tie in two stations on the Novell network
thru TCP/IP. We are able to bring up just the TCP/IP on the
stations or just Netware but not both(which is our goal). The
ethernet cards we are using are ne2000 and we have ne2000 packet
driver. We also have gone thru the SHGEN to generate a new IPX
shell. Listed below is what's in the autoexec.bat:
REM NE2000 using IRQ=5, I/O=320h 0h320h
ne2000 -n 0x60 0x05 0x320h 
ipx
NET3  

Everything loaded fine, until net3 which returns File Server not
found.
Supposedly, the ne2000 packet driver's -n option would allow it to
deal with the 802.3/Ethernet II(used by TCP/IP) without
reconfiguring the server. FTP's suggestion was that I try
reconfiguring the LAN driver on the server to recognize the two
protocols. Unfortunately, the cards we are using in our servers do
not support ETHERNET II. 

Has anybody out there encountered this problem and found a solution
without reconfiguring the server???
All help would be greatly appreciated!!! 


-- 
---------------------------------------------------------
=======jelle jorritsma======jaj@sactoh0.SAC.CA.US========
---------------------------------------------------------

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 18:15:23 GMT
From:      THIER@ORCAD2.dnet.ge.com
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: Host Lockup During Socket Transfers


My original question:

>   In attempting to run TCP socket transfers between two processes
>residing in the same SPARCstation host, I am experiencing system 
>lock-up after some number of transfers have taken place (the number
>of transfers varys; it's usually between 950 and 2850 with 30 ms. 
>intermessage spacing). Message sizes are 4496 octets. System 
>configuration is:
>
>                  SPARCstation 1+
>                  SunOS 4.1
>                  GENERIC Kernel.
>                  16 MB memory.
>                  210 MB disk.
>                  56MB swap.
>                  Send/Receive Queues = 4096
 

The trophys go to the following who discerned that I was in need
of the Loopback patch (100159-01):


Hal Stern        stern@sunne.East.Sun.COM
Mark Plotnick    mp@allegra.att.com
Daniel Quinlan   danq%chs@boulder.colorado.edu

I was surprised to find that the loopback driver gets invoked even
without using the loopback address, (Thanks again to Hal Stern):
 
	"when the IP layer sees dest IP == my IP, it gives the packet
    to the lo device driver instead of the ie or le driver."
 


Other Responses:
---------------
from  Lixia Zhang  lixia@parc.xerox.com

Dont know if you've already got help from others.  To me the system
resources you ran out seem to be the ports.  I believe you can only
have a limited number of active tcp ports.  When transmission is finished,
the closing connection must wait for 2*T time period before the port being
freed, where T is the max life time of pkt in the net (this wait period
is for reliability reason, to make sure all previous pkts have dead before
the port can be reused).  You may check the appendix of RFC1185 to find
out how long this T value is (if my memory is not faulty, I remember it
is mentioned there).
 


From:  Mike Raffety  mcnc!oddjob.uchicago.edu!oconnor!miker

I don't suppose your transmitting host has been up a long time (e.g.,
100-130 days), has it?  I discovered a bug a year-ish ago in Sun's TCP
code.  It's rather complex, but let me try to explain it ...
 
When you open a TCP connection, a byte counter is assigned to it, which
is simply a copy of a system counter that ROLLS OVER at 2^32, or about
18 weeks.  Once the stream is opened, and the counter for that stream
initialized, that counter is incremented by one for each byt/octet
transmitted.  If your machine is up long enough, and you transmit
enough data, eventually that stream-specific counter rolls over (the
closer to that magic 18 +/- weeks, the less data it takes to get
there).  The RECEIVING TCP side DOESN'T roll over properly, so it fails
to recognize the packet after the rollover occurs, and asks for a
retransmit of the "right" packets.  With backoff algorithms, this
quickly settles down to near-silence.  Once the SYSTEM counter rolls
over, everything works fine again ... until the next rollover
approaches.


Many thanks to all who responded and to Mike Fischbein at Sun's Albany
office for mailing me the patch.


John Thier
GE Defense Systems Division
Pittsfield MA
thier@orcad2.dnet.ge.com

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 19:19:16 GMT
From:      uccxmgm@unx2.ucc.okstate.edu (Martin McCormick)
To:        comp.protocols.tcp-ip
Subject:   compuserve

Is there a gateway between the Internet and "Compuserve?"  I would like
to be able to down-load some files from a Compuserve site.
Thank you.

Martin McCormick
Amateur Radio WB5AGZ
Oklahoma State University
Computer Center
Data Communications Group
Stillwater, OK

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 May 91 22:56:58 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Network configuration problem


   global internet
      |
      R
      |    net1
   ------------------------------------------
               |        |             |
               A        B             C
               |        |             |
   --------------  ------------  ------------
      net2           net3          net4


I don't know about your other routers, but HP 9000 Unix boxes do support
non-byte aligned netmasks; the HP internal network uses a netmask of
255.255.248.0 on a class A network.

Seems to me that you should configure all the nodes on net2 with a default
route through A's net2 address; similarly for net3 and B and net4 and C.
Each of the routers B C and R should have routes for the net2 network
through A's net1 address; similarly for B and net3, C and net4. Also, the A
B and C routers should use router R as their default route; this should give
everyone in your net visibility to the outside world as well.

The tricky (or ugly) part is what to do about the nodes on net1. You could
configure them with the specific routes for A/net2, B/net3 and C/net4 while
using R as the default router. Or, you could use just R as the default
router and depend on ICMP Redirect messages from R to install per-node
routes in the routing table on the net1 system. Finally, you could configure
the nodes on net1 to use proxy ARP (assuming all of A, B, C, and R support
it). Personally, I'd recommend the first configuration; it's a bot of a pain
to get all the systems on net1 configured, but the performance and network
impact are optimized.

Using default routes on the net2/net3/net4 nodes should make them relatively
easy to configure. It is absolutely not necessary to add scads of per-node
routes by hand; if you use the second alternative for configuring your net1
nodes, per-node routes should be created automatically by the ICMP
Redirects.

Good luck.
--
This is not an official statement of The Hewlett-Packard Company. No
warranty is expressed or implied. The information included herein is not to
be contrued as a committment on HP's part. The devil made me do it. This
won't save me from the lawyers' wrath, but it can't hurt.

Jason Zions			The Hewlett-Packard Company
Colorado Networks Division	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 00:44:02 GMT
From:      cmo@pogo.WV.TEK.COM (Christine Olsen)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip tests

I've heard that the Department of Defense has some public
domain TCP/IP tests.  

Does anyone know how to get them?

Thanks for any help,

Christine 

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 08:35:38 GMT
From:      Ray_Soper.wgc-e@rx.xerox.com
To:        comp.protocols.tcp-ip
Subject:   FTP Conformance Testing

Is there a standard set of conformance tests for FTP?
Is there a reference implementation to test against?
How do people "normally" test new FTP implementations?
Does anyone run a conformance testing service?
And similar questions . . .

Thanks,
Ray Soper.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 12:51:52 GMT
From:      randall@Virginia.EDU (Randall Atkinson)
To:        news.groups,comp.protocols.tcp-ip
Subject:   Re: RFD: comp.protocols.snmp

I have inquired of the SNMP mailing list maintainer
at NYSERnet whether it would be agreeable to gateway
the comp.protocols.snmp newsgroup with the existing
SNMP mailing list if the newsgroup were created.

The answer to whether they will be gatewayed is mostly
in the hands of the list maintainer.

I personally would prefer to see the list promoted to
an Internet newsgroup (those with the "inet" distribution)
and simply gatewayed in the same manner as the TCP-IP
list is with comp.protocols.tcp-ip.

Perhaps the "inet newsgroup czar" could be persuaded to
do this ???

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 13:15:41 GMT
From:      eric@picard.sbi.com (Eric Ho)
To:        comp.dcom.lans,comp.dcom.modems,comp.protocols.tcp-ip
Subject:   idea on easy wide-area networking.

Just wondering if there're ethernet/modem vendors out there that are
planning to make boxes that would take ip packets off a regular phone line -
e.g. it'll be nice if telebit modem have thick ethernet connectors in
addition to RS232 connectors. This also means that the modem will need to
handle SLIP/PPP well between what is flowing on the phone line and what is
going on in its builtin ethernet card.

Alternatively, a Cabletron box for instance can take RJ11's in addition
to regular thick ethernet connectors.  This also means that the cabletron
will have modem cards built into the box and they'll be able to handle
SLIP/PPP.

If this is possible, this'll really make wide-area networking easy and
hopefully more affordable (e.g. you just buy this modem and hook it to
your Sun's ethernet connector at home or your X terminal at home and when
your home's phone line eventually turns fiber-optic one day, all you need
to change is 1 or 2 cards in your modem).  It'll be nice if these new modems
can also handle signals on cable-tv in addition to regular phone line signals
- this means that you can subscribe to an "ethernet" channel with your
local cable-tv company and you'll have a high-bandwidth local area network
at some $20 a month - i.e. instead of getting signals of your favorite 
movie on HBO, you get signals for your IP packets from your neighbors. 
I guess that this latter feature will be a bit far off for current
modem vendors.

Oh well...
--

==========================================
+ Eric Ho                          Email: eric@sbi.com
+ Salomon Brothers, Inc.  [SISS]   Phone: (201) 896-4356
==========================================

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 13:38:10 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP Conformance Testing

In article <"14-May-91..9:35:38.+1".*.Ray_Soper.wgc-e@rx.Xerox.com> Ray_Soper.wgc-e@rx.xerox.com writes:

   Is there a standard set of conformance tests for FTP?
   Is there a reference implementation to test against?
   How do people "normally" test new FTP implementations?
   Does anyone run a conformance testing service?

Ray,

The traditional tests of FTP are interoperability tests, not
conformance tests; the published RFCs on FTP are rather weak in
describing what parts of the protocol need to be done, and are
completely lacking in specifying (e.g.) data formats which would
facilitate FTP'ing entire directory trees.  There is still much work
to be done in the standardization and specification area.

Regarding simple protocol questions, it's really quite easy to
generate a testbed for FTP implementations.  There is an extensive
catalog of sites which offer anonymous FTP services; at the very
least, your test mechanisms should examine a sample of these services
and verify interoperability for any protocol features which you'd like
to test out.  comp.archives is a good source of ongoing data to drive
a test regimen.  Grab copies of the most favorite FTP add-on scripts
(the 'autoftp' things which attack dial SIMTEL20, the 'bftp'
background FTP scripts, the 'expect' package with its FTP driving
routines come to mind) and see to it that your package offers an
adequate sampling of these features on the client side.

On the server side, it's ridiculously easy to generate a lot of test
traffic.  Put up a system with your ftp server that offers an
anonymous FTP login; populate the public directories with interesting
materials, and post an announcement to this effect somewhere on
usenet.  To ensure that people will notice your site, it would be best
to include in it materials which are traditionally forbidden fruit to
NSFnet sites -- nudie pix, racy stories, other items of prurient
interest, encryption algorithms, political propaganda, and meeting
notes of secret societies are items which should generate traffic from
a wide range of client systems.  this will ensure that you'll also be
able to test the efficiency of your FTP system and your network under
load, and it will give you an unmatched opportunity to find problems.

Please contact me directly if you have any questions.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com

"(6) The Plan shall identify how agencies and departments can
collaborate to ... expand efforts to improve, document, and evaluate
unclassified public-domain software developed by federally-funded
researchers and other software, including federally-funded educational
and training software; "
			"High-Performance Computing Act of 1991, S. 272"

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 14:44:58 GMT
From:      peterg@murphy.com (Peter Gutmann)
To:        comp.protocols.tcp-ip
Subject:   Starting a PPP Install



Hello,

I am going to be attempting to put up PPP for our internal use
shortly. What I am looking for is tips or pointers to make
this a little easier. Pointers to papers and/or RFCs are
gratefully accepted.

The plan is to put PPP up between a small group of three
remote sun 3s and our network here.

Thanks in advance.

Peter Gutmann

Murphy & Durieu		peterg@murphy.com
NYC, NY			212-618-0973

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 15:00:49 GMT
From:      edgar@jake.prz.tu-berlin.de (Edgar Ostrowski)
To:        comp.protocols.tcp-ip
Subject:   WANTED: article "Performance" (Jacobson, 1988)


In his book "UNIX Network Programming" W. Richard Stevens refers to a
posting from V. Jacobson to this newsgroup:

   "Performance", Message-ID <8811231121.AA19744@helios.ee.lbl.gov>,
   Usenet, comp.protocols.tcp-ip Newsgroup, Nov. 1988

Can anyone repost this article or send a copy to me ?
(my email address is edgar@marvin.prz.tu-berlin.de)


Thanks
-edgar-

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 16:05:03 GMT
From:      cudcv@warwick.ac.uk (Rob McMahon)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Partial subnetting

We have a class B address (137.205.0.0) for the University.  Currently the
whole campus is running without subnets, with bridges between each department
and the backbone, but we allocated the numbers such that we could later give
each department its own subnet, and change the bridges for routers should it
become necessary.

We now have our first department that actually wants to be split off with a
router, and I realise that I don't understand how it works at all.  Here was
the plan (internet address/netmask):

			    137.205.0.0/0xffff0000
				      |
				      |
			 ----------------------------
			 |                          |
     Bridge			 Router
			 |  			    |
              137.205.232.0/0xffff0000	 137.205.176.0/0xfffffc00

But the Cisco router we had on trial won't let you set different netmasks on
its two interfaces "in the current implementation".  Does anyone know if this
is likely to change ?

A nearby book calls what we are trying to do an "illegal" setup, and says it
is "recommended" to have the same netmask throughout the network.

It seems that to make this work the routing tables on the Unix hosts ought to
have a netmask associated with each entry, but it's not there.  When I tried
to add a route to such a gateway the machine lost contact with the entire
world.  (I still don't understand this, if the machine was just picking the
wrong route and sending all packets to the router, why didn't the router just
forward them to the correct machine ?)

Is this setup not supposed to work ?  Why not ?  It seems like an obvious
application (so obvious that I just assumed it was going to work without
really sitting down and thinking about it).  We don't want to have to subnet
the entire University just yet, but it would be nice to keep our options open.

Cheers,

Rob
-- 
UUCP:   ...!mcsun!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 16:07:17 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip,comp.dcom.cisco
Subject:   Packet from unknown router

In order to transition one of our Ethernet segments from a class C network
to a subnet of our class B net, I've configured it as two logical networks,
192.5.104 and 131.239.32.  I had to configure this interface on our cisco
router to use 255.255.255.255 as its broadcast address, because it doesn't
know enough to use the appropriate subnet-specific broadcast address for
the logical subnet it wants to send to.  This means that hosts on the
131.239.32 subnet see RIP broadcasts intended for 192.5.104 hosts, and vice
versa.  Routed on these hosts spits out lots of "Packet from unknown router"
messages for the broadcasts from the other logical subnet.

Does anyone know how to get routed to shut up about these?  They're
annoying the users and they fill up /var/adm/messages, making it difficult
to find real messages.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 16:10:34 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Board Level Ethernet/TCP/IP Products

I'm looking for information about Ethernet boards packaged with
a TCP/IP protocol suite. We need access both to the transport
layer facilities (TCP/IP/UDP) and to "raw" Ethernet packets
(i.e. physical addresses bypassing logical addresses).
We're using it with a VMEbus based system.

I'd also be interested to hear if anyone knows of a supplier of
VME boards that just have some LANCE chips and VME drivers.

So far I've heard about 3 suppliers:

Motorola has an Ethernet comm board, though our local techie says
that you can't get raw Ethernet with their stock software. They'll
sell a TCP/IP package to us, but I don't think you can drop below
ARP and use physical addresses.

CMC ("a Rockwell company") has a similar board, and sells "Protocol
Implementor's Kits" for TCP/IP or OSI. The kits include binaries
for TCP/IP that run on the board.  Alternatively you can load up
their "Link Level Driver" and talk directly to the Ethernet.

Then there's SBE, Inc., which has a similar line of products.
They have their VLAN-E and MLAN-E boards that run a version of
TCP/IP from "Spider Systems." Their PR blurb claims that they also
support a link level interface.

Now The Question: has anyone had experience with any of these or
any other similar boards? Good? Bad? Did it process this news
item? Would it be transmitting your reply to me? I'll post a
summary of any e-mail responses I get.

Rick.
smith@sctc.com    Arden Hills, Minnesota.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 17:29:52 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: RFD: comp.protocols.snmp

Randall,

The list maintainer is PSI, and it maintained/distributed
through uu.psi.com (!uupsi).
We are certainly agreeable to gatewaying the mailing list into
comp.protocols.snmp once we are assured that there has been
a appropriate vote on newsgroup creation.

Marty
---------

 I have inquired of the SNMP mailing list maintainer
 at NYSERnet whether it would be agreeable to gateway
 the comp.protocols.snmp newsgroup with the existing
 SNMP mailing list if the newsgroup were created.
 
 The answer to whether they will be gatewayed is mostly
 in the hands of the list maintainer.
 
 I personally would prefer to see the list promoted to
 an Internet newsgroup (those with the "inet" distribution)
 and simply gatewayed in the same manner as the TCP-IP
 list is with comp.protocols.tcp-ip.
 
 Perhaps the "inet newsgroup czar" could be persuaded to
 do this ???

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 18:23:37 GMT
From:      eric@picard.sbi.com (Eric Ho)
To:        comp.protocols.tcp-ip
Subject:   slip connection...

Hi,

Does anyone out there know what is the exact sequence of actions to establish
a slip connection (assuming of course, you've SLIP installed at both ends --
also assuming that you've a Sun at each end of the connection) ?
Do I have to get those modems that can store phone numbers on non-volative ram
or the SLIP distribution actually comes with utilities that allow me to get to
the modem and dial the number ?
I'm also interested in what comes next after the phone call/connection has
been established -- i.e. is there some other programs I need to invoke
(locally) then or I need to type in something or do some kind of login or what
?  I'm confused.

Any pointers much appreciated.
--

==========================================
+ Eric Ho                          Email: eric@sbi.com
+ Salomon Brothers, Inc.  [SISS]   Phone: (201) 896-4356
==========================================

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 18:41:42 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

uccxmgm@unx2.ucc.okstate.edu writes:
   Is there a gateway between the Internet and "Compuserve?"  I would like
   to be able to down-load some files from a Compuserve site.

The only connection to CompuServe is for email passage.  You can't get
at CompuServe's libraries through it.  They require you to login to
their systems as a known subscriber who can be billed in order to get
at such stuff.

--karl

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 May 91 20:52:34 GMT
From:      hendrick@ctron.com (Jim Hendrick)
To:        comp.protocols.tcp-ip
Subject:   SNMP tool Problem

Hi,
	We are having a problem with mit-tools snmp*** (get, set, next etc.)
Specifically, with certain MAC addresses/OID combinations, it crashes
the snmptool. We suspect this is due to the combination addr./oid being too
long but have not yet the time to pour through the source code. Thus this
posting is to find out what the latest v. of the snmptools is to see
how far out of date we are (our copy circa 1989) and if anyone else
had run afoul of this before (and found a soln?). Thanks in advance.
Please respond via email if this is not approp. to this group.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 05:42:28 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
To:        comp.sys.dec,comp.protocols.tcp-ip
Subject:   Promiscuous mode for Digital DELQA?

I am installing the Berkeley Packet Filter code shipped with tcpdump on
a VAX-3500 with 4.3 BSD-reno.  The difficulty is putting the DELQA into
promiscuous mode.  A DEC technical rep made mention of a special setup
packet that must be sent to the board to enable said function (no csr
stuffing).

Question: Can anyone with a DELQA user's guide send me the format of said
packet?  Better yet, is there a patched if_qe.c module already done
somewhere?  Thanks.

/pbp
--
Paul Pomes, Computing Services Office
University of Illinois - Urbana

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 05:49:58 GMT
From:      joshua@Spies.COM (Joshua Geller)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <1991May14.174227.29625@oar.net> karl.kleinpaste@osc.edu writes:
|>uccxmgm@unx2.ucc.okstate.edu writes:
|>   Is there a gateway between the Internet and "Compuserve?"  I would like
|>   to be able to down-load some files from a Compuserve site.
 
|>The only connection to CompuServe is for email passage.  You can't get
|>at CompuServe's libraries through it.  They require you to login to
|>their systems as a known subscriber who can be billed in order to get
|>at such stuff.

	And their mail is semi-frequently hosed. For the amount of money
	they charge their subscribers, it does not seem to me that said
	subscribers get incredibly good service. 

|>
|>--karl


josh

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 06:33:27 GMT
From:      Walter_William_Kemmerer@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

There is a email gateway between the Internet and Compuserve.  In order
to use it to transfer files from compuserve, you'd need to be able to
get the files into a format that compuserve's email handler can access.
If you are moving files from a personal file area there's no problem.
If OTOH you're transferring data from a clipping service like ENS, go &
send them to yourself (this assumes you've got a compuserve id), and
then remail them out the gateway.  If you're trying to send forum files,
I don't see an easy way you can get 'em to a point that they can be
emailed (other than uploading into a PC and downloading into mail -
yecch!)

Anyway, the format to mail from Compuserve's email to the Internet is
to use the To: address ">INTERNET: usrid@location".  Actually, old
style "!" addresses work, too, for the UUCP crowd.

Hope that answered your question.  If not, please follow up - "we're
always open!"    :-)

Cheers,
Walt Kemmerer
WWKIII@MCIMAIL.COM

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 07:45:22 GMT
From:      etstjan@dutepp0.et.tudelft.nl (Jan van Oorschot)
To:        comp.protocols.tcp-ip
Subject:   Sage, The FREE SNMP tool


The Sage, A SNMP-based Network Management Tool
----------------------------------------------

This is the first version of The Sage. The Sage is a network
management tool, to be used by experienced network managers. The Sage
can be tailored so that normal people can use it, Real Soon Now.

At the moment, to use The Sage, you should know SCHEME, a LISP-like C
language (or something like that). The Sage accepts SCHEME programs
with SNMP request imbedded in them. A few example programs are
included in this first distribution. Look at them !!!!!!!

Programming The Sage is realy simple. An average program to, for
example, obtain a CISCO routing table was written in 5 minutes. Once
you know SCHEME the SNMP world is yours. The Sage hides all SNMP
details for you, and you can work with normal SCHEME variables and
values.

This distribution of The Sage  runs on most UNIX based workstations
with a TCP/IP interface. It has been tested on a SUN SLC (SUN-OS
4.1.1) and a IBM AIX RS6000 machine.

You can get the Sage using anonymous FTP from:

    dutepp0.et.tudelft.nl

directory:

    Sage

The Sage is the result of hard work by three people. 

    Alfred Kayser      --> SCHEME interpreter
    Dirk Wisse	       --> ASN.1 library
    Jan van Oorschot   --> The Sage
    
You get the source, learn from it. The Sage consists of highly
portable C code and is a realy good piece of work.

If you are going to write you own Sage programs, make them available
to the whole world. Send them to the mailing-list:

   beholder@et.tudelft.nl

You can subscribe to this mailing list by send a message with the
subject:

	@@ subscribe Beholder
to:
	dnpap@et.tudelft.nl


We will collect the contributions and include the usefull ones with the next
distribution.

We want The Sage to be the reason why people really start using SNMP.
So pass this message on to your friend (or your enemies). Let us know
what you think of The Sage, both compliments and complaints are
welcom.


greetings  	Jan

-- Ir. Jan van Oorschot.             --- Email: JPMvOorschot@et.tudelft.nl --
-- Data Network Performance Analysis Project                               --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 07:57:03 GMT
From:      goud@sicsun.epfl.ch (Mireille Goud)
To:        comp.protocols.tcp-ip
Subject:   gateways ignores ICMP redirect



   Our NSC router (DX4130) does not update its routing table when it
receives an ICMP redirect message (host redirect or network redirect).
The ICMP redirect comes from the routers default gateway (on the same
subnet) and gives the address of a better gateway on the same subnet.

   I dont find anything in the RFCs about what a gateway should do when
it receives an icmp redirect, but a gateway must be intelligent and
optimize the traffic on the network...
   NSC says the ICMP redirect messages are only for hosts.

   Can somebody help me? Thank you.


 Mireille Goud
 EPFL - SIC
 1015 Lausanne              goud@sic.epfl.ch

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 11:40:03 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking packet formats of 802.1 (part D), spanning tree

Does someone have an electronic description they can send me
describing the layout of spanning tree packets for bridges
(802.1 part D) -- or the hardcopy reference ?
thanks
tom
  thd@ornl.gov

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 13:14:54 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   Re: idea on easy wide-area networking.


    From: sbi!zeuswtc!aristotle!picard.sbi.com!eric@uunet.uu.net  (Eric Ho)
    Subject: idea on easy wide-area networking.

    Just wondering if there're ethernet/modem vendors out there that are
    planning to make boxes that would take ip packets off a regular phone line
    e.g. it'll be nice if telebit modem have thick ethernet connectors in
    addition to RS232 connectors. This also means that the modem will need to
    handle SLIP/PPP well between what is flowing on the phone line and what is
    going on in its builtin ethernet card.
    
Telebit just so happens to be moving in the direction you suggest, but 
they are taking it one step at a time.  They recently developed and
released a product called NetBlazer which routes ethernet/SLIP/PPP,
(supports MULTIPLE ports and also incoming/outgoing terminal service).

For now the modems are outboard, I would project that it is only a 
matter of time before they release a version with internal modems, 
and then onward to further refinements, towards the ideal "black box"
you propose.  They have a sensible product strategy worth looking into.

Hope this helps,

== Gordon Lee                 FTP Software Inc
== voice: (617) 246-0900      26 Princess St
== fax:   (617) 245-7943      Wakefield, MA  01880

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 14:18:21 GMT
From:      wmarko@UB.D.UMN.EDU (William J. Marko)
To:        comp.protocols.tcp-ip
Subject:   commercial access in the chicago area

would some kind soul(s) please mail me the names of the firms
providing commercial internet access in the chicago, illinois area.

does cicnet have any commercial customers?

thanks
-- 
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 15:11:41 GMT
From:      birwin@ficc.ferranti.com (R. L. Bob Irwin)
To:        comp.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   IBM 3270 Emulation Recommendation?


I'm looking for product information (hardware and software) and
user recommendations for the following terminal/printer emulation
problem:

Need to provide IBM 3270 terminal emulation on up to 30 Xwindow
workstations networked via TCP/IP Ethernet to a fileserver.  Need
to appear to the remote IBM Comm Controller as a 3274 Cluster
Controller.  Support up to 32 LUs, mainly 3270 terminals, and a
couple of 3270 printers.  Workstation hardware selection not
complete, but may be Sun3s and SparcIIs.  Prefer to have the
dedicated SNA/SDLC line attached to the File Server with an
intelligent comm board providing the cluster controller
emulation, but will consider other configurations.

|IBM |___|37x5|___|Sync |____  |Sync |___|File  |
|HOST|   |Comm|   |Modem|   /__|Modem|   |Server|-----Enet----
         |Cntr|            SNA             3274      | . . |  
                                           Emula.   WS1   WS30

I'd be glad to prepare a summary of responses or a submission to
the FAQ.

Thank You,
   Bob Irwin                  birwin@ficc.ferranti.com

-- 
Bob Irwin   <birwin@ficc.ferranti.com>  Sugar Land, TX.  (713) 274-5456
Roses are red, violets are blue; I'm schizophrenic and so am I.  - ??

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 15:32:29 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

joshua@Spies.COM writes:
   |>The only connection to CompuServe is for email passage.

   And their mail is semi-frequently hosed. For the amount of money
   they charge their subscribers, it does not seem to me that said
   subscribers get incredibly good service. 

[adjusting mailer-daemon cap.  (Yes, I really have such a thing, a
weird blue-and-purple hat with horns on it that Elizabeth Zwicky
crocheted for me a couple of years back.  It makes me fit the part.)]

Consider that the situation is the following...

1. The link to CServe is a 9600bps modem and a poor protocol.
2. The link is passing almost 2 orders of magnitude more traffic per
day than was ever anticipated.  That'll teach us...
3. The queue which builds up during the nominal working day now
finally manages to clear around 4am EST the next morning...just in
time for the Europeans using it to start generating the next day's
blortful.
4. There are CServe users who are requesting large(!) things from
places like bitftp@pucc.princeton.edu.  That MBASes like bitftp are
tolerated at all in non-load-sensitive incantations is a mystery to me.
5. When the backlog gets too great, the load on the MX hosts too high,
and the discs there too full, we have to shut down the mailers while
we try to get things to clear somehow.  (We do _not_ shut down the
mailers for "days at a time," as a rumor I heard described it.)
6. When things go completely insane, as they did about 2 weeks ago, we
ultimately boot up SneakerNet and deliver, oh, about 8000 messages to
CServe via magtape.  Probably closer to 12000 this last time, actually.
7. The support for the link on the Internet side is strictly volunteer.
8. CServe is taking steps to move the gateway entirely in-house, so as
not to depend on volunteer assistance, and to gain the advantages of
higher link speeds and possibly faster protocols.  I've been
contracted to help with the software conversion and assist CServe
people in some of the questions of maintaining an IP connection.  They
have chosen a commercial IP provider, and the lines are (or should be)
ordered.

In the meantime, the current house of toothpicks is occasionally blown
over and we have to go whittle a new set to build it up again.  Just a
little patience, we'll get there.  And apologies for the occasionally
degraded/delayed service in the meantime.

--karl kleinpaste
Personification of the Internet (Light) Side
of the Schizoid CompuServe Mailer Daemon
(and the CompuServe (Dark) Side is itself
 schizoid-split as well, imagine that)

PS- No, emphatically, general IP (telnet) access into CompuServe is
_not_ part of the game plan.

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 15:43:37 GMT
From:      n2dsy@cbnewsh.att.com (j.gordon.beattie)
To:        rec.radio.amateur.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   ROSE X.25 Source/Executable/Documentation Announcement

The Radio Amateur Telecommunications Society (RATS) is pleased 
to announce that the complete, source, executable and documentation
for the ROSE X.25 Switch by Tom Moulton, W2VY is now available for
non-commercial Amateur Radio use.  

RATS encourages others to port the code to other platforms and to
use it to develop new applications in amateur radio and other areas.
Amateur Radio use of the code requires the developer to simply send
RATS the source code to the new environment or application for further
distribution by RATS as part of the growing RATS Open Systems Environment
(ROSE) platform.  Other development uses of the code are also possible,
with licensing available through RATS.  For further information contact:
J. Gordon Beattie, Jr., N2DSY at the address or telephone listed below.


Points of Distribution

The software will be posted to the RATS Bulletin Board System
at +1.201.387.8898.   login as "rats" and use xmodem.

Folks wishing to obtain the software via e-mail can contact
n2dsy@hou2d.att.com.   A uuencoded copy of the ZIP archive
will be sent to you.

ftp via the Internet will be arranged shortly.


RSWS0422.INF
.
   The Radio Amateur Telecommunications Society is pleased to
   provide you with a complete archive of the latest version of the
   ROSE X.25 Switch software.  Please follow the directions for
   unpacking this version of the software and you will minimize
   problems.  If you have any questions please call Gordon Beattie,
   N2DSY at +1.201.387.8896 or via packet: n2dsy@n2dsy.nj.usa.

1. Make sure that you have about 2 megabytes of free disk space.
   You won't need to use it all, but it will give you room to play
   with the code once you explode the ZIP file.

2. Create the directory path "c:\SRC\RATS\ROSE0422".  You may
   use another drive if you like, but this structure will keep you
   out of trouble when you get future releases of software.

3. With the ZIP file archive on a diskette use the following
   command to break down the ZIP archive onto your "c:" drive:

               PKUNZIP -d a:\RSWS0422.ZIP c:\SRC\RATS\ROSE

4. Please note that the "-d" option will create the required
   subdirectories for you.  If you have problems, make sure that
   the version of PKUNZIP is as current as the one shown below or
   later.

   PKUNZIP (tm)    FAST!    Extract Utility    Version 1.01    07-21-89
   Copyright 1989 PKWARE Inc.  All Rights Reserved.  PKUNZIP/h for help


5. Now go make something useful using this code and send us a copy!

   The Radio Amateur Telecommunications Society 
   206 North Vivyen Street
   Bergenfield, NJ  07621
   +1.201.387.8896

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 15:59:33 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: gateways ignores ICMP redirect

In article <1991May15.095703@sicsun.epfl.ch> goud@sicsun.epfl.ch (Mireille Goud) writes:
>
>
>   Our NSC router (DX4130) does not update its routing table when it
>receives an ICMP redirect message (host redirect or network redirect).
>The ICMP redirect comes from the routers default gateway (on the same
>subnet) and gives the address of a better gateway on the same subnet.
>
>   I dont find anything in the RFCs about what a gateway should do when
>it receives an icmp redirect, but a gateway must be intelligent and
>optimize the traffic on the network...
>   NSC says the ICMP redirect messages are only for hosts.
>
>   Can somebody help me? Thank you.
>
>
> Mireille Goud
> EPFL - SIC
> 1015 Lausanne              goud@sic.epfl.ch

This is pretty normal behavior for current routers.

RFC1009 (and its someday successor) indicate that routers running routing
protocols should NOT respond to Redirects.  The routing protocols should
always provide better information than a Redirect.

Are your gateways communicating via a routing protocol? If not, why not?

Art

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 16:03:04 GMT
From:      harper@pembvax1.bitnet
To:        comp.protocols.tcp-ip
Subject:   Need tn3270 for vax/vms

Does anyone know where I can get a publice domain/shareware version of tn3270
for VAX/VMS using CMU/TEK-IP?  Or if there are any available?

Thanks in advance. 
=====================I speak for myself ONLY!!================================
Eric Harper                      |  Remember:
Computer Center                  |    Waste not, want not.
Pembroke State University        |
Internet:                        |    Use the time you have today,
 harper%pembvax1@ncsuvm.ncsu.edu |    it may be gone tomorrow.

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 16:37:57 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP flow control query


       ....  The pausing host will send a datagram with one byte of garbage
       data as a probe after a few seconds, to which the receiving end
       responds with an ACK with the current window size ....
    
    The ACK from the stalling [client] host is in response to the zero-window
    probe sent by the pausing [server] host....

If in fact the single byte of data is garbage, then the sequence number MUST
be SND.UNA - 1, and the segment is a "keepalive".  A real zero-window-probe
is sent with SND.UNA (not SND.NXT, or you may wedge if someone shrinks the
window on you) as the sequence number and a real data byte.
    
    When the stalling host's receive window changes from zero to non-zero, it
    should be sending out an ACK at that time, rather than waiting for the
    zero-window probe from the pausing host.

This is true, but it doesn't excuse you from implementing zero-window-probe
logic.  The single ACK might get lost in transit, and if this happens, the
TCP connection necessarily stays stalled until the sender probes.

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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 16:43:04 GMT
From:      tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re: gateways ignores ICMP redirect

Briefly put, it is quite dangerous for routers to use icmp redirects.
For a routing algorithm to work correctly (that is, no long-term
looping), then the information received at each router must be
consistent with that received  by other routers.

The use of icmp redirects by routers can easily lead to looping,
if it is not a coordinated part of the routing algorithm (I don't know
any routing algorithms that explicitly use redirects).

One question is--why is the router getting the redirects in the
first place?

PT

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 18:51:55 GMT
From:      toni@usenix.ORG (Toni Veglia)
To:        comp.protocols.tcp-ip
Subject:   SEDMS II Proceedings Now Available


USENIX, the UNIX and Advanced Computing Systems professional and
technical organization, is a not-for-profit association dedicated to
  *  fostering innovation and communicating research and 
technological developments,
  *  sharing ideas and experience, relevant to UNIX, UNIX-related
and advanced computing systems
  *  providing a forum for the exercise of critical thought and
airing of technical issues.

Founded in 1975, the Association sponsors two annual technical
conferences, a once-a-year vendor exhibition, and frequent
symposia and workshops addressing special interest topics, 
such as C++, Mach, systems administration, and distributed/multi-
processor sytems.   USENIX publishes proceedings of its meetings, 
a bi-monthly newsletter ;login:, a refereed technical quarterly, 
Computing Systems, and is expanding its publishing role with
a book series on advanced computing systems.  The Association
also actively participates in and reports on the activities of
various ANSI, IEEE and ISO standards efforts.

For membership information, please contact:  office@usenix.org.


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

If you couldn't join us in Atlanta, the proceedings from the Symposium
on Distributed and Multiprocessor Systems II (SEDMS) are now available
for $30 for USENIX members, and $36 for non-members.  This price 
includes postage for domestic and Canadian shipping.  Please add $20
for overseas postage (air printed matter).

You can place your order by phone or email using your VISA or Master-
card.  Or you can send a check or purchase order to our office.

USENIX Association
2560 Ninth St., Suite 215
Berkeley, CA  94710
415-528-8649
office@usenix.org
 
                  The USENIX Association Staff
______________________________________________________________________

	Symposium on Experiences with Distributed
	     and Multiprocessor Systems
		       (SEDMS) II

		   March 21-22, 1991
		   Atlanta, Georgia

TABLE OF CONTENTS


Session I  System-Building & Experience		

Experience Developing the RP3 Operating System .....................1
	Ray Bryant, Hung-Yang Chang and Bryan Rosenburg (IBM Research
	Division, Thomas J. Watson Research Center)

Experiences with Distributed Data Management in Real-time
C3 Systems.........................................................19
	Paul J. Fortier (Naval Underwater Systems Center),
	David V. Pitts, John C. Sieg, Jr. and C. Thomas Wilkes 
	(Department of Computer Science, University of Lowell)

The ION Data Engine................................................35
	Marc F. Pucci (Bellcore)

Building a Semi-Loosely Coupled Multiprocessor System Based
on Network Process Extension.......................................51
	Helen S. Raizen (Prime Computer Inc.) and Stephen C. Schwarm 
	(Digital Equipment Corporation)



Session II  RPC and Communications	

Implementation and Performance of a Communication
Facility for the RAID Distributed Transaction Processing
System.............................................................69
	Enrique Mafla and Bharat Bhargava  (Department of Computer
	Sciences, Purdue University)

Experience with Threads and RPC in Mach............................87
	Dan Duchamp (Computer Science Department, Columbia University)

Kernel-Kernel Communication in a Shared-Memory
Multiprocessor....................................................105  
	Eliseu M. Chaves, Jr. (Universidade Federal do
	Rio de Janeiro, Brazil), Thomas J. LeBlanc, Brian D. Marsh
	and Michael L. Scott (Computer Science Department, University
	of Rochester)


Session III  Scheduling & Synchronization 	 

Process Scheduling and Synchronization in the Renaissance
Object-Oriented Multiprocessor Operating System...................133  
	Vincent F. Russo (Department of Computer Sciences, Purdue
	University)

A Hybrid Approach to Load Balancing in Distributed
Systems...........................................................149
	Prabha Gopinath (Philips Laboratories), and Rajiv Gupta
	(Department of Computer Science, University of Pittsburgh)

FALCON: A Distributed Scheduler for MIMD Architectures............149
	Andrew S. Grimshaw  (Department of Computer Science, University
	of Virginia) and Virgilio E. Vivas (Department of Informatics,
	LAGOVEN, S.A., Venezuela)



Session IV  Debugging and Analysis 	

Performance Evaluation of the Sylvan Multiprocessor
Architecture......................................................165
	Forbes J. Burkowski, Charles L. A. Clarke, Gordon J. Vreugdenhil
        (Department of Computer Science, University of Waterloo) and
        Crispin Cowan (Computer Sciences Department, University of
	Western Ontario)

Debugging Multiprocessor Operating System Kernels.................185
	Noemi Paciorek, Susan LoVerso and Alan Langerman 
	(Encore Computer Corporation)

Debugging the Time Warp Operating System and Its Application
Programs..........................................................203
	Peter L. Reiher (Jet Propulsion Laboratory), Steven Bellenot
	(The Florida State University),  and David Jefferson (UCLA)



Session V  Performance Tuning 		

Lock Granularity Tuning Mechanisms in SVR4/MP.....................221
	Mark D. Campbell, Russ Holt and John Slice 
	(NCR Corporation, E&M Columbia)
Measured Performance of Caching in the Sprite Network File 
System...........................................................229 
        Brent Welch (Xerox-PARC CSL) 


Session VI  Distributing Memory and Data 

Using Kernel-Level Support for Distributed Shared Data...........247
	David L. Cohn, Paul M. Greenawalt, Michael R. Casey and
	Matthew P. Stevenson (Department of Computer Science and
	Engineering, University of Notre Dame)

Virtual Memory Xinu..............................................261
	Douglas Comer and James Griffioen (Department of Computer
	Sciences, Purdue University)

Early Experience with Building and Using the Gothic
Distributed Operating System.....................................271
	Isabelle Puaut, Michel Banatre and Jean-Paul Routeau 
	(IRISA--INRIA, France)


Session VII  Distributed Systems 	

Supporting an Object-Oriented Distributed System: Experience
with UNIX, Mach and Chorus......................................283
	F. Boyer, J. Cayuela, P. Y. Chevalier, A. Freyssinet,
	and Daniel Hagimont (Unite Mixte Bull-IMAG Systemes, Gieres,
	France)

Can We Study Design Issues of Distributed Operating Systems
in a Generalized Way?...........................................301
	G. W. Gerrity, A. Goscinski, J. Indulska, W. Toomey and W. Zhu 
	(Department of Computer Science, University College,
	University of New South Wales)

Language and Operating System Support for Distributed
Programming in Clouds...........................................321
	Partha Dasgupta (Department of Computer Science and
	Engineering, Arizona State University), R. Ananthanarayanan,
	Sathis Menon, Ajay Mohindra, Mark Pearson, Raymond Chen and
	Christopher Wilkenloh  (Distributed Systems Laboratory,
	College of Computing, Georgia Institute of Technology)

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 20:26:38 GMT
From:      mark@dosli.govt.nz (Mark Wright)
To:        comp.protocols.tcp-ip
Subject:   Re: Sage, The FREE SNMP tool

In article <.674293522@dutepp0> etstjan@dutepp0.et.tudelft.nl 
(Jan van Oorschot) writes:
>
>The Sage, A SNMP-based Network Management Tool
>----------------------------------------------
>
>This is the first version of The Sage. The Sage is a network
>management tool, to be used by experienced network managers. The Sage
>can be tailored so that normal people can use it, Real Soon Now.
>
    .. stuff deleted ...
>You can get the Sage using anonymous FTP from:
>
>    dutepp0.et.tudelft.nl
>
>directory:
>
>    Sage
>
        ... more stuff deleted ...

Could anyone who gets this in nz let me know? Otherwise I'll end up get some 
ftp-mailer somewhere to get it for me.


-- 

 Mark Wright.                    Dept. of Survey and Land Information,NZ.
 email: mark@dosli.govt.nz       phone: 64 4 710-380 ext 8688

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 20:42:23 GMT
From:      lyndon@cs.athabascau.ca (Lyndon Nerenberg)
To:        rec.radio.amateur.packet,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Re: ROSE X.25 Source/Executable/Documentation Announcement

>The Radio Amateur Telecommunications Society (RATS) is pleased 
>to announce that the complete, source, executable and documentation
>for the ROSE X.25 Switch by Tom Moulton, W2VY is now available for
>non-commercial Amateur Radio use.  
 
>Points of Distribution
 
>ftp via the Internet will be arranged shortly.

Now available via anonymous FTP from:

	nro.cs.athabascau.ca:~ftp/hams/rose-422.zip

I will also place a (12 bit) compressed tar archive there in a day
or so containing everything except the binaries (and with CRLF to LF
bashing done on the text files) for the Unix crowd.


-- 
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
           atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca
                    Packet: ve6bbm@ve6bbm.ab.can.noam
      The only thing open about OSF is their mouth.  --Chuck Musciano

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 20:45:35 GMT
From:      zdbvs@rmatl.UUCP (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   icmp protocol unreachable and berkeley 4.3 TAHOE


I am testing a port that I did of B.43 TAHOE TCP/IP code to an embedded system.


When I send a non-UDP, non-TCP, IP packet to the target system, I expect
to see an ICMP protocol unreachable message come back. I see no such
message. Upon looking through the code, I see that IP packets of this
type are supposed to go up through the "raw" interface to potential
clients. My system has no raw clients. 

I do not see any kernel code that will generate a protocol unreachable
message. Before I hack up the IP interface to the raw sockets, I wanted
to be sure I did not miss something. For instance, is there some daemon
sitting out in user space that fields unclaimed raw packets and "does the
right thing" ? ( I certainly hope not ). 

It seems that I will just have to make the IP layer send icmp error messages
instead of calling raw_input() for this embedded system.
Anybody already solved this one ?


Bill VerSteeg
VerSteeg CodeWorks (contracting at Racal-Milgo)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 21:27:09 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,alt.sys.sun,osu.sys.sun.managers
Subject:   Re: SLIP authenication routines & SLIP routing

In article <ERIC.91May15104238@picard.sbi.com> eric@picard.sbi.com.ogi.edu writes:
   Are there authentication utilities of some sort that will be part
   of the SLIP distribution (wherever they're) so that no random site
   can SLIP into one's local network ?  Dial-back modems are really
   not good enough though.
   
That's something that SLIP didn't provide, but has been addressed in
PPP's simple Password Authentication Protocol.  If you're stuck with
SLIP then you'll need to roll your own solution for each case.  Such
arrangements are typically based on login name, system password, etc.

   Also, I want to know how IP packets are routed once they got to the
   remote site.

That's the task of the host IP implementation.  Neither SLIP nor PPP
know anything about routing.

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 May 91 22:18:27 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   Caching only nameserver breaking


Our caching only nameserver running on an RS6000, rev 3005 has started to
break intermittently. It is also a resolver. /etc/resolv.conf is listed
below:  
nameserver	127.0.0.1
nameserver	128.207.254.223
nameserver	128.207.254.44
nameserver	136.240.1.21
domain	ca.boeing.com

When the nameserver breaks, it stops resolving from the local nameserver
cache and looks only to /etc/hosts.  It also refuses to query other
nameservers.

The really weird thing is that it seems to get well after an indeterminate
amount of time.  Suddenly, the local nameserver starts resolving, apparently
none the worse for wear.

Sometimes I can stop/restart named to make it well, but this doesn't always
work.

Has anyone seen this or have any theories?

Any help greatly appreciated.

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

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 10:40:07 GMT
From:      campbell@dev8h.mdcbbs.com (Tim Campbell)
To:        comp.misc,comp.protocols.tcp-ip
Subject:   Re: IBM 3270 Emulation Recommendation?

In article <GKBBL_C@ny1.ferranti.com>, birwin@ficc.ferranti.com (R. L. Bob Irwin) writes:
> 
> I'm looking for product information (hardware and software) and
> user recommendations for the following terminal/printer emulation
> problem:
> 
> Need to provide IBM 3270 terminal emulation on up to 30 Xwindow
> workstations networked via TCP/IP Ethernet to a fileserver.  Need
> to appear to the remote IBM Comm Controller as a 3274 Cluster
> Controller.  Support up to 32 LUs, mainly 3270 terminals, and a
> couple of 3270 printers.  Workstation hardware selection not
> complete, but may be Sun3s and SparcIIs.  Prefer to have the
> dedicated SNA/SDLC line attached to the File Server with an
> intelligent comm board providing the cluster controller
> emulation, but will consider other configurations.
> 
> |IBM |___|37x5|___|Sync |____  |Sync |___|File  |
> |HOST|   |Comm|   |Modem|   /__|Modem|   |Server|-----Enet----
>          |Cntr|            SNA             3274      | . . |  
>                                            Emula.   WS1   WS30

Use Sun's SNA/3270 software.  It does exactly what you want (also handles
file xfer w/IBM boxes using IBM's IND$FILE software).

  ---------------------------------------------------------------------------
	  In real life:  Tim Campbell - Electronic Data Systems Corp.
     Usenet:  campbell@dev8.mdcbbs.com   @ McDonnell Douglas M&E - Cypress, CA
       also:  tcampbel@einstein.eds.com  @ EDS - Troy, MI
 CompuServe:  71631,654	 	 (alias  71631.654@compuserve.com)
 P.S.  If anyone asks, just remember, you never saw any of this -- in fact, I 
       wasn't even here.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 12:29:39 GMT
From:      jj@dcs.leeds.ac.uk (J Jackson)
To:        comp.protocols.tcp-ip
Subject:   name handling in DNS resolvers

In experimenting with DNS (before dropping use of hosts files),
we came across differences in the way different software resolved names
that users had provided.

BIND (and derivations - most UN*Xes) build a search list of
progressively wider domains to successively append to the user
provided name. This gives a decent user interface where users only
need to specify enough 'local' part of the name - not the full
domainname of a service.

However some implementations do not provide such user friendly
procedures. e.g. FTP Inc's PC/TCP uses the algorithm that if the user
supplied name contains a '.' (period) it is used "as-is" in the DNS
resolution, otherwise a default domain is appended. (FTP Inc. support
staff don't think there is any need for change.)

Such 'simpler' (brain dead!) procedures may be ok in a site without
much sub-domaining, but for large sites users are forced to use fully
qualified domainnames for any service outside their local sub-domain.

Have others found this, and if so are you satisfied with the position?
I have found nothing specific in the Host Requirements or DNS RFC's.
Surely we should expect a standard appraoch to this?

=======================================================================
Jim Jackson                                  Email :
School of Computer Studies	        UK - JANET : jj@uk.ac.leeds.dcs
Leeds University                          Internet : jj@dcs.leeds.ac.uk
Leeds    LS2 9JT
UK                                           Phone :     +44 532 335451
=======================================================================
     Opinions! What Opinions? I just wield the brush round here.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 12:37:22 GMT
From:      scanlon@interlan.Interlan.COM (Mike Scanlon)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking packet formats of 802.1 (part D), spanning tree

Tom,
I don't have it in electronic form but I will snail it to you.  What's
your address.
		Michael Scanlon
		scanlon@interlan.com

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 13:28:26 GMT
From:      jaques@drbob.tay2.dec.com (Robert Royal Jaques)
To:        comp.protocols.tcp-ip
Subject:   <None>

Subject:OSPF and RIP interaction 
Lines: 31

--

We are in the process of iplementing an OSPF backbone network connected
to a lot of rip subnets.

During implementation we have run across this interesting question:

Should rip hop counts increase per circuit ala rip or remain fixed as
you cross an OSPF backbone.  Is there any guidance on this.  I can seem
to find mention in the OSPF draft RFC on rip hop counts.

Has anyone else faced this problem.

The router we are using seems to add a rip hop count for each ospf circuit.
However you  cannot adjust that metric on the ospf circuit as you can
on a RIP circuit

thanks

bob

___________________________________________________________________________
|          any relation with reality is purely coincidental               |
|_________________________________________________________________________|
|  Dr Robert R Jaques   !! dr bob !!       |  Mail addresses              |
|  Digital Equipment Corporation           |  jaques@setprv.enet.dec.com  |
|  Cororate Telecommunication Engineering  |  setprv::jaques              |
|  Littleton, MA                           |  bob jaques @ vro            |
|  tel 508-952-4024  dnt 227-4024          |                              |
 ___________________________________________________________________________

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 14:50:42 GMT
From:      eric@picard.sbi.com (Eric Ho)
To:        comp.protocols.tcp-ip,mail.list.sun-managers,comp.dcom.lans,erinet.mailing-list.sun.managers
Subject:   dropping SLIP connections...


Hi,

Does anyone out there know if SLIP would detach/drop the module/connection if
the remote site is powering off their Sun-at-home (or Xterm-at-home) or
modem-at-home ?

Currently, the current sequence of actions to take is to tip from your
Sun-at-home to make the call, exit tip without hanging up the modem and then
run slattach on the Sun-at-home and you're on the air.  This assumes that your
Sun-at-office already got the SLIP module pushed/attached to the kernel and
that your modem-at-office is in auto-answer mode.

What I want to do is to have the Sun-at-office to do some kind of
authenication each time I dial-in from home BEFORE the Sun-at-home push/attach
the SLIP module and then when I power-down my Sun-at-home/modem-at-home, my
Sun-at-office would pop the SLIP module from the kernel -- i.e. as soon as I
hangup the phone-call at home (either voluntarily or involuntarily as in a
thunderstorm), nobody else can SLIP into my LAN-in-office (via my
Sun-at-office).

Keeping the line up all the time or use dial-back modem at my office is no
good because my Sun-at-home could also be my Sun-at-vacation-home or
Sun-at-hotel or Sunclone-on-airplane.

[Please reply to the email address as described below].
--

==========================================
+ Eric Ho                          Email: eric_newsbox@picard.sbi.com
+ Salomon Brothers, Inc.  [SISS]   Phone: (201) 896-4356
==========================================

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 15:01:08 GMT
From:      goud@sicsun.epfl.ch (Mireille Goud)
To:        comp.protocols.tcp-ip
Subject:   Re: gateways ignores ICMP redirect


Thanks to the people who answered my question.

I want to summarize here the answers and why I have the problem.

The problem :

   We have 2 parallel backbones in the school (One ethernet backbone
and one fddi backbone). The departments are all connected to the
backbones with a cisco router. Some departments are connected to the
two backbones (with only one router which has one fddi interface and
at least two ethernet interfaces) and the other departements are
connected only on the ethernet backbone (in the futur all the
departments will be connected on the two backbones). 
(Why 2 backbones ? because we had the ethernet backbone already and
it was not too expensive to keep that backbone as a spare backbone).

   For the departments connected to the 2 backbones we want the
traffic uses the fddi backbone if it is running and the traffic uses
the ethernet backbone only if the fddi backbone is down.

   We couldn't obtain this result with the rip protocol so we use the
igrp protocol.

   The cray is connected to the 2 backbones with 2 different NSC
routers. These routers do not understand igrp protocol. Our idea was
to give a default gateway to the NSC routers and they would have
learned the better routes by ICMP redirect from the default gateway.



The answers :
   
  ICMP redirects are sent only by routers and processed only by hosts.
  In RFC 1009 4.5.5 they say that dumb routers should pay attention
to redirects. 


Conclusion :
   Maybe, it is difficult to consider NSC routers as dumb routers.
   So I have to give all the static routes to the NSC routers. That
is the progress...


Thanks


Mireille Goud
Sic - EPFL              goud@sic.epfl.ch

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 17:11:35 GMT
From:      nobody@blia.sharebase.com (Nobody at all)
To:        comp.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: IBM 3270 Emulation Recommendation?

In article <GKBBL_C@ny1.ferranti.com> birwin@ficc.ferranti.com (R. L. Bob Irwin) writes:
>
>I'm looking for product information (hardware and software) and
>user recommendations for the following terminal/printer emulation
>problem:
>
> [...]
>
>|IBM |___|37x5|___|Sync |____  |Sync |___|File  |
>|HOST|   |Comm|   |Modem|   /__|Modem|   |Server|-----Enet----
>         |Cntr|            SNA             3274      | . . |  
>                                           Emula.   WS1   WS30

While doing a Unix to System/370 port of an AI engine,
I used the SunLINK package to obtain the services of a timeharing house
for the 370 time.  The link was a lease-line LU2 from the Sun to the 370
and the Sun environment looked like

	____  |Sync |___|File  |
	   /__|Modem|   |Server|-----Enet---- | client WS's | ....
			
			 Sun3/xxx
			 running
			 SunLINK

This was quite satisfactory, although it did surface the 9600 baud limitation
normally seen by all remote 3270's (ie slow screen painting).

Recommend you contact your local Sun sales rep.

------
Jeff Beard		jeffb@sharebase.com

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 17:42:48 GMT
From:      bjork@NISC.SRI.COM (Steven Bjork EJ223)
To:        comp.protocols.tcp-ip
Subject:   Net 1?

Hm.

A traceroute for your inspection and comment vs. net 1:

Script started on Thu May 16 10:34:16 1991
phoebus-1>traceroute asylum.sf.ca.us
traceroute to asylum.sf.ca.us (192.48.232.17), 30 hops max, 40 byte packets
 1  srinet-gw (192.33.33.3)  4 ms  4 ms  3 ms
 2  BARRNET-GW.SRI.COM (128.18.1.5)  2 ms  2 ms  2 ms
 3  barrnet^36.1 (131.119.36.1)  5 ms  3 ms  3 ms
 4  SU-A.BARRNET.NET (131.119.251.200)  5 ms  6 ms  4 ms
 5  NSS13.BARRNET.NET (131.119.254.240)  7 ms  5 ms  5 ms
 6  129.140.13.75 (129.140.13.75)  12 ms  11 ms  12 ms
 7  129.140.70.13 (129.140.70.13)  30 ms  26 ms  29 ms
 8  129.140.6.14 (129.140.6.14)  31 ms 129.140.6.78 (129.140.6.78)  35 ms 129.140.6.14 (129.140.6.14)  33 ms
 9  129.140.75.6 (129.140.75.6)  68 ms  80 ms  78 ms
10  129.140.11.14 (129.140.11.14)  69 ms 129.140.11.78 (129.140.11.78)  72 ms  85 ms
11  129.140.73.11 (129.140.73.11)  118 ms  149 ms  124 ms
12  129.140.9.16 (129.140.9.16)  149 ms 129.140.9.80 (129.140.9.80)  127 ms 129.140.9.16 (129.140.9.16)  117 ms
13  College-Park.MD.ALTER.NET (192.41.177.249)  127 ms  122 ms  127 ms
14  Falls-Church.VA.ALTER.NET (137.39.11.1)  135 ms  129 ms  126 ms
15   (137.39.2.2)  199 ms  195 ms  198 ms
16  TISMtV-gw.ALTER.NET (137.39.3.2)  185 ms  185 ms  202 ms
17  192.70.178.7 (192.70.178.7)  188 ms  212 ms  195 ms
18  1.0.0.2 (1.0.0.2)  364 ms  365 ms  322 ms
19  1.1.0.2 (1.1.0.2)  441 ms  461 ms  1080 ms
20  asylum-net^17 (192.48.232.17)  450 ms  666 ms  756 ms
phoebus-2>^
script done on Thu May 16 10:34:38 1991

Puzzled,

--Steven

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 17:48:18 GMT
From:      rbraun@spdcc.COM (Rich Braun)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.misc,comp.binaries.ibm.pc.d,comp.dcom.lans,comp.sys.novell
Subject:   SOSS version 3.2 -- Bigger Buffers


                SOSS Version 3.2 - An NFS server for DOS
                ----------------------------------------

     SOSS is a file server conforming to SUN Microsystems' NFS protocol
     version 2. It will run on IBM-PC compatibles under Microsoft
     MS-DOS, using any Ethernet interface supported by Clarkson
     University's packet drivers.

     Version 3.2 has the following improvements over version 3.1:

	- I/O requests can be up to 1024 bytes long; the old limit
	  was 512.
	- Writing to a file now sets the correct modification time.
	- A filesystem with 0 bytes free can now be mounted.
	- A detailed installation guide has been written.

     It can be used in a standalone environment as a file server for
     DOS or Unix users running client NFS (e.g., Sun PC-NFS), or it can
     be used within a Novell NetWare environment to provide transparent
     access to files on Novell servers via NFS.

     SOSS relies on source code taken from PC/IP, a public-domain TCP/IP
     package developed at CMU and MIT.  It also relies on packet drivers
     collected and distributed by Clarkson University.  These drivers
     allow you to set up a dual-protocol stack, allowing simultaneous
     access to TCP/IP and NetWare using a single Ethernet interface card.
     (They are in a file called drivers.zip on sun.soe.clarkson.edu and
     on many of the same systems which carry SOSS.)

     SOSS is free software.  You may use it within your organization for
     any purpose desired.  You may redistribute it to other organizations,
     provided you do not earn a profit when doing so, that you make source
     code available, and that you abide by the terms of the Gnu General
     Public License (see the file COPYING).

     The following systems currently distribute SOSS via anonymous ftp:

        System                         Directory	Contact
        ------------                   ---------        -------
        spdcc.com			pub/sos		rbraun    (MA)
        sun.soe.clarkson.edu		pub/ka9q	nelson    (NY)
        grape.ecs.clarkson.edu		pub/msdos/tcpip	nelson    (NY)
	cs.ep.utexas.edu		pub/sos		pwesley   (TX)
	garbo.uwasa.fi			pc/connect	hv	  (Finland)
	kirk.bu.oz.au			pub/pc/net/soss	bambi     (Australia)
	nestroy.wu-wien.ac.at		pub/src/PCtcp/soss  mah   (Austria)

      The following system currently distributes SOSS via anonymous uucp or
      via a BBS download:
 
         System		Phone Number	Directory	Contact
         ------------   ------------	---------	-------
         sir-alan.UUCP	812 333 0450	/u/pubdir/SOSS	mikes@iuvax.cs.
							  indiana.edu
  
      For more information on uucp/BBS sites contact the SYSOP directly.

     BITNET access:

	Bitnet sites can access a mail-server called BITFTP@PUCC.BITNET;
	just send a message HELP to that address to get just that (i.e
	help).  Example of a connection to sun.soe.clarkson.edu follows:

	FTP sun.soe.clarkson.edu UUENCODE
	USER anonymous
	CD pub/ka9q
	DIR
	BINARY
	GET driverss.zip
	QUIT

     E-mail retrieval:

	Send mail to archive-server@sun.soe.clarkson.edu with a body
	containing the single word "help".  That works for everybody,
	BITNET, UUCP, whatever.

     Direct modem retrieval:

	You can phone in to grape.ecs.clarkson.edu at (315) 268-6667,
	and download pub/msdos/tcpip/soss.zoo.

     When in doubt:

	Or send $10 for a floppy diskette.  Be sure to say what disk
	density you want.

	Russell Nelson
	11 Grant St.
	Potsdam, NY 13676

     SOSS was written by See-Mong Tan, Harvard Holmes, Craig Eades, and
     Richard Braun.

[You may repost this for the benefit of others.]

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 18:17:27 GMT
From:      mmorse@Z.NSF.GOV ("Michael H. Morse")
To:        comp.protocols.tcp-ip
Subject:   PC Remote control software over the Internet

Has anyone tried using one of the PC remote control software packages
(such as CloseUp or Carbon Copy) over the Internet?  The idea would be
to connect the controlling PC to a terminal server, Telnet to a
milking machine, and then to the controlled PC.  Does anyone know
authoritatively if such a thing is possible?

Thanks in advance.

--Mike

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Thu, 16 May 1991 18:23:21 GMT
From:      jpdia@mbunix.mitre.org (Dia )
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   information on IDPR

Does anyone out there in netland have any information on IDPR
(Inter-Domain Policy Routing) ?  I am specifically interested in any
papers or documents that have been published about it.  Where can
I get my hands on copies of these publications ?

Thanks a lot in advance

jay

P.S.

Note that I am looking for information on IDPR, *not* IDRP (Inter-Domain
Routing Protocol)....  I am pretty sure they are different things.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 19:25:13 GMT
From:      xxwrp@picasso.lerc.nasa.gov (Bill Palenske)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   IBM Series/1 to RS/6000 Questions


I am looking for an equivalent product to the _Yale Ascii_ program 
(IBM Series/1) to provide the same function for an IBM RS/6000
functioning as a TCP/IP server.  Access to IBM hosts is provided by the  
RS/6000 TN3270 command.  Currently there is no product that I am
aware of that provides a transparent mode of operation for the RS/6000
TN3270 command.  The transparent mode of the YALE ASCII program would
allow me to interrupt 3270 data stream transmission and display graphics 
on a TEKTRONICS type terminal.  

Email will do.  I will summarize.  Thanks.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 21:13:44 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

From article <1991May15.143317.4297@oar.net>, by karl.kleinpaste@osc.edu:
> 
> PS- No, emphatically, general IP (telnet) access into CompuServe is
> _not_ part of the game plan.

How did you guess people could be interested in this, and so why
isn't compuserv interested in this - we do have a commercial internet
by now too, don't we ?
---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless
             bandwidth - the final frontier.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 21:20:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   DEC protocol traffic formats

Netlanders, 

     I would appreciate someone directing me to a source that gives the 
standard format for the DEC protocol traffic packets.  I am interested in 
reducing the amount of DEC packets on a segment which is used exclusively 
for TCP/IP.  Some devices were manufactured by DEC, so I really don't need 
to filter on ethernet addresses of DEC origin.  (Did I mention that the 
segment is an ethernet segment?  I suppose one could infer that, but in case 
this isn't as "across the board" as I believe it to be, I wanted to clarify.)

     Is there such a source, or am I looking for something that doesn't exist?

     Thanks in advance for whatever pointers I receive.  


                                                       Kathy

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 21:24:35 GMT
From:      yuko@dbaccess.com (Yuko Tanaka)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP software on VM


   Does anybody know TCP/IP software which runs on VM (CMS or GCS) and 
has socket interface to application?   SAS C interface is the best for
us.  
   
   IBM TCP/IP for VM (R1.2) does not have socket interface and also 
requires IBM C for System/370 (we are calling White Smith C) which we don't
want to use.         
  
-- 
Yuko Tanaka                     INTERNET: yuko@dbaccess.com      V     V 
c/o DB Access Inc.              UUCP: {uunet,mips}!troi!yuko  ==  .   .  ==
2900 Gordon Avenue, Suite 101   FAX: (408) 735-0328           ===   o   === 
Santa Clara, CA 95051           TEL: (408) 735-7545           ===   v   ===

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 21:28:35 GMT
From:      henderso@mprgate.mpr.ca (Mark C. Henderson)
To:        comp.unix.wizards,comp.protocols.tcp-ip,comp.unix.programmer
Subject:   need help with TCP/IP (socket) performance problem


I don't know if there is any way around this, but here is our problem...

We have an application which opens a socket to a Xyplex terminal server
in an HP terminal emulator window. HP terminals use (of course) ENQ/ACK
flow control and the serial line we are connected to via the Xyplex is
9600 bps. Unfortunately, we're getting absolutely miserable performance
with this set up (screen update...&c. is extremely slow). Typical
sessions run almost twice as slowly (in terms of screen update) as they
do with an HP terminal hooked directly to the serial line.

A small diagram follows.
              
Workstation| 		     
running	   |  TCP/IP socket  |      |	Serial line    | Host which 
HP terminal|-----------------|Xyplex| -----------------| requires an HP
emulator   |    ethernet     |      |		       | terminal

I figure the problem is being caused by the use of ENQ/ACK flow control
(no choice) perhaps combined with some of the other peculiarities of
the HP terminal protocol, as it doesn't show up with this setup if we
replace the HP terminal emulator with a VT100 emulator (say xterm) and
the serial connection with one to a Unix host.

One thing we've tried is the TCP_NODELAY option, which doesn't seem to
give us any significant performance improvement (it seemed reasonable that
it might...) Are there are some other options that we should try?

Any help would be greatly appreciated.

Mark
-- 
Mark C. Henderson, Special Service Networks, MPR Teltech Ltd.
8999 Nelson Way, Burnaby, BC V5A 4B5 CANADA	
Email: 		henderso@mpr.ca, uunet!ubc-cs!mprgate!henderso
Telephone: 	+1 604 293 5474 

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 23:15:32 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.misc,comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: IBM 3270 Emulation Recommendation?

In article <13972@blia.sharebase.com> jeffb@blackhaw.UUCP (Jeff Beard) writes:
>
>While doing a Unix to System/370 port of an AI engine,
>I used the SunLINK package to obtain the services of a timeharing house
>for the 370 time.  The link was a lease-line LU2 from the Sun to the 370
>and the Sun environment looked like
>
>	____  |Sync |___|File  |
>	   /__|Modem|   |Server|-----Enet---- | client WS's | ....
>			
>			 Sun3/xxx
>			 running
>			 SunLINK
>
>This was quite satisfactory, although it did surface the 9600 baud limitation
>normally seen by all remote 3270's (ie slow screen painting).
   
   There is no such limit.  If your 3270 emulator will allow
   faster speeds, you can run at 64 Kbit or even higher...as
   long as the FEP has the proper hardware.  

   Neither NCP nor VTAM care about the baud rate for 3270 in the
   gen....it is part of the link parameters...unrelated to LU or
   PU daffynishions.

   A lot of the smaller Unix boxen can't run faster, but a
   PC with a smart card or a Unix with smart front-end certainly
   can.

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      16 May 91 23:23:35 GMT
From:      rick@ut-emx.uucp (Rick Watson)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Novell/IPX and packet drivers

I have a token ring attached PC that is a Novell/IPX client that I
would also like to run NCSA Telnet on.  There is already IP on the
token ring; I don't need to route IP to some other segment. 

I know this can be done with the IPXPKT packet driver, but this
requires another machine to unwrap the IP encapsulated in IPX
packet, right?  Will Novell/IPX use a token ring packet driver
so I can run both IPX and IP?

Rick Watson 
The University of Texas Computation Center, 512/471-3241
   internet: rick@akbar.cc.utexas.edu        bitnet: watson@utadnx
   uucp:     ...!cs.utexas.edu!ut-emx!rick   span:   utspan::utadnx::watson

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 04:38:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   KNET 200

I've reviewed the archives, looking for observations on the KNET
software, and found mixed reactions, with some of the comments from
several years ago quite negative.

What's the current status?  Has it been brought up-to-speed, or should
we still look elsewhere (given that we were given the hardware)?

--Frank

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 10:05:39 GMT
From:      pcl@robots.ox.ac.uk (Paul Leyland)
To:        comp.os.vms,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,comp.sys.dec
Subject:   Summary of "VMS lpd (Line Printer Daemon) wanted" responses


A little while ago, I posted a request for information about a
Unix-compatible line printer daemon to run under VAX/VMS.  Now that
the response rate has fallen, here's the promised summary.

First off, let me thank the following people for their assistance:

	bernards@ECN.NL				Marcel Bernards
	meadows@cslvax.weeg.uiowa.edu		Howard Meadows
	allen@ecf.ncsl.nist.gov.		Dan Allen
	cczanj@vax.ccc.nottingham.ac.uk		Andy Jack
	lilianstrom@krang.fnal.gov		Al Lilianstrom
	mvrf6@tnofel.fel.tno.nl			Martin van Roon
	jansen%decnet.madraf@vms3.macc.wisc.edu	Stephan Jansen
	barkelew@ccwf.cc.utexas.edu		David Barkelew
	xxseub@osprey.lerc.nasa.gov		Steven Eubanks
	hughes@bronze.ucs.indiana.edu		Larry Hughes
	wong_a@summer.chem.su.oz.au		Adrian Wong
	smith@mcclb0.med.nyu.edu		Ross Smith
	cliffb%isavax@uunet.uu.net		Cliff Bedore

(Some of the above are "metoos", but thanks anyway.)

Most everyone recommended CMU-TEK.  For example:

> You could buy CMU-TEK 6.3 (or higher ?) from the Carnegy-Mellon
> University for a few hundred bucks We have that stuff here on almost
> all our VMS systems.  LPR LPD TELNET FTP SMTP and some more stuff is
> implemented very well.
 
> Lotta cheaper than UCX or Multinet.

and ...

> You can order CMU-TEK 6.5 for $200 on TK50 at:
 
> Karen Heilman
> Carnegie-Mellon University
> 4910 Forbes Avenue, UCC 124
> Pittsburg, PA 15213, USA


Matthew Madison made the following offer ...

> I have taken the CMU-Tek LPR/LPD software (from V6.4 with some mods) and
> ported it to UCX.  If you've got CMU-Tek already, I can share it with you.


However, Dan Allen said:

> 	I have a version of LPD/LPR originally developed for VMS and
> The Wollongong Group's WIN/TCP software.  A number of people have
> expressed an interest in using it with UCX and a port of the client
> (VMS print symbiont) was done by a gentleman in Germany.  The server
> code is being converted by a gentleman in Atlanta at this time.  The
> last report I had was that it was working and he was in the process
> of final testing.  I'm maintaining a list of people who are using this
> software and will announce new versions as they become available.
> 
> 	The source (VAX C) for TWG and the UCX symbiont are available
> via anonymous ftp from this site (ECF.NCSL.NIST.GOV = 129.6.48.2).  It
> is stored as a VMS saveset (BSDPRINT.BCK).


The other commercial offering mentioned was Multinet.  For example:

> Buy Multinet from TGV instead of UCX as Multinet's LPD server allows exactly 
> what you want.  Works real nice.  I have it running on a number of machines.

and ...

> P.S. IMHO Multinet from TGV beats the pants off UCX at this juncture and
>      is a heck of a lot cheaper. It provides all of the usual Internet
>      services including BOTH CLIENT AND SERVER NFS!  Great support and
>      nice people to work with to boot.  They also have a discount for
>      educational institutions.

and ...

> 	Switch to MultiNet, it has solved our Unix->VMS printing
> problems and appears to be quite a robust implementation of TCP/IP
> for VMS (much better than CMU). Some surprising net software runs
> under MultiNet (rusers, finger, rsh etc.). At the moment I'm reading
> the news using ANUNews (for VMS), which is using the NNTP service 
> over MultiNet to query a Unix news server. Nice!


Once again, thanks folks.

Paul Leyland

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 10:09:52 GMT
From:      slootman@dri.nl (Paul Slootman)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Program to print to Spiderport TCP server needed

Hi,
I need to print via TCP/IP to a serial port on a Spiderport T151 terminal
concentrator. In the manual of the Spiderport there is a listing of an
example program, however, before I start typing, I wondered if this has
been done before (of course it has!). Could some kind soul mail the
program? I'll cancel this article as soon as I get a reply...

I need it (at this time) for SCO Xenix and/or Unix. In the future I
need it for other systems as well. I have another program which does
this, however, that one works fine for Chase Iolans, but not for
Spiderports. I think this is because Iolans run Lachman TCP/IP, and
the Spiderports run Spider TCP/IP (no surprises there). Am I right?
Why should this make a difference?

Th[advance]anks,

Paul.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 14:15:28 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

eckert@immd4.informatik.uni-erlangen.de writes:
   > PS- No, emphatically, general IP (telnet) access into CompuServe is
   > _not_ part of the game plan.

   How did you guess people could be interested in this,

No guessing involved; the two most common questions I get about CServe
are "how do I address a subscriber" and "can I telnet there?"

   and so why isn't compuserv interested in this

I don't know.  For one thing, though, their hosts don't speak IP.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 14:53:04 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   PC Remote control software over the Internet


   From: "Michael H. Morse" <mmorse@z.nsf.gov>
   Date: Thu, 16 May 1991 14:17:27 EDT

   Has anyone tried using one of the PC remote control software packages
   (such as CloseUp or Carbon Copy) over the Internet?  The idea would be
   to connect the controlling PC to a terminal server, Telnet to a
   milking machine, and then to the controlled PC.  Does anyone know
   authoritatively if such a thing is possible?

My gut feeling is that you're probably going to have to find a remote
control package that contains support for the INT14 interface. FTP
Software's PC/TCP allows you to TELNET to some host, and then invoke a
terminal-emulation package that supports INT14, and you get everything
you'd get from a 9600 bps dialup connection, with the exception of
session initiation. You have to TELNET, then fire up the emulator, and
once connected, you can't TELNET somewhere else without starting the
whole process over again. TELNETing to a router would alleviate this
last sticking point.

If you find a "Carbon Copy", "Close UP",-type thing that supports
INT14, I would also be interested in hearing about it. I looked last
year, and couldn't find anything.

Bob Stratton           | 
Stratton Systems Design| SMTP: strat@gnu.ai.mit.edu, c_bstratton@hns.com
Alexandria, Virginia   | PSTN: +1 301 409 2703
"Personally, I think the DNS administrative interface was designed by the IRS."
							--Mark Beyer

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 15:33:27 GMT
From:      romkey@asylum.asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   re: name handling in DNS resolvers

As the person who designed the way DNS lookup works in PC/TCP, I'll
explain to you why it's done that way.

Suppose you do your domain name lookup by working your way up the
domain name. Your host's domain name is W.X.Y.Z. It's presented with
name A; so first it tries A.X.Y.Z, then it tries A.Y.Z, etc.

Or, perhaps you present it with A.B and it tries A.B, A.B.Z, A.B.Y.Z.

There are other searches it could do, too.

In any of these cases, the user can have the name resolve into a
system that's not the one they expected, and then have no way to
specify that name. By the principle of least astonishment, you
shouldn't allow that to happen.

For instance, if I'm using the name LEEDS.AC.UK, and I'm inside
MIT.EDU and MIT happens to have a LEEDS.AC.UK.MIT.EDU, I may never be
able to contact the true LEEDS.AC.UK because my searching-DNS resolver
decides that it should use the one inside MIT.

And, if you say "Well, let's first try the top level domain
interpretation rather than the path", then you'll have people who
expect consistent behaviour and are rather shocked that when they type
LEEDS.AC.UK they get the top level host, rather than
LEEDS.AC.UK.MIT.EDU.

Before you argue that nobody has name duplication like that, let me
make two points:

1. Such names have existed. The Media Lab at MIT had several names
like EDU.MIT.EDU for a while.

2. Nothing prevents them from existing; and if software you provide
won't work with them, you WILL find sites that create them and them
are functionally cursed because of an implementation decision you
made.

Basically, I agree that doing the searching is handy, but I think it's
also brain damaged because it can lead to ambiguous cases and wall off
the users from sections of the DNS so that they can no longer access
chunks of the name space, because their searching algorithms find
the incorrect ones first.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 16:52:41 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Partial subnetting

In article <=~P_0Q&@warwick.ac.uk> cudcv@warwick.ac.uk (Rob McMahon) writes:
>We have a class B address (137.205.0.0) for the University.  Currently the
>whole campus is running without subnets, with bridges between each department
>and the backbone, but we allocated the numbers such that we could later give
>each department its own subnet, and change the bridges for routers should it
>become necessary.
>
>... our first department ... actually wants to be split off with a router,
>...  Here was the plan (internet address/netmask):
>
>			    137.205.0.0/0xffff0000
>				      |
>				      |
>			 ----------------------------
>			 |                          |
     Bridge			 Router
>			 |  			    |
>              137.205.232.0/0xffff0000	 137.205.176.0/0xfffffc00
>
>It seems that to make this work the routing tables on the Unix hosts ought to
>have a netmask associated with each entry, but it's not there.

Briefly: Yes, it will not work, for the reason stated. The next
generation of IP routers will keep masks with routes at all times, but
the routing protocol software to distribute and manage such routes is
still not frozen solid enough to give to the unwashed masses (OSPF-2 is
in draft, and there is still a vocal minority that insists that "dual
IS-IS" MUST be supported).

Universally masked routes will also resolve the other thing that
"intuitively ought to work": Disjointed subnets.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 17:35:20 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers


    BIND (and derivations - most UN*Xes) build a search list of
    progressively wider domains to successively append to the user
    provided name...
    
    However some implementations do not provide such user friendly
    procedures. e.g. FTP Inc's PC/TCP uses the algorithm that if the user
    supplied name contains a '.' (period) it is used "as-is" in the DNS
    resolution, otherwise a default domain is appended. (FTP Inc. support
    staff don't think there is any need for change.)
    
The Internet's experience with defaulting of partial domains is poor.
Perhaps my response to another person who recently asked for the same thing
will explain.
    
    He said:

    Machine "opus" in domain "eng.hou.xyz.com" wishes to establish a
    connection with machine "milo" in "se.hou.xyz.com".  Currently "opus"
    user must use the fully qualified domain name in his command, i.e. tn
    "milo.se.hou.xyz.com".

    Under other TCP/IP implementations, i.e Lachmann, BSD, SUNOS, the
    "opus" user only has to specify the portion of the name different
    from his own domain, i.e. telnet "milo.se".

The problem is that domain names are hierarchical, and the Internet is big.
In an Internet environment, given your example, the best 'opus' can do is to
issue the following DNS queries to translate "milo.se":

	milo.se.eng.hou.xyz.com			fails at eng.hou.xyz.com
	milo.se.hou.xyz.com			works

However, the host 'opus' will never be able to reach a machine named "milo"
in the "se" domain (Sweden).  This is perplexing to the user and frustrating
to explain if you're a Tech Support person.  If you reverse the order of
search in order to allow access to all top-level domains, 'opus' will send:

	milo.se					goes to the DNS root & fails
	milo.se.com				goes to the DNS root & fails
	milo.se.xyz.com				goes to xyz root & fails
	milo.se.hou.xyz.com			goes to hou.xyz.com, works.

Two failed queries to the DNS root for most lookups is a major price to pay,
and the people who run the DNS root know where I live; I'd suffer severely
if I did this to them...

The Host Requirements RFCs (1123 in this case) address this issue (pp 83, 84),
and their view of "search lists" is that they should not be implemented unless
the host is capable of caching "negative responses", which DOS PC/TCP's TSR
kernel cannot do at this time.  Such a cache might use a significant amount
of DOS memory; would you consider 8Kb or 16Kb a reasonable price to pay for
this feature?

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

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 17:43:06 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: commercial access in the chicago area

>would some kind soul(s) please mail me the names of the firms
>providing commercial internet access in the chicago, illinois area.
>
>does cicnet have any commercial customers?

I'm sure CICNet would be happy to talk to you.  I think they have some
commercial customers; I know they have talked to a few potential
customers.

I can't find an "info" address for them, but you could try
holbrook@cic.net, or call (313) 998-7680.

Doug Nelson
Michigan State University

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 18:07:36 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   KNET 200


   Date: Thu, 16 May 1991  22:38 MDT
   From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>

   I've reviewed the archives, looking for observations on the KNET
   software, and found mixed reactions, with some of the comments from
   several years ago quite negative.

   What's the current status?  Has it been brought up-to-speed, or should
   we still look elsewhere (given that we were given the hardware)?

I had client last year that was in the throes of bringing up KNET with
both MVS and VM machines. As I understood it, Spartacus was rewriting
code specifically for this client. I witnessed around 8 revisions in
3Q and 4Q of last year, but their stuff still didn't resolve to DNS
servers. I worked in detail with the SMTP implementation, and I wasn't
impressed - I'd look at the U. Wisconsin TCP/IP implementation.

Bob Stratton           | 
Stratton Systems Design| SMTP: strat@gnu.ai.mit.edu, c_bstratton@hns.com
Alexandria, Virginia   | PSTN: +1 301 409 2703
"Personally, I think the DNS administrative interface was designed by the IRS."
							--Mark Beyer

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 18:08:03 GMT
From:      wmarko@UB.D.UMN.EDU (William J. Marko)
To:        comp.protocols.tcp-ip
Subject:   Re: commercial access in the chicago area

since i forgot to say 'thanks in advance', i had better issue a
blanket 'thank u' to those who provided information.

several folks wrote to provide the needed info.

the providers so far are:	

cicnet
psi, inc
uunet's alternet

if there are others, they have not surfaced yet.  thanks for the
leads.

> >would some kind soul(s) please mail me the names of the firms
> >providing commercial internet access in the chicago, illinois area.
> >
> >does cicnet have any commercial customers?
> 
> I'm sure CICNet would be happy to talk to you.  I think they have some
> commercial customers; I know they have talked to a few potential
> customers.
> 
> I can't find an "info" address for them, but you could try
> holbrook@cic.net, or call (313) 998-7680.
> 
> Doug Nelson
> Michigan State University
> 


-- 
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 18:12:35 GMT
From:      freeman@ux1.cso.uiuc.edu (Jay Freeman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.misc
Subject:   Re: Running TCP/IP on Novell workstations(Netware 3.1)

jaj@sactoh0.sac.ca.us (Jelle A. Jorritsma) writes:

>We are starting a project to network our Novell workstations to
>other hosts(Unisys A-series,IBM AS400, Unix servers,etc) via
>TCP-IP. We've got an evaluation package from FTP and all we want to
>do initially is just to tie in two stations on the Novell network
>thru TCP/IP. We are able to bring up just the TCP/IP on the
>stations or just Netware but not both(which is our goal). The
>ethernet cards we are using are ne2000 and we have ne2000 packet
>driver. We also have gone thru the SHGEN to generate a new IPX
>shell. Listed below is what's in the autoexec.bat:
>REM NE2000 using IRQ=5, I/O=320h 0h320h
>ne2000 -n 0x60 0x05 0x320h 
  add -d here
>ipx
>NET3  
 
>Everything loaded fine, until net3 which returns File Server not
>found.
>Supposedly, the ne2000 packet driver's -n option would allow it to
>deal with the 802.3/Ethernet II(used by TCP/IP) without
>reconfiguring the server. FTP's suggestion was that I try
>reconfiguring the LAN driver on the server to recognize the two
>protocols. Unfortunately, the cards we are using in our servers do
>not support ETHERNET II. 
 
>Has anybody out there encountered this problem and found a solution
>without reconfiguring the server???
>All help would be greatly appreciated!!! 


Hi, try adding the -d option to the packet driver. This delays (-d, getit?)
execution of the packet driver until after NET3 has completed its business.
We use this successfully here with wd8003 cards. Good luck, Jay

e-mail: freeman@ux1.cso.uiuc.edu

>---------------------------------------------------------
>=======jelle jorritsma======jaj@sactoh0.SAC.CA.US========
>---------------------------------------------------------
-- 
*************************************************************************
* 73 de Jay, WT9S     Internet: freeman@ux1.cso.uiuc.edu                *
*                     Packet:   wt9s@n9hhi.il.usa.na                    *
*************************************************************************

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 18:55:17 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   dns NOT working

In the course of trying to debug why many name servers do not resolve
my 1.32.165.139.in-addr.arpa the first time they need it and do it
all right the second time and on until some cache times out something,
I started to use nslookup to perform non recursive queries.
Now, I find that the root server C.NYSER.NET 192.33.4.12 replies nothing,
not even in NS section, to the query for vm1.ulg.ac.be A that's the
authoritative server for 165.139.in-addr.arpa.
Moreover, it replies nothing for "be" SOA or NS.

What's the right door to knock at in case of such problems?

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 19:51:47 GMT
From:      Piet.Beertema@MCSUN.EU.NET
To:        comp.protocols.tcp-ip
Subject:   Re: dns NOT working


	Now, I find that the root server C.NYSER.NET 192.33.4.12 replies
	nothing, not even in NS section, to the query for vm1.ulg.ac.be A
	that's the authoritative server for 165.139.in-addr.arpa.
	Moreover, it replies nothing for "be" SOA or NS.
I just queried c.nyser.net for the soa and ns
records for a number of other top level domains
and just got "noerror", but no information.
Looks like their nameserver is messed up.

	What's the right door to knock at in case of such problems?
nyser.net.	86309	SOA	nisc.nyser.net.  zort.nisc.nyser.net. (
In this case zort@nisc.nyser.net, I'd say. I'm
including him (her?) in the Cc.


	Piet

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      17 May 91 20:07:26 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   telnet and Nagle's algorithm

>
>...Based on the responses I received, I would suggest the following
>additions to RFC1122/1123:
>  
>    1. Where a terminal emulator is running on a workstation directly
>       on the Internet, the system SHOULD ensure that escape sequences are
>       transmitted in a single TCP packet....
>

The basic problem (and the reason folk warned you away from the algorithm
you are now using) is that there is no such thing as a TCP packet.  A TCP
connection just transfers streams of bytes with no record boundries.  Every
so often this list gets a question along the lines of 'I do a write of N bytes
but sometimes my read doesn't get all N bytes'.  The answer is that any
assumptions made about how TCP traffic is handled are eventually doomed
to failure.

>
>The writers of RFC 1122 (Requirements for Internet Hosts) were
>apparently aware of this kind of problems, because they gave SHOULD
>status to the Nagle Algorithm, and MUST status to letting an application
>turn it off....
>
>...I would remind implementors that RFC1122 says they MUST allow an
>application to turn off Nagle.  Does anyone know how this is done in
>practice?  I don't think a site configuration option really meets this
>requirement, but perhaps I misinterpret the spec.
>

Yet more bad news.  The primary reason for allowing Nagle's algorithm to be
turned off was X-Windows.  Nagle's algorithm is very bad for any application
(such as X-windows) with short bursts of high priority traffic.  For these
sorts of applications, most (all?) vendors who do Nagle allow 'no Nagle' as
an option when opening a connection.

Thus, it is the *application* which can turn off Nagle, not the user.  Even
worse from your point of view, the one application you would have a very
tough time convincing people should be un-Nagled, the one application which
generates the overwhelming majority of 'wasteful' small packets in the
Internet, the one application for which Nagle was designed, is telnet.

enjoy (or more accurately, sorry),
leo j mclaughlin iii
ljm@ftp.com

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 01:25:01 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: PC Remote control software over the Internet

>Has anyone tried using one of the PC remote control software packages
>(such as CloseUp or Carbon Copy) over the Internet?  

Yes, (though only over very little pieces).  Get two PCs running the
NetBIOS LAN version of CloseUP/Carbon Copy and a vendor of NetBIOS over
TCP/IP which supports M/P-node or extended B-node services.  Stir gently and
hope the delay characteristics don't upset the PC software too badly....

>...The idea would be to connect the controlling PC to a terminal server,
>Telnet to a milking machine, and then to the controlled PC....

..Sorry, no telnet allowed if you really want remote control -- you need
CloseUP/Carbon Copy type software running over TCP/IP at both ends.  If
you fit Stanford's licensing characteristics you can get their VT100
emulation telnet server for DOS, but that really is a very different beast.

>Does anyone know authoritatively if such a thing is possible?
    
Yes.  Though as I mentioned, your mileage will vary.

enjoy,
leo j mclaughlin iii
ljm@ftp.com

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 08:12:28 GMT
From:      johnm@vaxc.cc.monash.edu.au
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Running TCP/IP on Novell workstations(Netware 3.1)

jaj@sactoh0.sac.ca.us (Jelle A. Jorritsma) writes:

>... We are able to bring up just the TCP/IP on the
>stations or just Netware but not both(which is our goal). The
>ethernet cards we are using are ne2000 and we have ne2000 packet
>driver. We also have gone thru the SHGEN to generate a new IPX
>shell. Listed below is what's in the autoexec.bat:
>REM NE2000 using IRQ=5, I/O=320h 0h320h
>ne2000 -n 0x60 0x05 0x320h
>ipx
>NET3
>Everything loaded fine, until net3 which returns File Server not
>found.

Hopefully you have Version 9 of the Clarkson Packet Driver collection.
Version 8 had a small omission which broke the -n functionality.

Make sure you did SHGEN using BYU's PDSHELL.OBJ, and not a NE2000
driver.  You can't have the NE2000 packet driver trying to control the
Ethernet card, and a NE2000 driver in IPX trying to control the Ethernet
card at the same time.  The PDSHELL code will make IPX use the packet
driver for I/O.

>Supposedly, the ne2000 packet driver's -n option would allow it to
>deal with the 802.3/Ethernet II(used by TCP/IP) without
>reconfiguring the server. ...

Yes, the -n option will allow packets with Novell's 802.3 packet
encapsulation to be used, instead of Novell packets with Ethernet II
encapsulation as normally used by BYU's PDSHELL.

>Has anybody out there encountered this problem and found a solution
>without reconfiguring the server???

The code in the -n option was developed to avoid having to reconfigure
servers (and obtain Ethernet II Boot ROMS).

freeman@ux1.cso.uiuc.edu (Jay Freeman) writes:

>Hi, try adding the -d option to the packet driver. This delays (-d, getit?)
>execution of the packet driver until after NET3 has completed its business.
>We use this successfully here with wd8003 cards. Good luck, Jay

Not quite.  The -d option delays the packet driver's initialization of
the Ethernet card until the packet driver is actually used (by NET3) for
the first time.  This allows a PC to boot from a Novell server using the
Ethernet driver in the Novell Boot ROM and load the packet driver,
IPX_PD and NET3 and close the boot image file before the packet driver
takes over control of the Ethernet board.  (More gory details available
on request.)

If you aren't remote booting, I can't see any reason to use -d, and it
may suppress some error reporting information.

        John
--
John Mann, Leader - Networking Section  | johnm@vaxc.cc.monash.edu.au
Computer Centre, Monash University      | phone: +61 3 565 4774
Clayton, Vic 3168, Australia            | fax:   +61 3 565 4746

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 17:03:39 GMT
From:      RAF@CU.NIH.GOV (Roger Fajman)
To:        comp.protocols.tcp-ip
Subject:   Re:  PC Remote control software over the Internet

> >Has anyone tried using one of the PC remote control software packages
> >(such as CloseUp or Carbon Copy) over the Internet?
>
> Yes, (though only over very little pieces).  Get two PCs running the
> NetBIOS LAN version of CloseUP/Carbon Copy and a vendor of NetBIOS over
> TCP/IP which supports M/P-node or extended B-node services.  Stir gently and
> hope the delay characteristics don't upset the PC software too badly....

Most NETBIOS over TCP/IP implemetations (including FTP Software's) seem
to be B-mode only.  Can someone name some that aren't?  TCP/IP protocol
implementations that aren't internetworkable (such as B-mode NETBIOS) seem
like almost a contradiction in terms to me.

> >...The idea would be to connect the controlling PC to a terminal server,
> >Telnet to a milking machine, and then to the controlled PC....
>
> ..Sorry, no telnet allowed if you really want remote control -- you need
> CloseUP/Carbon Copy type software running over TCP/IP at both ends.  If
> you fit Stanford's licensing characteristics you can get their VT100
> emulation telnet server for DOS, but that really is a very different beast.

I understand that PC Anywhere allows remote control of character-based
applications with the other end being a VT100, rather than another copy
of PC Anywhere.  This would seem to allow the milking machine connected
to controlled PC idea to work.  Has anyone actually tried it?

Roger Fajman                                   Telephone:  +1 301 402 1246
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 19:18:23 GMT
From:      demel@TUNAMEA.TUWIEN.AC.AT (Johannes Demel)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

I understand that the automatic generation of a domain search list may
not be unique and results in domains which cannot be reached simply.
(at least some implementations of the automatic generation use a trailing
dot to escape from the autmatic generation which solved the problem of
uniqueness, but it is not very userfriendly and it is no solution for
sendmail).
An the other hand the implementationin PC/TCP ist not userfriendly too.
At our University (domain tuwien.ac.at) we have part of the "private"
hosts in the departments and general purpose hosts with services for the
whole university located directly below the domain-name of the university.
But we have an increasing number of hosts (and PC's) which are located
within subdomains (i.e. one more level in the domain-name) assigned to
a department. This makes it easy to assign unique names for the whole 
university (currently approx. 600 hosts) and allows the delegation of
management of the host-names. But this departments have to pay the
price to specify the full domain-name for general service hosts, which is
frustating. 
But there is a well known method to solve the problem without getting
problems with the uniqueness and without requiring 8-16 kbytes of memory.
You can define a list of domains, which may be appended to a name given
which does not contain a dot. E.g. I may define the list
     kom.tuwien.ac.at
     tuwien.ac.at

An for the hostname abc the following names are checked:
     abc.kom.tuwien.ac.at
     abc.tuwien.ac.at
But if the specify the hostname   abc.xy   only
     abc.xy
will be checked.
Something like this method is implemented in cisco-routers.


---
Johannes Demel   demel@edvz.tuwien.ac.at   demel@tunamea.tuwien.ac.at
Computing Center, Head of Communications Group
Technical University Vienna
Wiedner Hauptstrasse 8-10/020, A-1040 Wien, Austria
Tel:  +43 (222) 58801-5829      Fax:  +43 (222) 5874211

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 20:00:09 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet and Nagle's algorithm


In article <9105172007.AA28847@ftp.com> ljm@FTP.COM (leo j mclaughlin iii) writes:
>Yet more bad news.  The primary reason for allowing Nagle's algorithm to be
>turned off was X-Windows.  Nagle's algorithm is very bad for any application
>(such as X-windows) with short bursts of high priority traffic.  For these
>sorts of applications, most (all?) vendors who do Nagle allow 'no Nagle' as
>an option when opening a connection.
>
>Thus, it is the *application* which can turn off Nagle, not the user.  Even
>worse from your point of view, the one application you would have a very
>tough time convincing people should be un-Nagled, the one application which
>generates the overwhelming majority of 'wasteful' small packets in the
>Internet, the one application for which Nagle was designed, is telnet.
>

I simply don't underestand this. If there is ONE application for which
instantaneous sending of individual bytes is important, it is telnet.
Otherwise user interaction could simply go to hell. Consider what
would happen if, for instance, you tried to do something like an
arcade game over Telnet. Or cursor control in an editor.

Besides, if you want a Telnet with Nagle, can't you simply have the
Telnet program ask for no Nagle???


Doug McDonald

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 22:22:36 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

I fully understand the issues with using any sort of default domain or
search list when given a dotted name, whether the default is used first
or last, but I don't see where this logic applies to a single part name.
In this case, with the usual longest to shortest search, I'm only going
to search within my own institution.

My solutions to this are:  a) put CNAMEs for most of the general hosts
and resources in our top-level domain (MSU.EDU), and b) point PC/TCP at
IEN 116 service as a backup to domain name service, primarily to resolve
single part host names that don't fit within the chosen domain.  This
works, in part, by automating the process which generates both the DNS
table and the hosts file used by the IEN 116 server, ensuring that they
remain in sync.

Doug Nelson
Michigan State University

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 22:34:22 GMT
From:      pyrros@cis.udel.edu (Christos Pyrros)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.ibm.pc.misc
Subject:   3com 3C501 Jumper Settings Needed, Please!

I have a 3com 3C501 Ethernet card (MCA bus) but I have misplaced the manual.
I would greatly appreciate it if someone could please email me the jumper
setting tables for the i/o address and memory address.

Thanks,

Chris

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      18 May 91 22:41:59 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP, SNMP, and Bridges

>   An IP router MUST have different IP addresses on its interfaces. Remember,
>   the purpose of an IP Router is to forward packets between different
>   IP networks and different IP Networks have different IP Network/Subnetwork
>   numbers, therefore the addresses will be different.
>
>I don't think that necessarily follows -- seems to me that KA9Q NOS
>gets by (if you so desire) with one IP address for the whole box, and
>routing done on a per interface basis.  Or am I missing something ?

The question is what address do you use as a gateway address for systems
connected to a given interface.  For serial lines, there is no problem,
since there's only one place to send the data; hence serial lines can
easily live without their own IP address.  For network interfaces, though,
you either need an IP address on the local net, or you have to rely on
proxy ARP to find the gateway.  Now this all assumes *I'm* not missing
something, too.

Doug Nelson
Michigan State University

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 00:07:17 GMT
From:      ribanez@wam.umd.edu (Ricardo Delrosario Ibanez)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Looking for Pump Mail

Hello netlanders,

   Is there an ftp site for Pump Mail ? I believe that Pump Mail is a poor man's version of IBM's PROFS, and it comes with an SMTP interface. Thanks ...


                                                  Ricardo Ibanez
                                                  ribanez@cscwam.umd.edu

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 01:28:18 GMT
From:      sra@LCS.MIT.EDU (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

Any further discussion on this topic should move to the mailing list
Namedroppers@NIC.DDN.MIL (aka USENET comp.protocols.tcp-ip.domains).

There are two issues here:

1) What kind of user interface will allow nicknames without accidently
   breaking things for users whose configuration, although legal, is
   not what the implementor had in mind?

2) What kind of user interface can the Internet support without
   spending too much of the available bandwidth on DNS queries?

Previous messages from John Romkey and James Van Bokkelen gave some
reasons why issue (1) is harder than it looks.  Here's another: what
should your resolver do if, in the process of following your search
path, it hits a zone whose name servers are dead or inaccessible?  The
only safe thing to do is give up.  This does not make users happy.
Users who are not intimately familiar with the DNS find this
particularly frustrating, since, from their point of view, whether a
particular nickname works on a given day is completely unpredictable.

Issue (2) is the reason for the comments in RFC 1123 about avoiding
excessive root queries.  As someone who has written a resolver that
supports negative response caching, I think RFC 1123 allows lazy
implementors to get away with murder by allowing the use of search
paths with only the internal-dot detection algorithm.  Ok, it protects
the root and the top-level name servers, but there are some pretty
huge non-leaf zones further down the tree (in the MIL subtree, for
example), and the internal-dot algorithm doesn't help them at all.
The only defense that the name servers of these zones have against
being beaten into the ground by resolvers with lame search path
implementations is to trust the administrators who own those resolvers
not to put these name servers on search paths.  Given the number of
administrators who appear to believe that the readability of the Bind
Operators Guide and the DNS RFCs could be improved by translating them
all into ancient Sanskrit, I do not find this prospect reassuring.

Also note that even negative response caching doesn't solve all the
problems with search paths, because some name servers lie.  If you
cache negative responses, you believe those lies without trying again
until the TTL expires, unless you impose an arbitrary ceiling on the
TTLs in your negative response cache.

The people at WSMR-SIMTEL20.ARMY.MIL are running my resolver code.
The last time I checked, they had both search paths and negative
response caching turned off, because they prefered a predictable
universe to the convenience of search paths.  I don't blame them.

--Rob Austein

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 05:10:36 GMT
From:      dws@uafsun1.uark.edu (David W. Summers)
To:        comp.protocols.tcp-ip
Subject:   Two (or more) logical networks on one physical network.

Hello NetLanders,
   I need some advice.  Here is our configuration:

engr-net (130.184.64.XX)
netmask  (255.255.255.0)
<----------------------->
         ^
         |
     ----------
     |        |
     |PC-Route|
     |        |
     ----------
         |
         V
------------------------
cseg-net (130.184.65.XX)
netmask  (255.255.255.0)

What I would like to do is to put at least 2 logical sub-nets on the
130.184.65.0 network.  How can I go about doing this?  I'm a novice at
this stuff (but I learn fast! :-) and have not found much documentation
on this in the manuals (SunOS 4.1.1).  From what I understand, there should
be some way to specify a network-wide (130.184.65.XX -wide, that is) network
and netmask combination (maybe using /etc/networks and/or /etc/netmasks?)
to specify how the network should look at the addresses and decide which
network a certain address is on.

The main reason I would like to do this is to put a SLIP network addressing
on to our thin-net LAN in this room.  Let me clarify that.  We are playing
around with SLIP and our Campus Net Admin. has given us a network address
(130.184.68.XX) to play around with SLIP.  In a few weeks we are going to
need to use the '68' network address for another room network in another
part of the building.  I would like to set it so that the SLIP addresses
are on the same network address (130.184.65.XX) as our ethernet IP addresses
here on the network in the room.

What I have tried so far is as many combinations of network addresses and
netmasks in the /etc/networks and /etc/netmasks files as I can form an
educated guess for.  I finally got the Sun to boot with the netmask set
for 255.255.255.128 but then when it re-ifconfig's (is that a word? :-)
using NIS it puts it back to 255.255.255.0.  I went over to our NIS master
and tried to put the same config in its /etc/networks and /etc/netmasks
and run (cd /var/yp; make) to update the NIS slave server on this room
network, but have not gotten it to set the netmask correctly.

I'm still playing with it but I am beginning to wonder if it is possible at
all?  Is there a better way to do this?  We only have 7 or 8 machines on this
room network and could really use the extra bits to specify another network
if it is possible.  I just saw some stuff about setting the routing metric
to 0 for logical networks on the same physical network so I'm about to try
that.  


   Any help (RTFM specs (pages)) or advice or "not possible" suggestions
would be greatly appreciated!  I'm still learning this stuff but have
already learned a great deal from "expirience", i.e., doing it the hard/wrong
way....maybe this is another such instance?


   Thanks!
    - David Summers
    (dws@engr.uark.edu)
-- 
                         "Never under-estimate the bandwidth of a station-wagon
David Summers             full of tapes, hurtling down the highway."
dws@engr.uark.edu         - Tanenbaum, "Computer Networks"

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 05:35:53 GMT
From:      Randall Atkinson <randall@Virginia.EDU>
To:        news.announce.newgroups,news.groups,comp.protocols.tcp-ip
Subject:   ANNOUNCEMENT:  comp.protocols.snmp new inet group

  Agreement has been reached that comp.protocols.snmp will presently
be created as an "inet" newsgroup. 

  The new newsgroup comp.protocols.snmp will be bidirectionally gated
to the existing SNMP Mailing List in the same manner as the TCP/IP
Mailing List is gated with comp.protocols.tcp-ip.  

  In effect what is going on here is that an existing Internet mailing
list is also becoming an "inet" newsgroup.

And we thank you for your support. :-)

  Randall Atkinson
  randall@Virginia.EDU

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 09:44:08 GMT
From:      mshiels@tmsoft (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Re:  PC Remote control software over the Internet

PC Anywhere will allow anyone of aprox. 50 terminal types to access it.  That
is it best feature above any of the other remote control packages.  I have
gotten it working across various netbios emulatos.  I wouldn't see a problem
with NetBIOS over TCP/IP.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 12:16:30 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   3Com 3C501 Jumper Block Settings

Please forgive my sending this info to the entire mailing list, but the
return address at Udel.edu was bogus, so here goes ...

To: cis.udel.edu@louie.udel.edu
Subject: Re: 3com 3C501 Jumper Settings Needed, Please!

Chris -

The jumpers on a 3C501 are as follows:

	DMA Channel	Default=1
	INterrupt Level	Default=3
	IO Base Addr	300H

	Memory Base Addr Deafult=EC00H
	Mempry Enable	Deafult=Disable
	Transc. Select	Default=BNC (thin-net)

IO Base Address Jumper Block
	The board uses 16 sequential I/O Addresses, starting at the I/O Base
	Address selected.  You can set the board to select a starting address
	from 000H to 3F0H, inclusive.  The base addresses are set in the 
	jumper blocks in hexadecimal.  The default address, 300H, is set-up
	as follows:

		9  8  |  7  6  5  4  |  3  2  1  0
	Hex       3   |      0       |      0
	Jumpers 1  1  |  0  0  0  0  |  *  *  *  *  (*=not applicable)

Memory Base Address is ONLY USED if the optional EtherStart PROM is used.
It may have a value from 00000H to FF000H in 4 Kbyte increments.  The book is
NOT clear on how this is done, but I suspect that it is similar to the I/O
Base Address jumpers, but without the low-order 2 bytes...

I am only about 5 miles from campus.  If you would like, I could Xerox the
501 manual for you....

Hope this helps.

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714-6066	

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 17:52:31 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Re: Partial subnetting

cudcv@warwick.ac.uk (Rob McMahon) writes:

>A nearby book calls what we are trying to do an "illegal" setup, and says it
>is "recommended" to have the same netmask throughout the network.

Its not illegal, but its not supported by just about anything yet.

However, support for this isn't as hard as was implied by a previous
response - routers do need to keep the network mask with every route,
but its not essential to use a routing protocol that transmits masks,
RIP can cope in this kind of evnironment just fine (and if RIP does,
so will just about anything else reasonable - just leave out EGP).

What a new routing protocol is needed for is the ability to assign the
subet masks in any random fashion - but is you're willing to assign
netmasks, and net numbers, in a structured fashion with respect to the
physical topology of the net, then it will all work just fine.  That
restriction is typically not a problem at all in most environments, esp
where you have a backbone with a wide subnet mask, and spur nets with
narrow masks.

If only you could find routers to support it - its not difficult, masks
in the routing table, and a little proxy ARP is all that's required.

kre

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 23:02:25 GMT
From:      paul@actrix.gen.nz (Paul Gillingwater)
To:        comp.unix.sysv386,news.software.b,news.software.nntp,comp.protocols.tcp-ip
Subject:   NNTP periodic failures on ISC UNIX

We have a problem with our NNTP, and would appreciate any helpful
suggestions.

Here's our configuration:

386/33MHz with ISC 2.2.1, running TCP/IP 1.2 on a WD 1003E LAN card.
We're connected via a PCRouter (software running on another PC) to a
local University Internet node, where we receive mail and news via
SMTP and NNTP.  We have 10 Mb of RAM.

We're using NNTP version 1.5.11 (with patches for ISC UNIX).

The problem is that two or three times a day, the NNTP appears to
lock up.  This also causes mail to stop, so it seems to be a problem
that restricts a resource used by both SMTP and NNTP (perhaps
streams buffers?)

We've tried shutting down the LAN, then restarting it by changing the
init level, but this does not seem to work.  We know that the
PCRouter is fine, because we can still TELNET or FTP over the LAN
(sometimes).  We can usually PING the PCRouter successfully too.
This has meant that the only way we can restart the connection is to
do a complete powerdown and reboot.

Obviously, this isn't very pleasant.

Can anyone (especially ISC support) suggest a possible cause for
this, and perhaps a fix?  For example, how can we find out if there
is a memory leak, or perhaps a loss of streams buffers?  Is there
some way we can enable NNTP debug logging to trace where it fails?

Another symptom is that there seem to be multiple NNTP processes
left hanging around (we have a housekeeping script which kills these
off from time to time).  If they're not killed cleanly, perhaps some
resource is being lost.  This seems to be a result of occasional
loss of connection to our feed.  The active NNTP process stops, but
doesn't go away.  When more news comes through, a new NNTP process
is started, but the old one doesn't go away.

Here's a netstat -a:

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0   2259  192.100.53.17.nntp     130.195.5.20.6750      CLOSED
tcp        0      0  *.smtp                 *.*                    LISTEN
tcp        0      0  *.time                 *.*                    LISTEN
tcp        0      0  *.daytime              *.*                    LISTEN
tcp        0      0  *.chargen              *.*                    LISTEN
tcp        0      0  *.discard              *.*                    LISTEN
tcp        0      0  *.echo                 *.*                    LISTEN
tcp        0      0  *.domain               *.*                    LISTEN
tcp        0      0  *.finger               *.*                    LISTEN
tcp        0      0  *.nntp                 *.*                    LISTEN
tcp        0      0  *.exec                 *.*                    LISTEN
tcp        0      0  *.login                *.*                    LISTEN
tcp        0      0  *.shell                *.*                    LISTEN
tcp        0      0  *.telnet               *.*                    LISTEN
tcp        0      0  *.ftp                  *.*                    LISTEN
tcp        0      0  *.*                    *.*                    CLOSED
udp        0      0  *.1225                 *.*                   
udp        0      0  *.1030                 *.*                   
udp        0      0  *.1027                 *.*                   
udp        0      0  192.100.53.17.domain   *.*                   
udp        0      0  127.0.0.1.domain       *.*                   
udp        0      0  *.domain               *.*                   
udp        0      0  *.ntalk                *.*                   
udp        0      0  *.1025                 *.*                   
udp        0      0  *.1024                 *.*                   
udp        0      0  *.syslog               *.*                   
udp        0      0  *.*                    *.*                   

Any help would be gratefully appreciated.
-- 
Paul Gillingwater, paul@actrix.gen.nz

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 May 91 23:31:59 GMT
From:      paul@actrix.gen.nz (Paul Gillingwater)
To:        comp.unix.sysv386,news.software.b,news.software.nntp,comp.protocols.tcp-ip
Subject:   Re: NNTP periodic failures on ISC UNIX

In article <1991May19.230225.2544@actrix.gen.nz> paul@actrix.gen.nz (Paul Gillingwater) writes:
> We have a problem with our NNTP, and would appreciate any helpful
> suggestions.

Here's a bit more info:  occasionally we get this message appearing
in mail.  It looks like we have a slight problem with stream
resources somewhere.  Anyone like to suggest how we can tune some
more in?

From news@actrix.gen.nz Sun May 19 23:25:08 1991
Received: by actrix.gen.nz id <AA02897-5.65b/4.26>; Sun, 19 May 91 23:25:06 GMT
Date: Sun, 19 May 91 23:25:06 GMT
From: News administrator <news@actrix.gen.nz>
Message-Id: <9105192325.AA02897@actrix.gen.nz>
Nntpxmit: newshost.comp.vuw.ac.nz hello: Out of stream resources
Apparently-To: news@actrix.gen.nz
Status: RO


*************************************************
Cron: The previous message is the standard output
      and standard error of one of your cron commands.


-- 
Paul Gillingwater, paul@actrix.gen.nz

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 01:19:11 GMT
From:      heiko@methan.chemie.fu-berlin.de (Heiko Schlichting)
To:        comp.unix.sysv386,news.software.b,news.software.nntp,comp.protocols.tcp-ip
Subject:   Re: NNTP periodic failures on ISC UNIX

paul@actrix.gen.nz (Paul Gillingwater) writes:

>We have a problem with our NNTP, and would appreciate any helpful
>suggestions.

We have a similar configuration and the same problems.

>Here's our configuration:
>
>386/33MHz with ISC 2.2.1, running TCP/IP 1.2 on a WD 1003E LAN card.
>We're connected via a PCRouter (software running on another PC) to a
>local University Internet node, where we receive mail and news via
>SMTP and NNTP.  We have 10 Mb of RAM.
>
>We're using NNTP version 1.5.11 (with patches for ISC UNIX).

We use a 386/33 MHz with WD 8003E and ISC 2.2 + NNTP 1.5.10.

>The problem is that two or three times a day, the NNTP appears to
>lock up.  This also causes mail to stop, so it seems to be a problem
>that restricts a resource used by both SMTP and NNTP (perhaps
>streams buffers?)

We have this problem too. 
Do a "telnet 127.0.0.1 119" only gives a "trying..." and nothing happens.
There are similar problems with SMTP ("telnet 127.0.0.1 25") some times
but it seems to be independant from NNTP problems. At one time NNTP locks 
up and at another SMTP locks.

>We've tried shutting down the LAN, then restarting it by changing the
>init level, but this does not seem to work.  We know that the
>PCRouter is fine, because we can still TELNET or FTP over the LAN
>(sometimes).  We can usually PING the PCRouter successfully too.
>This has meant that the only way we can restart the connection is to
>do a complete powerdown and reboot.

If NNTP locks up we have to shutdown too but for the SMTP problems there
is a workaround:

kill all running "sendmail -bd" processes and restart the sendmail daemon
with "/usr/lib/sendmail -bd -q10m". This works in most cases but you 
get a bind() error sometimes. In this case only a complete reboot helps.
We use smail 3.1.20 - I don't know if this works with the ISC sendmail too.

I think the problem is that there are a lot of TCP/IP process is the
status CLOSED and they didn't terminate. 
This is *NOT* a special problem of NNTP. It is a general TCP/IP problem
with ISC.

Look at our netstat output - there are CLOSED processes by uucp (over TCP/IP),
telnet, smtp and ftp too:

Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      8  methan.chemie.fu.1660  ki1.chemie.fu-be.uucp  CLOSED
tcp        0      0  methan.chemie.fu.nntp  crane.aa.ox.com.4337   LAST_ACK
tcp        0      0  methan.chemie.fu.1484  athene.uni-pader.ftp-d LAST_ACK
tcp        0      3  methan.chemie.fu.1430  taurus.tat.physi.4242  CLOSED
tcp        0      1  methan.chemie.fu.1416  taurus.tat.physi.telne CLOSED
tcp        0      8  methan.chemie.fu.1413  ki1.chemie.fu-be.uucp  CLOSED
tcp        0      0  methan.chemie.fu.telne gibb.math.fu-ber.2879  ESTABLISHED
tcp        0      8  methan.chemie.fu.1215  ki1.chemie.fu-be.uucp  CLOSED
tcp        0      8  methan.chemie.fu.1162  ki1.chemie.fu-be.uucp  CLOSED
tcp        0   1846  methan.chemie.fu.telne troll.cs.tu-berl.2778  CLOSED

And after a while - this will lock TCP/IP and makes a reboot
necessary.

Bye, heiko.
-- 
 |~|    Heiko Schlichting                   | Freie Universitaet Berlin 
 / \    heiko@fub.uucp                      | Institut fuer Organische Chemie
/FUB\   heiko@methan.chemie.fu-berlin.de    | Takustrasse 3
`---'   phone +49 30 838-2677; fax ...-5163 | D-1000 Berlin 33  Germany

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 01:23:50 GMT
From:      david@ccvr1.ncsu.edu (David Joyner)
To:        comp.protocols.tcp-ip
Subject:   Developing application level protocols

I am developing an application level protocol that will be used by client
programs to communicate with a daemon that manages a dbm database of mail
aliases.  We are planning to distribute the client programs to system
managers around our campus so they can easily manage their aliases and mailing
lists.

I am using RFC 821 (SMTP) as a starting point, but I was wondering if there 
are any other documents which I could take a look at (RFC's or otherwise).
Also, if anyone has any advice or suggestions, I would be happy to hear 
from you.  Email response is fine.

Thanks in advance.


--
+===========================================================================+
|                  David Joyner (David_Joyner@ncsu.edu)                     |
|        North Carolina State University Computing Center - Systems         |
+===========================================================================+

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 12:08:33 GMT
From:      bill@TUATARA.UOFS.EDU (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve



>    and so why isn't compuserv interested in this
> 
> I don't know.  For one thing, though, their hosts don't speak IP.

Unless things have changed drastically since the last article I read about
Compuserve, they are running PRIME Mini's.  They most assuredly can speak
IP.  And if the interest was there, there is always the milking-machine 
approach with terminal servers.  I would imagine the reasons are more
political/philosophical than technical.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 13:34:42 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   How is UTP fault-tolerant?

James E. Gaskin, author of the "Networking" column in _UNIX Today_,
mentions in the 4/29/91 issue that we should

     "Start working on your management by showing them how
     little extra it costs to use fault-tolerant UTP rather
     than fault-intolerant coax for new installations.  Arrange
     for a demo of a good management package, stressing
     decreased downtime."

The column dealt with unshielded twisted pair, concentrators and
other UTP-oriented devices.  Would someone please explain how UTP
and concentrators enable one to establish a more reliable net?  This
was all news to me.

bill
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 14:35:57 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   PC Remote control software over the Internet


   Date: Fri, 17 May 91 21:25:01 -0400
   From: leo j mclaughlin iii <ljm@ftp.com>

   Yes, (though only over very little pieces).  Get two PCs running the
   NetBIOS LAN version of CloseUP/Carbon Copy and a vendor of NetBIOS over
   TCP/IP which supports M/P-node or extended B-node services.  Stir gently and
   hope the delay characteristics don't upset the PC software too badly....

Would you be so kind as to explain why the NetBIOS implementation
style (m/p vs b node) is important. I've read the RFC's, but I'm not
clear as to which services you're depending on. (Especially in the
extended B-node case.)

Bob Stratton           | 
Stratton Systems Design| SMTP: strat@gnu.ai.mit.edu, c_bstratton@hns.com
Alexandria, Virginia   | PSTN: +1 301 409 2703
"Personally, I think the DNS administrative interface was designed by the IRS."
							--Mark Beyer

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 14:59:49 GMT
From:      fab@md.interlink.com (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   re: name handling in DNS resolvers

The function of the search list for the DNS resolver is to let the
user customize the higher level domains to search.  Then the user
can decide how to handle their unique naming usage.

Secondly, if the user interface accepts a trailing dot, then the ambiguity
of a partial name matching a fully-qualified name can be avoided.  The name
with the trailing dot is  the fully-qualified name and needs no domain
appended to it.

Sounds to me like some more work needs to be done on that resolver code.

------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 16:09:42 GMT
From:      jessea@homecare.COM (Jesse W. Asher)
To:        comp.protocols.tcp-ip
Subject:   Unused portion of first octet?

Correct me if I'm wrong, but Class A-C networks depend on the number of
the first octet in the address.  Class A is 1-127, Class B is 128-191,
and Class C is 192-223.  What happens to 224-254?  What are these being
used for, or are they being used for anything?  Just a curious mind
wanting to know.


-- 
      Jesse W. Asher        NIC Handle:  JA268         Phone: (901)386-5061
                       Health Sphere of America Inc.
	       5125 Elmore Rd., Suite 1, Memphis, TN 38134
 Internet: jessea@homecare.COM                 UUCP: ...!banana!homecare!jessea

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 16:21:19 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   NFS traffic numbers

Good morning!
Does anyone know of any hard numbers that are around for NFS network usage? How
many active mounts create how much udp traffic, etc. If you know of anything
like this could you please point me in the right direction?
Thanks in advance,
Chris VandenBerg
CMC -  A Rockwell Intl Co.   125 Cremona Dr.   Goleta, CA. 93117
Internet - chrisv@cmc.com          ma-bell - 805-562-3127 

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 16:55:05 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Unused portion of first octet?

In article <1991May20.160942.24296@homecare.COM> jessea@homecare.COM (Jesse W. Asher) writes:
>Correct me if I'm wrong, but Class A-C networks depend on the number of
>the first octet in the address.  Class A is 1-127, Class B is 128-191,
>and Class C is 192-223.  What happens to 224-254?  What are these being
>used for, or are they being used for anything?  Just a curious mind
>wanting to know.

Its not actually the first octet, bit the first bits, as follows:

	0XXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class A
	10XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class B
	110XXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class C
	1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class D (Multicast)
	1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Reserved

Art

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 17:52:13 GMT
From:      dmorris@bmrl.med.uiuc.edu (Doug Morris)
To:        comp.protocols.tcp-ip
Subject:   Looking for program to port serial connect over TCP.

Sometime earlier a program was announced on the network called TCPPORT.
The purpose was to allow a "normal" serial program to communicate over 
a TCP network.  Does anyone know the anon ftp address of this
program?


| Doug Morris                       |  University of Illinois            |
| email: dmorris@bmrl.med.uiuc.edu  |  Biomedical Magnetic Resonance Lab |
| fax:   217-244-1330               |  1307 W. Park St.                  |
| voice: 217-244-0290               |  Urbana Il 61801                   |
 --------------------------------------------------------------------------
-- 
| Doug Morris                       |  University of Illinois            |
| email: dmorris@bmrl.med.uiuc.edu  |  Biomedical Magnetic Resonance Lab |
| fax:   217-244-1330               |  1307 W. Park St.                  |
| voice: 217-244-0290               |  Urbana Il 61801                   |

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 18:15:11 GMT
From:      mrs@ms.secs.csun.edu (Mike Stump)
To:        comp.protocols.tcp-ip
Subject:   Re: Net 1?

Gee, and I thought no one would notice!  :-)  I even had a chance to see
the offending equipment.  You can also traceroute to kithrup.com, or
cygnus.com to see it.  You can ask gumby@cygnus.com to give the box a
proper address.  I have already let him know (months ago...) that this is
a BAD thing, but if others do also, he might fix it.

In article <9105161742.AA13238@phoebus.nisc.sri.com> bjork@NISC.SRI.COM (Steven Bjork EJ223) writes:
>Hm.
>
>A traceroute for your inspection and comment vs. net 1:
>
>Script started on Thu May 16 10:34:16 1991
>phoebus-1>traceroute asylum.sf.ca.us
>traceroute to asylum.sf.ca.us (192.48.232.17), 30 hops max, 40 byte packets
> 1  srinet-gw (192.33.33.3)  4 ms  4 ms  3 ms
> 2  BARRNET-GW.SRI.COM (128.18.1.5)  2 ms  2 ms  2 ms
> 3  barrnet^36.1 (131.119.36.1)  5 ms  3 ms  3 ms
> 4  SU-A.BARRNET.NET (131.119.251.200)  5 ms  6 ms  4 ms
> 5  NSS13.BARRNET.NET (131.119.254.240)  7 ms  5 ms  5 ms
> 6  129.140.13.75 (129.140.13.75)  12 ms  11 ms  12 ms
> 7  129.140.70.13 (129.140.70.13)  30 ms  26 ms  29 ms
> 8  129.140.6.14 (129.140.6.14)  31 ms 129.140.6.78 (129.140.6.78)  35 ms 129.140.6.14 (129.140.6.14)  33 ms
> 9  129.140.75.6 (129.140.75.6)  68 ms  80 ms  78 ms
>10  129.140.11.14 (129.140.11.14)  69 ms 129.140.11.78 (129.140.11.78)  72 ms  85 ms
>11  129.140.73.11 (129.140.73.11)  118 ms  149 ms  124 ms
>12  129.140.9.16 (129.140.9.16)  149 ms 129.140.9.80 (129.140.9.80)  127 ms 129.140.9.16 (129.140.9.16)  117 ms
>13  College-Park.MD.ALTER.NET (192.41.177.249)  127 ms  122 ms  127 ms
>14  Falls-Church.VA.ALTER.NET (137.39.11.1)  135 ms  129 ms  126 ms
>15   (137.39.2.2)  199 ms  195 ms  198 ms
>16  TISMtV-gw.ALTER.NET (137.39.3.2)  185 ms  185 ms  202 ms
>17  192.70.178.7 (192.70.178.7)  188 ms  212 ms  195 ms
>18  1.0.0.2 (1.0.0.2)  364 ms  365 ms  322 ms
>19  1.1.0.2 (1.1.0.2)  441 ms  461 ms  1080 ms
>20  asylum-net^17 (192.48.232.17)  450 ms  666 ms  756 ms
>phoebus-2>^
>script done on Thu May 16 10:34:38 1991
>
>Puzzled,
--
If I can get mail to you via a legally registered fully qualified
domain name, you could be on Saturn for all I care.

		-- quote by Bob Sutterfield <bob@MorningStar.Com>

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 18:39:28 GMT
From:      jose@cod.NOSC.MIL (Jose R. Vazquez Santana)
To:        comp.protocols.tcp-ip
Subject:   SNMP agents

Netters,

	I'm working in a project that involves the use of the
SNMP protocols between Sparcstations and VME cards.  For that
purpose I acquire the Sun Network Manager tool(SNMgr) that
provides for the use of SNMP agents.  I would like to know if
you have any good/bad experience with this tool or with any
other one used for the same purpose.  I would also want to know
if someone in the net have implemented any agent for VME cards
or any other piece of hardware, using SNMP, that can be helpful.

	I know that the group comp.protocols.snmp was recently
created but I can't get to it.  So how I can be added to the
SNMP mailing-list?

	Please reply by e-mail.  I can post a summary if there
is enough interest.  Thanks in advance.


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

Jose R. Vazquez
Code 855
Naval Ocean Systems Center
San Diego, CA  92152-5000
(619) 553-6625

DDN: jose@nosc.mil
UUCP: sdcsvax!nosc!jose

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 18:44:02 GMT
From:      sam@giza.cis.ohio-state.edu (Sam Neely)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <9105201208.AA22490@tuatara.uofs.edu> bill@TUATARA.UOFS.EDU (Bill Gunshannon) writes:
>
>
>>    and so why isn't compuserv interested in this
>> 
>> I don't know.  For one thing, though, their hosts don't speak IP.
>
>Unless things have changed drastically since the last article I read about
>Compuserve, they are running PRIME Mini's.

Actually, CompuServe uses Dec-10 based technology running a variant
of TOPS-10.

>   And if the interest was there, there is always the milking-machine 
>approach with terminal servers.  I would imagine the reasons are more
>political/philosophical than technical.

At this point, you run into the NSFnet acceptable use policy which
states "Thou shalt not use the NSFnet for commercial use."  CompuServe
would have to block most sites.

	- Sam

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 19:49:34 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   re: name handling in DNS resolvers

In article <9105171533.AA01010@asylum.asylum.sf.ca.us>, romkey@asylum.asylum.sf.ca.us (John Romkey) writes:
|> As the person who designed the way DNS lookup works in PC/TCP, I'll
|> explain to you why it's done that way.
|> 
|> Suppose you do your domain name lookup by working your way up the
|> domain name. Your host's domain name is W.X.Y.Z. It's presented with
|> name A; so first it tries A.X.Y.Z, then it tries A.Y.Z, etc.
|> 
|> Or, perhaps you present it with A.B and it tries A.B, A.B.Z, A.B.Y.Z.
|> 
|> There are other searches it could do, too.
|> 
|> In any of these cases, the user can have the name resolve into a
|> system that's not the one they expected, and then have no way to
|> specify that name. By the principle of least astonishment, you
|> shouldn't allow that to happen.
|> 


Ahh, but most recursive searching resolver libraries can be forced not to
append successive domains by anchoring the name with a period.

Take an example:  Suppose I'm in a subdomain "com.mit.edu" with a host "x"
Now suppose I try to telnet to "x.com":

$ telnet x.com

I get x.com.mit.edu, which is probably what I don't want.  So I use:

$ telnet x.com.   <-- note the anchor

And I get exactly what I wanted.... x.com

This is user friendly.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 20:45:03 GMT
From:      root@ttsi.lonestar.org (System)
To:        comp.protocols.tcp-ip
Subject:   RPC port to SCO Unix?


Has anyone modified the RPC 4.0 sources to run on SCO Unix?
Any help will be greatly appreciated.
-- 
Mark S. Evans                 Tandem Telecommunications Systems Inc.
Phone: 214-516-6201           850 E. Central Parkway
Fax:   214-516-6801           Plano, TX 75074
Mail:  mse@ttsi.lonestar.org

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 May 91 23:54:23 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: Unused portion of first octet?

Jesse W. Asher writes:
|
|   Correct me if I'm wrong, but Class A-C networks depend on the number of
|   the first octet in the address.  Class A is 1-127, Class B is 128-191,
|   and Class C is 192-223.  What happens to 224-254?  What are these being
|   used for, or are they being used for anything?  Just a curious mind
|   wanting to know.

The Internet Numbers RFC [1] contains the authoritative reference on
network numbers.  Snipped from this vast RFC is the following:

[2]   The fourth type of address, class D, is used as a multicast
      address [13].  The four highest-order bits are set to 1-1-1-0.


                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1 1 1 0|                  multicast address                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Class D Address


      Note:  No addresses are allowed with the four highest-order bits
      set to 1-1-1-1.  These addresses, called "class E", are reserved.

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

[3]   Other Reserved Internet Addresses

      * Internet Address                   Network           Reference
      - ----------------                   -------           ----------
        224.000.000.000-239.255.255.255    Multicast         [JBP]
        240.000.000.000-255.255.255.255    Reserved          [JBP]

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

Hope this helps.

</Erik>

References:

[1] RFC 1166 Kirkpatrick, S.; Stahl, M.K.; Recker, M.  Internet numbers.
    1990 July; 182 p. (Format: TXT=566778 bytes) (Obsoletes RFC 1117,
    RFC 1062, RFC 1020)
[2] ibid, page 4
[3] ibid, page 100

--
Erik Naggum             Professional Programmer            +47-2-836-863
Naggum Software             Electronic Text            <enag@ifi.uio.no>
0118 OSLO, NORWAY       Computer Communications      <erik@naggum.uu.no>

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 00:06:44 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: Unused portion of first octet?

Art Berggreen writes:
|
|   Its not actually the first octet, bit the first bits, as follows:
|
|	   0XXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class A
|	   10XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class B
|	   110XXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class C
|	   1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Class D (Multicast)
|	   1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX	Reserved            

I think it's easier if you present it with network and host numbers:

   0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh  Class A
   10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh  Class B
   110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh  Class C
   1110mmmm.mmmmmmmm.mmmmmmmm.mmmmmmmm  Class D (multicast)
   1111xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx  Reserved

Of course, then there's subnetting...

</Erik>
--
Erik Naggum             Professional Programmer            +47-2-836-863
Naggum Software             Electronic Text            <enag@ifi.uio.no>
0118 OSLO, NORWAY       Computer Communications      <erik@naggum.uu.no>

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 00:16:11 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve


 - on the burning question: Why isn't Compu$erve on the Internet ?

In article <123603@tut.cis.ohio-state.edu> sam@giza.cis.ohio-state.edu (Sam Neely) writes:
>At this point, you run into the NSFnet acceptable use policy which
>states "Thou shalt not use the NSFnet for commercial use."  CompuServe
>would have to block most sites.

If CompuServe were to hook up to a commercial IP network vendor, they
would have done THEIR part of the deal. Academic users would be presumed
to be using CIS fro academic purposes, and if their use was not academic,
they surely would not be doing it on NSFnet in the first place ?
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 02:03:48 GMT
From:      hirose@coron.sws.cpd.mei.co.jp (Masato Hirose)
To:        comp.protocols.tcp-ip
Subject:   documents about 4.3BSD-reno's TCP

I'm looking for the documents about new TCP, especially about
4.3BSD-reno's TCP. Does anyone know about it, except RFCs and
the source codes. :)  E-mail is welcome. Thanks.

--

Masato Hirose (hirose@sws.cpd.mei.co.jp)
Matsushita Electric IND. Co.,Ltd. [Panasonic] Japan

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 11:59:31 GMT
From:      bill@TUATARA.UOFS.EDU (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve


> >   And if the interest was there, there is always the milking-machine
> >approach with terminal servers.  I would imagine the reasons are more
> >political/philosophical than technical.
>  
> At this point, you run into the NSFnet acceptable use policy which
> states "Thou shalt not use the NSFnet for commercial use."  CompuServe
> would have to block most sites.

1.  There are commercial INTERNET providers that Compuserve could hook up to.
2.  It is not Compuserve's responsibility to police the NSFnet.  It is up to
    the users to ensure that their traffic meets Acceptable Use Policy.

It might even make the commercial INTERNET providers look more attractive if 
one of them could lure Compuserve into the fold.  But, I stand by what I said
above,  it isn't a technical problem.

bill

-- 

     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 13:55:20 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Diving into TCP/IP again... need help finding docco...

Hi folks. I'm diving into the TCP/IP part of our network again. This time
I want to set up a single nameserver machine, so we don't have to edit
everyone's hosts.txt file for every new machine. Where do I look to find
out how this is done? I want to use a System V/386 machine with intel's
TCP/IP product as the nameserver if possible, but we will have a bunch of
machines on it... including some Unisys 1100s that only support the basic
DDN suite. Any hope of getting them to use a nameserver?

Also, I'd like to use this as an opportunity to renumber our net. We
originally set up as a class C network, but since we're unlikely to ever
hook up straight to the real Internet is there any reason not to simplify
things by using a class A network number?

"Consult your local GURU", you say? Sorry, as far as this goes I'm as much
of a GURU as anyone at this site. Pitiful, isn't it?

To minimize bandwidth, please mail responses.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 14:02:44 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Multiple tcp/ip cards in one PC

We have a request for support that I'm having trouble with, and I thought
I'd ask the net. Basically, we have some people who want to run two tcp/ip
cards concurrently in one PC. I believe they want one to be a hot standby
for the other... it's not a gateway or anything like that. The TCP software
is Interlan's, and the cards are NP600s. Any ideas?
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 14:10:43 GMT
From:      ian@ukpoit.co.uk (Ian Spare)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

In article <1991May20.133442.1309@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes:
>other UTP-oriented devices.  Would someone please explain how UTP
>and concentrators enable one to establish a more reliable net?  This
>was all news to me.
>


With pleasure ....

We have two nets for RD&D , one UTP and one Thin-ethernet. 

In the UTP net there is an ethernet repeater giving UTP ports , I can add or 
remove devices on this without knocking out the net ( unless the two devices
are talking of course !!! ) compare and contrast with my thin net where speed
is of the essence and all Unix consoles start getting retry counts 
exceeded etc.

Also if a user has a PC , say 200 feet away , connected via UTP and has the 
cunning  idea of re-arranging his furniture when he breaks the thinnet
the whole segment doesn't go down.

UTP wins hands down , but it's a pain when you run out repeater ports or
just need an extra one for a demo and can't find one free.


-- 
Ian Spare , iT , Barker Lane , CHESTERFIELD , DERBYS , S40 1DY , GREAT BRITAIN

   E-mail : ian@ukpoit.uucp - VOICE : +44 246 214296 - FAX : +44 246 214353

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 14:34:09 GMT
From:      ps@axis-design.axis-design.fr (Patrick Sinz)
To:        comp.protocols.tcp-ip
Subject:   Fast TCP-IP/NFS


We are looking for any PD or OEM package optimising TCP-IP and or NFS
on
	[34]86 Unix with ISA or EISA ethernet boards
and
	MIPS with VME based ethernet boards.

We are interested in any solution both board dependent ones and board
independent ones.
Hints and research directions are also apreciated.

Thank you for mailing to
		ps@axis-design.axis-design.fr

			Cheers.

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 14:37:19 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   re: name handling in DNS resolvers

>Ahh, but most recursive searching resolver libraries can be forced not to
>append successive domains by anchoring the name with a period.

I'd put it the other way, viz:
1) The naive user types full x.y.z canonical names.
2) The more understanding may drop any level of his own host name with,
   typed on host myhost.dpt1.domain :
   x. giving x.dpt1.domain
   x.dtp2.. x.detp2.domain etc...
3) Nothing left to chance, no more name servers resolving single labels to
   local host name, nothing to do with the guru's 1035 dots convention etc...

And I don't like the idea of the host file serving nicknames' purpose.
Nicknames are often personal and the user should be able to maintain its own,
mapping to full names and not addresses. A host file doesn't do that.
Finally, it's sorry that making these kinds of subjects an implementation
issue produces such various user interfaces.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 14:44:10 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

[This begins to encroach on territory that
 rightly belongs to com-priv@psi.com...]

lars@spectrum.cmc.com writes:
    - on the burning question: Why isn't Compu$erve on the Internet ?

Because they haven't got a clue? :-)

   If CompuServe were to hook up to a commercial IP network vendor, they
   would have done THEIR part of the deal.

Perhaps true.  But (picking an example out of the air here; no slurs
against corporate entities implied) when {HP,DEC,Sun,ATT <pick one>}
employees start accessing CompuServe's graphics forums for image
downloading via their NSFNet-affiliated network connection, who gets
the blame?  Past indications are that placement of materials which are
"unsuitable" to the Internet must be removed by the provider of the
materials; cf. complaints about certain GIF collections.  (Hm.  I
almost begin to wonder if there's a connection between CompuServe's
non-presence on the Internet and the fact that the GIF graphics format
is a CompuServe creation, specifically a guy by the name of Steve
Wilhite.  Nah, it's too improbable...)

   Academic users would be presumed to be using CIS fro academic purposes,

Would they?  The presumption in the cases of GIF collections seems to
be guilty-until-proven-innocent.  Not that this has stopped Usenet's
alt.sex.pictures from succeeding, of course.

   and if their use was not academic,
   they surely would not be doing it on NSFnet in the first place ?

I don't mean to offend, but that strikes me as naive.

Just for starters, it would be interesting to me to know how many
connections to CompuServe via...
	NSFNet -> Merit -> hermes.merit.edu -> Telenet -> CompuServe
are really legit.  I wonder about all kinds of things regarding that
access point; "appropriate use" stipulations notwithstanding, Telenet
and CompuServe both _must_ be making a handy profit, directly, by such
connections.  No fuzziness with "indirect" or "incidental" profit
here, just raw bitpipe connectivity, for a price.  I can't use it in
the first place, myself; my account at CompuServe is free for obvious
reasons, so they don't let me get in via Telenet.

   From: bill@tuatara.uofs.edu (Bill Gunshannon)
   Date: 21 May 91 11:59:31 GMT

   1. There are commercial INTERNET providers that Compuserve could hook up to.

They are doing so, for the mail gateway.  Alternet is the IP supplier.

   2. It is not Compuserve's responsibility to police the NSFnet.  It is
   up to the users to ensure that their traffic meets Acceptable Use Policy.

That's empirically disprovable, see above; the NSFNet would police CompuServe.

   But, I stand by what I said above, it isn't a technical problem.

Yes, you're entirely correct, it's a political problem.  That's why
this is really no longer an issue for tcp-ip, and hasn't been for at
least the last 3 or 4 notes in the thread; note Reply-To: and
Followup-To: (the latter will confuse your news interface, no doubt).

--karl

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 15:05:20 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

Erik J. Murrey writes:
|
|   Ahh, but most recursive searching resolver libraries can be forced
|   not to append successive domains by anchoring the name with a
|   period.

This is illegal in mail addresses.

</Erik>
--
Erik Naggum             Professional Programmer            +47-2-836-863
Naggum Software             Electronic Text             <erik@naggum.no>
0118 OSLO, NORWAY       Computer Communications        <enag@ifi.uio.no>

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 15:36:13 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for program to port serial connect over TCP.

The program is available from [129.97.128.196] in pub/wattcp/apps.zip.
The other zips are source which you probably don't need for testing.

Erick

-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 16:49:51 GMT
From:      brian@edat.UUCP (brian douglass personal account)
To:        comp.dcom.lans,comp.os.os2.apps,comp.protocols.tcp-ip,biz.sco.general
Subject:   OS/2 Lan Manager TCP/IP

I need to connect an Compaq running SCO ODT 1.1 with TCP/IP over Token
Ring to a Lan Manager 1.x system under OS/2.  I am looking for the 
TCP/IP driver to run on the LM system as another protocol stack.

I am investigating FTP PC-TCP but this seems to be more than I am 
needing.  Any comments or suggestions?  How about 3-COM or other 
vendors?  E-mail please and desired, I will summarize.

Brian Douglass			Voice: 702-361-1510 X311
Electronic Data Technologies	FAX #: 702-361-2545
1085 Palms Airport Drive	brian@edat.uucp
Las Vegas, NV 89119-3715

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 16:54:58 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <1991May17.131622.16043@oar.net> karl.kleinpaste@osc.edu writes:
>eckert@immd4.informatik.uni-erlangen.de writes:
>   How did you guess people could be interested in this,
 
>No guessing involved; the two most common questions I get about CServe
>are "how do I address a subscriber" and "can I telnet there?"
 
>   and so why isn't compuserv interested in this
 
>I don't know.  For one thing, though, their hosts don't speak IP.

Compuserve likes to bill for the use of their systems; billing people
who telnet in would be very difficult. They do very little for "free";
I use quotes since the things that CIS doesn't directly bill for, you
are still paying TYMNET or long distance charges for.

If CIS could see money in telnet/ftp connections, it'd already be done.


-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
I support drug testing. I believe every public official should be given a
shot of sodium pentathol and ask "Which laws have you broken this week?".

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 16:55:03 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: telnet and Nagle's algorithm

> From tcp-ip-RELAY@NIC.DDN.MIL Sat May 18 16:53:34 1991
> Date: 18 May 91 20:00:09 GMT
> From: sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!usenet@ucsd.edu  (Doug McDonald)
> Organization: University of Illinois at Urbana
> Subject: Re: telnet and Nagle's algorithm
> References: <9105172007.AA28847@ftp.com>
> Sender: tcp-ip-relay@nic.ddn.mil
> To: tcp-ip@nic.ddn.mil
> 
> 
> In article <9105172007.AA28847@ftp.com> ljm@FTP.COM (leo j mclaughlin iii) writes:
> >Yet more bad news.  The primary reason for allowing Nagle's algorithm to be
> >turned off was X-Windows.  Nagle's algorithm is very bad for any application
> >(such as X-windows) with short bursts of high priority traffic.  For these
> >sorts of applications, most (all?) vendors who do Nagle allow 'no Nagle' as
> >an option when opening a connection.
> >
> >Thus, it is the *application* which can turn off Nagle, not the user.  Even
> >worse from your point of view, the one application you would have a very
> >tough time convincing people should be un-Nagled, the one application which
> >generates the overwhelming majority of 'wasteful' small packets in the
> >Internet, the one application for which Nagle was designed, is telnet.
> >
> 
> I simply don't underestand this. If there is ONE application for which
> instantaneous sending of individual bytes is important, it is telnet.
> Otherwise user interaction could simply go to hell. Consider what
> would happen if, for instance, you tried to do something like an
> arcade game over Telnet. Or cursor control in an editor.
> 
> Besides, if you want a Telnet with Nagle, can't you simply have the
> Telnet program ask for no Nagle???
> 
> 
> Doug McDonald

Actually, the lack of the Nagle algorithm is what can cause user interaction
to be degraded.  The whole point of the Nagle algorithm is that it reduces
the number of tiny packets being sent/received, thus reducing both system
and network overhead.

From RFC 1122, section 4.2.3.4:

	A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
	coalesce short segments.  However, there MUST be a way for
	an application to disable the Nagle algorithm on an
	individual connection.
	...
	The Nagle algorithm is generally as follows:
		If there is unacknowledged data (i.e., SND.NXT >
		SND.UNA), then the sending TCP buffers all user
		data (regardless of the PSH bit), until the
		outstanding data has been acknowledged or untill
		the TCP can send a full-sized segment (Eff.snd.MSS
		bytes; see section 4.2.2.6)

In BSD networking code, it is more or less:
	1) On the first write, send the data, even if it is
	   less than the MTU.
	2) Queue up successive writes until:
		a) we have MTU bytes of data to send
		b) an ACK comes back from the previous data
		c) a timer goes off.
	3) Send as much data as we can in one packet, and go
	   back to step 2.

The Nagle algorithm uses the fact that tiny packets are going out,
and the other side will be acking the data immediatly, because there
will be data coming back from the remote side and it can piggyback the
ACK on the data.  In rlogin/telnet, when doing single character, remote
echo, you know that the ACK will be coming back fairly quickly, because
the other side will be sending back a packet with the data to echo to the
terminal.  So, rather than dribbling out packets with one byte of data
in each packet, the Nagle algorithm allows the packets to be clumped
together.  When you are logged in across a long delay network, and you
see your typed characters being echoed in clumps of three or four
characters, that is usually the Nagle algorithm at work.

If you have an application that is sending out small packets, and
the remote side can't do anything when it gets the first packet because
it needs the data in the next packet, then  the Nagle algorithm will
hurt you.  (This is a sitution when user level stdio is helpful, or
using one writev() call instead of several write() calls to write non-
contiguous data (e.g., headers seperate from data) will avoid the problems
that the Nagle algorithm can cause.)

			-David Borman, dab@cray.com

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 17:01:52 GMT
From:      graham@netwrx1.NW1.COM (James M. Graham)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   NNTP on SCO UNIX


Does the NNTP Version 1.5.11, available on UUNET build on an SCO UNIX host
with SCO (Lachman) TCP/IP? I would like to build the server on the SCO
machine which receives news via UUCP. I would like the SCO machine to be
a server for PCs on a LAN running TCP/IP and WinQVT/NET NNTP client software.
Does this all sound feasible. I am not sure what our current version of news
software is that is presently running on the SCO UNIX machine.

Does the NNTP software receive news via UUCP and deliver to clients via
TCP? Or does NNTP require CNEWS software to talk to the UUCP Usnet feed?

Any info will be greatly appreciated.

Jim Graham

==============================================================================
  James M. Graham		Usenet:	  uunet!netwrx1!graham
  Open Networks, Inc.		Internet: graham%netwrx1@uunet.uu.net
  Reston, Virginia		Voice:    (703) 648-0013

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 17:20:18 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

In article <1991May20.133442.1309@banana.fedex.com> bill@banana.fedex.com (bill daniels) writes:
>... Would someone please explain how UTP
>and concentrators enable one to establish a more reliable net? ...

Assuming "UTP" means "10BaseT", the crucial issue is that 10BaseT is a star
topology, with each host connected directly to the hub, whereas other forms
of Ethernet are bus topologies, with more than one host hanging off of each
piece of wire.  Given good equipment design, star topologies have one big
advantage:  a foulup on one wire does not mess up anyone else.  When Joe
Random User disconnects his cable to move his machine from one side of
his office to the other, only his own machine's connectivity is disrupted.
If he's on a bus-topology network, he may well take down everyone who's
on the same piece of cable.

There is a dark side to this particular Force, of course. :-)  If the
central hub is down, *everybody* is out of communication.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 17:21:08 GMT
From:      ole@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   June ConneXions


The June issue of ConneXions--The Interoperability Report will soon
hit the streets. Of particular interest to the readers of these lists
may be:

- An article on MIB development and Integration
- An overview of the recent Security enhancements to SNMP
- A status report on the NREN
- A report on TCP/IP "activities" in the UK JANET community
- A review of Volume II of "Internetworking with TCP/IP"

Ole

Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040,
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu
Direct: (415) 962-2515

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 17:33:35 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

In article <1991May20.133442.1309@banana.fedex.com>, bill@banana.fedex.com (bill daniels) writes:
> 
> The column dealt with unshielded twisted pair, concentrators and
> other UTP-oriented devices.  Would someone please explain how UTP
> and concentrators enable one to establish a more reliable net?  This
> was all news to me.

If a conventional or thinwire coax is opened or shorted -- to add
a new transceiver, or because you want to reroute or extend the
cable, or because some electricians decided it was in the way but
that they could easily cut it and resplice it with black tape
later, you lose your whole net.  With UTP, everything is a ``home
run''; a problem on one segment affects only that segment.

Of course, a problem with the hub takes our your whole net, but that's
often easier to find and fix than a cable problem.

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 20:49:35 GMT
From:      bill@pyrite.nj.pyramid.com (Bill Pechter)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <9105201208.AA22490@tuatara.uofs.edu> bill@TUATARA.UOFS.EDU (Bill Gunshannon) writes:
>
>Unless things have changed drastically since the last article I read about
>Compuserve, they are running PRIME Mini's.

Nah, they're running DEC KL10's which run a modified TOPS10.  The Source,
purchased by Compuserve, ran Prime minis.

Delphi ran VAX's with VMS...

Anyone know what Genie runs?

Bill
-- 
Bill Pechter                       | "The postmaster always pings twice."
Pyramid Technology                 | bill@pyrite.nj.pyramid.com
10 Woodbridge Center Drive         | rutgers!pyrnj!pyrite!bill
Woodbridge, NJ 07095 (908)602-6308 | pyramid!pyrnj!pyrite!bill

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 21:28:56 GMT
From:      sl@wimsey.bc.ca (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <9105211159.AA23740@tuatara.uofs.edu> bill@TUATARA.UOFS.EDU (Bill Gunshannon) writes:
>
>1.  There are commercial INTERNET providers that Compuserve could hook up to.
>2.  It is not Compuserve's responsibility to police the NSFnet.  It is up to
>    the users to ensure that their traffic meets Acceptable Use Policy.
>
>It might even make the commercial INTERNET providers look more attractive if 
>one of them could lure Compuserve into the fold.  But, I stand by what I said
>above,  it isn't a technical problem.

It's far more likely that the current commercial provider's are not too terribly
happy about Compuserve getting interested in IP connectivity. It would be kind of 
interesting if Compuserve was able to provide dialup PPP or SLIP from all of their 
access points..... 

Locally the University of BC's dialup ports for UBCNet offer X.28/X.29 access to 
X.25 hosts, Telnet to internet hosts, or SLIP (either by using %slip or just sending 
a slip packet in command mode). 

If Compuserve was to introduce a service like that with some services behind it like
say POP3, FTP, and Telnet things could get quite interesting :-) Of course we hope
that they would join CIX and have an NFSNet interconnect as well. 

-- 
Stuart Lynne	Computer Signal Corporation, Canada
		...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca 

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 21:56:28 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

In article <1991May21.172018.11672@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>Assuming "UTP" means "10BaseT", the crucial issue is that 10BaseT is a star
>topology, with each host connected directly to the hub, whereas other forms
>of Ethernet are bus topologies, with more than one host hanging off of each
>piece of wire.  Given good equipment design, star topologies have one big
>advantage:  a foulup on one wire does not mess up anyone else.

We use an intermediate solution here.  Our network is mostly thin Ethernet
(we considered twisted pairs when we were rewiring, but I don't remember
why we decided against it), with the large subnets implemented using a
number of segments radiating from an intelligent repeater (Cabletron IRMs).
Any one segment has about a dozen hosts on it, so a cable problem generally
is limited to affecting that many hosts.  The intelligent repeater isolates
the segments electronically and can selectively shut down an individual
port (either manually, or automatically upon certain triggers such as
excessive error rates).

-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 21:58:08 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

In article <ENAG.91May21170512@gyda.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
|> Erik J. Murrey writes:
|> |
|> |   Ahh, but most recursive searching resolver libraries can be forced
|> |   not to append successive domains by anchoring the name with a
|> |   period.
|> 
|> This is illegal in mail addresses.
|> 


Arguably, MTA's shouldn't do any user-friendly heuristics on mail addresses at
all.  I would hope that the UA will form FQDN's to work with.  Otherwise, you
might run into the wildcard MX problems...

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 22:04:01 GMT
From:      jqj@duff.uoregon.edu (JQ Johnson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   advanced telnet features

I am looking for Mac telnet clients that support various modern telnet
features.  Since it doesn't look to me as if any of the current players in
this game (NCSA, MacIP, Intercon, Versaterm, etc.) currently support them,
I'd also be very interested in data indicating that development work was
in progress or at least that one of the developers was actively
participating in the IETF Telnet WG.  Specifically, I'm interested in:

1/ full linemode support (RFC1116), preferably tested against the Borman
   4.4bsd telnetd.  including negotiated local editing characters

2/ support for AUTHENTICATION and ENCRYPTION options

3/ support for authentication using Kerberos version 5

4/ NAWS (RFC1073)

5/ IP TOS support.  IP source routing support (I don't really want this
   one, but would be interested in knowing if anyone is working on it)

Reply by mail and I'll summarize to comp.sys.mac.comm.

-- 
JQ Johnson
Director of Network Services		Internet: jqj@oregon.uoregon.edu
University of Oregon			voice:	(503) 346-1746
250E Computing Center			BITNET: jqj@oregon
Eugene, OR  97403-1212			fax: (503) 346-4397

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 22:06:12 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

enag@ifi.uio.no (Erik Naggum) writes:

>Erik J. Murrey writes:
>|   by anchoring the name with a
>|   period.
 
>This is illegal in mail addresses.

No its not - its illegal to transport such an address over SMTP,
but its perfectly acceptable as a user interface - the mailer
completes any abbreviations, and removes any trailing dots
after that.

kre

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 22:42:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Diving into TCP/IP again... need help finding docco...

> Also, I'd like to use this as an opportunity to renumber our net. We
> originally set up as a class C network, but since we're unlikely to ever
> hook up straight to the real Internet is there any reason not to simplify
> things by using a class A network number?

Yes but you may hook up to a real internet, say 2 years, 1 year or 5 years 
down the road.  You wish you had applied to the network gods and got real 
numbers.  I would recommend, that you apply for valid numbers so that you
do not have to renumber some time in the future.  It only takes a few 
minutes and fill in the blanks, to save a lot of hassle down the road.

If you are the real GURU for your site I would recommend that you get
Douglas Comer book on Networking it should help you understand some
basics.

jim jones

College of St. Catherine
jrjones@alex.stkate.edu

612-690-6856

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 23:32:46 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

UTP is fault-tolerant in the sense that a cut cable generally affects only
the single node attached to it; the UTP hub will detect that one of its
ports is busted in some sense and take it out of the loop. If everyone was
one a single stretch of coax, a cut cable would affect every node on that
segment. Breaking the coax to insert another tee would stop the entire
segment, while adding a new UTP line to a hub shouldn't affect any other
users.

Of course, you're still vulnerable on the 10Base2 or 10Base5 links between
the hubs, and if you've cascaded hubs via UTP you have a larger
vulnerability on the cascading UTP lines, but that's a lot more manageable
than barrel and tee connectors etc. Also, you have the added vulnerability
of an active device (the hub itself) which might fail and take out n devices
with it.

Jazz

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      21 May 91 23:36:46 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Unused portion of first octet?

Also, class A network 127 isn't a real assignable network, as any IP address
on net 127 must be interpreted as a valid loopback address for the
transmitting node. One should never see a packet on a network sent from or
destined to net 127.

Jazz

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 01:00:13 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

gary@sci34hub.sci.com writes:
   Compuserve likes to bill for the use of their systems; billing people
   who telnet in would be very difficult.

This is false.  Connect time is connect time; they know how long
you've been there by any access method, and they'll bill
appropriately.  Remember the hermes.merit.edu Telenet access point --
this effect is already there.

   If CIS could see money in telnet/ftp connections, it'd already be done.

Also false.  Regardless of the raw $$$ that might be available,
CompuServe has a really serious problem with political questions.
They are quite paranoid about being on the receiving end of political
complaints; getting the original mail connection in place required an
agreement with the FRICC (this was 1989) which says, essentially, that
neither CompuServe nor NSFNet will charge the other for the use of the
other's network.  More recently, questions of "appropriate use"
agreements with each of the IP suppliers with which they checked
somewhat dominated their concerns.

Please, this is not a topic appropriate to tcp-ip any more; please
take it to com-priv@psi.com, if anywhere.  (Unfortunately, I
understand that my Reply-To: isn't surviving the news->mail gateway at
ucbvax.  Ohwell.)

--karl

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 07:54:43 GMT
From:      wbrand@krishna.shearson.com (Willy Brandsdorfer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In article <419@worf.dbaccess.com> yuko@dbaccess.com (Yuko Tanaka) writes:


>      Does anybody know TCP/IP software which runs on VM (CMS or GCS) and 
>   has socket interface to application?   SAS C interface is the best for
>   us.  
>
>      IBM TCP/IP for VM (R1.2) does not have socket interface and also 
>   requires IBM C for System/370 (we are calling White Smith C) which we don't
>   want to use.         


TCP/IP Version 2 supports a normal socket interface. I think you need to use
IBM C. I'm not an expert on this but I believe you can link this to SAS/C

------------------------------------------------------------------------------
William Brandsdorfer            | UUCP:    !uunet!shearson.com!wbrand
Lehman Brothers                 | ARPA:    wbrand@shearson.com
388 Greenwich St.               | Voice:   (212) 464-3835
New York, N.Y. 10013            | Yell:    "Hey Willy"
---------------------------------------------------------------------------

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 11:58:05 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

Erik Naggum (I) wrote:
|
|    This [trailing dot in domain name] is illegal in mail addresses.

I've been alerted to the precise meaning of "illegal", and would like
to change it to "invalid" or "non-conformant", or "violates syntax" or
something like that.  There is no Internet Police, Court System, etc...

Robert Elz writes:
|
|    No its not - its illegal to transport such an address over SMTP,
|    but its perfectly acceptable as a user interface - the mailer
|    completes any abbreviations, and removes any trailing dots
|    after that.

I didn't think we talked about user interfaces.  I don't think I'd
want to use a mailer which had that much "intelligence", but that's my
opinion.

</Erik>
--
Erik Naggum             Professional Programmer            +47-2-836-863
Naggum Software             Electronic Text             <ERIK@NAGGUM.NO>
0118 OSLO, NORWAY       Computer Communications        <enag@ifi.uio.no>

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 14:04:06 GMT
From:      assg7@fel.tno.nl (Rene van den Assem)
To:        comp.protocols.tcp-ip
Subject:   Prog. for SUN to reassemble IP-packets wanted.

The subjects says it all:

I have a SUN set up as a router between two subnets. On one of
the subnets I have FTPs PC/TCP, which doesn't properly support
fragmented IP-packets. However, I like this package, so I want
to do the reassembly in the router (through which all IP-packets
are going). I know that this isn't the standard way of doing things,
but is there anyone out there who has a program to do this
(on a SUN SS1).

Rene van den Assem,
assem@tnofel.fel.tno.nl,
+31703264221

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 15:42:00 GMT
From:      LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU
To:        comp.protocols.tcp-ip
Subject:   tn3270

I would like to ask the help of someone in order to get information on tn3270.
I know about RFC 1041 but I would like to find more about real use of this
option: examples of topologies using this kind of terminal emulation,
equipments used, implementations, software available, limitations etc..
I will compile all the responses received and present a result report to the
list.

Thanks in advance

Liane Tarouco
University Federal of Rio Grande do Sul
Institute of Informatics
Porto Alegre - Rs - Brazil
liane@sbu.ufrgs.anrs.br

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 18:01:47 GMT
From:      reidar@cucrd0.med.columbia.edu (reidar)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Per Vendor ethernet address assignments


I would appreciate it if someone could mail me a list of the assigned ethernet addresses and
the manufacturers to whom they are assigned.  I have the following list and would like to
have the gaps filled.  I am particularly interested in 000080.



00000C	Cisco
000020	DIAB (Data Intdustrier AB)
000022	Visual Technology
00002A	TRW
00005A	S & Koch
000065	Network General
000093	Proteon
00009F	Ameristar Technology
0000A9	Network Systems
0000AA	Xerox		Xerox machines
0000B3	CIMLinc
0000C0	Western Digital
0000DD	Gould
000102	BBN		BBN internal usage (not registered)
001700	Kabel
00DD00	Ungermann-Bass
00DD01	Ungermann-Bass
020701	Interlan	UNIBUS or QBUS machines, Apollo
020406	BBN		BBN internal usage (not registered)
02608C	3Com		IBM PC; Imagen; Valid
02CF1F	CMC		Masscomp, Silicon Graphics
080002	Bridge
080003	ACC (Advanced Computer Communications)
080005	Symbolics	Symbolics LISP machines
080008	BBN
080009	Hewlett-Packard
08000A	Nestar Systems
08000B	Unisys
080010	AT+T
080014	Excelan		BBN Butterfly, Masscomp, Silicon Graphics
080017	NSC
08001A	Data General
08001B	Data General
08001E	Apollo
080020	Sun		Sun machines
080022	NBI
080025	CDC
080028	TI		Explorer
08002B	DEC		UNIBUS or QBUS machines, VAXen, LANBridges
			(DEUNA, DEQNA, DELUA)
080036	Intergraph	CAE stations
080039	Spider Systems
080045	Xylogics???
080047	Sequent
080049	Univation
08004C	Encore
08004E	BICC
08005A	IBM
080067	Comdesign
080068	Ridge
080069	Silicon Graphics
08006E	Excelan
080075	DDE (Danish Data Elektronik A/S)
08007C	Vitalink	TransLAN III
080080	XIOS
080087	????
080089	Kinetics	AppleTalk-Ethernet interface
08008B	Pyramid
08008D	XyVision	XyVision machines
AA0003	DEC		Global physical address for some DEC machines
AA0004	DEC		Local logical address for systems running DECNET

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 18:21:56 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Diving into TCP/IP again... need help finding docco...

In article <70ECA8FF2AFF405D34@alex.stkate.edu> JRJONES@ALEX.STKATE.EDU writes:
 >> Also, I'd like to use this as an opportunity to renumber our net. We
 >> originally set up as a class C network, but since we're unlikely to ever
 >> hook up straight to the real Internet is there any reason not to simplify
 >> things by using a class A network number?
 >
 >Yes but you may hook up to a real internet, say 2 years, 1 year or 5 years 
 >down the road.  You wish you had applied to the network gods and got real 
 >numbers.  

I will wholeheartedly second this having just spent my weekend renumbering
FPS San Diego's network.  Do it right the first time.  It's much easier.
--
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 19:46:27 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <1991May21.165458.7441@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
> Compuserve likes to bill for the use of their systems; billing people
> who telnet in would be very difficult.

Why?

I'm sure it'd look like this:

	% telnet compuserve.com
	Trying...
	Connected to compuserve.com.
	Escape character is '^]'.
	Host: CIS
	Username: 70216,1076
	Password:

	Welcome to Compuserve!

Similarly, they would provide FTP service on the same basis:

	% ftp compuserve.com
	Connected to compuserve.com.
	220 compuserve.com FTP server ... ready.
	Name: (compuserve.com:peter): 70216,1076
	331 Password required for 70216,1076.
	Password:
	230 User 70216,1076 logged in.
	ftp> cd amigatech
	100 CWD command okay.
	...

> If CIS could see money in telnet/ftp connections, it'd already be done.

They have their eyes closed.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 20:12:18 GMT
From:      elogan@hp835.mitek.com (Ernie Logan)
To:        comp.protocols.tcp-ip
Subject:   Re: Prog. for SUN to reassemble IP-packets wanted.

In article <1991May22.140406.19366@fel.tno.nl> assg7@fel.tno.nl (Rene van den Assem) writes:
>The subjects says it all:
>
>I have a SUN set up as a router between two subnets. On one of
>the subnets I have FTPs PC/TCP, which doesn't properly support
>fragmented IP-packets. However, I like this package, so I want
>to do the reassembly in the router (through which all IP-packets
>are going). I know that this isn't the standard way of doing things,
>but is there anyone out there who has a program to do this
>(on a SUN SS1).
>
>Rene van den Assem,
>assem@tnofel.fel.tno.nl,
>+31703264221

Rene:

FTP, Inc. say they fixed fragmented IP packet problem in version 2.04.
2.05 is the current version. Try contacting them at support@ftp.com. for an
update. I too like this package.



Ernie Logan
AS/400 TCP/IP Development
elogan@mitek.com

OpenConnect Systems
2033 Chennault Drive
Carrollton, Texas USA 75006
Phone: (214) 490-4090
*-------------------------------*
* "My opinions are mine alone.	*
* No one else would want them."	*
*-------------------------------*

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 20:28:50 GMT
From:      jms@mrsvax.mis.arizona.edu (The IRS gets 28% of this message---and everything else I own)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <.QHBBXB@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes...
>In article <1991May21.165458.7441@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
> 
>I'm sure it'd look like this:
> 
>	% telnet compuserve.com
>	Trying...
>	Connected to compuserve.com.
>	Escape character is '^]'.
>	Host: CIS
>	Username: 70216,1076
>	Password:
> 

Actually, this service is already available.  All you have to do is find
one of the sites which has both a CompuServe link and an Internet link
that is willing to handle your traffic.  When I log onto CompuServe, I
sure don't use no slow dialin line.  

> 
>> If CIS could see money in telnet/ftp connections, it'd already be done.
> 
>They have their eyes closed.

CompuServe is very technically adept, and has a number of very good
people working for it.  However, it runs as an extremely low-overhead
organization.  The question is not whether they "see money" in such a
connection; there have been individuals calling for such a connection for
at least 9 years.  The question is where the project falls in a long list
of projects, all designed to satisfy customer requests.  It is clear from
their current directions that CompuServe is ready to offer such a connection;
the current impediments are almost certainly political, legal, and procedural
rather than technical.

In any case, such aspersions in this forum do nothing to improve the situation; 
a well-worded letter requesting such a capability sent to the appropriate
vice president (probably Sandy Trevor) certainly would be a more useful
use of all our time.

jms

Joel M Snyder, 627 E Speedway, 85705  Phone: 602.626.8680 FAX: 602.795.0900
The Mosaic Group, Dep't of MIS, the University of Arizona, Tucson
BITNET: jms@arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms   
"Communication without purpose is artistic masturbation." - Rod Steiger

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 21:37:49 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Diving into TCP/IP again... need help finding docco...


         ...since we're unlikely to ever hook up straight to the real
         Internet is there any reason not to simplify things by using
         a class A network number?
      
      Yes but you may hook up to a real internet, say 2 years, 1 year
      or 5 years down the road.  You wish you had applied to the
      network gods and got real numbers.

I have helped several organizations prepare for and achieve Internet
connectivity, none of whom thought they'd ever have it when they first
"designed" (I use that term loosely :-) their local network and
connected those first two workstations to a little hunk of yellow
Ethernet.  Now that they have dozens or hundreds of machines talking
IP, it's exponentially more difficult to renumber than it would have
been if they had started with their own address in the first place.

How many networks have you seen numbered 192.9.200?  Sun did the world
a favor by introducing them to IP, but didn't emphasize the need to
acquire their own slice of the address space.  One very large local
organization has been using 192.9.200, ..201, ..202, ..203, and ..204
for years.  Now it has become an issue of turf battles and intense
internal politics, as they must renumber all those hosts and gateways.
The transition from isolation to "connected status" is turning out to
be far, far more painful than it needed to be.

   Do it right the first time.  It's much easier.

Amen.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      22 May 91 22:57:43 GMT
From:      matthew@hermesa.uucp (Matthew Kayes)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for OS/2?

Are there any TCP/IP's yet for OS/2 clients?  Thanks for your
help.

Matthew Kayes

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 00:03:50 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

enag@ifi.uio.no (Erik Naggum) writes:

>I've been alerted to the precise meaning of "illegal",

OK, I will avoid using that too, though I really don't see the need
to be that pedantic, I think we all know what is meant.

>I didn't think we talked about user interfaces.

I think that's exactly what we've been talking about - what names
the users can use in various applications to refer to various hosts.

>I don't think I'd want to use a mailer which had that much "intelligence",
>but that's my opinion.

Basically, to satisfy user expectations, you want the same names to
work for all applications, if you can telnet to x.y and have it
reach some particular host, you want ftp to x.y in the same environment
to reach exactly the same place, and what's more, mail to x.y to do the
same (allowing for MX records that may direct mail to a particular host
for delivery, but the overall effect is the same).

If you don't want your mail user agent completing partial domain names
for you, then logically you also don't want your telnet client doing it
either, or your ftp client, or ... and you just use fully qualified
names all the time.  That's OK, if that's what you want, and the
question of how abbreviated names should work will be irrelevant to you.
It will still be relevant to lots of other people though.

kre

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 03:15:00 GMT
From:      randy@rls.UUCP (Randall L. Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <543@pyrite.nj.pyramid.com>, bill@pyrite.nj.pyramid.com (Bill Pechter) writes:
> In article <9105201208.AA22490@tuatara.uofs.edu> bill@TUATARA.UOFS.EDU (Bill Gunshannon) writes:
>>
>> Unless things have changed drastically since the last article I read about
>> Compuserve, they are running PRIME Mini's.
> 
> Nah, they're running DEC KL10's which run a modified TOPS10.  The Source,
> purchased by Compuserve, ran Prime minis.

True and they're now converting to VMS.  I toured their data center last
fall and they still had *ton's* of RP06's!! The antique KL10's and KL20's
still humming along.  The Primes were sitting the corner running but not
being used, as I was told.  Modifying TOPS seemed to be a costly venture
in the long run.  Might have been more costly to be out of business
though.  Anyway, I really don't know how central it was to the business. 
Presumably, very.  They do all (almost) their own hw support even on the
new Vaxen.  The biggest Vax they had (at the time) was a 6410. 

Cheers!

- randy

Usenet: randy@rls.uucp
Bangpath: ...<backbone>!osu-cis!rls!randy
Internet: rls!randy@tut.cis.ohio-state.edu
Do not meddle in the affairs of the network news,
	for they are subtle and quick to anger.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 04:12:33 GMT
From:      sfr@pdact.pd.necisa.oz.au (Stephen F. Rothwell)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC port to SCO Unix?

In article <1991May20.204503.4563@ttsi.lonestar.org>, root@ttsi.lonestar.org (System) writes:
> 
> Has anyone modified the RPC 4.0 sources to run on SCO Unix?
> Any help will be greatly appreciated.

Can anyone tell me if the RPC 4.0 sources are available, and if so
where?

Stephen Rothwell		NEC/Information Systems Australia
sfr@pdact.pd.necisa.oz.au	Software Development Centre, Canberra

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 08:19:13 GMT
From:      matt@bacchus.esa.oz (Matt Atterbury)
To:        comp.misc,comp.protocols.ibm,comp.protocols.tcp-ip,comp.windows.x
Subject:   IBM 3270 <-> x3270 connectivity.


	*** AVOID FOLLOW UPS TO ALL NEWSGROUPS - Mail me and I'll summarise ***

	I'm after a similar thing to Bob Irwin. Also, please note that I
	know _very_ little about IBM/SNA except for a few "magic" words
	(e.g. 3270, 3274, etc :-).

	On a [non SUN] workstation I would like to run x3270. It seems to
	talk 8-bit asynchronous EBCDIC (correct me if I'm wrong) and
	emulates a 3270 terminal. If I could just get my workstation
	connected to a 3274 (or equivalent), would I have my mainframe
	connection? As far as I can see, all I need is a _cheap_ black box
	to do the 9-bit (1 parity) EBCDIC synchronous SDLC <-> 8-bit
	asynchronous EBCDIC conversion. If my workstation could talk SDLC
	through its serial port, I wouldn't even need that?


|IBM |___|37x5|___|3274|___|black|___| w/s |
|HOST|   |Comm|   |Clus|   | box |   |  +  |
|    |   |Cntr|   |Cntr|   |     |   |x3270|

	thanks in advance ...
--
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au]   Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au            "klaatu barada nikto"
  or: ...!uunet!murtoa!bacchus.esa.oz.au!matt         "consider this a divorce"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET  "life? don't talk to me about life!"

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 13:28:11 GMT
From:      xxseub@osprey.lerc.nasa.gov (Steven Eubanks)
To:        comp.protocols.tcp-ip
Subject:   Re: PC Remote control software over the Internet

In article <9105201435.AA01612@hns.com>, c_bstratton@HNS.COM (Bob
Stratton) writes:
|> 
|>    Date: Fri, 17 May 91 21:25:01 -0400
|>    From: leo j mclaughlin iii <ljm@ftp.com>
|> 
|>    NetBIOS LAN version of CloseUP/Carbon Copy and a vendor of NetBIOS
|> over
|>    TCP/IP which supports M/P-node or extended B-node services.  Stir
|> gently and

stuff deleted.

|> 
|> Would you be so kind as to explain why the NetBIOS implementation
|> style (m/p vs b node) is important. I've read the RFC's, but I'm not
|> clear as to which services you're depending on. (Especially in the
|> extended B-node case.)
|> 

I'm not sure I can speak to the extended B-node case, but B-node
requires all clients of a NetBIOS server (both ends of a CloseUP/Carbon
Copy session) to be
contained within a single LAN.  B-node dependent
services/implementations will 
not operate across an extended LAN which merely routes.  Bridging
(perhaps
via bridging routers ) would be required to support this functionality. 
RFCs
1001/1002 do include mechanisms to support NetBIOS across routed LANs
via
M/P-node support, but: 1) either the potential user market is not [yet
:-)] large
enough for the vendor community to merit the development effort, 2)
NetBIOS-based
LANs are typically being "bridged", or 3) there are enough unresolved
issues
in the RFCs to make interoperability between vendors a sticky issue;
that to
the best of my knowledge, the available M/P-node based product offerings
are
underwhelming or virtually non-existant.  Maybe the problem stems from
all three.

I'm sure that's more than you asked for.... oh well.

Steve
-- 
Steven W. Eubanks,  Telecomm & Networking 	NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-9479					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
"For every complex problem there's a simple solution, and it's usually wrong...

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 13:39:54 GMT
From:      shj@login.dkuug.dk (Stig Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   Emulating msgop(2) and semop(2) via TCP/IP?

Question 1:

I have some applications that utilizes the System V ipc features,
namely the semop(2) and msgop(2) calls. I wonder if there is a
library that emulates these system calls, so that they'll work
across a network?

For instance, our database lockmanager runs on the server. To
access the database from another machine, one has to perform an
rlogin/telnet/rsh to the server, otherwise the application can't get in
touch with the lockmgr, since it runs on another machine. There is no
real problem with the database itself, since it can be accessed via
NFS.

We're using SysV r3.2 (ISC 2.2) and are running their TCP/IP and
NFS.

Question 2:

In the same environment as above: How do one submit a print job from a
client to the printer attached to the server? All I could find in the
documentation, was some references to a Dos printer server.

Question 3:

Is it possible to share devices (/dev/*), such as tty-ports
across TCP/IP?

That was all my questions for today - thanks :-)
--
Stig Jacobsen
shj@login.dkuug.dk / sysadm

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 14:41:26 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '91 AP (again?)


[Apologies if this is a repost, but I haven't seen my first posting get
back to me and I've just learned that the airfare deal, which requires
a purchase by 30 June, is apparently very good]

========================================================================

                         Advance Program

                           SIGCOMM '91
                           Conference

             Communication Architectures and Protocols

                      September 3 - 6, 1991

                       Zurich, Switzerland


========================================================================
         SIGCOMM '91  General Information

SIGCOMM is the annual conference of the ACM Special Interest Group in
Computer Communication.  For the first time in its over 20 years,
SIGCOMM '91 will be held in Europe, namely in Zurich, Switzerland, at
the Swiss Federal Institute of Technology (ETH), September 3-6, 1991.
This advance program contains the tentative schedules of the conference
and the tutorials.  For further informatiom, feel free to contact
the conference committee by

 E-Mail           sigcomm91@clients.switch.ch
 FAX              +41-1-938-1557
 Telephone        +41-1-937-2447

 Surface          SIGCOMM '91  Secretariat
 Mail             P.O. Box
                  CH-8340 Hinwil
                  Switzerland

Zurich , one of the larger cities of Switzerland, is easily reached from
all-over the world through its international airport.  Participants
arriving at the Zurich airport will see a booth labeled SIGCOMM '91
where they can obtain initial directions on finding their way.  People
arriving by train can get a first orientation from the hotel information
panel at the Zurich Main Station.

Public transportation is very reliable and efficient:  the train takes
15 minutes from the airport to the center of the city from which hotels
and the ETH are within another 15 minutes reach.  Each conference
participant will get a free ticket for an unlimited number of rides on
the Zurich Tram and Bus network, valid throughout the whole week.

Accommodation is provided by several hotels, all located within 1.5 km
(walking distance) from the conference site.  Hotel reservations can be
made via the attached conference registration form.

Conference Location and Registration Desk

 Address             Gloriastrasse 35
 Tram Stop           Voltastrasse
                     (Tram numbers 5 or 6, direction Zoo)
 Telephone           (+41-1-) 261-0750
 Open                Monday 16:00-20:00, Tuesday-Friday 08:00-18:00

The climate is mild with temperatures around 20 degree Celsius (68
degree F); rain cannot be ruled out.

Special Airfare:  For your convenience SIGCOMM '91 has arranged for
special conference airfares through Hoffman Travel and American
Airlines.  To take advantage of discounted fares (for travel dates
between August 28 and September 15)
       call Jody Katz, Hoffman Travel, +1-800-221-4674,
       identify SIGCOMM '91.
Tickets must be issued before June 30, 1991.

========================================================================
         SIGCOMM '91  Overall Schedule

Conference Sessions usually last for 90 minutes.  They will take place
in a single, sufficiently large auditorium, well-equipped with
audio-visual facilities.

Breaks will last for 30 minutes, refreshments are served in the lobby in
front of the auditorium.

Lunches are served in the Restaurant of the ETH main building, which
implies a 10 minutes walk from the conference building.  Participants
receive lunch by presenting their badges.  Extra lunch tickets are
available at the registration desk.

Three Tutorials will be conducted in parallel on Tuesday.

The Conference Technical Program is scheduled in 10 sessions from
Wednesday to Friday.

The Opening Session on Wednesday morning will start at 08:45.

The SIGCOMM Business Session is scheduled on Wednesday, 17:40.

The Welcome Apero will be offered on Tuesday, at 18:00, in the Foyer of
the ETH main building.

A Social Event is scheduled for Thursday evening.  During a boat trip on
the beautiful lake of Zurich, there will be a banquet.  Musical
(folkloristic) entertainment will interleave with speeches by honorary
guests.  Informal dress is recommended.  The social event is included in
the conference registration fee except for student participants.
Additional tickets for students or accompanying persons can be
purchased at the registration desk.

Please note .....  SIGCOMM '92 will be held at the Hyatt Regency in
Baltimore, Maryland, USA, Monday August 17 through Thursday August 20.
Mark your calendar now .

========================================================================
         SIGCOMM '91  Conference Committee

 General Chair                    Eduard Mumprecht, IBM Research, Zurich
 Program Chair and Tutorials      Bernhard Plattner, ETH Zurich
 Program Co-Chair                 Greg Wetzel, AT&T Bell Laboratories
 Registration                     Mrs. Anne Schicker
 Local Arrangements               Hannes Lubich, ETH Zurich,
                                  and Raymond Bandle, University of Zurich
 Treasurer                        Peter Heinzmann, ITR Rapperswil
 Publicity                        Craig Partridge, BBN, Cambridge, Mass.


 Cooperating Institutions:

 IEEE       IEEE Switzerland Section
 SI         Schweizer Informatiker Gesellschaft
 SWITCH     Swiss Telematic Services for Education & Research
 ITG        Informationstechnische Gesellschaft des SEV
 TIK        Institut fur Technische Informatik und Kommunikationsnetze, ETH

========================================================================
         SIGCOMM '91  Tutorial A:
         Metropolitan Area Networks and High Speed Local Area Networks
         by Lawrence J. Lang and David M. Piscitello,
            Bellcore, Red Bank, NJ 07701, USA.

This tutorial examines two emerging Metropolitan Area Network (MAN)
technologies, Fiber Distributed Data Interface (FDDI) and the
Distributed Queue Dual Bus (DQDB) MAN:

1. What is MAN Technology?

2. ANSI X3T9.5 Fiber Distributed Data Interface (FDDI)

Overview of FDDI
Standards
Topologies and Station Types
Media Access Control Formats and Procedures (MAC)
Physical Layer and Media (PHY/PMD)
Station Management (SMT)
Applications

3. IEEE 802.6 Distributed Queue Dual Bus (DQDB)

Overview of DQDB
Standards
Media Access Control Formats and Procedures
Management Control Protocol and Bandwidth Balancing
Physical Layer Convergence Procedures/Media (US/European)
Switched Multi-megabit Data Service (SMDS)
Applications

4. Comparing, Contrasting and Connecting FDDI, DQDB and SMDS

FDDI and SMDS are friends
Interconnecting FDDI with SMDS/DQDB
FDDI requirements
Dedicated line options
SMDS options
ETSI MAN options

Lawrence J. Lang is a member of the Broadband Data Services division at
Bellcore.  He is Bellcore's representative to the SMDS Interest Group,
an industry forum, and ANSI X3T9.5, which develops FDDI standards.  He
works on Switched Multi-megabit Data Service (SMDS), concentrating on
such issues as internetworking with FDDI, billing, and exchange access.
Since starting with Bellcore in 1986, he has worked on diverse new
services, including bill management, encryption, image communi- cations,
digital radio, and videotex gateways.
Larry received a BSE in electrical engineering from Duke University and
an MS in operations research from Stanford University.

David M. Piscitello is a member of the Broadband Data Services division
at Bellcore.  Prior to joining Bellcore, he worked for Unisys (former
Burroughs) on proprietary data network architectures, TCP/IP, and OSI.
He is a former Vice-Chair of the ANSI committee responsible for OSI
Transport/Network Standards, a former member of several ISO OSI
Subcommittees, and a member of the IETF.  Dave works with Larry on SMDS,
concentrating on SMDS feature refinements, Customer Network Management,
and operation of internetworking and routing protocols over SMDS.
Dave received a BS in Mathematics from Villanova University.

========================================================================
         SIGCOMM '91  Tutorial B:   Network Security
         by Dr. Stephen Kent,
            BBN Communications, Cambridge, MA 02140, USA.

      Introduction

course outline; context for network security; why network security;
network environment model; protocol layering

      Attacks & Security Philosophy

passive & active wiretapping; example attacks; network security philosophy

      Security Services

ISO 7498-2; what's missing?

      Cryptographic Concepts

algorithms & keys; symmetric ciphers; asymmetric ciphers; cryptograhic
system integrity

      Symmetric Cipher Modes (DES examples)

block mode; block chaining mode; output feedback mode; cipher feedback mode

      Cryptography for Layer 2

"link" encipherment example; why use "link" cryptography?; synchronous
link cryptography; asynchronous link cryptography; LAN cryptography (802.10)

      Cryptography for Layer 3/4

"end-to-end" encipherment example; why use "end-to-end" cryptography?;
SDNS SP3; SDNS SP4

      Key Management

key management principles; key distribution center concept & example;
public-key certificates (X.509); key distribution using certificates the
certification hierarchy for Internet; Privacy Enhanced Mail ;

      Cryptography for Layer 7

realtime vs. staged delivery applications; 1988 X.411 security facilities
Internet Privacy Enhanced Mail; X.500 directory system use of cryptography

      User Authentication Technology

personal authentication criteria; problems with passwords;
challenge-response schemes; "Watchword" & "Secure-ID" systems;
a word about biometrics

Stephen Kent is the Chief Scientist of BBN Communications, a division of
Bolt Beranek and Newman Inc., where he has been enganged in network
security research and development activites for over a decade.  His work
has included the design and developemnt of user authentication and
access control systems, end-to-end encryption and access control systems
for packet networks, performance analysis of security mechanisms, and
the design and implementation of secure transport layer and electronic
message protocols.  He was a charter member of the board of directors of
the International Association for Cryptologic Research.

Dr.  Kent received the B.S.  degree in mathematics from Loyola
University of New Orleans, and the S.M., E.E., and Ph.D.  degrees in
computer science from the Massachusetts Institute of Technology.



========================================================================
         SIGCOMM '91  Tutorial C:
         ATM Networks: Architecture, Technology and Performance Modeling
         by Prof. Dr. Paul J. Kuehn,
            Dipl.-Ing. H. Kroener and Dipl.-Ing. T. Theimer,
            University of Stuttgart, Germany

High speed networks are applied in computer communication for LAN
interconnection, fast file transfer or data retrieval and for broadband
telecommunications such as video, high resolution picture transfer, HiFi
audio and document transfer.  Two main technologies are directing to
these applications:  High Speed Local Area Networks (HSLAN) /
Metropolitan Area Networks (MAN) and Wide Area Networks on the basis of
Asynchronous Transfer Mode (ATM).  ATM is also the basis for future
Broadband-ISDN and the Integrated Broadband Communication Network (IBCN)
of the future.

The tutorial addresses mainly the ATM aspects and is structured in 4
parts.  In the first part, services, grade of service parameters and
network requirements are introduced which lead to the integration of a
broad spectrum of different services.  In the second part, the logical
structure of the B-ISDN is introduced, i.e.  the Asynchronous Transfer
Mode (ATM), the layered ATM protocol architecture, of the Physical Media
Dependent (PMD) part, the ATM and the ATM Adaption Layers (AAL), the
Protocol Data Unit Structures and the basic control algorithms.  In the
third part, technological aspects are addressed such as ATM Terminals,
ATM Switching Networks and Signalling.  The last part covers performance
modeling aspects as variable bitrate sources, source policing
algorithms, loss control, connection admission control end end-to-end
delay control.  Generic models, their analysis methods and key results
will be given to demonstrate the potential of performance modelling for
the design of ATM networks.

Paul J. Kuehn received the Dipl.-Ing.  and the Dr.-Ing.  degrees in
electrical engineering from the University of Stuttgart in 1967 and
1972, respectively, where he also was an Assistant Professor and head of
a research group for traffic research in computer and communication
systems.  At the University Erlangen-Nuremberg he taught courses on
communications switching.  In 1977 he joined Bell Laboratories, Holmdel,
NJ.  In 1978 he was appointed Full Professor for Communications,
Switching and Transmission at the University of Siegen, Germany.  Since
1982 he has been back at the University of Stuttgart to the chair of
Communications Switching and Data Technics.  His areas of interest
include communication switching, computer and communication systems
performance evaluation.
Besides being member of the ACM and numerous German professional
societies, Prof.  Kuehn's membership on an international level includes
the Communications Switching Committee of the NTG, the International
Advisory Council of the International Teletraffic Congress (ITC), and
W.G.  7.3 of the IFIP.  He was appointed Vice President of the ITC in
1985, and Governor of the ICCC in 1987.  In 1989 Professor Kuehn has
been elected IEEE Fellow.

========================================================================
         SIGCOMM '91  Wednesday, Sept. 4

OPENING
 Presentation of the SIGCOMM Award
 Presentation of the SIGCOMM '91 Student Paper Award

SESSION 1: New Approaches to Congestion and Flow Control
    Chair: Stephen Pink (Swedish Institute of Computer Science)

 A Control-Theoretic Approach to Flow Control
    Srinivasan Keshav (Univ. of California, Berkeley)

 Loss-Load Curves: Support for Rate-based Congestion Control
 in High-speed Datagram Networks
    Carey L. Williamson, David R. Cheriton (Stanford Univ.)

SESSION 2: Routing
    Chair: Deborah Estrin (Univ. of Southern California)

 Dynamics of Distributed Shortest-Path Routing Algorithms
    William T. Zaumen, J. J. Garcia-Luna Aceves (SRI International)

 Finding Disjoint Paths in Networks
    Deepinder P. Sidhu, Raj Nair, Shukri Abdallah (Univ. of Maryland - BC)

 Efficient and Robust Policy Routing Using Multiple Hierarchical Addresses
    Paul F. Tsuchiya (Bell Communications Research)

SESSION 3: Modelling and Formal Methods
    Chair: Deepinder Sidhu (Univ. of Maryland - BC)

 GSPN Models of Random, Cyclic, and Optimal 1-Limited Multiserver Multiqueue Sys
    Marco Ajmone Marsan (Politecnico di Torino),
    S. Donatelli (Universita di Torino),
    F. Neri, U. Rubino (Politecnico di Torino)

 Queueing Analysis of A Statistical Multiplexer with Multiple Slow Terminals
    Zhensheng Zhang (Columbia Univ.)

 Efficient Gateway Synthesis from Formal Specifications
    D. M. Kristol, D. Lee, A. N. Netravali, K. Sabnani (AT&T Bell Laboratories)

SESSION 4: Traffic Characterization
    Chair: Gregory Wetzel (AT&T Bell Laboratories)

 Characteristics of Wide-Area TCP/IP Conversations
    Ramon Caceres (Univ. of California, Berkeley),
    Peter B. Danzig, Sugih Jamin,
    Danny J. Mitzel (Univ. of Southern California)

 Comparison of Rate-Based Service Disciplines
    Hui Zhang, Srinivasan Keshav (Univ. of California, Berkeley)

 A Study of Priority Pricing in Multiple Service Class Networks
    Ron Cocchi, Deborah Estrin (Univ. of Southern California),
    Scott Shenker, Lixia Zhang (XEROX Palo Alto Research Center)

========================================================================
         SIGCOMM '91  Thursday, Sept. 5

SESSION 5: Analysis of Congestion and Flow Control Protocols
    Chair: Craig Partridge (Swedish Institute of Computer Science)

 Observations on the Dynamics of a Congestion Control Algorithm:
 The Effects of Two-Way Traffic
    Lixia Zhang, Scott Shenker (XEROX Palo Alto Research Center),
    David D. Clark (MIT Laboratory for Computer Science)

 Performance Analysis of a Feedback Congestion Control Policy
 Under Non-negligible Propagation Delay
    Y. T. Wang (AT&T Bell Laboratories), B. Sengupta (NEC Research Institute)

 Analysis of Dynamic Congestion Control Protocols
    - A Fokker-Plank Approximation
    Amarnath Mukherjee (Univ. of Pennsylvania),
    John C. Strikwerda (University of Wisconsin, Madison)

SESSION 6: Communication Architectures
    Chair: Gerald W. Neufeld (Univ. of British Columbia)

 Design of an ATM-FDDI Gateway
    Sanjay Kapoor, Gurudatta M. Parulkar (Washington Univ.)

 Nomenclator Descriptive Query Optimization for Large X.500 Environments
    Joann J. Ordille, Barton P. Miller  (Univ. of Wisconsin, Madison)

 Flexible Protocol Stacks
    Christian Tschudin (Universite de Geneve, Switzerland)

SESSION 7: Designing for Mobility
    Chair: Jonathan M. Smith (Univ. of Pennsylvania)

 A Network Architecture Providing Host Migration Transparency
    Fumio Teraoka, Yasuhiko Yokote,
    Mario Tokoro (Sony Computer Science Laboratory)

 Concurrent Online Tracking of Mobile Users
    Baruch Awerbuch (MIT Laboratory for Computer Science),
    David Peleg (The Weizmann Institute)

 IP-based Protocols for Mobile Internetworking
    John Ioannidis, Dan Duchamp, Gerald Q. Maguire Jr. (Columbia Univ.)

SESSION 8: Protocol Design and Analysis
    Chair: Vinton G. Cerf (Corp. for National Research Initiatives)

 The LAMS-DLC ARQ Protocol
    Christopher Ward, Cheong Choi (Auburn Univ.)

 Hardware Flooding
    Ajei Gopal (Cornell Univ.),
    Inder Gopal, Shay Kutten (IBM Thomas J. Watson Research Center)

SOCIAL EVENT
    Do not miss boat trip on the lake of Zurich.
    There will be a rich banquet and good entertainment.

========================================================================
         SIGCOMM '91  Friday, Sept. 6

SESSION 9: Load Scheduling
    Chair: Harry Rudin (IBM Research, CH)

 Network Locality at the Scale of Processes
    Jeffrey Mogul (Digital Equipment Corp.)

 MARS: The Magnet II Real-Time Scheduling Algorithm
    Jay M. Hyman, Aurel A. Lazar, Giovanni Pacifici (Columbia Univ.)

 About Maximum Transfer Rates for Fast Packet Switching Networks
    Jean-Yves Le Boudec (IBM Zurich Research Laboratory, Switzerland)

SESSION 10: Architectures for High Speed Networking
    Chair: Gary Delp (IBM Research, USA)

 A Host-Network Interface Architecture for ATM
    Bruce S. Davie (Bell Communications Research)

 A High Performance Host Interface for ATM Networks
    C. Brendan, S. Traw, Jonathan M. Smith (Univ. of Pennsylvania)

 Fairisle: An ATM Network for the Local Area
    Derek R. McAuley (Univ. of Cambridge, UK)


========================================================================
         SIGCOMM '91 Program Committee

Vinton G. Cerf, USA                    Gerald W. Neufeld, Canada
A. Lyman Chapin, USA                   Craig Partridge, USA
Gary Delp, USA                         Stephen Pink, Sweden
Maria Dimou, Switzerland               Bernhard R. Plattner, Switzerland
Deborah Estrin, USA                    Marshall T. Rose, USA
Jose Garcia-Luna, USA                  Harry Rudin, Switzerland
Jean-Pierre Hubaux, Switzerland        Pietro Schicker, Switzerland
Lawrence H. Landweber, USA             Deepinder Sidhu, USA
Stewart Lee, Canada                    Jonathan Smith, USA
Hannes Lubich, Switzerland             Douglas B. Terry, USA
Derek R. McAuley, UK                   Paul von Binst, Belgium
Manel Medina, Spain                    Gregory Wetzel, USA
David Mills, USA

========================================================================


CONTACT THE CONFERENCE OFFICE FOR REGISTRATION FORMS USING THE ADDRESSES
AT THE START OF THIS FORM.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 15:16:07 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: Per Vendor ethernet address assignments

In article <218@cucrd0.med.columbia.edu>, reidar@cucrd0.med.columbia.edu (reidar) writes:
> 

See RFC1060 available from a NIC near you. It has fairly up-to-date lists of
vendor, protocol, and Multicast numbers.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov		(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything. Especially
anything gnu.

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 17:40:39 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <22MAY91152850@mrsvax.mis.arizona.edu> jms@mrsvax.mis.arizona.edu writes:
> In any case, such aspersions in this forum do nothing to improve the
> situation...

I call them as I see them. Further comments taken to email.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 17:47:21 GMT
From:      wiltzius@lll-crg.llnl.gov (Dave Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Proxy ARP question

I have searched the host requirements documents, rfc1009 and other
RFCs without finding a definitive answer to the following:  Should
proxy ARP work only for hosts on the same network, but different
subnets?  In particular, should it specifically *not* work between
hosts on different networks (such as 128.100 and 128.99)?

Nothing I have found says it should not work for the latter but
there are statements that imply it should only work for hosts on
subnetted networks when going to other hosts on the same subnetted
network (here the assumption is that the host depending upon proxy
ARP does not do subnetting).

Thanks.
  Dave Wiltzius
  Lawrence Livermore Nat'l Lab
  wiltzius@llnl.gov

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 19:48:57 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP question

Proxy ARP seems to have been invented originally simply to handle
the problem of systems that did not implement subnets.  I believe
the first implementations worked only with addresses on other subnets
of the same network.  It's not used by a number of people for
other purposes, and many implementations will respond to requests
for addresses on other networks.  We use it for finding gateways.
That is, we don't like the idea of hardcoding gateway addresses
into 100s of config files.  So we configure most of our systems
to ARP for everything.  It's then the gateways' job to make sure
that the right gateway responds.  We're moving to Cisco's Gateway
Discovery Protocol slowly.

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 19:58:11 GMT
From:      spalleti@smdnet.intel.com
To:        comp.protocols.tcp-ip
Subject:   Request suggestions about ethernet problem


 Hi,

 We are experiencing packet fragments problem in one of our 802.3 segment. 
 Sniffer gives following analysis about these packets:

 Destination Address: AAAAAAAA 
 Frame error: fragment : bad CRC or Bad alignment
 Souce Station: ????????           Frame size: 7 or 8 bytes


 We see high number of framents in this ethernet (802.3) segment. Our guess
 is workstation interface borad or cable fault. 

 Our problem is, we cann't identify source station. Please make note of frame
 size(7 or 8 bytes).

 I appreciate any suggestion to trace this problem. I want to know what
 causes this kind of framents(all A's). 

 Thanks in Advance
 Steve Palleti

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 22:18:54 GMT
From:      mcginnis@kuhub.cc.ukans.edu
To:        comp.protocols.tcp-ip
Subject:   NDIS compliant TELNET?  Please help.

I need to run DEC PathWorks and TELNET on personal computers.  It
looks like PathWorks will only work with NDIS protocol compliant
network packet drivers...

Anybody out there make a TELNET that will work with NDIS?

Any clues will be much appreciated and undoubtedly earn the giver
much good karma.

Thanks.

Michael McGinnis            internet: mcginnis@kuhub.cc.ukans.edu
Academic Computing Center     bitnet: mcginnis@ukanvax
University of Kansas           voice: (913)864-0413
Lawrence, Kansas  66045          FAX: (913)864-0485

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      23 May 91 23:48:13 GMT
From:      stu@tandem.com (Stuart G. Phillips)
To:        comp.dcom.lans,rec.radio.packet,comp.protocols.tcp-ip
Subject:   Wireless LAN mailing list


There is currently much discussion and publicity about Wireless LANs, their
possible applications, choice of frequency, protocols, etc.  The I.E.E.E 802
committee has established a sub-committee (802.11) to propose a standard
for Wireless LANs.

Wireless LANs pose a unique challenge to the engineer since they represent
a combination of technologies:

	- RF design
	- Propagation and wave physics
	- Data communications
	- Computer engineering
	...

Few engineers or designers have all these skills in their portfolio; progress
towards Wireless LANs therefore requires teamwork and an open mind to allow
experts in different technologies to contribute and work towards a common goal.

We propose to establish a moderated mailing list to provide a technical forum
for the development of Wireless LANs specifically aimed at data communications
rather than voice.  Our goal in moderating the mailing list is to avoid the
degeneration of the list into a forum for answering users questions such as
"Which Wireless LAN should I choose ?" or "I have this problem, please help !".

Our hope is that the mailing list will provide a forum for the engineering
and design issues associated with all aspects of wireless LANs.

Assuming that the traffic on the mailing list got to a reasonable level we
also propose to gateway the mailing list into a moderated USENET News group.


If you are interested in contributing towards the technical development of
Wireless LANs and support this proposal for a forum, please e-mail to

	listserv@tandem.com

To subscribe to the mailing list, send a mail message to the above address
with the following command in the body of the message at the beginning
of the line.

	add jblow@sum.domain.org wireless

Help may be obtained from the list server by including the word HELP at the
beginning of the line in an e-mail message.


Stuart Phillips
Kevin Rowett

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 00:15:35 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2?

In article <1991May22.225743.6588@hermesa.uucp> matthew@hermesa.uucp (Matthew Kayes) writes:
>Are there any TCP/IP's yet for OS/2 clients?  Thanks for your
   
   Yep.  Answer to WHICH depends on whether you mean Microsoft's
   or IBM's OS/2, OS/2 or OS/2-EE, and in EE the specific
   version number.

   IBM, 3COM, FTP, and likely may others...

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 00:19:03 GMT
From:      smart@manta.mel.dit.csiro.au (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Finding the nearest server


In a recent message in comp.protocols.iso.x400, Christian Huitema
has suggested that it would be desirable if internet users could
address mail to the X.400 world in the form

	/C=us/.../@x400.net

I.e. specify a generic "@gateway" instead of users having to know
specific gateways. This arose because there is a plan to do the 
converse on the X.400 side.

This brings up a recurring theme. We want to connect to the nearest
machine offering some particular service: the nearest BITNET gateway;
the nearest root nameserver; the nearest font server for some font;
the nearest ftp server for gnu software.

A while ago there was a fascinating suggestion posted on how to do
this sort of thing using IP distance servers. That suggestion has
not been taken up and I would like to suggest an alternative that is
much simpler.

The layer that understands distance in IP is the IP routing layer.
So this is the only layer (currently) which can be used to discover
"closeness". The idea is to create generic addresses to go with
the generic names.

Let us suppose that subnets 192.255.x are used for this purpose.
If the generic X.400 gateway is given 192.255.17 then the entry
in the DNS will be:

   x400.net.	IN	A	192.255.17.1

All the hosts which provide this service will have at least two IP
interfaces: their "real" interface to the IP network and a fake
interface with network number 192.255.17.1. That interface will be
"up" whenever the indicated service is available. [This is 
actually quite nice: you can take a service down temporarily
and requests for the service will automatically go to the next
nearer server.]

This technique will work well as-is for stateless UDP services.
For other services there may be occasions where the nearest server
changes in the middle of a conversation and the TCP connection
gets blown away. For protocols that retry like e-mail this is not
a great disaster but it is undesirable even there.

So all the servers advertising the route to 192.255.x services
should provide a new service on a new well-known-port: that service
will be a UDP query with the response being the servers "real"
domain name and real IP addresses. This service could be used in
various ways, but the most obvious is for the subroutine which
is equivalent to unix's "gethostbyname" (and other subroutines
which discover IP addresses) to say "this is a 192.255.x number;
therefore I shouldn't just return it: I should ask it for its
real IP address and return that".

Though the full use of these generic IP addresses should be restricted
to hosts that implement the real-IP-discovery protocol, they will
still work fine for existing software where the service is a stateless
UDP service. They can also be used where the users make a conscious
choice to put up with the reliability problems which are likely to be
very mild: probably no worse than we see from my edge of the 
Internet galaxy already.

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

It is very easy to implement these false IP addresses: you can
do it today in unix by ifconfiging some unused device like a
pty. It would also be easy to write a fake interface that gives
host unreachable ICMPs for host numbers other than .1.

Bob Smart <smart@mel.dit.csiro.au>

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 00:22:49 GMT
From:      stu@tandem.com (Stuart G. Phillips)
To:        comp.protocols.tcp-ip
Subject:   Wireless LANs mailing list

There is currently much discussion and publicity about Wireless LANs, their
possible applications, choice of frequency, protocols, etc.  The I.E.E.E 802
committee has established a sub-committee (802.11) to propose a standard
for Wireless LANs.

Wireless LANs pose a unique challenge to the engineer since they represent
a combination of technologies:

	- RF design
	- Propagation and wave physics
	- Data communications
	- Computer engineering
	...

Few engineers or designers have all these skills in their portfolio; progress
towards Wireless LANs therefore requires teamwork and an open mind to allow
experts in different technologies to contribute and work towards a common goal.

We propose to establish a moderated mailing list to provide a technical forum
for the development of Wireless LANs specifically aimed at data communications
rather than voice.  Our goal in moderating the mailing list is to avoid the
degeneration of the list into a forum for answering users questions such as
"Which Wireless LAN should I choose ?" or "I have this problem, please help !".

Our hope is that the mailing list will provide a forum for the engineering
and design issues associated with all aspects of wireless LANs.

Assuming that the traffic on the mailing list got to a reasonable level we
also propose to gateway the mailing list into a moderated USENET News group.


If you are interested in contributing towards the technical development of
Wireless LANs and support this proposal for a forum, please e-mail to

	listserv@tandem.com

To subscribe to the mailing list, send a mail message to the above address
with the following command in the body of the message at the beginning
of the line.

	add jblow@sum.domain.org wireless

Help may be obtained from the list server by including the word HELP at the
beginning of the line in an e-mail message.


Stuart Phillips
Kevin Rowett

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 07:41:33 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS compliant TELNET?  Please help.

In article <1991May23.171854.31021@kuhub.cc.ukans.edu> mcginnis@kuhub.cc.ukans.edu writes:

   I need to run DEC PathWorks and TELNET on personal computers.  It
   looks like PathWorks will only work with NDIS protocol compliant
   network packet drivers...

   Anybody out there make a TELNET that will work with NDIS?

Maybe, but none of the free ones do.  Use dis_pkt instead.  It was recently
mentioned in comp.archives...

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
Clear cutting is criminal, spiking trees is criminal, and using hyperbole of
this magnitude in a serious discussion is criminal.  -- Irv Chidsey

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 10:38:45 GMT
From:      dalk@vax87.aud.auc.dk
To:        comp.protocols.tcp-ip
Subject:   Map of Internet

Hej,

I am looking for a map of the Internet for a slide. Does someone on the net
have this on a PostScript file (or another print file) ?

I am also interested in stuff concerning TCP/IP, ISODE and networks generally.
If you have such things please E-mail them to me.

Thanx

Lars Kalsen
Aalborg University Center
Denmark

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 14:04:07 GMT
From:      ake@dayton.saic.com (Earle Ake)
To:        comp.protocols.tcp-ip
Subject:   Re: Per Vendor ethernet address assignments

In article <218@cucrd0.med.columbia.edu>, reidar@cucrd0.med.columbia.edu (reidar) writes:
> 
> I would appreciate it if someone could mail me a list of the assigned ethernet addresses and
> the manufacturers to whom they are assigned.  I have the following list and would like to
> have the gaps filled.  I am particularly interested in 000080.

	The list is in the file RFC1060.TXT located at NIC.DDN.MIL.  I couldn't
find 000080 in the list.  Does anyone know where there is a more recent list?
I have a few that are not listed as well.  They are 0080D6 and 00001B.


Earle
_____________________________________________________________________________
             ____ ____    ___
Earle Ake   /___ /___/ / /     Science Applications International Corporation
           ____//   / / /__                 Dayton, Ohio
-----------------------------------------------------------------------------
Internet: ake@dayton.saic.com        uucp: dayvb!ake         SPAN: 28284::ake

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 14:21:20 GMT
From:      jmd@EMPEROR.HANDHELD.COM
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

Jazz writes:
> ...but that's a lot more manageable than barrel and tee connectors etc. ...

While not directly on the topic, AMP's thinnet tap system takes the pain
out of 10base2 networks. The wall jacks make before break, allowing
live disconnects, and there's only one cable and one BNC going to the CPU.
They use a special twin coax cable fed to a special BNC that brings the
center conductors together at the pin of the single BNC.  So you can
disconnect either the BNC from the CPU or the plug from the wall without
interrupting the rest of the network.
Jim De Arras

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 14:53:57 GMT
From:      bgi@stiatl.salestech.com (Brad Isley)
To:        comp.protocols.tcp,comp.unix.sysv386
Subject:   Problems with ISC SLIP and their reply: It don't work well.


This is a summary of my conversations so far with Multiuser/Interactive
regarding our problems with ISC SLIP delivered with TCP/IP 1.2.

I hope several things will result from this posting.

   1) Someone will be wiser.
   2) Someone can help with our problem.
   3) Someone will have an easier time getting as far as I did.
   4) Interactive will fix their software.

Please note the Reply-To: line above.  Until I get Interactive's sendmail
to work the way it's supposed to you are better off replying there.
(It's a 3b1).

emory!slammer!brad writes:
>Eric Storch at Multiuser Systems wrote:
> Brad,
> 
> As per our conversation, here is the copy of the mail that I got back from
> Interactive Technical Support:

Thanx - replies to uunet!emory!slammer!brad work.  I'm having sendmail
problems that will be addressed in another note.
 - so please reply there for now.

I have some additional notes and a reply for the folks at Interactive.

I'm also posting this to Usenet comp.protocols.tcp-ip and comp.unix.sysv386.
Someone out there might benefit or be able to help.

emory!slammer!brad writes:
>someone at interactive support wrote:
>> emory!slammer!brad wrote:
 =============================================================================
>>	.
>>	.
>>	.
>> I have an AST 386/33 running Interactive 2.2
>> Ethernet is a WD8003 with TCP/IP 1.2 and NFS 2.1.
>> Serial ports are controlled by a Comtrol Ultra-8 with driver version 1.08.
>> 12 megs RAM installed.  Adaptec 1542B.  Wangtek tape controller and drive.
>>
>> Everything is stable without SLIP.
>
>What port is SLIP running on? We don't support SLIP running on anything
>but our standard asy ports.
>		 ***

Why is this not documented?  Imagine the load on a system running SLIP on
a builtin port running 38400 bps or even 19200 bps.  I even called and
asked if SLIP was supported on intelligent multiport boards and the
answer was, "Yes."  I even went as far as asking, "Can I use it as a gateway?"
Same answer.  Sorry - don't ask who I talked to.  I don't remember.

>>
>>   We're running SLIP and uucp to connect to Performance Systems
>> International.  The uucico will eventualy hang with an error message:
>>
>> news uupsi  (5/13-9:00:52,172,31) IN SEND/SLAVE MODE (INPUT FAILURE)
>>
 ...
>Has the customer configured uucp over TCP/IP? How can you possibly run
>a uucp process such as uucico over SLIP without first configuring UUCP
>to run over TCP/IP?

Yes.

Thankfully this isn't a problem anymore.  It was the result of a
timeout caused by one of two things:  1)  Remote modem hanging up.
The hangup was cause when the remote modem choked on V.42BIS.  I
don't know what kind of modem it is.  I told my TB1600 to connect
in a non-error-correcting mode and no more hang-ups.  PSI told me
that they didn't support V.42BIS in this area yet.  I assumed the
modems could figure that out.  I was wrong.  2)  Default route
mysteriously disappearing from the table.  This one I think was
due to SLIP coming up and down.  A few minutes after adding the
route it will disappear.  Add it again and it stays.

>>   We have another problem that may be causing some of the uucico hangs.  The
>> TCP/IP we run does not seem to always route packets properly.  After
>> establishing the SLIP connection we add a default route through it.  Lots
>> of packets that should go out the SLIP wire do not.
>>
>
>Again, we don't like to route data through a non-supported SLIP device.

OK.  So I should run SLIP on the builtin port.  This brings the performance
of the system (386 33mhz) to an unacceptable level.  Why can't you support
generic serial devices?  Are you telling me that it cannot route packets
properly?  Or are you saying it cannot send packets properly?
Please clarify.  I'd like to think that routing decisions are made
without detailed network interface knowledge.

>> #       @(#)_netd2.slip 1.1              89/07/13"
>> #
>> sl_ip  = "/dev/sl" lsap 0x888   # stream for IP messages
>> link sl_ip under ip_tcp name "sl0"
>> #ifconfig "sl0" stislp uupsi netmask 255.255.255.0 up
>> #ifconfig "sl0" stislp uupsi up
>> ------------------------------------
>> The ifconfig for sl0 is commented out because at boot time the modem may not
>> be connected to PSI.  Connecting to psi is done with this shell script.
>
>SLIP isn't going to care that the modem is not connected. If you type
>'ifconfig sl0' then it will still report that the device is there.

All NFS daemons and some other TCP daemons crash with timeouts if the sldial
& slattach aren't running when slip is ifconfig'd.  This requires a reboot to
make the system stable.  Switching to runlevel 2 and back up to 3 after
dialing sets the stage for a crash.

>>  After running the sldial and pressing ESC we then run
>> /etc/ifc:
>> ------------------------------------
>> set -x
>> tty=`cat /etc/slip.tty`
>> touch /usr/spool/locks/LCK..$tty
>> slattach /dev/ttyu03 `cat /etc/slip.bps`
>> addr=`cat /etc/slip.addr`
>> ifconfig sl0 $addr $addr netmask 255.255.255.0 up
>> #ifconfig sl0 $addr $addr up
>> gated -tu /usr/adm/route.log
>
>Here's a MAJOR PROBLEM.  SLIP does *NOT* work with a gateway!  It is
>logged as a bug.

Okay, so what's the solution?  TCP/IP 1.2 has been out for how long?  How
long should we wait for a fix?  Re the manual "Interactive TCP/IP System
Admin Manual" page 44 under section 6.2 Initiating SLIP Over Modem and Serial
Lines, "If you are using one system to act as a gateway ...
/etc/gated"

  According to Interactive documentation your gated performs routing
decisions normally performed by routed.  We DO NOT want it to act as a
gateway in the sense that would function as an internetwork router.
What we want is for it to have the smarts to figure out which device
outgoing packets should be sent to.  Users here want to rlogin to this
machine.  From there they should be able to access the Internet via SLIP.
This seems to be working acceptably now.  Ping looses many more packets
than any other network application.

>Why are there 0's in the hosts file? This will result in irradic network
>behavior. Using 0's indicates a netmask not an IP address.
>I would suggest him to change this soon.

Sorry for this.  I didn't set this up - but I WILL change it soon.
No other machines have had a problem with it.  Convergent CTIX, Sun-OS,
DG-UX, HP-UX, PC-NFS, BW-NFS, NCSA Telnet, KA9Q, Wollongong on VMS, Banyan
and even AIX 1.1, 1.2 and 3.1.5 are all happy with it.

>> 127.1   local localhost
>> 20.0.0.1        st640.salestech.COM st640 #        Convergent 640
>> 20.0.0.3        huey.SalesTech.Com huey
>> 20.0.0.4        louie.SalesTech.Com louie
>> 20.0.0.5        dewey.SalesTech.Com dewey
>> # Everything with the suffix pc are pc's
>> 20.0.0.6        johnpc
>> 20.0.0.7        johnpc1
>>	.
>>	.
>>	.
>> 20.0.0.207      vxdsh
>> 20.0.0.208      vxdsi
>> 20.0.0.209      vxdsj
>> 20.0.0.210      vxdsk
>>
>> 128.145.107.101 uupsi
>> 128.145.107.101 stislp.salestech.com stislp
>> 136.161.128.3   uu.psi.com
>> ------------------------------------
>>
>>   Our internal network at SalesTech is 20.0.0.  We do not advertize our
>> presence through PSI to the Internet.  The machine this is running on,
>> 'stiatl', is not used as a gateway to the Internet; I just run gated because
>> the TCP/IP 1.2 documentation says gated does the routing instead of routed.
>> Any user here must access the Internet directly from stiatl.
>>
>>   After the 'route add default 128.145.107.101 1' command, most, but not all,
>> packets that aren't addressed to the 20.0.0 network go out the modem.  We have
>> a line analyzer and watch them.  Ping is quite useful here.  If we ping the
>> other end of the link, 128.145.107.101 or if we ping 128.145.107.127 (the
>> address of the machine at the other end) the response is fine.  Ping response
>> is also OK from uunet.uu.net.  However, if we ping 192.67.67.20 or 192.33.4.100
>> the first few pings go out the slip port, but subsequent pings do not.
>> I assume the wd0 network gets them but I cannot tell.
>>
>
>Are these addresses supposed to be reachable via ethernet or SLIP? Again,
>the problem is probable trying to run gated with SLIP.

This local network 20.0.0 is reachable only via ethernet.  The Internet is
only reachable from stiatl - see netstat output.

>>   Netstat says the default route is there.  Technical support at PSI says it
>> should work.  Any ideas?

[uucico hang notes deleted - problem solved]

>> netstat -nr:
>> ------------------------------------
>> Routing tables
>> Destination          Gateway              Flags    Refcnt Use        Interface
>> 127.0.0.1            127.0.0.1            UH       7      409        lo0
>> 128.145.107.101      128.145.107.101      UH       0      0          sl0
>> default              128.145.107.101      UG       3      63         sl0
>> 20                   20.0.0.50            U        0      1166       wd0
>> ------------------------------------
>>
>> netstat -r:
>> ------------------------------------
>> Routing tables
>> Destination          Gateway              Flags    Refcnt Use        Interface
>> localhost            localhost            UH       7      409        lo0
>> port1.atlanta.pub-ip port1.atlanta.pub-ip UH       0      0          sl0
>> default              port1.atlanta.pub-ip UG       3      69         sl0
>> 20                   20.0.0.50            U        0      1290       wd0
>> ------------------------------------
>>
>>> ping statistics:
>> ------------------------------------
>> PING 128.145.107.101: 56 data bytes
>> 64 bytes from 128.145.107.101: icmp_seq=0. time=830. ms
>> 64 bytes from 128.145.107.101: icmp_seq=1. time=760. ms
>> 64 bytes from 128.145.107.101: icmp_seq=2. time=740. ms
>> 64 bytes from 128.145.107.101: icmp_seq=3. time=760. ms
>>
>> ----128.145.107.101 PING Statistics----
>> 4 packets transmitted, 4 packets received, 0% packet loss
>> round-trip (ms)  min/avg/max = 740/772/830
>> PING 192.67.67.20: 56 data bytes
>> 64 bytes from 192.67.67.20: icmp_seq=2. time=1350. ms
>> 64 bytes from 192.67.67.20: icmp_seq=5. time=700. ms
>>
>> ----192.67.67.20 PING Statistics----
>> 12 packets transmitted, 2 packets received, 83% packet loss
>> round-trip (ms)  min/avg/max = 700/1025/1350
>> PING 192.67.67.20: 56 data bytes
>> 64 bytes from 192.67.67.20: icmp_seq=0. time=690. ms
>>
>> ----192.67.67.20 PING Statistics----
>> 21 packets transmitted, 1 packets received, 95% packet loss
>> round-trip (ms)  min/avg/max = 690/690/690
>> PING 192.33.4.100: 56 data bytes
>> 64 bytes from 192.33.4.100: icmp_seq=0. time=450. ms
>> 64 bytes from 192.33.4.100: icmp_seq=1. time=490. ms
>> 64 bytes from 192.33.4.100: icmp_seq=2. time=430. ms
>> 64 bytes from 192.33.4.100: icmp_seq=3. time=450. ms
>> 64 bytes from 192.33.4.100: icmp_seq=4. time=420. ms
>> 64 bytes from 192.33.4.100: icmp_seq=5. time=420. ms
>> 64 bytes from 192.33.4.100: icmp_seq=6. time=440. ms
>> 64 bytes from 192.33.4.100: icmp_seq=7. time=440. ms
>> 64 bytes from 192.33.4.100: icmp_seq=8. time=430. ms
>> 64 bytes from 192.33.4.100: icmp_seq=9. time=430. ms
>> 64 bytes from 192.33.4.100: icmp_seq=10. time=450. ms
>> 64 bytes from 192.33.4.100: icmp_seq=11. time=430. ms
>> 64 bytes from 192.33.4.100: icmp_seq=16. time=1350. ms
>>
>> ----192.33.4.100 PING Statistics----
>> 29 packets transmitted, 13 packets received, 55% packet loss
>> round-trip (ms)  min/avg/max = 420/510/1350
>> ------------------------------------
>>
>>   The thing to keep in mind wher reviewing the above ping stats:
>>
>>   Sometimes all the pings would go out SLIP and the host failed to respond.
>> Sometimes a few initially would go out SLIP, but then the rest would not.
>> It seems that the router gets confused about where they should go.  The last
>> example (192.33.4.100) all the missing responses were due to the ping not
>> going out the SLIP interface.
>>
>>   One more question: We use the Internet nameservers when SLIP is up.  I
>> also setup a nameserver here on a Sun 4/470 that runs just fine.  I was
>> hoping this would allow users on stiatl to be able to find hosts both on the
>> Internet and our local network with this setup.  However, stiatl seems to
>> only use the first /etc/resolv.conf nameserver address listed.  It seems
>> that if the first nameserver lookup request fails then the lookup will fail.
>> But if the first host times-out it will proceed to the next one.  Does the
>> first host have to be all-knowing?  Do I have to setup stiatl as a
>> nameserver and have it pool the names from the Internet AND our local
>> network for this to work?
>>
>>
>> Of the several issues above I would like to enumerate them for reference:
>>
>> 1) Apparently routing is not always right.
>>     Packets destined for the SLIP gateway sometimes do not get sent there.
>>     What is wrong?
>
>SLIP does *not* work with gated (gateway).

OK.  When can I get one that works?  If gated is not running then no packets
at all go out the SLIP device.  Ver 1.2 seems to work fine unless I'm
checking on ping statistics.  Ping looses a much higher percentage of packets
than any other application.

>>
>> 2) Am I bringing SLIP up correctly?
>>
>
>It should be done per the documentation.

If I do it per the documentation (on the Comtrol port) the TCP software
crashes with timeouts - "Cannot validate service."  To solve this problem
I commented out the ifconfig "sl0" in netd.cf.  If the asy driver is
used the remaining performance is abysmal and functionality is the same.
I'll settle for the manual ifconfig for now and keep it on the Comtrol.
It might not be "supported", but it works much better than the asy.

>> 3) Should nameserver clients query all servers?
>>     3a) If not, should I set up stiatl as a nameserver pooling both sources?
>>
>
>Yes, but with SLIP? I don't know. SLIP has problems with running a gateway,
>I havn't tried it with nameservers, mainly because I can't get it to work
>with a gateway.

I guess the solution here is to put up a nonauthoratative nameserver
on stiatl.  I'll try that.

>> 4) Why does uucico fail?
>>     4a) Why does uucico hang in the job table while running over SLIP?
>>     4b) Why do subsequent uucico's get nowhere?
>>
>
>Has UUCP been setup to run over TCP/IP?

Problem solved.  As long as the connection is alive and the default route
out the SLIP connection doesn't disappear from the table it works fine.

>The last thing, we *don't* support SLIP running over multiport cards.
>It has hooks in it specifically for our asy driver.

I strongly suggest that your SLIP be "fixed" so that is works with generic
tty drivers for reasons enumerated above.  Other 386 unixes I know of have
no problems supporting 16 simultansous SLIP connections as gateways.
The only difference I noticed between asy and comtrol is the time-outs and
subsequent daemon crashes cause by no connection at startup with comtrol.
This is fixed with the manual ifconfig.

>> ============================================================================
>>
>> An update to the previous mail.
>> I installed the 2.2.1 update and nothing has changed much.

... [ deleted notes that are covered above ]

>After he fixes a couple of those things his network should be ok.

Except for the fact that gated does the routing and does not always work.

>good luck,
>Interactive support
> 
> -- 
> 	MULTIUSER Systems
> 	Technical Support
> 	...!isd001!support

I do appreciate your help with this but to be frank the only information
that has helped is the fact that SLIP with gated is buggy and SLIP is only
supported on asy.  Just knowing that helps in that I know I cannot fix it
and I'm not doing something completely wrong.  I now know gated's limitations
and I know what causes TCP timeouts/crashes when the SLIP modem hangs up.

To summarise:  I know why it doesn't work.
               Now I need to know when it WILL work.

Anxiously awaiting a fully functional TCP/IP package...
-- 
-----------------------------\      / ..and Apple thought GUI was theirs!.. \
 bgi@salestech.com 841-4169    \---| Yer local zymurgist & Amiga hacker/user |
          OR                        \ Klein bottle for sale- Inquire within /
 uupsi!stiatl!bgi                     Brad Isley,  Sales Technologies, Inc.

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 15:51:27 GMT
From:      ken@dali.cc.gatech.edu (Ken Seefried iii)
To:        comp.protocols.tcp-ip
Subject:   Re: How is UTP fault-tolerant?

In article <886@Emperor.HandHeld.com> jmd@EMPEROR.HANDHELD.COM writes:
>Jazz writes:
>
>While not directly on the topic, AMP's thinnet tap system takes the pain
>out of 10base2 networks. 

One caveat here.  While the AMP connectors are really neat most of the
time, they are fragile.  We tracked a nasty impedance problem down to
an AMP wall connector that had been broken by someone backing a
rolling chair into the plug.

Other than that, I love 'em (I've got 60+ machines hooked up this
way).

--

	ken seefried iii	"I'll have what the gentleman 
	ken@dali.cc.gatech.edu	 on the floor is having..."

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 19:53:25 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re: name handling in DNS resolvers

>    BIND (and derivations - most UN*Xes) build a search list of
>    progressively wider domains to successively append to the user
>    provided name...
>The Internet's experience with defaulting of partial domains is poor.
>Perhaps my response to another person who recently asked for the same thing
>will explain.
>    
>The Host Requirements RFCs (1123 in this case) address this issue (pp 83, 84),
>and their view of "search lists" is that they should not be implemented unless

I don't think "domain guessing" should be done at all.  It causes 
problems with getting the wrong host, with uucp addresses, with users 
switching machines ("why does this address work in this window and not 
the other?" or "why can't so and so reach me? I gave them my address that
works for others.") and with name server load.  Make people specify the full
address all the time and give them a keyboard macro or alias where typing
the extra characters is a problem.


-- 
Jon Zeeff (NIC handle JZ)	 zeeff@console.ais.org

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 19:56:38 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <10716@rls.UUCP> randy@rls.UUCP (Randall L. Smith) writes:
>In article <543@pyrite.nj.pyramid.com>, bill@pyrite.nj.pyramid.com (Bill Pechter) writes:
>> In article <9105201208.AA22490@tuatara.uofs.edu> bill@TUATARA.UOFS.EDU (Bill Gunshannon) writes:
>>>
>>> Unless things have changed drastically since the last article I read about
>>> Compuserve, they are running PRIME Mini's.
>> 
>> Nah, they're running DEC KL10's which run a modified TOPS10.  The Source,
>> purchased by Compuserve, ran Prime minis.
>
>True and they're now converting to VMS.  I toured their data center last
>fall and they still had *ton's* of RP06's!! The antique KL10's and KL20's
>still humming along.  The Primes were sitting the corner running but not
>being used, as I was told.  Modifying TOPS seemed to be a costly venture
>in the long run.  Might have been more costly to be out of business
>though.  Anyway, I really don't know how central it was to the business. 
>Presumably, very.  They do all (almost) their own hw support even on the
>new Vaxen.  The biggest Vax they had (at the time) was a 6410. 
>Usenet: randy@rls.uucp

I know that this is somewhat afield of tcp-ip, but I had heard from a former
employee that Compuserve was working with a company that had rights
to manufacture new DEC-20s.

Modifying the operating system heavily was the only way to run a timesharing
company in the '70s.  The vendor systems, especially on large machines,
simply didn't have the security, billing, and communications options
required to run a commercial timesharing business.  Most of the big
timesharing outfits had a real wrench getting onto newer hardware
and more standard software sometime during the '80s.  By then, vendor
software was a little more up to the task, and running standard software
didn't mean too many compromises.

Compuserve became more specialized than most and so has stayed on the
modified stuff longer.  They also have managed to extend the life of
a timesharing business longer than most--many of their competitors
have already or are now leaving the timesharing business.

An example of the things which were nearly mandatory in the timesharing
business is task reconnection.  With the low quality phones and modems
available then, disconnections were frequent.  It was not economically
viable to simply send your task a SIGHUP (or equivalent).  Most timesharing
companies had some concept of reconnecting to a running task.  Somebody
from Bell Labs presented a framework for doing this under Unix about
two years ago; I think portions of it may have made it into SVR4.

-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 20:23:33 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP for OS/2?

There are several. FTP Software, IBM, 3Com, Essex Systems, and
Ungermann Bass all have TCP/IP for OS/2. Other companies may as well.
They probably all have ftp clients and servers, telnet clients and
servers, and other TCP/IP utilities. Ours (PC/TCP for OS/2) and IBM's
have NFS clients (last I heard, IBM's NFS client didn't support password
authentication, but they may have fixed that by now), and ours and
3Com's have a netBIOS.




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

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Fri, 24 May 1991 21:22:35 GMT
From:      snyde_sl@tsca02.uucp (Steve Snyder)
To:        news.software.nntp,comp.protocols.tcp-ip
Subject:   Problems using rn over a telnet connection

Our site recently established a newsfeed.  We are running C news (last
patch date is 24-Mar-91) and rn (last patch date is 01-Jan-91, # 54)
on an Apollo DN3000 under Domain/OS SR10.2 (sys 5.3 environment).
The ASCII terminals we have are connected to Black Box terminal
servers.

The problem we are having concerns using rn over a telnet or rlogin
connection to the news server.  It seems that regardless of what type 
of terminal (VT100, VT320, PC, SUN SPARC2, HP9000/380, or even another 
Apollo bitmap display) I use to telnet to the news server, this 
problem occurs.  The problem is that rn repeatedly displays the 
first '--read now? [npq]' prompt (beeping every time) as shown below:

Unread news in comp.ai					34 articles
Unread news in comp.ai.edu				 3 articles
Unread news in comp.ai.neural-nets			38 articles
Unread news in comp.ai.shells				 4 articles
Unread news in comp.arch			       128 articles
etc.

********  34 unread articles in comp.ai--read now? [ynq]
Type h for help.

********  34 unread articles in comp.ai--read now? [ynq]
Type h for help.

********  34 unread articles in comp.ai--read now? [ynq]
Type h for help.

********  34 unread articles in comp.ai--read now? [ynq]
Type h for help.

So I just have to quit and get out of rn.  This problem with rn does
not occur on Apollo bitmap displays that access the news server 
through the Domain file system.  (I have symbolic links set up from
all of our other Apollos to the necessary files and directories on
the news server.)  Although from these workstations I can generate
the same response by typing control characters that rn does not 
accept.  As far as I can determine there are no control characters
being sent by the remote terminal.  (I have saved a terminal session
in a file and done a hex dump of this file.)

The readnews reader (distributed with C news) works fine from remote
terminals over telnet, but I'd really like to give every user the
ability to use rn from any remote terminal or workstation.  I believe
that rn is running in curses cbreak mode at the above prompt, whereas
readnews is probably not.

Any ideas why rn responds this way over a telnet connection, or 
possible solutions to this problem?  I've run out of ideas.  I posted 
this previously to news.software.b and news.newusers.questions but got
no responses.

Should I be using rrn and NNTP?  (I answered no to Configure's "Do you
want this built as remote rn (rrn)?" question.)  Does rrn let you run 
rn over a telnet connection to a news server?  I'd prefer responses by
email, but I'll continue to watch the newsgroups where I posted this
if you'd rather post a reponse for the benefit of others who might
have a similar problem and questions.  Thanks.
-- 
Steve Snyder             | You've got to know when to code 'em,
Electronic Data Systems  | know when to modem, know when to load 'em,
snyde_sl@otsc.eds.com    | and know when to run.
uunet!tsca02!snyde_sl    |                        --Anonymous

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 22:29:20 GMT
From:      mitton@enet.dec.com (Dave Mitton)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS compliant TELNET?  Please help.


 >From: mcginnis@kuhub.cc.ukans.edu
 >Newsgroups: comp.protocols.tcp-ip
 >Subject: NDIS compliant TELNET?  Please help.
 >Date: 23 May 91 22:18:54 GMT
 
 >I need to run DEC PathWorks and TELNET on personal computers.  It
 >looks like PathWorks will only work with NDIS protocol compliant
 >network packet drivers...
 
 >Anybody out there make a TELNET that will work with NDIS?

Not sure I understand the problem.  Digital's PATHWORKS V4.0 TCP/IP
support _INCLUDES_ a TELNET that works with NDIS IP stack.   It's also 
supported by our SETHOST terminal emulator.

	Dave.

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      24 May 91 23:35:10 GMT
From:      elie@spectrum.cmc.com (Elie Azar)
To:        comp.protocols.tcp-ip
Subject:   FTP compressed transmission ......


Hi,

I need information relating to the "compressed" transmission
mode for FTP. That would include any RFCs or other documents....

I would also like to locate a public domain version of ftp that supports
the "compressed" transmission mode.

If anybody can provide information regarding this issue, please send mail
to the above address; your help will be greatly appreciated.

Thank you in advance.

ELie.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      25 May 91 10:03:53 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for OS/2?


 >> 
 >> Are there any TCP/IP's yet for OS/2 clients?  Thanks for your
 >> help.
 >>

This is getting to be a FAQ. I supposed I should create a file...


The following companies all sell TCP clients for OS/2.

IBM
Novell
3Com
Ungermann-Bass
FTP Software

I believe Wollongong & Hewlett-Packard do also, but have not seen
recent evidence.





					Larry Backman

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      25 May 91 13:32:33 GMT
From:      larry@nstar.rn.com (Larry Snyder)
To:        comp.protocols.tcp,comp.unix.sysv386
Subject:   Re: Problems with ISC SLIP and their reply: It don't work well.

bgi@stiatl.salestech.com (Brad Isley) writes:


>>What port is SLIP running on? We don't support SLIP running on anything
>>but our standard asy ports.
>>		 ***
 
>Why is this not documented?  Imagine the load on a system running SLIP on
>a builtin port running 38400 bps or even 19200 bps.  I even called and
>asked if SLIP was supported on intelligent multiport boards and the
>answer was, "Yes."  I even went as far as asking, "Can I use it as a gateway?"
>Same answer.  Sorry - don't ask who I talked to.  I don't remember.

We've run SLIP on both a Digiboard 8i and a dumb ASY port with a
16550AFN at speeds of 38400.  Throughput on the Digi is higher
than the ASY port.

Throughput averages around 1780 cps running UUCP over SLIP using
v.32bis modems.

>modems could figure that out.  I was wrong.  2)  Default route
>mysteriously disappearing from the table.  This one I think was
>due to SLIP coming up and down.  A few minutes after adding the
>route it will disappear.  Add it again and it stays.

yep - we've noticed this when bringing SLIP up and down - thank
goodness we don't go up and down all day long!

>All NFS daemons and some other TCP daemons crash with timeouts if the sldial
>& slattach aren't running when slip is ifconfig'd.  This requires a reboot to
>make the system stable.  Switching to runlevel 2 and back up to 3 after
>dialing sets the stage for a crash.

yes - for sure

We are planning on moving over to Dell SVR4 3.0 when it is released
for our primary gateway.  Dell is constantly working on the product -
and their 2.01 release is quite solid.

The ability to support multiple concurrent SLIP connections is 
quite appealing

-- 
      Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391
                         HST/PEP/V.32/v.32bis/v.42bis 
                        regional UUCP mapping coordinator 
               {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      26 May 91 17:05:43 GMT
From:      csu@alembic.acs.com (Dave Mack)
To:        comp.protocols.tcp-ip
Subject:   What good is the 127.x.x.x network?

Is it my imagination, or is there an entire Class A network (127.x.x.x)
that is essentially unusable? Is anybody out there using it for
anything besides loopback?

-- 
Dave Mack

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 03:10:28 GMT
From:      smoot@cs.utexas.edu (Smoot Carl-Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP question

In article <May.23.15.48.56.1991.14837@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>Proxy ARP seems to have been invented originally simply to handle
>the problem of systems that did not implement subnets.  I believe
>the first implementations worked only with addresses on other subnets
>of the same network.

By definition Proxy ARP can only respond to hosts which do not understand
subnets.  If the machine sending the ARP request understood subnets, it 
would use the usual IP routing mechanism to route its packets.  Proxy ARP
is a surrogate for real routing.  The host which does not understand subnets
thinks the whole network (which may be subnetted) is directly attached to
its own network interface.

We did add a "feature" which lets Proxy ARP check the routing table of the
responding router.  This is useful in circumstances where a particular
network segment is not really subnetted.  This allows you to establish the
subnet mask simply on the router an leave all the host network masks as if
they were on an unsubnetted network.  All that is required is to establish
static routes to each of the ``pseudo'' subnets accessible via that
interface.

This is a useful feature for sites which are slowly migrating to a fully
subnetted network, but either have machines which do not understand subnets
or are forced to slowly migrate because of time contraints.  Proxy ARP
is useful, but using true subnets is a much better alternative.
-- 
Smoot Carl-Mitchell, Texas Internet Consulting
smoot@tic.com, smoot@cs.utexas.edu

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 12:17:54 GMT
From:      andrewf@syacus.acus.oz.au (Andrew Friedman)
To:        comp.protocols.tcp-ip
Subject:   Yet more stuff about Nagle, BSD, escape sequences and TCP/IP PUSH

Hi,

I've been following the thread with some interest and would like to make
a few remarks.  I should make a disclaimer straight away, I am a TCP/IP
novice, and spend most of my days working with the OSI suite of
protocols.  No doubt you'll tell me where I'm wrong, maybe you'll be
kind enough to tell me where I'm right. 

I'm not sure if anybody has mentioned that the Nagle algorithm will
interact particularly badly with a remote host when a key stroke isn't
echoed (such as the keystroke under question) and the host delays
sending acknowledgements (according to the BSD daemon book, BSD delays
acknowledgements). 

So changing the application to send a character sequence with no effect e.g.
a null will force the acknowledgement out much sooner.

Of course, this won't help when the network itself is misbehaving.

The above assumes that the Telnet client forwards every character as
soon as it is written.  If the client is perhaps smarter (and from Leo
McLauglin's posting I assume BSD Telnet clients aren't smarter) and
wants to reduce network load it might collect characters using a short
timeout, but also forward collected characters after reading a
forwarding character, e.g.  an control character, like ESC. 

Again, the sequence is split, but Nagle is not to blame. The Telnet
shouldn't have been clever about forwarding on control chars, or should it?

If this is the case, than I don't know what could be easily done,
perhaps the the client might allow you to change the forwarding chars. 
I can think of one realistic place where this situation might arise,
somebody out in X.25 land, with an X.3 terminal session gatewayed to a
Telnet session.  At least on a PAD forwarding characteristics are always
alterable. 

Michael and others suggest that Telnet clients treat escape sequences
specially, and/or disable Nagle, but that doesn't help those people who
need to distinquish between an ALT-F COKEBOTTLE and an ALT-F.  I think a
character collection period with a small-timeout inside Telnet would be
a more general solution.  This better behaved Telnet might be entitled
to use a connection without being subject to Nagling, but it wouldn't
really matter.

Actually, I doubt that at the speed I type at, Nagling makes any difference,
and I wonder if Nagles algorithm is more intended for applications that
abuse the network with lots of small packets rather than fingers.

When Nagle's algorithm was first mentioned in this thread.  I was
against it.  I said to myself, how can that naughty Nagle delay sending
a packet, when the TCP/IP user has done a PUSH.  Later, reading the
daemon book, I discovered BSD doesn't implement PUSH bit, (not even to
the extent required by RFC1122?), so every write from the TCP/IP user
will go to the network (flow control willing) in the absense of Nagle.
If BSD had a user controllable PUSH Nagle wouldn't be nearly as needed.
But that would flaw the programming paradigm, you can't flush file
descriptors only file pointers.

Eventually, I decided, that even PUSHed packets should be Nagled, because
the network needs all the help it can get but a bound of timeout 
comparable to the average round trip time, rather than having to wait for
a delayed ack.

Of course the real problem is that networks are pretty lousy for applications
sensitive to delay, and timing. Somebody want to do a P.D. NeWS?

Thanks for listening,

Andrew 

Internet: andrewf@syacus.acus.oz.au
ACSnet:   andrewf@syacus.acus.oz

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 15:36:16 GMT
From:      root@infoac.rmi.de (INFOAC-Operator)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

jms@mrsvax.mis.arizona.edu (The IRS gets 28% of this message---and everything else I own) writes:

>In article <.QHBBXB@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes...
>>In article <1991May21.165458.7441@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes:
>> 
>>I'm sure it'd look like this:
>> 
>>	% telnet compuserve.com
>>	Trying...
>>	Connected to compuserve.com.
>>	Escape character is '^]'.
>>	Host: CIS
>>	Username: 70216,1076
>>	Password:
>> 
or like this:

telnet compuserve.com
compuserve.com: No address associated with name

-rm

-- 
*****************************************************************
   ___  ____  ___    _  _ ___ ___   ___ ___ ___     ___ _  _
  /__/ / / /   /    /\ / /__   /   /__//__//   /__//__ /\ /
 / \  /   / __/_   /  / /__   /   /  //  //__ /  //__ /  /

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 17:35:07 GMT
From:      metzger@watson.ibm.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

In article <552.283ced35@vax87.aud.auc.dk> dalk@vax87.aud.auc.dk writes:
>I am looking for a map of the Internet for a slide. Does someone on the net
>have this on a PostScript file (or another print file) ?

At one time, a number of years ago, I saw such a thing. Back then,
there was just the ArpaNet and a few other add-ons.

Now, there are literally hundreds of thousands of machines on the
internet. There are thousands of networks, including lots and lots off
people who have SLIP connections to the darndest places (I know people
with home ethernet networks and SLIP connections in to the internet).
Most of these sites don't have their latitude and longitude known by
anyone, including their owners, so a geographic map of sites is, for
most sites, impossible. A logical map would tell you very little
indeed; it would just be a giant connected graph.

Furthermore, there are now lots of cross country networks, too. NSFnet
is of course a major backbone, but PSI, AlterNet, and others exist,
too. They all interoperate and interconnect, but there is no longer
one single nationwide backbone the way that the ArpaNet used to be.

If there is a postscript internet map, it must be woefully incomplete,
and highly uninformative.

Perry Metzger
-- 
"Live Free or Die!"
For information on the Libertarian Party, call 1-800-682-1776

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 18:08:57 GMT
From:      fff@eng.microplex.com (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   network interfaced lp daemon

Could some kind soul give me an idea how widespread network support for the 
lp daemon (a la SUNOS) is amongst the various flavours of Unix?  As far as
I can tell SCO Unix/Xenix doesn't support it - is SCO the exception or the
rule?
-- 
Fred Fierling    fff@microplex.com       Tel: 604 875-1461   Fax: 604 875-9029
Microplex Systems Ltd   265 East 1st Avenue   Vancouver, BC   V5T 1A7,  Canada

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      27 May 91 20:52:30 GMT
From:      smeg@laguna.uucp (Maarten Koning)
To:        comp.protocols.tcp-ip
Subject:   Re: What good is the 127.x.x.x network?

In article <1991May26.170543.7991@alembic.acs.com> csu@alembic.acs.com (Dave Mack) writes:
>Is it my imagination, or is there an entire Class A network (127.x.x.x)
>that is essentially unusable? Is anybody out there using it for
>anything besides loopback?
>
>-- 
>Dave Mack

I have an OS simulation that runs under UNIX at user level as a single
process.  This simulator has full IP networking capabilities and when
it starts up, it dynamically allocates an IP address out of the 127
network. It also adjusts the hosts (in my case, a Sun 4/65) routing table
to route to a special networking interface that provides a file descriptor
interface to a user level process.  The simulator sends and receives
these IP packets using good old read & write to /dev/ip.

Anyway, the 127 net is handy when you need an IP address that never
leaves your machine on a real (hardware) interface.

Maarten Koning
--
//include1 pgm=disclaimer,parm='my opinions only'
Maarten Koning | Internet:  smeg@bnr.ca        | Phone: (613) 763-8796
BNR Ltd.       |     UUCP:  smeg@bigsur.UUCP   | FAX:   (613) 763-2626

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 02:08:43 GMT
From:      hageman@x102c.ess.harris.com (George Hageman 76222)
To:        comp.protocols.tcp-ip
Subject:   Standard Benchmarks for TCP/IP -- Do they exist?

I am looking for a standard benchmark for TCP/IP networks similar
to the benchmarks that are available for evaluating computers.
Any pointers to either public domain source or private suppliers
would be appreciated.  I will summarize the results to the net
if there is any other interest.

Thanks in advance,

George W. Hageman



-----------------------------------------------------------------------------
George W. Hageman       407/984-5908   | "A government that is big enough to  
Harris GISD, Melbourne, FL  32902      |  give you all you want is big enough
Internet: hageman@x102c.ess.harris.com |  to take it all away." -- B. Goldwater

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 03:00:20 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

Why not just show your class a globe of the planet ???


-- 
Rob Logie                                    EMAIL: logier@cheops.qld.tne.oz.au
Telecom Australia                            FAX:   +61 7 837 4704
TNE Computer Support Services                PH:    +61 7 837 5174
Brisbane Office                              "These are my opinions alone"

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 13:57:07 GMT
From:      golds@fjc.GOV (Rich Goldschmidt)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans,comp.sys.novell
Subject:   NFS performance

I posted a request here for info about two weeks ago with no response, so
I'll try again.  The original query was about how file server performance
was measured.  What do claims of "X" users supported really mean, and how are
those measurements made.  And how do NFS and Novell compare on the same 
hardware, like a 386 or 486 running either Novell 3.11 or Interactive with
NFS.  There must be people out there who know answers to at least some of
these questions!

And just to broaden the scope, what are peoples experiences out there with
Interactive's NFS.  I have observed that the documentation has errors and is
incomplete, and the authentication doesn't work the way it ought to.  What is
of greater concern is I am seeing slower NFS file service performance than I 
had expected, and getting what I think are a lot of NFS errors.



-- 
Rich Goldschmidt: uunet!fjcp60!golds or golds@fjc.gov
Commercialization of space is the best way to escape the zero-sum economy.
Disclaimer: I don't speak for the government, and it doesn't speak for me...

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 14:23:33 GMT
From:      jlister@slhisc.uucp (John Lister)
To:        comp.protocols.tcp-ip
Subject:   Re: compuserve

In article <1991May16.211344.16328@informatik.uni-erlangen.de> eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes:
>From article <1991May15.143317.4297@oar.net>, by karl.kleinpaste@osc.edu:
>> 
>> PS- No, emphatically, general IP (telnet) access into CompuServe is
>> _not_ part of the game plan.
>
>How did you guess people could be interested in this, and so why
>isn't compuserv interested in this - we do have a commercial internet
>by now too, don't we ?
>---

Let's ask the final question:  how about telnet/FTP *out* of Compuserve as
well?!  (Since we're looking at possible commercial uses of the Internet, I
would speculate that making access available *at a premium* to Compuserve users
outside of prime hours, could provide a significant amount of money.  Look how
much traffic went through the Internet/Compuserve mail gateway from Bitftp...)

John Lister.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 15:14:36 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   Porting BSD telnetd to a Sun

For a number of trivial reasons, I'm trying to compile the BSD 4.3
telnetd source on a Sun-3 running SunOS 4.1.  Is this possible?  Has
anybody done this successfully?  Can anybody give me some hints?

I already know of a few minor gotchas.  For example, BSD wants a
different version of /usr/include/arpa/telnet.h than what Sun
provides.
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 16:12:02 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

In article <1991May27.173507.20501@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes:
>In article <552.283ced35@vax87.aud.auc.dk> dalk@vax87.aud.auc.dk writes:
>>I am looking for a map of the Internet for a slide. Does someone on the net
>>have this on a PostScript file (or another print file) ?
>
>At one time, a number of years ago, I saw such a thing. Back then,
>there was just the ArpaNet and a few other add-ons.

BBN (if I remember right) used to put up a current map of the internet
at each IETF meeting during the mid-to-late '80s.  They gave up when there
got to be too many nets to make any sense on a page.  The Internet has has
grown several fold since then.

But a map showing just the backbones and regionals (and their interconnection
points) might be doable and useful.  This could only ever be a snapshot,
as the Internet is constantly changing, but the backbones are probably
the most stable part.

>Perry Metzger

Art

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 16:48:30 GMT
From:      fish@hpctdlb.HP.COM (Dave Fish - Marketing)
To:        comp.protocols.tcp-ip
Subject:   TCP checksums

I'm interested in how common it is for TCP implementations to use all zeros
for the TCP header checksum.  I know that some HP machines do this but 
how common is this in the real world?
 

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 19:56:34 GMT
From:      karrer@bernina.ethz.ch (Andreas Karrer)
To:        comp.protocols.tcp-ip
Subject:   configuring gated on a backup router

I'm having problems with setting up gated on a router that should only
be used when a router parallel to it is down:

                |       |
                +---B---+
            A---|       |---D
                +---C---+
                |       |

A backs up its filesystems to D's exabyte. This takes *ages* when it is
routing thru C, but it's near the top speed of the exabyte when routing thru B.

I tried "interfacemetric <address> 1" in C's gated.conf, but then sometimes
A is talking to B *thru B* although A and C are on the same subnet.

btw all these are talking RIP only.


+-----------
  Andi Karrer, Communication Systems, ETH Zuerich, Switzerland
  karrer@bernina.ethz.ch                 - terible simplifieur

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 21:11:07 GMT
From:      92disanto@gsb-yen.stanford.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   PCNFS Security Problems - Questions...


I would like to know about security problems using NFS on a PC.
I'm building an application that needs to download and upload user
files on a UNIX host to and from a personal computer.  At first
I thought that I could rely on NFS to do this for me, but I am finding
out that site administrators seem to think that NFS has too many
security problems to allow its use from a PC.  Can someone summarize
what these problems are?  As I (somewhat) understand it, the standard
NFS protocol allows an entire volume to be mounted, and it has no
way to enforce user-level restrictions on access to files on that volume.
Is this correct?  Is there a way to build an application so that it
could use NFS in a secure fashion without exposing an installation
to security risks?

Send response (or copy of) to "simpsons@leland.stanford.edu".  Thanks.

Jim.
 

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 21:23:10 GMT
From:      joshua@Spies.COM (Joshua Geller)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

In article <1991May28.161202.14155@salt.acc.com> art@opal.acc.com (Art 
Berggreen) writes:

|>But a map showing just the backbones and regionals (and their interconnection
|>points) might be doable and useful.  This could only ever be a snapshot,
|>as the Internet is constantly changing, but the backbones are probably
|>the most stable part.

Hey, I'd settle for one of the backbones. Backbones and regionals would cause
me to literally faint in ecstatsy. I have NSF maps, but as several people
point out, that is far from adequate.

|>Art


josh

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 21:31:32 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In article <3270025@hpctdlb.HP.COM> fish@hpctdlb.HP.COM (Dave Fish - Marketing) writes:
>I'm interested in how common it is for TCP implementations to use all zeros
>for the TCP header checksum.  I know that some HP machines do this but 
>how common is this in the real world?

Not very, I hope.  It has never been legal.  UDP allows omission of the
checksum by this means; TCP does not.  RFC 1122:

         4.2.2.7  TCP Checksum: RFC-793 Section 3.1

            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
            checksum is never optional.  The sender MUST generate it and
            the receiver MUST check it.
-- 
"We're thinking about upgrading from    | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 to SunOS 3.5."              |  henry@zoo.toronto.edu  utzoo!henry

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 21:33:00 GMT
From:      systemdw@NTSC.NAVY.MIL ("SYSTEM MANAGER")
To:        comp.protocols.tcp-ip
Subject:   installation problems with EXCELAN tcpip interface




We are having problems getting 2 Excelan tcp/ip interface boards that 
were acquired for our vax computers, to communicate with other systems
on a local area network.
Board status shows EXOS204 FIRMWARE RELEASE 5.5, HARDWARE 0.0, SOFTWARE 4.F

The Excelan boards will only communicate with each other.  We have
tried to get a Cisco router and other software products such as
Wollongong to communicate, but with no luck.  All products use the
same class C ip address X.Y.X.-.  Using the debugger features of
a Cisco router clearly shows that the Excelan interface does not
respond to telnet or ping commands and does not see the Excelans
attempts at opening connections.  Having static arp table entries at
both the source and destination systems, publishing the arp entries,
and using the netload -e command to change the physical address to
a Dec manufactured board, a subnet mask setting to 0xff.0xff.0xff.0x0
have not been helpful.  We also reinstalled the software.

Netstat -e visually shows any changes when they are made to the board.
Bstat shows 11 transmitted frames (probably arps) when we try to go to
another TCPIP interface that is not listed in the arp table.

The transmission medium is ok, since the other systems can communicate
on the same segment.

Did we miss something in the EXCELAN documentation ???????????????????

Thanks for any assistance,
   ----------------------------------
   -   SYSTEMDW@NTSC.NAVY.MIL       -
   - NAVAL TRAINING SYSTEMS CENTER  -
   - ORLANDO FLORIDA                -
   ----------------------------------

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 21:54:41 GMT
From:      hedrick@athos.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip, jpc@avdms8.msfc.nasa.gov
Subject:   Re: Porting BSD telnetd to a Sun

We use the 4.4 telnetd on our Suns.  With either version, you'll want
to add some code to the section that opens the controlling pty.  Look
for

  for (i = 0; i < 16; i++) {
	line[sizeof("/dev/ptyp") - 1] = "0123456789abcdef"[i];
 	p = open(line, O_RDWR);
	if (p > 0)
		goto gotpty;
  }

Instead, you want something like the following.  (This is taken from
our 4.4 version of telnetd, so I haven't actually used it in the 4.3
one, but I think it should be OK.)  Note that this code is
SunOS-specific, and should work in 4.0.3c or later.  (It depends upon
an undocumented side-effect of TIOCGPGRP.)

  for (i = 0; i < 16; i++) {
	line[sizeof("/dev/ptyp") - 1] = "0123456789abcdef"[i];
	p = open(line, O_RDWR);
	if (p > 0) {
	  line[5] = 't';
	  chown(line, 0, 0);
	  chmod(line, 0600);
	  /* make sure the tty isn't in use */
	  if (ioctl(p, TIOCGPGRP, &dummy) == -1 &&
	      errno == EIO)
	    goto gotpty;
	  chmod(line, 0666);
	  close(p);
	  line[5] = 'p';
	}
  }

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 May 91 22:10:45 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In article <3270025@hpctdlb.HP.COM> fish@hpctdlb.HP.COM (Dave Fish - Marketing) writes:
>I'm interested in how common it is for TCP implementations to use all zeros
>for the TCP header checksum.  I know that some HP machines do this but 
>how common is this in the real world?

You must be talking about the *UDP* checksum, which is optional.  The TCP
checksum isn't optional.

Most BSD-derived Unix systems have a kernel variable that controls whether
UDP checksums are generated and checked (it's generally called something
like "udp_cksum", but I've seen variants without the underscore).  In
recent SunOS releases it's configurable in a header file at kernel build
time.  SunOS defaults to having checksums off.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 01:13:01 GMT
From:      brennan@coco.cchs.su.oz.au
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   tcp/ip ARPA for HP3000 ??


	Hello people!

	Okay, blow a fuse if I haven't posted to the right groups...

	We are stuck with a HP3000 mini in our Library, that we now
	want to get onto the net.
	What alternatives do we have for getting ARPA services?

	ANY clues, tips, laughs would be appreciated..

	especially when I'm a person surrounded by Suns && Vaxes!!

	HP3000's.... ohmygod!!

	<@_@>
	ldcb

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Luke Brennan                             e-mail: brennan@coco.cchs.su.oz.AU +
+ EDP Unit, S209                                   lukeb@casino.cchs.su.oz.AU +
+                                    brennan%coco.cchs.su.oz.au@cunyvm.BITNET +
+ Cumberland College of Health Sciences,                              ,-_|\   +
+ The University of Sydney                  voice: +61 2 646 6402    /     \  +
+ East Street, Lidcombe, NSW 2141             fax: +61 2 646 4853    \_,-._*  +
+ AUSTRALIA                                                               v   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 05:55:06 GMT
From:      S.K.Quinn@massey.ac.nz (S.K. Quinn)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcp/ip ARPA for HP3000 ??

Try WIN/TCP from Wollongong. 
Phone (415) 962-7100 Palo Alto California.
Fax   (415) 969-5547

There should be an Australian dealer. This is a HP recommended third party
product. Features Telnet, ftp, smtp
-- 
Stephen K Quinn                   S.K.Quinn@massey.ac.nz
MIS                               Phone (64) (63) 505062
Massey University                 Fax   (64) (63) 505603

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 14:51:00 GMT
From:      jimp@cognos.UUCP (Jim Patterson)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcp/ip ARPA for HP3000 ??

In article <1991May29.110116.1@coco.cchs.su.oz.au> brennan@coco.cchs.su.oz.au writes:
>	We are stuck with a HP3000 mini in our Library, that we now
>	want to get onto the net.
>	What alternatives do we have for getting ARPA services?

You should specify; is that a BIG HP3000 (9xx series) or a SMALL HP3000
("STACK" 16 bit architecture). (BIG refers to the word size, not physical
size, i.e. 32 bit as opposed to 16 bit).

If you have a big 3000 (i.e. something running MPE/XL), talk to HP.
They should have an ARPA services product real soon now, if it isn't
already out. Note: HP's ARPA services doesn't include telnet, but
does have FTP.

If it's a small 3000 (one running MPE/V), try contacting Wollongong.
Here's a very dated U.S. address:

    The Wollongong Group Inc
    1129 San Antonio Road
    Palo Alto, California 94303
-- 
Jim Patterson                              Cognos Incorporated
UUNET:uunet!cognos.uucp!jimp               P.O. BOX 9707    
BITNET:ccs.carleton.ca!cognos.uucp!jimp    3755 Riverside Drive
PHONE:(613)738-1440 x6112                  Ottawa, Ont  K1G 3Z4

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 16:19:53 GMT
From:      phil@shl.com (Phil Trubey)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcp/ip ARPA for HP3000 ??

In article <1991May29.110116.1@coco.cchs.su.oz.au> brennan@coco.cchs.su.oz.au writes:
>	We are stuck with a HP3000 mini in our Library, that we now
>	want to get onto the net.
>	What alternatives do we have for getting ARPA services?

You have to buy two packages unfortunately.  One is something called
ARPA Services for MPE or something like that from HP which gives you
an Ethernet board and a TCP kernal.  Then you have to purchase
third party software to give you the application programs (I kid
you not).  Wollongong sells such a thing for the HP 3000.

Two observations:  

it isn't cheap and the last time we did this we found that HP's TCP
has interoperability problems with Wollongong's TCP package
for the PC.  It works well with most other TCP's, though.

Good luck.

-- 
Phil Trubey                     |  Internet: phil@shl.com      
SHL Systemhouse Inc.            |  UUCP:     ...!uunet!shl!phil
50 O'Connor St., Suite 501      |  Phone:    613-236-6604 x667
Ottawa, Ontario, Canada         |  Fax:      613-236-2043

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 17:01:06 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted : ethernet protocol list...

In article <1991May29.181433.1@vmsa.technion.ac.il>, politis@VMSA.TECHNION.AC.IL writes:
|> 
|> 	Hello ,
|> 
|> Could anyone give me the translation of these ethernet protocols or give  a
|> pointer to a site I could FTP an extensive list of protocols along with their
|> translation ,as I might discover new protocols on our network and I wouldn't 
|> like to send such a request every week or so ...
|> 
|> 				Thank you all,
|> 					Joseph.
|>               


Some of these packet types may be misleading.  For instance, if your ethernet
is incurring errors, you may see funny packet types go by on your equipment.
Most network analyzers still capture what they can from a bad packet.  Just
keep in mind that the packet type could be reported incorrectly in these cases.

Be sure to check the FCS (CRC), Overrun, Collision and runt packet error counts
to see if this is the cause of these packets....

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 17:18:34 GMT
From:      brian@cimage.com (Brian Kelley)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Charon Problems



I'm in the process of trying to make Charon 2.0A work on our network.  I
initially tried to use our Netware 3.10 server and when it didn't work
switched to our 2.15 SFT server and had the same problems.

Right now I just want to test Charon's ability to grab a job out of a Novell
queue and place it in a UNIX lpr queue.  I believe I have everything set up
correctly, but when I start charon up, I get the following message:

Info: Attaching to Queue DSI_DM/lpr
Warning: Attach failed with error ea for Queue DSI_DM/lpr, unlinking

Charon will then continue to operate and pretend everything is ok.  My
jobs do not get forwarded to my UNIX host, however.  With charon running,
when I examine my queue (lpr) with the Netware 3.10 pconsole it says there
are no attached print servers (though I would think my charon printserver,
lpr, should show up).

Has anyone else has this problem before or succeeded in getting charon to
work (esp. with Netware 386)?



  Thanks for any help!

    Brian


---
brian@cimage.com

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 18:14:33 GMT
From:      politis@VMSA.TECHNION.AC.IL
To:        comp.protocols.tcp-ip
Subject:   Wanted : ethernet protocol list...


	Hello ,

Could anyone give me the translation of these ethernet protocols or give  a
pointer to a site I could FTP an extensive list of protocols along with their
translation ,as I might discover new protocols on our network and I wouldn't 
like to send such a request every week or so ...

				Thank you all,
					Joseph.
              
Please email if you have partial answer to my request and I will summarize them
unless someone can provide me with a FTP site ( no need to have the job done 
twice , right ??? )


E-mail :  politis@vmsa.technion.ac.il


Politis Joseph
Network Team at the Technion Institute 
Haifa ,Israel.

/*********************** start of unknown protocols **************************/
x0808 : 
x0dc0 : 
x2020 : 
x2573 : 
x2e80 : 
x2e87 : 
x302c : 
x3731 : 
x3ae5 : 
x3c01 : 
x3c02 : 
x3c03 : 
x3c07 : 
x3c09 : 
x3c0a : 
x3c0b : 
x3c0d : 
x4430 : 
x4500 : 
x454d : 
x4920 : 
x5612 : 
x6520 : 
x656c : 
x6814 : 
x6c0c : 
x6d65 : 
x6e80 : 
x6f63 : 
x726f : 
x7365 : 
x736d : 
x7415 : 
x7420 : 
x7503 : 
x75e6 : 
x7ae5 : 
x7ee5 : 
x8787 : 
x8b50 : 
x8c1a : 
x9ad9 : 
xaaaa : 
xbf41 : 
xe0d1 : 
xe83c : 
xffff :
/********** end of unknown protocols ( until the next one appears !!!)*******/

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 18:57:09 GMT
From:      latzko@luna-sea.rutgers.edu (Alexander Latzko)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcp/ip ARPA for HP3000 ??

brennan@coco.cchs.su.oz.au writes:


>	Hello people!
>	We are stuck with a HP3000 mini in our Library, that we now
>	What alternatives do we have for getting ARPA services?
>	HP3000's.... ohmygod!!
>+ Luke Brennan                             e-mail: brennan@coco.cchs.su.oz.AU +

I feel sorry for you.  We are stuck with one of these beasties and it
has driven us practically to drink.  The only solution when we started
was a combination of TWG's overprices TCP suite and a cisco router to
convert from 802.3 to ethernet II framing.

Since then the TWG software has been mostly fixed ( now supports subnets, 
ethernet framing, and DNS resolver ), but is still expensive.

Try info@twg.com for pricing and the like.  Good luck

alex

latzko@hardees.rutgers.edu			{backbone}!rutgers!latzko

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 22:04:01 GMT
From:      kevin@cfctech.cfc.com (Kevin Darcy)
To:        comp.protocols.tcp-ip,news.software.b,comp.unix.programmer
Subject:   Re: Problems using rn over a telnet connection

In article <1991May24.212235.8187@otsc.eds.com> snyde_sl@tsca02.uucp (Steve Snyder) writes:
>Our site recently established a newsfeed.  We are running C news (last
>patch date is 24-Mar-91) and rn (last patch date is 01-Jan-91, # 54)
>on an Apollo DN3000 under Domain/OS SR10.2 (sys 5.3 environment).
>The ASCII terminals we have are connected to Black Box terminal
>servers.
>
>The problem we are having concerns using rn over a telnet or rlogin
>connection to the news server.  It seems that regardless of what type 
>of terminal (VT100, VT320, PC, SUN SPARC2, HP9000/380, or even another 
>Apollo bitmap display) I use to telnet to the news server, this 
>problem occurs.  The problem is that rn repeatedly displays the 
>first '--read now? [npq]' prompt (beeping every time) as shown below:
>
> [example given]
>
>So I just have to quit and get out of rn.  [further details]
>
>Any ideas why rn responds this way over a telnet connection, or 
>possible solutions to this problem?  I've run out of ideas.  I posted 
>this previously to news.software.b and news.newusers.questions but got
>no responses.

We've seen identical behavior from rn and trn over AT&T Starlan connections
on 3B2's. My guess is that the pty driver used by your telnetd is based 
on STREAMS, and the rn/trn code is known to not handle STREAMS-based tty 
drivers quite correctly in O_NDELAY mode.

Specifically, the code doesn't respect the following critical distinction 
(this is a quote from the read(2) section of a vendor manual):

	When attempting to read a file associated with a tty has no
	data currently available:

		If O_NDELAY is set, the read will return 0.

		[...]

	When attempting to read a file associated with a _stream_ that has no
	data currently available:

		If O_NDELAY is set, the read will return a -1 and set errno to
		EAGAIN.

We have a local hack that works around this problem. I can send it to anyone
who is interested.

Followups to news.software.b and/or comp.unix.programmer.

>Steve Snyder             | You've got to know when to code 'em,
>Electronic Data Systems  | know when to modem, know when to load 'em,
>snyde_sl@otsc.eds.com    | and know when to run.
>uunet!tsca02!snyde_sl    |                        --Anonymous

-------------------------------------------------------------------------------
kevin@cfctech.cfc.com 		  | Kevin Darcy, CFC Unix Systems Administrator
...sharkey!cfctech!kevin 	  | MIS/Technical-Services/Distributed-Systems
Voice: (313) 759-7140 		  | Chrysler Corporation
Fax:   (313) 758-8173 		  | 25999 Lawrence, Center Line, MI 48015
-------------------------------------------------------------------------------

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 22:19:15 GMT
From:      croft@csusac.csus.edu (Steve Croft)
To:        comp.protocols.tcp-ip
Subject:   Clarkson and NCSA Telnet

One of the packet drivers in the Clarkson package is more
up-to-date than the similar driver in the NCSA Telnet
program.  It is possible to run the Clarkson driver and have
it supercede the driver in NCSA Telnet?  Thanks!

Steve Croft

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 22:25:36 GMT
From:      mah@wu-wien.ac.at (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In article <WBRAND.91May22095443@krishna.shearson.com>, wbrand@krishna.shearson.com (Willy Brandsdorfer) writes:

|> TCP/IP Version 2 supports a normal socket interface. I think you need to use
|> IBM C. I'm not an expert on this but I believe you can link this to SAS/C
|> 

Well, normal. I does  have connect(), but it doesnt have accept(), at least
last time I checked (I checked thoroughly, because I wrote a tape server
for VM).

Seems like they implemented the bare minimum so they could link Xlib.

- michael


-- 
Michael Haberler 		mah@wu-wien.ac.at,  mah@awiwuw11.bitnet
University of Economics and Business Administration
A-1090 Vienna, Augasse 2-6	    Biz:    +43 (1) 31336 x4796 Fax: 347-555
Home: +43 (1) 961-679 (voice & fax) D-Netz: +43 (663) 811-056

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 22:54:52 GMT
From:      croft@csusac.csus.edu (Steve Croft)
To:        comp.protocols.tcp-ip
Subject:   Re: Clarkson and NCSA Telnet

I believe I have found my own answer...  just set the config.tel
file to use the packet driver...  not clear in the documentation,
but easy enough to figure out.

steve

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 23:36:24 GMT
From:      Daniel_Murphy@MTS.RPI.EDU
To:        comp.protocols.tcp-ip
Subject:   IBM's VNET

I obtained a reference concerning IBM's VNET from the 1989 book
THE MATRIX by John Quarterman, and he cited this net address.
The name of the author was H. Nussbacher.  Any info. on the
availability of the VNET information in the U.S. would be
greatly appreciated.  Thank you.
 
Daniel Murphy
Communication Dept.
Rensselaer Polytechnic Institute
Troy, NY
USA

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 May 91 23:46:33 GMT
From:      zweig@parc.xerox.com (Jonathan M. Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In 1's complement arithmetic there are two ways of writing "zero". In C they
are 0x0000 and 0xffff (16-bit).  I can't see any reason why the checksum would
need to always come out to be nonzero (i.e. 0x0000 could happen).

Consider the 16-bit ones complement of the 16-bit ones complement sum of a
bunch of numbers that happen to add up to 0xffff (such as, say, 0xff00 and
0x00ff with a bunch of 0x0000's too). Yikes! It is all zeroes.

The TCP checksum is never optional (though you can use a different one if you
like, by supporting RFC1146-style checksum algorithm negotiation), but it is
not clear to me that it cann never be all zeroes.

In fact, I can't figure out a way that the checksum would ever be 0xffff
("negative zero").  If you can think of a set of 16-bit values whose TCP
checksum is 0xffff let me know.  Since 0xffff + 0xffff = 0xffff (and not
0x000), I can't figure out a sum that comes out to 0x0000 in order to get
complemented to 0xffff by the vanilla TCP checksum algorithm.

-Johnny Checksum

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 01:00:12 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: tcp/ip ARPA for HP3000 ??

What sort of HP 3000? Which revision of MPE? HP supports ARPA services and
TCP/IP on the MPE/XL OS for the 3000 Series 900 machines, and there are also
solutions available (not all from HP) for the older CISC-based 3000s running
MPE/V.

You might try talking to your local HP sales folk.
--
This is not an official statement of The Hewlett-Packard Company. No
warranty is expressed or implied. The information included herein is not to
be construed as a committment on HP's part. The devil made me do it. This
won't save me from the lawyers' wrath, but it can't hurt.

Jason Zions			The Hewlett-Packard Company
Colorado Networks Division	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 02:27:15 GMT
From:      piacenti@granite.ma30.bull.com (Paul Piacentini)
To:        comp.protocols.tcp-ip
Subject:   ethernet alignment errors


  Most of our ethernet equipment, analyzers, etc report counters on bytes,
packets, CRC errors, collisions, runts, giants, and frame alignment errors.
I'm a little fuzzy on exactly what consistutes a frame alignment error.
Is it a packet that was transmitted within the minimum IEEE inter-packet delay
spec window (9.6 usec?) ?
If that's the case, is it tallied up as an aligment error by every device that
saw it, ALONG with being tallied as a transmitted packet? Or does it count as
an error and get discarded as a non-valid packet? Does the destination ignore
it and wait for a retransmit?
Are they caused by a bad transceiver? controller timing problems? bad carrier
detection? software greedy for the bandwidth?

Can anyone enlighten me on this .. an inquiring mind wants to know

thanks, Paul

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 _\ /_              Paul E. Piacentini |  Bull Worldwide Info Systems
  / \   piacenti@granite.ma30.bull.com |  300 Concord Rd. MA30-857     _\ /_
                        (508) 294-3450 |  Billerica, Mass 01821         / \

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 03:27:10 GMT
From:      pace@tabarzin.usace.mil (Joe Pace)
To:        comp.protocols.tcp-ip
Subject:   Strange slowness

We have a strange problem when sending data between an Intergraph
workstation and an HP 9000/340, the transfer rate seems to be
very slow (about 500K/minute) compared to other machines (Sun, Unisys,
Apollo) sending the same data to the same HP using the same method.

The network looks like this:

																   
  Sun   Apollo   Intergraph           Unisys                       
   |      |           |                 |                          
---+------+-----------+-----------+-----+------------ (Thick net)
                                  |                                
                             PC Router (Ka9q - IBM AT)                    
                                  |                                
                  -----+----------+----- (Thin Net)                
                       |                                           
                   HP 9000/340                                     
                                                                   
                                                                   
                                                                   
The command being issued from the Sun, Apollo, Unisys, and Intergraph is:

   tar cvfb - 20 . | dd ibs=20b obs=1k | rsh hp-9000 "dd ibs=1k of=data"

The file grows at a rate of about 5 megs/minute when using the
Sun, Apollo, and Unisys machines, but grows by only about 500K/minute
when sending from the Intergraph.

The Intergraph machine does not exhibit this problem when sending to
other Intergraphs or Apollo machines, and is able to transfer
at about 5 megs/minute when sending the data via an Apollo, i.e.,

  ... | rsh apollo "dd bs=1k | rsh hp-9000 'dd ibs=1k of=data' "

Using FTP to copy files exhibits the same behavior.

Does this sound like a familier problem?  It seemd odd that this
is only affecting the Intergraoh machines.

Thanks 

  Joe
-- 
Joe Pace
US Army Corps of Engineers                                     pace@usace.mil
Sacramento District                                     JPPACE@UCDAVIS.BITNET
650 Capitol Mall, Sacramento, CA  95814         (916) 551-1133, FAX: 551-1100

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 08:33:36 GMT
From:      yrjola@hkkk.fi (Matti Yrjola)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Re: tcp/ip ARPA for HP3000 ??

In <1991May29.110116.1@coco.cchs.su.oz.au> brennan@coco.cchs.su.oz.au writes:


>	Hello people!
 
>	Okay, blow a fuse if I haven't posted to the right groups...
 
>	We are stuck with a HP3000 mini in our Library, that we now
>	want to get onto the net.
>	What alternatives do we have for getting ARPA services?

What model HP3000 do you have? The "classic" HP3000 series (with CISC 
architecture) do not have a HP solution for ARPA/Berkeley services,
but Wollongong Group have one available. For the "New Generation" 3000s
(RISC machines) you can get FTP and Telnet from HP. I think FTP is
a software product, but Telnet is a hardware solution (a Telnet
TCP/IP-card added to a HP DTC terminal server or as a separate Telnet
Gateway).
Product number for the Telnet Access card is HP2347A (we have ordered
one).

Another solution is to hook up a TCP/IP terminal server to the
RS-ports on the 3000.


>	especially when I'm a person surrounded by Suns && Vaxes!!

Wax? Is that something you use on your surfboard?  :-)

>	HP3000's.... ohmygod!!

Good Luck

my








-- 
----------------------------------------------------- I did it  M   M  Y   Y
 Matti Yrjola, Helsinki School of Economics, Computer Center !  MM MM   Y Y
 Runeberginkatu 14-16, 00100 HELSINKI, FINLAND               !  M M M    Y
 INTERNET: yrjola@hkkk.fi                                    !  M   M  waY

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 15:29:14 GMT
From:      snorthc@relay.nswc.navy.mil (Stephen Northcutt)
To:        comp.protocols.tcp-ip
Subject:   interop 91 and gov't rates

Government workers (at least this one ) really don't make a lot
of $$$.  So it really hurts when people cut deep into our personal
pockets.  The best network conf.  IMHO is interop.  Interop has
grown very large, too big for San Jose.  This year the hotel rooms
are being managed by Convention Housing Management, who are nice
people.  The bad news is there are no gov't rates available.  I am
booked into a nice, inexpensive, hotel, the Vagabond which should
fall more or less within my per diem.  So if you are a Gov't employee
and want to go to interop, you best get hopping.
FLAME> Gov't workers have been a fairly large contingent at interop.
Gov't people and $$$ have had a lot to do with TCP being where it is
today.  This is a slap in the face :-( <FLAME

===================================================================
   ** my dream: voice, video, data, 3 services, 1 network **
===================================================================

Stephen Northcutt (snorthc@relay.nswc.navy.mil)     News Admin

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 17:03:39 GMT
From:      hastings+@ANDREW.CMU.EDU ("Eugene F. Hastings")
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

There are a number of maps online at nis.nsf.net in the aptly named maps
subdirectory. They vary in degree of "obsoleteness" from being as current
as is preactical, to being of interest only to compulsive historians.

I believe there is comparable information on nic.nordu.net for European
nets.

Gene

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 17:18:57 GMT
From:      billy@vaxb.acs.unt.edu
To:        comp.protocols.tcp-ip,comp.misc
Subject:   Internet Library Guide

Hi,

Another release of the "UNT's Accessing On-line Bibliographic Databases"
handout is now complete.  The count is now around 200 Internet library systems.

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
the PACS-L or LIB_HYTELNET mailing lists.

================================================================================
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 (129.120.1.4) via anonymous FTP
in the library directory.  The files are:

LIBRARIES.TXT - ASCII version
LIBRARIES.PS  - Postscript version
LIBRARIES.WP5 - WordPerfect 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.

Detailed Description by Roy Tennant (rtennant@library.berkeley.edu) [edited
by Billy Barron]:

Please note that these instructions are only for Internet sites.  Users
with access only to BITNET should send a mail message to BITFTP@PUCC
with HELP at the first and only line of the message.  The response will
give you instructions on using the Princeton BITFTP server, which
provides a mail interface to the FTP portion of the TCP/IP protocol
suite.  
 
TO RETRIEVE:
At your system prompt, enter:               ftp vaxb.acs.unt.edu
      or                                    ftp 129.120.1.4
When you receive the Name prompt, enter:    anonymous
When you receive the password prompt, enter your Internet address.
When you are at the ftp> prompt, enter:     binary
At the next ftp> prompt, enter:             cd library
Then enter:                                 get FILENAME

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 an easy to use
form 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@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.  Sorry
about the Appendices on some library software that are not yet completed.  I
will complete as time permits.


I have problems printing the PostScript file.

I found a problem at my end that was causing 75% of these problems.  I have not
yet resolved what is causing other people difficulty.  The evidence right now
is pointing to the fact that *some* FTP packages are stripping out CRs when
they are not supposed to (WIN/TCP on VMS is an example of this).


The text version is all on one line.  How can I fix that?

The following is the combination of a couple of mail messages from
Scott Robinson, CMU (she@opel.ece.emu.edu).  Thanks, Scott!

The problem is probably due to the fact that the UNIX ftp(1) (at least the
one under Ultrix) strips Carriage Return charaters during file transfers. Use
the 'cr' command to toggle carriage-return stripping.  With stripping off,
you will have the necessary delimiter. Then use tr(1) or your favorite
editor to convert your Carriage Returns into the appropriate character.
I used the following to convert files I retrieved (and later renamed to get
rid of the ';#' stuff.)

#!/bin/sh

for i in README libraries.adr libraries.contacts libraries.ps libraries.txt networks.hlp
do
	mv $i foo
	tr -d '\015' < foo > $i
done

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 17:47:09 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   libc resolver for SUN 4/490

Good morning folks!
I was wondering if anyone knows of where you can get libc that works with the
resolver for the SUN4/490 class machine? The normal SUN4(SPARC) modules don't
work on the 470 or 490 because of the I/O cache or something. I would truly
appreciate a pointer to somebody who has built one on this architecture.
Thanks in advance,
Chris VandenBerg
CMC -  A Rockwell Intl Co.   125 Cremona Dr.   Goleta, CA. 93117
Internet - chrisv@cmc.com          ma-bell - 805-562-3127 

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 17:59:41 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP question

>By definition Proxy ARP can only respond to hosts which do not understand
>subnets.  If the machine sending the ARP request understood subnets, it
>would use the usual IP routing mechanism to route its packets.

This definition is a little too simplistic.  For example, we use subnets
here, but have multiple subnet sizes.  Proxy ARP lets hosts on the big
subnet find systems on the small subnets which are carved out of the
big one.

Doug Nelson                             nelson@msu.edu
Michigan State University

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 18:27:59 GMT
From:      rubin@watson.ibm.com (Bill Rubin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In <1991May29.222536.14957@swdsrv.edvz.univie.ac.at> mah@wu-wien.ac.at (Michael Haberler) writes:
> In article <WBRAND.91May22095443@krishna.shearson.com>, wbrand@krishna.shearson.
>
> |> TCP/IP Version 2 supports a normal socket interface. I think you need to use
> |> IBM C. I'm not an expert on this but I believe you can link this to SAS/C
> |>
>
> Well, normal. I does  have connect(), but it doesnt have accept(), at least
> last time I checked (I checked thoroughly, because I wrote a tape server
> for VM).
>
> Seems like they implemented the bare minimum so they could link Xlib.

Well, you haven't checked recently, since our TCP/IP Version 2 for VM (and
MVS) both have fairly complete socket implementations, including accept().
VM V2 has been out since last November, MVS V2 was available this March.

-- Bill Rubin
   IBM TJ Watson Research

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 18:45:39 GMT
From:      chw@hpctdlbcol.hp.com (Charlie Whiteside)
To:        comp.protocols.tcp-ip
Subject:   Re: ethernet alignment errors

/ hpctdlb:comp.protocols.tcp-ip / piacenti@granite.ma30.bull.com (Paul Piacentini) /  8:27 pm  May 29, 1991 /
>  Most of our ethernet equipment, analyzers, etc report counters on bytes,
>packets, CRC errors, collisions, runts, giants, and frame alignment errors.
>I'm a little fuzzy on exactly what consistutes a frame alignment error.
>Is it a packet that was transmitted within the minimum IEEE inter-packet delay
>spec window (9.6 usec?) ?

No. 802.3/Ethernet frames are required to send their data in 8 bit units called
octets or bytes. If the frame ends (CSN goes false) and the number of bits is
not divisible by eight then the frame had an alignment error.  An alignment
error can be divided into two categories. (These are terms we use here, the
industry may use variations on these) a. Dribble frame - This occurs when a
frame is not octet aligned but the FCS was good. Usually means the CSN line
went false a few bits after the frame ended, FCS good shows that data integ-
rity for the frame exists.  b. Misaligned frame - Non-octet aligned frame 
with bad FCS. Could be an extra bit(s) was added in the data field, caused
shift of data, FCS caught the extra bits.

Inter Frame Spacings of less than 9.6 uS is a totally different measurement.

Hope this helps.

Charlie


chw@hpctdlb.hp.com
719-531-4388

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 19:21:01 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Confirming DNS name matches local host name

Given an internet IP, is there a way to retrieve what the host at that IP
actually calls itself. In other words, I want to confirm that what DNS
says actually matches the local host name.

I thought telneting in through the "smtp" port and capturing the output 
would be an option but the "smtp" output resists capture.

Any help or suggestions would be greatly appreciated.



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

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 20:10:04 GMT
From:      zweig@parc.xerox.com (Jonathan M. Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In fact, I can prove that if the ones-complement arithmetic is done the way I
learned it at my mother's knee, then the TCP checksum field will never contain
0xffff, though it can contain 0x0000.  I think it was dumb for UDP to use
0x0000 as the "no checksum" value, when 0xffff is impossible (i.e. you could
implement a checksum algorithm that doesn't mess around with substituting -0
for 0 since it will never happen in a real datagram).

The proof is based on the fact that the ones complement (1C) sum of a set of
numbers is 0 (I will use 0 to mean 0x0000 and -0 to mean 0xffff) if and only
if all of the numbers are 0.

(<==) trivial.  Add 0 to 0 and you get 0.
(==>) observe that if the set of numbers to be added contains any nonzero
(i.e. not 0x0000) number, there will be a 1 in at least one of the bit
positions of one of the addends.  The only way the corresponding bit in the
sum could be 0 is if there are an even number (>=2) of 1's in that column of
the sum.  But wait! That means there will be a carry out of that position.
Since 1C addition has end-around carry (i.e. you can perform the addition
bitwise was long as you take the carry bit out of the leftmost single bit
addition and add it back to the sum), that carry bit can't "go away". That is,
the only way you will stop carrying is by adding the 1 to a bit of the sum
that is 0.  There is no way in 1C addition to add 1 to anything and have it
end up as 0 (it will be -0, possibly, but never 0).  This means that the carry
bit out the end of any pairwise addition results in a nonzero sum. By
induction, we see that there cannot exist a set of numbers not all 0 that add
up to 0.

Since RFC793 defines the checksum as the bitwise complement of the 1C sum of
all the 16-bit words in a datagram, we see that since the sum can never be 0,
the complement can never be -0.

I am told that there are brain-damaged (to my mind) ways of implementing 1C
arithmetic that automagically sustitute 0 for -0 if it is the result of an
addition.  So we can blame this boneheadedness with the 0/-0 switcheroo on
them, I suppose.

Does anyone know why UDP chose 0 (rather than -0) to indicate no checksum? Was
someone smoking something?  It seems to me it has complicated (albeit by only
a couple of instructions) every TCP and UDP checksum calculation ever, at a
cost to society of millions of dollars (add up all those cycles for me,
please).

Of course, it's probably far too late to start making a fuss about it now.

-Johnny Checksum

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 20:57:43 GMT
From:      mark@dosli.govt.nz (Mark Wright)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: Charon Problems

In article <1991May29.171834.23181@cimage.com> brian@cimage.com (Brian Kelley)
writes:
>
> ... switched to our 2.15 SFT server and had the same problems.
>
>Right now I just want to test Charon's ability to grab a job out of a Novell
>queue and place it in a UNIX lpr queue.  I believe I have everything set up
>correctly, but when I start charon up, I get the following message:
>
>Info: Attaching to Queue DSI_DM/lpr
>Warning: Attach failed with error ea for Queue DSI_DM/lpr, unlinking
>

Good thing I read the group before posting! I'm getting the same thing. I've
got Charon receiving lpr jobs and placing them in the Novell queue OK, it's
just going back the other way that's a problem. Anyone know what the code "ea"
means? We don't have a list on Novell error codes.
-- 

 Mark Wright.                    Dept. of Survey and Land Information,NZ.
 email: mark@dosli.govt.nz       phone: 64 4 710-380 ext 8688

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 21:04:22 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: Confirming DNS name matches local host name

In article <891@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
>Given an internet IP, is there a way to retrieve what the host at that IP
>actually calls itself. In other words, I want to confirm that what DNS
>says actually matches the local host name.
>
>I thought telneting in through the "smtp" port and capturing the output 
>would be an option but the "smtp" output resists capture.
>
 By "resists capture", I presume you mean you wish to run this from a script.
(Do you have 'mconnect', and if so, did you try this)?

 I am not sure what you expect by telnetting to the smtp port.  That isn't
going to tell you what the host calls itself.  It will tell you what the
smtp software on the host call itself.  Given how common misconfigured
mail software is, I would trust the DNS over the smtp dialogue for giving
the name.

 Then there is the question of what you mean by "what the host actually
calls itself".  A good guess is that when it is talking to itself, it
usually calls itself 'localhost', but somehow I doubt that this is what
you mean.

 Do you mean `hostname`?.  Do you mean `hostname`.`domainname` (assuming
that domainname exists)?  Do you mean the result of canonicalizing one of
these with a host table lookup?  or with a DNS lookup?  And in any case,
why would you care?


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 May 91 21:47:01 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Confirming DNS name matches local host name

In article <891@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
>Given an internet IP, is there a way to retrieve what the host at that IP
>actually calls itself. In other words, I want to confirm that what DNS
>says actually matches the local host name.

gethostbyaddr(3) should do the trick (don't know if it will or not if
you are running NIS):

# include <sys/types.h>
# include <sys/socket.h>
# include <netdb.h>

int main (argc, argv)
        int argc;
        char **argv;
{
        struct hostent *h;
	u_long	ip

/* assume ip gets set somehow */

        h = gethostbyname (&ip, sizeof (u_long), AF_INET);
        if (h == NULL) {
                fprintf (stderr, "Can't get host info for this host\n");
                exit (1);
        }

        printf ("official name: %s\n", h -> h_name);
}

alternatively, there is nslookup:

Given IP address 1.2.3.4

nslookup
> set q=ptr
> 4.3.2.1.in-addr.arpa.

should also do the trick. 

Warner
-- 
Warner Losh		imp@Solbourne.COM
Free to a good home: 10,000 Miller Moths.  Must promise not to breed them.

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 02:32:56 GMT
From:      ken@tcs.com (Ken Emery)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: Charon Problems

if you place the Charon printer server gateway (lpr) as a server 
on the novell queues which correspond to the unix printers this 
may solve your problem (we had this problem and it is not mentioned
in the manual).

Now if someone could just figure out why I can't print from 
windows to an Apple Laserwriter via Charon 2.0a I'd be a real happy
camper.

bye,
ken emery
internet: ken@tcs.com
voice: (415) 649-3789

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 03:23:00 GMT
From:      baird2@lincoln.ac.nz
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: Charon Problems

In article <1991May30.205743.19560@dosli.govt.nz>, mark@dosli.govt.nz (Mark Wright) writes:
>>Right now I just want to test Charon's ability to grab a job out of a Novell
>>queue and place it in a UNIX lpr queue.  I believe I have everything set up
>>correctly, but when I start charon up, I get the following message:
>>
>>Info: Attaching to Queue DSI_DM/lpr
>>Warning: Attach failed with error ea for Queue DSI_DM/lpr, unlinking
>>
> 
> Good thing I read the group before posting! I'm getting the same thing. I've
> got Charon receiving lpr jobs and placing them in the Novell queue OK, it's
> just going back the other way that's a problem. Anyone know what the code "ea"
> means? We don't have a list on Novell error codes.

I'm just about to start setting up Charon 2.0 so am interested in this
thread. Error code EA is "no such member". Have you run ADDQOP? Have you
run BINDFIX since running ADDQOP - I recall someone saying ADDQGRP for
Charon 3 had to be rerun after running BINDFIX and the same may apply to
ADDQOP.

----------------------------------------------------------------------------
   John Baird                           Internet:   J.Baird@ono.lincoln.ac.nz
   Senior Computer Consultant           CompuServe: 75360,35
   Centre for Computing & Biometrics    Phone:      (64) (3) 252-811
   Lincoln University                   Fax:        (64) (3) 252-944
   Canterbury
   New Zealand

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 03:35:57 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip,bit.listserv.ibmtcp-l
Subject:   any caveats for AS/400 TCP/IP ?


we are going to be installing TCP and an ethernet adapter in our AS/400.

anyone got any gotcha's or hints i should be aware of?

(i'm not an AS/400 type, but i guess i'll be learning soon.  8^)

are there any products to expand this beyond TELNET/FTP/SMTP ?

BTW: we have AT&T 3B2's on our existing network, the AS/400 is an add-on.

thanx
-- 
[ Jim Mercer  jim@lsuc.On.Ca  || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA  ]
[ Standards are great. They give non-conformists something to not conform to. ]
[      The opinions expressed here may or may not be those of my employer     ]

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 07:51:19 GMT
From:      deraadt@cpsc.ucalgary.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   Re: Porting BSD telnetd to a Sun

In article <May.28.17.54.40.1991.9637@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
>  Instead, you want something like the following.  (This is taken from
>  our 4.4 version of telnetd, so I haven't actually used it in the 4.3
>  one, but I think it should be OK.)  Note that this code is
>  SunOS-specific, and should work in 4.0.3c or later.  (It depends upon
>  an undocumented side-effect of TIOCGPGRP.)

Note that Sun's in.telnetd does not even do this. in.rlogind on sun does
though...

Oh, and script does not either.

Of course, gmacs.. etc.. anything from the net that deals with pty's, do
not either.

I believe that the reason they do this is because when they went to
session groups they messed up vhangup(), or equivelant. Not surprising.
All terminals, not just pty's, are screwed up now.
 <tdr.
--

SunOS 4.0.3: /usr/include/vm/as.h, Line 44      | Theo de Raadt
SunOS 4.1.1: /usr/include/vm/as.h, Line 49      | deraadt@cpsc.ucalgary.ca
Is it a typo? Should the '_'  be an 's'?? :-)   | deraadt@cpsc.ucalgary.ca

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 09:26:42 GMT
From:      jara@fulcrum.bt.co.uk (Jujhar Kandhola)
To:        comp.protocols.tcp-ip
Subject:   SNMP

Could somebody out there send me some information on the the 
"Simple Network Management Protocol". A high level description 
would be great along with details of where I can obtain some further 
information. 

If this is the not the newsgroup in which I should be asking this question
I apologise.

  Cheers 
     Jara

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 09:52:27 GMT
From:      paul@actrix.gen.nz (Paul Gillingwater)
To:        comp.protocols.tcp-ip,comp.sys.ibm.pc.misc,alt.bbs
Subject:   Want Telnet that can be run via serial port

No, I'm not looking for a version of SL/IP.  I'm looking for a
version of something like NCSA Telnet (which we already use) which
can use a modem as it's keyboard and console, i.e. instead of
talking to the screen and keyboard of the computer it's running on,
it allows a BBS to pass control to it to login to a remote system
over a LAN.

Has anyone heard of such a thing?  Is there a chance someone has
already modified NCSA Telnet to do this?  Is it feasible?

For background, here's part of our setup:

    PC Running D'Bridge    <-----serial----->   UNIX box in same room
    Terminal emulator

A user logs in to D'Bridge, then runs a locally written terminal
emulator that allows them to login to the UNIX box over the serial
link.  We want to do the same thing, only over 802.3 with TCP/IP.

We have the source code for the terminal emulator, so I guess we
could hook it into a PD INT 14 TCP/IP implementation -- if such a
thing exists.

Anyone got ideas?

Thanks in advance!
Please mail and I'll summarize.
-- 
Paul Gillingwater, paul@actrix.gen.nz

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 12:02:22 GMT
From:      NJG@CORNELLC.CIT.CORNELL.EDU ("Nick Gimbrone ", WIRDI: Whatever Is Right, Do It)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

>   IBM TCP/IP for VM (R1.2) does not have socket interface and also
>requires IBM C for System/370 (we are calling White Smith C) which we don't
IBM TCP/IP v2 for VM does include a socket interface for IBM C/370.
I suspect it would either work w/ other Cs or could be made to do so
without too much hassle (though I've not done so). I have used the
interface w/ C/370 and can state that it works.

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 12:06:37 GMT
From:      NJG@CORNELLC.CIT.CORNELL.EDU ("Nick Gimbrone ", WIRDI: Whatever Is Right, Do It)
To:        comp.protocols.tcp-ip
Subject:   Re: KNET 200

On Fri, 17 May 91 14:07:36 EDT you said:
>   Date: Thu, 16 May 1991  22:38 MDT
>   From: "Frank J. Wancho" <WANCHO@WSMR-SIMTEL20.ARMY.MIL>
>   I've reviewed the archives, looking for observations on the KNET
>   software, and found mixed reactions, with some of the comments from
>   several years ago quite negative.
>   What's the current status?  Has it been brought up-to-speed, or should
>servers. I worked in detail with the SMTP implementation, and I wasn't
>impressed - I'd look at the U. Wisconsin TCP/IP implementation.
I was recently speaking w/ someone who have both the KNET and IBM
TCP/IP products. IBM's product is a fixed up version of the Wisconsin
work (function added, performance improved, etc). As of early this year
not only does the IBM implementation far surpass KNet in function, it
is also now running faster than KNet. I believe that most IBM VM and MVS
sites feel that there is but one viable alternative today - IBM's
TCP/IP for VM and MVS.

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 12:41:45 GMT
From:      glenn8@garfield.cs.mun.ca (Glenn Stowe)
To:        comp.protocols.tcp-ip
Subject:   Getting a process from a tcp numer or PCB in netstat

Is there any way to trace the numbers appended to a connection name by the
protocol, as listed by netstat back to the process and determine its name?

If not, is there any other way to get the names of two processes (not
necessarily on the same machine, but connected by sockets) given the port?

Please reply via email.
-----
Glenn Stowe
glenn8@odie.cs.mun.ca

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 14:23:47 GMT
From:      scott@storm.Berkeley.EDU (Scott Orr)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.novell
Subject:   Re: Charon Problems


In article <1991May29.171834.23181@cimage.com>, brian@cimage.com (Brian
Kelley) writes:
|> 
|> 
|> I'm in the process of trying to make Charon 2.0A work on our network.  I
|> initially tried to use our Netware 3.10 server and when it didn't work
|> switched to our 2.15 SFT server and had the same problems.
|> 
|> Right now I just want to test Charon's ability to grab a job out of a Novell
|> queue and place it in a UNIX lpr queue.  I believe I have everything set up
|> correctly, but when I start charon up, I get the following message:
|> 
|> Info: Attaching to Queue DSI_DM/lpr
|> Warning: Attach failed with error ea for Queue DSI_DM/lpr, unlinking

We had the same error when installing Charon 2.0A with our NW 2.15 Net.  After
some trial and error we came up with the following solution.  First, name your
print server something other than lpr.  Once you've gone through all the steps
listed in the docs, go back into pconsole and make the new print server a 
print server for the outgoing queue.  Now when firing up charon, be sure to
add the -u option for that server and print server.  

(i.e. "charon -p printer.dat -l lpd.dat -h config.tel -u etadmin/charon2")

This worked for us and I imagine it should for NW/386.  I hope this helps, and
if not, email me.  Good luck.

Scott.

=============================================================================
When you have eliminated the impossible, whatever remains, however improbable,
must be the truth. -- Sherlock Holmes (Sir Arthur Conan Doyle)
============================================================================= 

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 14:48:52 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip
Subject:   Confirming DNS name - what I really meant

>I thought telneting in through the "smtp" port and capturing the output 
>would be an option but the "smtp" output resists capture.
>
| By "resists capture", I presume you mean you wish to run this from a script.
| (Do you have 'mconnect', and if so, did you try this)?

Yes, I was working with a script. I'm not familiar with 'mconnect' and couldn't 
find it on the RS6000.

> I am not sure what you expect by telnetting to the smtp port.  That isn't
> going to tell you what the host calls itself.  It will tell you what the
> smtp software on the host call itself.  Given how common misconfigured
> mail software is, I would trust the DNS over the smtp dialogue for giving
> the name.
 
> Then there is the question of what you mean by "what the host actually
> calls itself".  A good guess is that when it is talking to itself, it
> usually calls itself 'localhost', but somehow I doubt that this is what
> you mean.
 
> Do you mean `hostname`?.  Do you mean `hostname`.`domainname` (assuming
> that domainname exists)?  Do you mean the result of canonicalizing one of
> these with a host table lookup?  or with a DNS lookup?  And in any case,
> why would you care?

My intent was to ensure that DNS matched machine x with its "real" name -
what was configured in smtp and hopefully the same as the /etc/hosts name
used for host name initialization during booting. If machine x's smtp name
mismatchs DNS's name for machine "x", won't mail delivery to "x" misfire
for example?


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

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 15:08:28 GMT
From:      lim@slc6.INS.CWRU.Edu (Hock Koon Lim)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In article <WBRAND.91May22095443@krishna.shearson.com> wbrand@aries.shearson.com writes:
>>      Does anybody know TCP/IP software which runs on VM (CMS or GCS) and 
>>   has socket interface to application?   SAS C interface is the best for
>>   us.  
>>
>>      IBM TCP/IP for VM (R1.2) does not have socket interface and also 
>>   requires IBM C for System/370 (we are calling White Smith C) which we don't
>>   want to use.         

	
	Is anyone has any network printing solution for IBM TCP/IP with MVS over
Ethernet?    I am tring to find a solution for MVS/CICS printing over the campus
network.  Currently, all the CICS printers have to attach to the IBM7171 box. All
the MVS/CICS users are using the TN3270 on a PC with ethernet interface to communicate
with the Mainframe.  However, we would like to bring the CICS printer closer to them.
Maybe through lpr/lpd if there is a way on the IBM TCP/IP for MVS.  I would like
to know all your suggestions.

Thanks,




-- 
Hock-Koon Lim, Information Network services
Case Western Reserve University; Cleveland, Ohio, USA  44106   
(216) 368-2982        lim@ins.cwru.edu

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Fri, 31 May 1991 16:12:00 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: Confirming DNS name - what I really meant

In article <895@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
>
>My intent was to ensure that DNS matched machine x with its "real" name -
>what was configured in smtp and hopefully the same as the /etc/hosts name
>used for host name initialization during booting. If machine x's smtp name
>mismatchs DNS's name for machine "x", won't mail delivery to "x" misfire
>for example?

 If this kind of mismatch were so serious, probably half of the machines on
Internet would be unable to handle mail.  Actually you can usually tell
from the syslog entries or the 'Received:' headers whether your mailer
received mail from a system whose smtp name is different from its DNS
name.  The proportion of my syslog records showing this is not very high,
but that is because most of these misconfigured systems send their mail
to another system to forward it for them.

 If you are using 'sendmail', the SMTP name is determined by the $j
macro.  With most configuration setups, the handling of mail to your
domain is dependent on the class $=w, or perhaps $=w.$m .

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 16:28:27 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

> In 1's complement arithmetic there are two ways of writing "zero". In C they
> are 0x0000 and 0xffff (16-bit).  I can't see any reason why the checksum would
> need to always come out to be nonzero (i.e. 0x0000 could happen).
> 
> Consider the 16-bit ones complement of the 16-bit ones complement sum of a
> bunch of numbers that happen to add up to 0xffff (such as, say, 0xff00 and
> 0x00ff with a bunch of 0x0000's too). Yikes! It is all zeroes.
> 
> The TCP checksum is never optional (though you can use a different one if you
> like, by supporting RFC1146-style checksum algorithm negotiation), but it is
> not clear to me that it cann never be all zeroes.
> 
> In fact, I can't figure out a way that the checksum would ever be 0xffff
> ("negative zero").  If you can think of a set of 16-bit values whose TCP
> checksum is 0xffff let me know.  Since 0xffff + 0xffff = 0xffff (and not
> 0x000), I can't figure out a sum that comes out to 0x0000 in order to get
> complemented to 0xffff by the vanilla TCP checksum algorithm.
> 
> -Johnny Checksum

An interesting observation, and not very hard to prove.

If you look at the sequence of numbers incrementing by 1 at
the wrap around point, you have:

		... FFFE, FFFF, 0001, 0002 ...

Notice that 0000 is skipped, because:

		FFFF + 0001 = 10000 = 0001.

So, the only way that the 1's sum would be 0000 would be if each of
w1 through wn were equal to zero.

If you take the 1's complement of the sequence, you have:

		... 0001, 0000, FFFE, FFFD

Which is just the sequence of numbers decrementing by 1, at the
wrap around point.

So, just as addition will never yield a value of 0000, subtraction
will never yield a value of FFFF.  Another way of stating it is that
when the 1's sum wraps, it will give you -0, when the 1's difference
wraps, it will give you +0.

If you wanted to, since 0000 and FFFF are both identity elements, if
the 1's sum was computed to be FFFF, you could replace it with 0000,
and send the 1's complement of it across as the checksum, and everything
will work just fine; on the destination machine the checksum will still
compute as valid.

In fact, if you look at the BSD udp_output() code, if the checksum
is calculated to 0000, it is replaced with FFFF to ensure that the
destination machine will verify the checksum rather than skip the
checksum.  Because the TCP checksum is required, it doesn't bother
to change 0000 into FFFF.

			-David Borman, dab@cray.com

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 17:12:59 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Confirming DNS name matches local host name

>Given an internet IP, is there a way to retrieve what the host at that IP
>actually calls itself. In other words, I want to confirm that what DNS
>says actually matches the local host name.
>
>I thought telneting in through the "smtp" port and capturing the output
>would be an option but the "smtp" output resists capture.
>
>Any help or suggestions would be greatly appreciated.

Checking the SMTP port is probably the best way - I have done exactly
what you described.  Maybe you need to move to a different platform to
capture the SMTP port output - I had no difficulty doing this with SunOS
(Unix) Telnet.

Doug Nelson
Michigan State University

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 19:33:22 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

> There are a number of maps online at nis.nsf.net in the aptly named maps
> subdirectory. They vary in degree of "obsoleteness" from being as current
> as is preactical, to being of interest only to compulsive historians.

I would hope that the winner of the "Interim NREN" contract would do a
better job that this.

--Ed

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 19:36:33 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  Charon Problems

Code ea means 'No Such Member', and isn't supposed to be returned by
this call (attach Queue server to Queue).

Is your queue server listed as a server for this queue?


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Sr. Network Engineer   Clarkson University              (315)268-2292

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 20:05:54 GMT
From:      lbrooks@shl.com (Lyle Brooks)
To:        comp.protocols.tcp-ip
Subject:   PPP and SLIP help


I'm looking for information on PPP (Point to Point Protocol) and 
possibly SLIP.  If anyone could explain them and what the differences
are and/or point me to some documentation I would greatly appreciate
it.

What I'm looking to do is have serious dial-up connectivity to a LAN, none
of this XMODEM, Kermit, terminal emulation, remote login stuff.
I'm looking to use a portable PC running UNIX and TCP/IP to dial in
to a LAN and NFS mount a file system, send mail, do host to host
communication, etc.  Because its a portable as well as cost factors, T1 and 
dedicated lines are not an alternative.

Thanks in advance, and forgive me if this is in a FAQ list.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lyle D. Brooks     			lbrooks@shl.com	
1010 N. Glebe Rd.			uunet!shl!lbrooks
Arlington, VA 22201

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 20:51:08 GMT
From:      RBNTJC@ROHVM1.BITNET (Thomas J Cozzolino)
To:        comp.protocols.tcp-ip
Subject:   Clarkson NCSA/WINDOWS3/LPR/TCPIP

Help Netters!

Does anyone know when NCSA Telnet will support Windows3?  Is there a TCP/IP
that can run under Windows, use NCSA Telnet for IBM emulation, AND use
Windows-defined printers to spool to TCP/IP-connected printers?

I know, I know, I'm asking alot, but what the heck.

Please respond to me via Internet at rbntjc@rohmhaas.com or RBNTJC@ROHVM1
via Bitnet.

Thanks for any help.

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 20:52:32 GMT
From:      dhh@hpcndpc.CND.HP.COM (David Hanes)
To:        comp.protocols.tcp-ip
Subject:   Van Jacobson's algorithms

I am trying to locate any information concerning Van Jacobson's
header prediction algorithms.  If anyone could point me in the
right direction, I would greatly appreciate it!

Thanks,
David Hanes

Hewlett-Packard
Colorado Networks Division
3404 E. Harmony Road - Mail stop 102
Fort Collins, CO  80525

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 20:56:09 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: Porting BSD telnetd to a Sun

My question was:

>For a number of trivial reasons, I'm trying to compile the BSD 4.3
>telnetd source on a Sun-3 running SunOS 4.1.  Is this possible?  Has
>anybody done this successfully?  Can anybody give me some hints?

As nearly everyone pointed out, I was using the wrong source code.  I
got /pub/telnet.91.03.25.tar.Z from ucbarpa.berkeley.edu, unpacked it,
compiled it, and ran it.  Now I've got a new, improved telnet and
telnetd.  It works great with most machines.

I've had a number of problems with PC's running various packages, so
many that I'm considering abandoning the project.  The problems are
related to telnet terminal option negotiation apparently being
performed incorrectly for unrecognized options (such as AUTHENTICATION
or XDISPLOC) on the PC side.  The bad guys are:

1. PC-NFS telnet 3.0.1.  Not a problem with Sun's telnetd.  I plan to
upgrade to 3.5 in the near future; has anybody tried 3.5 telnet or
"Advanced Telnet" with the BSD telnetd yet?

2. CUTCP telnet V2.2/NFS-A.  Likewise works fine with Sun's telnetd.
Workaround: Use CUTCP's rlogin feature in telnet to go to the host's
rlogind instead, or use the port number feature to go to either rlogind
or the old telnetd at a different port.

I've done enough debugging to convince my (perhaps gullible) self that
the PC side is at fault and that defensive reprogramming on the Sun
side would be difficult and/or violate the RFC's.  It is possible to
strip out the offending telnet options from telnetd.c (I did make it
work that way), but by that time you'll probably be close to Sun's
telnetd in terms of features supported.

An interesting fact: telnet using either 1 or 2 above to
ucbarpa.berkeley.edu WORKS!  Well, I did get a login prompt, anyway; I
don't have an account there.  Does ucbarpa's working version turn off
these options?

Of course, I could be all wrong.

Many thanks and much grateful appreciation to:

karl.kleinpaste@osc.edu (Karl Kleinpaste)
Kim H|glund <shotokan@diku.dk>
Brendan Kehoe <brendan@cs.widener.edu>
hedrick@athos.rutgers.edu (Charles Hedrick)
deraadt@cpsc.ucalgary.ca (Theo de Raadt)
Pekka.Nikander@ngs.fi (Pekka Nikander)
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 21:12:32 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip
Subject:   DNS/smpt name matching ( 90% done {:)

In article <895@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
>
>My intent was to ensure that DNS matched machine x with its "real" name -
>what was configured in smtp and hopefully the same as the /etc/hosts name
>used for host name initialization during booting. If machine x's smtp name
>mismatchs DNS's name for machine "x", won't mail delivery to "x" misfire
>for example?
 
| If this kind of mismatch were so serious, probably half of the machines on
|  Internet would be unable to handle mail.  Actually you can usually tell
|  from the syslog entries or the 'Received:' headers whether your mailer
|  received mail from a system whose smtp name is different from its DNS
|  name.  The proportion of my syslog records showing this is not very high,
|  but that is because most of these misconfigured systems send their mail
|  to another system to forward it for them.
 
|   If you are using 'sendmail', the SMTP name is determined by the $j
|  macro.  With most configuration setups, the handling of mail to your
|  domain is dependent on the class $=w, or perhaps $=w.$m .

Thanks for the clarity.  Our environment includes a mix of DNS and non-DNS
machines and I believe there were problems (don't recall which direction)
when the DNS name mismatches the smtp name.  At any rate for my own sanity,
what's left of it, I would like to confirm that the names match. 
Fortunately, the code I have received enables some nominal checking.

Again, thanks for the patience.

Regards

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

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 23:31:54 GMT
From:      WELDEN@JAGUAR.ESS.HARRIS.COM
To:        comp.protocols.tcp-ip
Subject:   Congestion AVoidance Help Needed

From:	JUNGLE::WELDEN       31-MAY-1991 15:49:07.56
To:	EXOS%"tcp-ip@nic.ddn.mil"
CC:	WELDEN
Subj:	Congestion Avoidance Help Needed


                CONGESTION AVOIDANCE WHEN ICMP CAN'T BE USED
                ********************************************

I need feedback views and experience for a network situation we are facing in
using the TCP/IP protocols in a secure application.

Hosts on IEEE 802.3 LANs connect to a Packet Encryption Device and then by an
IEEE 802.3 LAN to an IP Router and then out into a WAN to the reverse set of
eomponents. The Packet Encryption Device will be a NSA approved item and will
create a barrior between the Hosts and the IP Router. 

When congestion starts in the WAN the IP Router would normally generate an ICMP
Source Quench packet to be sent back to the source Host but the Packet Encryp-
tion Device blocks it.

I need to know if anyone else has experienced this situation and/or what solid
recommendations ca be made. We feel we must be able to slow down selected sourceHosts in order to manage congestion avoidance in the network.

Please reply to:

                welden@jaguar.ess.harris.com

Walter Elden
Harris Corp-GCSD
Melbourne, FL
407/729-3661       407/729-2855  FAX

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      31 May 91 23:59:10 GMT
From:      geertj@philica.ica.philips.nl (Geert Jan de Groot)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP question

In article <97879@lll-winken.LLNL.GOV> wiltzius@lll-crg.llnl.gov (Dave Wiltzius) writes:
>I have searched the host requirements documents, rfc1009 and other
>RFCs without finding a definitive answer to the following:  Should
>proxy ARP work only for hosts on the same network, but different
>subnets?  In particular, should it specifically *not* work between
>hosts on different networks (such as 128.100 and 128.99)?

It probably doesn't work because the 'client' (ARP-requestor) has
no reason to ARP for a host that is not on his network. Foreign
networks should be routed, not proxy-arped.

The only reason why proxy arp works with subnetting is because a
client (wrongly) assumes he can reach the other host on the same
network and therefore ARPs instead of routes. This assumption was
made by older software that did not do subnetting. I have never 
seen software that didn't route for foreign networks.

If you can get your client software to ARP for foreign networks,
then I guess proxy-arp will work.

Geert Jan


--8<--nip-nip---------------------------------------------------------------

Geert Jan de Groot, Philips ICA, Weisshausstrasse 1, 5100 Aachen, Germany
Email: geertj@ica.philips.nl or ..!hp4nl!philica!geertj
Phone: +49 241 6003 714  FAX: +49 241 6003 709

END OF DOCUMENT