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 June 1991 (461 messages, 345615 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/06.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 Jun 91 01:20:32 GMT
From:      john@actrix.gen.nz (John Vorstermans)
To:        bit.listserv.ibm-nets,bit.listserv.ibmcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Telnet from DOS - UNIX box via serial port & ethernet

I am looking for software that will allow a user dialing in via modem
to a DOS box to login to a UNIX box via a small local ethernet.

What we really need is some sort of PD or sharware program that will 
allow us to telnet from the DOS box, over the ethernet to the Unix box
which allows output via the serial port on the DOS side.

We are using WD8003E cards on an AT DOS machine connected to a 386/33 unix
running Interactive 2.2.1. and tcp/ip 1.2

Any help or advice of any sort would be appreciated.  We would also welcome
any source code that we could perhaps hack to do the job.





-- 
john@actrix.gen.nz  

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 02:01:24 GMT
From:      sfrazier@mcinix.UUCP (Steven E. Frazier)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Setting time on a SCO ODT TCP/IP System

I have just installed TCP/IP on a SCO ODT system and on SCO Unix.
I understand that you can run some type of daemon on both machines
(one machine being the master and the other being the slave) and
have the time on the slave updated, is that correct.  Could anyonne
tell me the syntax on how to do that on both machines?

Thanks very much.  Please email me your response unless others
would have the same question.

Steve



-- 
Steven E. Frazier
 (614) 761-6612
  VNET 424-6612

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 10:41:09 GMT
From:      ROMANO@IVRUNIV.BITNET (Romano Rosponi)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

Have I read right ?
Is there a TCP/IP version 2 for VM ?
(IBM has just offered us a TCP/IP V1.2 for VM).

staying in doubt...


-----------------------------------------------------------------------------
                                Romano Rosponi             +39 45 8098 474
 CCCCC  IIIII  CCCCC  AAAAA     Centro di Informatica e Calcolo Automatico
 C        I    C      A   A     Universita' degli Studi di Verona
 C        I    C      AAAAA     Via dell'Artigliere 19, 37100 VERONA - ITALY
 CCCCC  IIIII  CCCCC  A   A
                                ROMANO@IVRUNIV.BITNET
-----------------------------------------------------------------------------

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 17:58:33 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

I would suggest reading RFC's 1157, 1158, and 1159.  There is an EXCELLENT
book on the subject of SNMP - "The Simple Book" by Dr. Marshall T. Rose
(Prentice-Hall, 1990).

This is a good starting point.

		-- John

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 19:22:15 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: IBM's VNET

Dear Daniel Murphy,  VNET is the name of IBM's internal RSCS network.
There is now a gateway between VNET and the Internet.  The gateway acts
as a filtering gateway and IBM users who wish to send or receive mail
from Internet users must register themselves to this gateway.

As of this time, a great many IBMers are registered to use the gateway.
You can inquire of the gateway to find out whether a particular IBMer
is registered (and what his/her Email address is) by sending mail to
nic@vnet.ibm.com  and just including as the subject line:
  whois name
The vnet gateway will respond with mail such as the following, which I
used to find out that John Hartmann (the developer of IBM's CMS Pipelines
product) was registered for the gateway.

>Date: Fri, 31 May 91 21:18:03 EDT
>From: nic@vnet.ibm.com
>To:   LVARIAN@PUCC.PRINCETON.EDU
>Subject: WHOIS Facility
>
>Hartmann, John is john@cphvm1.vnet.ibm.com
>
>Multiple requests may be made in a single note provided they do
>not exceed the daily limit of 25.

As this example illustrates, the Internet address for most IBM VNET users
whose VNET address might be user@node would be user@node.vnet.ibm.com .

You need also to be sensitive to the Acceptable Use Policies of NSFnet
and your midlevel network, which would disallow commercial activity (such
as placing an order over the network) but would allow other messages
which were of an educational or research nature.

I hope this helps.
  Lee Varian, Princeton University

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 20:11:58 GMT
From:      mouse@thunder.mcrcim.mcgill.edu (der Mouse)
To:        comp.protocols.tcp-ip,comp.unix.questions
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.
 (Questions generally end with `?', not `.'.)
> In other words, I want to confirm that what DNS says actually matches
> the local host name.

The generally-accepted way to do this is to ask the DNS for a PTR
record corresponding to the dotted-quad address with the quads reversed
and .in-addr.arpa appended.  For example, if I see a connection from
132.206.73.1, I might do something like

	[Thunder] 106> nstest 132.206.1.1
(132.206.1.1 is the local nameserver.)
	> p1.73.206.132.in-addr.arpa
(the p means ask for a PTR record; the rest is as I described above.)
	res_mkquery(0, 1.73.206.132.in-addr.arpa, 1, 12)
	res_send()
	HEADER:
		opcode = QUERY, id = 1, rcode = NOERROR
		header flags:  rd
		qdcount = 1, ancount = 0, nscount = 0, arcount = 0
		
	QUESTIONS:
		1.73.206.132.in-addr.arpa, type = PTR, class = IN
		
	Querying server (# 1) address = 132.206.1.1
	got answer:
	HEADER:
		opcode = QUERY, id = 1, rcode = NOERROR
		header flags:  qr aa rd ra
		qdcount = 1, ancount = 1, nscount = 0, arcount = 0
		
	QUESTIONS:
		1.73.206.132.in-addr.arpa, type = PTR, class = IN
		
	ANSWERS:
		1.73.206.132.in-addr.arpa
		type = PTR, class = IN, ttl = 86400, dlen = 29
		domain name = Lightning.McRCIM.McGill.EDU
		
	> 
(and there you are: 132.206.73.1 is Lightning.McRCIM.McGill.EDU.)

> I thought telneting in through the "smtp" port and capturing the
> output would be an option but the "smtp" output resists capture.

Check out the script(1) program; if you have it, that should be able to
deal with grabbing a copy of the session.

In any case, that's not really reliable.  The name reported on the SMTP
greeting message is all too often only vaguely related to the DNS name
of the machine.  (The first part is usually accurate, but the rest is
often the local YP - oops, NIS - or netinfo domain instead of the DNS
domain the machine is in, or sometimes absent altogether.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 91 22:17:29 GMT
From:      kzm@hls.com (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP

> I would suggest reading RFC's 1157, 1158, and 1159.  

Oops, a typo.  Actually, it's 1155 (for the SMI), 1156 (for MIB-I),
1157 (for the protocol, SNMP).  1158 is MIB-II but has been obsoleted
by 1213.  1159 is on a different subject.  (And if you're a glutton
for punishment, I recommend 1212 also).

> There is an EXCELLENT
> book on the subject of SNMP - "The Simple Book" by Dr. Marshall T. Rose
> (Prentice-Hall, 1990).
> This is a good starting point.

Agreed.

Keith.

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 07:42:48 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   how to obtain OSF/DCE document eletronically?


Hi netlander,
        I have heard that there is a document describing OSF/DCE rationale.
Is it possible to obtain it thru any ftp sites? Please forgive abt my ignorance
if I mis-used this net. Thanks a lot.

- Beng Hang Tay (email:taybengh@nusdiscs.bitnet)
  Dept of Info Syst and Comp. Sc.
  National University of Singapore.

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 13:09:24 GMT
From:      carson@darwin.ntu.edu.au
To:        comp.protocols.tcp-ip
Subject:   Re Charon Problems with printing.

In article <2287@godzilla.tcs.com>, ken@tcs.com (Ken Emery) writes:
> 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
-- 
Ken ,
Try alloting your printer to a os2:lpt number and it may work,
I had trouble printing from windows on an appletalk net and was able to
print when I selected os2:lpt2 and it printed fine then.

________________________________________________________________________
 *__ |\  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"	
________________________________________________________________________

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 18:15:28 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

>        Is anyone has any network printing solution for IBM TCP/IP with MVS
Version 2 of the IBM TCP/IP code for VM and MVS include lpr/lpd support.

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 20:11:16 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: Congestion AVoidance Help Needed


      Walter,

   My comments are based on the assumption that you are using a device
similar to the Xerox Encryption Unit (XEU) or the Motorola Network
Encryption Unit (NEU).  These devices encrypt everything but the link
level (Ethernet) header.  I know that there are people banging on NSA to
approve devices which encrypt starting at the IP data portion, but I
have not heard that NSA has approved anything, or even that they plan to
do so.  As a consequence, it is not possible to have the IP router route
the packets over the WAN -- the IP and higher layer data (data portion
of the Ethernet frame) is cryptographicly secured -- unless the router
itself is connected using one of these devices and running system high.

   Since you mention the congestion as being on the WAN and that you
expect the encryption devices to provide a barrier, the encrypted hosts
can safely ignore the router's traffic.

   As for the local network, the encryption units are slow enough that I
am not too concerned about congestion.  We have looked at both devices
mentioned above.  The packet rate is a function of packet size and
configuration options, but something like 200 packets per second through
the device is a reasonable number to use. The filtering rate is better
than that, though my recollection is that it is still not great (2000
packets per second ???), but I am at home now and cannot verify the
number.

   Umm, upon rereading your note, I am beginning to wonder what it is
you are trying to do.  I now have the impression that you want hosts on
Ethernet segments on opposite sides of the WAN to be able to talk to
each other.  Note that the devices mentioned above encrypt the entire
data portion of the Ethernet frame. As a consequence, only the Ethernet
header is visible outside of your secure domain.  Any routing decisions
must therefore be based on the Ethernet header information (layer 2)
unless the routing device fully participates in the secure domain.  If
the router participates in the secure domain, then it must itself have
an encryption unit inline with it's Ethernet attachment, and must run
system high.  You will also need some sort serial line engryption (ala
KG equipment) to re-encrypt the data going onto the serial line.  If you
then want to share the serial line with unencrypted traffic, you will
need something to multiplex the two streams together.  This is the sort
of thing we are currently doing within Ballistic Research Laboratories
and the Army Supercomputer NETwork (my team is currently responsible for
both).  ASCII graphics to the rescue:


              |                                            |
    SH1--XEU--+                                            +--XEU--SH2
              |                                            |
              +--XEU--SR1--KG                KG--SR2--XEU--+
              |              \              /              |
         UH1--+               MUX---^v---MUX               +--UH2
              |              /      WAN     \              |
              +-----------UR1                UR2-----------+
              |                                            |
            LAN1                                         LAN2

   'S' means secure, 'U' unsecure; 'H' is host and 'R' is router.  'XEU'
is the Ethernet packet encryption unit, and 'KG' is one of the standard
NSA approved serial line units.  `MUX` includes the device for mixing
the two data streams, as well as any CSU/DSU equipment.  'WAN' is
obvious -- it is how you are likely to feel when you realize you need
two routers on each end of the wire ;-) -- and the LAN's are the
respective Ethernets.  Again, note that all of the secure hosts and
routers will be running system high, and will have to be appropriately
secured.

   Finally, it is worth noting that there are several integrated CSU/DSU
boxes around which can split the circuit into two pieces.  At T1 rates,
I know of units from Larse, Verilink, and Avanti.  We have tested the
Larse and Verilinks units, but not the Avanti.  The only negative so
far was with the Verilink -- when splitting the line, it does not do
elastic buffering.  Instead it strobes the clock line when it wants a
bit.  Verilink chooses to call this a "gapped clock" -- I kid you not.
For some equipment this is not a problem, but for other equipment,
especially that which attempts to synchronize a local oscillator with
this signal, this simply does not work.

				Later,
				    Bob 
   --------
IP: reschly@BRL.MIL   UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly
U.S. Army Ballistic Research Lab. / Systems Eng. & Concepts Analysis Div. /
Networking & Systems Dev. Team / Aberdeen Proving Grounds, MD  21005-5066 /
ATTN: SLCBR-SE-A (Reschly) //   (301) 278-6808   FAX:-5075   DSN:298-

****  For a good time, call: (303) 499-7111.   Seriously!  ****

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 20:48:25 GMT
From:      sra@lcs.mit.edu (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

One algorithm for computing the ones-complement checksum on a
twos-complement machine works by explictly computing a sum modulo
0xFFFF.  The actual summation can be done in a larger word, and the
properties of the ones-complement sum can be preserved by occasionally
subtracting some large multiple of 0xFFFF.  The final step of this
algorithm returns the ones-complement of the quantity (sum mod
0xFFFF).  Thus, this algorithm will always return 0xFFFF instead of
0x0000.  So, at least in this case, making 0x0000 the excluded value
makes sense.

On certain machines (eg, the PDP-10, where normal fixed-point
arithmetic operates on 36-bit words) this is by far the easiest way to
compute the checksum, because the loop can sum 32-bit quantities
instead of 16-bit quantities without changing the result.

For those interested in the nitty-gritty, here's the UDP checksum code
from the CHIVES domain resolver.  The macro L32INT() obtains a 32-bit
integer from a 36-bit word; this involves some bit-shifting, but you
can think of it as a simple array reference.  ZERO_MOD_0xFFFF is the
largest multiple of 0xFFFF which can be represented as a positive
36-bit twos-complement quantity.

The basic algorithm is from the checksum routine in the ITS monitor.

  int udp_chksum(pkt)
      char *pkt;
  {
      int n, sum, *u;
      struct ip_header *ip_h;
      struct udp_header *udp_h;

      /* Initialize pointers, compute data length */
      ip_h = IP_HEADER(pkt);
      u = (int *) (udp_h = UDP_HEADER(pkt));
      n = ip_h->len - (ip_h->ihl * 4);

      /*
       * Initial sum is pseudo-header:
       *  IP source and destination addresses
       *  IP protocol number
       *  UDP data length (which gets added again part of UDP header!)
       * plus whatever bytes are in the last word of the packet buffer.
       */
      sum = ip_h->sh + ip_h->dh + ip_h->pro + udp_h->ln
	  + (L32INT(u[n/4]) & (~0 << (8 * (4 - (n % 4)))));

      /* Sum everything else, folding when necessary. */
      n /= 4;
      while(--n >= 0)
	  if((sum += L32INT(*u++)) < 0)	/* Carried into the sign bit? */
	      sum -= ZERO_MOD_0xFFFF;	/* Yeah, fix that */

      /* Final folding, return complement. */
      return((sum % 0xFFFF) ^ 0xFFFF);
  }

--Rob Austein

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 21:14:15 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP software on VM

> >        Is anyone has any network printing solution for IBM TCP/IP with MVS
> Version 2 of the IBM TCP/IP code for VM and MVS include lpr/lpd support.

That's incorrect.  Only the VM version has it.  It's only a "future
direction" for the MVS version.

Interlink's SNS/TCPaccess for MVS has an LPD server.

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 21:42:40 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Proxy ARP question

>If you can get your client software to ARP for foreign networks,
>then I guess proxy-arp will work.

On many systems, declaring ones self as the default router will cause the
system to ARP for *all* addresses, i.e.

# /etc/route add default `hostname` 0

will do the trick.
--
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

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 91 21:52:04 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: Confirming DNS name - what I really meant

If the system you're interested in has an SNMP daemon running, then

% snmpget w.x.y.z public system.sysName.0

will usually do the trick. "public" is the community name for the SNMP
agent; this is the sort-of default and will work unless the admin folks
deliberately changed the configured community name.

If no daemon is running, or the community name is wrong, the request will
time out.
--
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

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 00:01:58 GMT
From:      tad@wrq.com (Tad Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In article <1991May28.221045.27724@Think.COM> barmar@think.com 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.

  Actually, on HP 3000s (at least) the TCP checksum *IS* optional.  Not that
  this makes it "legal", but in the "real world" we do want to work with
  existing implementations.  Such HP implementations definitely exist.

  My understanding of the optional UDP checksum is that a bug in BSD 4.2
  would prevent UDP packets with checksums from being understood (I forget
  if the bug was on the sending or the receiving side).  In any case, most
  implementors would turn off UDP checksumming (i.e. send 0000) in order to
  not hit this bug.

  In answer to the original question, I think that HP is unique in permitting
  TCP checksumming to be turned off.  On *incoming* TCP sessions, a 3000 will
  decide to use real checksumming if the incoming SYN packet has a real
  checksum and will use a checksum of zero if the incoming SYN packet has a
  zero checksum (if checksumming has been turned off on the 3000).
  On *outgoing* sessions, the 3000 will use a zero checksum when checksumming
  is off.  As expected, this can cause interoperability problems with non-HP
  systems.

Tad Marshall -- software developer -- Walker Richer & Quinn, Inc.  Seattle, WA

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 01:41:09 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange slowness


There are many possibilities when it comes to networking slowness.

Obviously, slower systems talk slower. What might not be so obvious is
that sometimes faster systems end-up talking slower to slower systems
that slower systems do. When this happens you can see a large number
of retransmissions on the sending system. 

The slower system could be the destination, or perhaps an intermediate
router. Check rtxs on the Intergraph - particularly if is is equally
sow talking with other systems 'on the other side' of the PC router.

On newer TCP/IP's, things like 'fast rtx' and VJ congestion control
and avoidance can help overcome 'deficiencies' in paths (slow links,
routers, etc...) Ask your local Intergraph rep if there is 'fast rtx'
or VJ on the system. On such systems, you may still see many rtx's,
but the rates will remain higher.

If you really want to get your hands dirty, stick an analyser on
the wire(s) and trace a few conections.

More gory details can be had via email...

rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | "It's so fast, that _______" ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 04:00:30 GMT
From:      baw@terminator.cc.umich.edu (Brian Wolfe)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   PC TCP/IP packages

I am posting this for a friend who doesn't have access to news
posting, his address is  ddurbin@rpslmc.edu

Brian
----------------------------------------------------------

I am beginning the process of evaluating several commercial and public
domain PC based TCP and NFS software packages. Those I know about are PC-NFS
from Sun, FTP's PC/TCP, Wollongong's Pathway, and Beame & Whiteside. Does
anyone know some other packages I should be looking at?

Thanks,

Dave Durbin
ddurbin@rpslmc.edu



--
Brian Wolfe                    Internet: brian@rpslmc.edu
Rush Medical Center            Voice:    (312)-942-5781
Chicago, IL 60612 	       FAX:      (312)-942-2114 

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 06:11:17 GMT
From:      siemion@milton.u.washington.edu (John Siemion)
To:        comp.protocols.tcp-ip
Subject:   Synoptics LAN Hardware - any experienced designers?



Does anyone have any experience with using Synoptics LAN hardware?

I am interested in this because in the job I just started, the 
management has managed to toss a gigantic project my way for the design
of LANs using Synoptics concentrators, Cisco routers, Vitalink bridges, 
Appletalk, Apollo and IBM Token Ring, Ungermann Bass file server LANs,
Catia graphics stations/networks, plus other stuff...

I am very experienced in LAN technology, but I am not up-to-speed on
the latest equipment and design issues for the hardware listed above   
(especially the Synoptics stuff itself.)

Any experienced LAN designers, administrators, etc. have any suggestions
or design advice?  Particular ways to research this best?

Thanks.  Please reply by email.

John Siemion  :-)

Email: siemion@u.washington.edu

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 07:46:24 GMT
From:      PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Vance Morrison's brouter

On Sun, 2 Jun 91 09:48:56 EDT Grant R. Guenther said:
>Has anyone worked with Vance Morrison's experimental brouter ?  (It's in
>pub/pcroute/exp on accuvax.nwu.edu.)  In particular, I'd like to know if
>it has been tried with DEC's LAT protocols.

Vance's PCROUTE older versions related to experimental bridging in commented
out include files. I am not sure of the latest, but the doc doesn't refer to
bridging. Now, he has made a PCBRIDGE, and I think this one is only bridging.
So, is there a third one? Sorry to ask more than answer.

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

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 11:31:30 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting time on a SCO ODT TCP/IP System

You can use the "timed" daemon to synchronize time between systems.  There is
a man page for timed on SCO ODT.

If you need something more robust (and standard), you can use Network Time
Protocol and a radio clock (WWV, WWVB, or GPS).  We are in the process of
porting xntpd to SCO Unix - it is a non-trivial task, as we are discovering.

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 12:09:30 GMT
From:      John_A_Pham@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   where can I get all the RFC files in one tar file?

I'm looking for a ftp site that carry all the known RFC docs in one
tar file, is there such a site out there?
Thanks,
John

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 13:11:39 GMT
From:      aprm%gd@SHAFTER-EMH2.ARMY.MIL (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   When will DDN switch to GOSIP?

Text: 

The Army Small Multiuser Computer (SMC) contract, awarded to EDS,
uses TP4 for the transport layer and supports Intel's OpenNET and the
new GOSIP protocols.  TCP/IP is not on the contract, but DDN
connectivity hardware and software are.

Is DoD making a move to change DDN from TCP/IP to GOSIP? If so, what is
the timetable?

  --Gary Dunn
    U.S. Army USARPAC DCSRM IMO

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

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 14:17:02 GMT
From:      jc@netrix.nac.dec.com
To:        comp.protocols.tcp-ip
Subject:   What are the rules for Object Instances?

Here's my dumb question of the week: We have a bunch of people working
with  SNMP,  and  one  thing  that  has people confused is the "Object
Instance", which apparently is the name for the  funny  zero  that  is
appended to most (but not all) Object Identifiers.  We have determined
by experiment that with various agents lurking about on  the  network,
this  extra  zero octet is sometimes required, sometimes optional, and
sometimes forbidden.  But we haven't yet intuited the pattern, and TFM
(the  RFCs,  Marshall  Rose's  "Simple Book", etc.) seem to think that
this is so obvious that it isn't worth explaining. It isn't obvious to
us, and existing agents seem to follow a variety of rules.

Does  anyone  know  what the rules are for the use of this extra zero?
When is it required?   When  is  it  forbidden?   Or  is  it  just  an
idiosyncracy of the various agents?

Also,  since  it  is  (in  our  experience)  always  zero, is there an
explanation (other than sheer perversity ;-) that it is there at  all?
Can it ever be nonzero?

For instance, many agents require that the sysDescr  be  requested  as
43.6.1.2.1.1.0  or  they  won't  respond,  while others don't need the
zero.  (Some will also accept 1.3.6.1.2.1.1, but  that's  a  different
problem.  :-)  There seems to be no obvious meaning to multiple (i.e.,
different) values for this variable, so why would an instance ever  be
needed?

Is there some rule in the RFCs that covers this, so we  can  point  at
some of the agents and say "You're doing it wrong" and possibly get it
changed so they're all the same?  Or is it just a  weirdness  that  we
have  to  learn  to live with?  It ain't easy writing clients when the
agents out there are inconsistent.  But maybe  if  we  understood  the
rules better...

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 16:38:41 GMT
From:      mleech@bnr.ca (Marcus Leech)
To:        comp.protocols.tcp-ip
Subject:   Authenticated SMTP, anyone done one?

Has anyone done an authenticated SMTP, and if so, is there an RFC in
  existence that describes it?

What I have in mind is something like the following:

Assume that there's a secure/authenticated channel between the User Agent
  and the MTA (sendmail or its equivalent). When the MTA establishes a
  connection to another SMTP MTA, that MTA issues a "challenge" or something
  to authenticate the transaction.  Anyone done one?

I realize that this breaks the existing SMTP philosophy of allowing any
  SMTP to connect to any other.  I'm thinking of corporate internets, rather
  than "the INTERNET".


-- 
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 17:14:44 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Congestion AVoidance Help Needed

In article <9106012137.AA20860@ucbvax.Berkeley.EDU> WELDEN@JAGUAR.ESS.HARRIS.COM writes:
>
>                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.

Well, there are a lot of people who believe that Source Quenches are of
very limitied utility, and that modern transport implementations (e.g.
Slow-Start TCP) can do a good job of adapting to congestion by monitoring
the loss of packets.  Source Quenches themselves can easily be lost
during congestion, and many routers rate limit the number of Source
Quenches generated anyway.

Art

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 17:46:11 GMT
From:      crom@cbnewsb.cb.att.com (michael.crom)
To:        comp.terminals,comp.protocols.tcp-ip
Subject:   AT&T 750CX & SLIP/PPP


Recently, we received 2 AT&T 750CX color X terminals.
Anyway, these terminals are 1024 x 768, color, have an ethernet AUI port,
and an RS-232 port (they also have mouse, keyboard, monitor, etc!).

By default, they use the ethernet port for communications.  That's fine
for in the office, where there's coax, but we need to take these
things where there is no network.  Supposedly, they can be set up
to run SLIP (according to the glossy info sheets).  After playing with
the terminal a bit, it seems like it should do both SLIP & PPP, which
is great.  There is a setup window where you can say the serial port
can either be unused, run as a dumb 'modem window', or can run SLIP/PPP.

Running as a dump 'modem window' works just fine -- one can talk with a
host or with the modem, and act like a vt100 terminal.
Of course, it's just plain ASCII at this point.

Selecting the SLIP/PPP option on the setup window doesn't seem to do anything.
After rebooting the terminal, just the 'services' window comes up.

How can you talk to the modem to initiate a call, or login in to startup
SLIP or PPP on the remote host?


e.g.:  How do you run SLIP or PPP on the AT&T 750CX terminal?


			- Mike Crom
			AT&T Network Systems
			Lisle, IL
			crom@vogon.att.com
			att!vogon!crom
			attmail!mcrom

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 18:39:05 GMT
From:      jbreeden@netcom.COM (John Breeden)
To:        comp.protocols.tcp-ip
Subject:   Printing to a terminal server

Does anyone know of a piece of code that will allow a Unix print queue
to be redirected to a terminal server via telnet (like the peice of
code that xyplex supplies with their terminal servers?). I'm trying to
provide the same type of print services with a non-xyplex terminal
server, hoping that someone has already invented this wheel).

Thanx in advance;

-- 
 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."

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 19:28:27 GMT
From:      poorman@convex.com (Peter W. Poorman)
To:        comp.protocols.tcp-ip
Subject:   Re: Printing to a terminal server

In <1991Jun3.183905.12329@netcom.COM> jbreeden@netcom.COM (John Breeden) writes:

>Does anyone know of a piece of code that will allow a Unix print queue
>to be redirected to a terminal server via telnet [...]

Check out "tcpf".  Available as C source for UNIX from "ftp.cisco.com".

This generally relies upon the capability of CISCO routers to open a raw
TCP stream to a terminal port.  It ought to work with other brands as well,
assuming they have a similar capability.

--Pete
  poorman@convex.com

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 19:46:09 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.protocols.tcp-ip
Subject:   SIGIOT ignored in Sun DNS

Hello,

Does anyone know if Sun has implemented the SIGIOT signal to generate
nameservice stats?  I find no trace of it in Sun documentation and
the signal is apparently ignored.

Any information appreciated.

Thanks,

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

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 20:23:13 GMT
From:      chen@cunixf.cc.columbia.edu (Bill Chen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP stack


Does anyone know where I might be able to get a TCP/IP stack
(shrink-wrapped or PD is okay) for a SPARC based embedded system?  Any
pointers as to where else to look would also be appreciated.  Thanks.

- bill
_____________________________________________________________________
William Chen		chen@cunixf.cc.columbia.edu
Network Planning	212-854-7593
Columbia University	

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 20:32:54 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   KA9Q as dialup IP Router?

I am interested in the possibility of using KA9Q to provide the
function of a dialup-IP router between distant TCP/IP networks,
using the "ppp" 
protocol and with the dialup connection being 
automatically established and broken, as and when required.
I would prefer to take this approach than to install the "dialup-IP"
unix package at each end (mainly because one end isn't unix!).
However, I find the KA9Q documentation a bit hard to com to grips with.
I would be grateful for guidance as to whether this is possible and
some suggestions for how to go about it, please.
Thank you
Andrew Hardie
-- 

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

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 21:17:44 GMT
From:      jonson@SERVER.AF.MIL (Lt. Matt Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Diving into TCP/IP again... need help finding docco...

<Peter da Silva writes>
> Subject: Diving into TCP/IP again... need help finding docco...
> Message-Id: <COGBBWG@xds13.ferranti.com>
> 
> machines on it... including some Unisys 1100s that only support the basic
> DDN suite. Any hope of getting them to use a nameserver?
>
The trick in the AF (we have a bunch of 1100s, which, in some cases act
as "e-mail hosts") is to use the nameserver as a forwarding agent.  The
1100 style mail will use a header like
	131-16-2-1::mailbox
which tells it to send to mailbox@131.16.2.1.  If you know a hostname, bounce
the mail off a host that knows how to resolve hostnames, e.g. your nameserver
host.  Let's say your nameserver host is 192.30.100.1 and you had Internet
connectivity and want to send to me from the 1100.  Cheat and do this:
	192-30-100-1::jonson@server.af.mil
Not pretty, but it will work.  If you have any more in depth questions about
1100s, I can put you in touch with the AF Gurus.  I generally avoid those 
machines because they are about as friendly as holding a snake in the hand.


/matt
-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

Any opinions herein are my own, and do not represent official AF views.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 21:21:42 GMT
From:      henryc@oar.net (Henry Clark)
To:        comp.protocols.tcp-ip
Subject:   Xnetdb v2.02 now available


This is to announce the availability of xnetdb version 2.02 (the current 
version being 2.01).  Major improvements/additions from v2.01 -> v2.02 
include:

*  assorted bugs fixed

*  support for hosts has been added

*  a graphical traceroute function has been added

Xnetdb may be obtained via anonymous ftp from thor.oar.net (131.187.1.135)
in the /pub directory.  I've included a bit of the man page below.

I'm also in the process of setting up a mailing list for those interested
in using xnetdb.  Drop a note to me (henryc@oar.net) and you'll get added.

Henry

----

DESCRIPTION
     Xnetdb is a network monitoring tool based on X  Windows  and
     SNMP  which also has integrated database and statistic view-
     ing capabilities.  Xnetdb will  determine  and  display  the
     status  of  routers and circuits it has been told to monitor
     by querying the designated sites and displaying the  result.
     Additionally,  it also has integrated database functionality
     in that it can display additional information about  a  site
     or  circuit  such  as the equipment at the site, the contact
     person(s)  for  the  site,  and  other  useful  information.
     Finally  it  can  gather  designated statistical information
     about a circuit or router and display it on demand.

OPTIONS
     -v        This enables the verbose mode of xnetdb.  This  is
               useful only when used with the -monitor option.

     -monitor  This enables the monitor mode of xnetdb  in  which
               it  will actively query routers to determine their
               status and update the map to reflect that  status.
               The  default  is not to monitor so that unecessary
               SNMP traffic is avoided.

     -display host
               This will display  the  xnetdb  map  on  the  host
               specified.

     -cpath path
               This gives the path in which it will find  all  of
               the  xnetdb  configuration  files.  Note that this
               defaults to the setting in the xnetdb.h  file  set
               at compilation.


USING XNETDB
     Invoking any of the  database  or  statistics  functions  is
     merely  a  function of pressing the left mouse button on the
     proper item and selecting the choice of  interest  from  the
     menu.   For  example,  to  invoke  the router menu, move the
     pointer on top of the router  you  desire  more  information
     about  and  the  press  the left mouse button, to invoke the
     circuit menu press the left mouse button on top  of  a  cir-
     cuit, and to invoke the summary/stats menu to press the left
     mouse button anywhere  else.   To  quit  xnetdb,  press  "q"
     within the xnetdb window.


CONFIGURATION FILE
     The configuration file xnetdb.cf specifies all of the things
     that  you  want  xnetdb  to  monitor and/or keep information
     about.  There are three types of things which can be 
     configured into the file - routers, hosts, and variables.

     ROUTER <path> <routername> <mapname> <ipaddress> <community>
        The <path> entry specifies the  path  into  the  database
        where  xnetdb can find information about the router.  The
        <routername> entry specifies the name of  the  router  in
        the  database.   The  <mapname>  entry specifies the name
        which will be displayed on the xnetdb  map.   The  <ipad-
        dress>  entry  specifies  the  ip  address of the router.
        Finally, the <community> entry specifies the SNMP commun-
        ity name to use when querying the router.

     HOST <path> <hostname> <mapname> <ipaddress> <community>
        The <path> entry specifies the  path  into  the  database
        where  xnetdb  can  find information about the host.  The
        <hostname> entry specifies the name of the  host  in  the
        database.   The  <mapname> entry specifies the name which
        will be displayed on the  xnetdb  map.   The  <ipaddress>
        entry specifies the ip address of the host.  Finally, the
        <community> entry specifies the SNMP  community  name  to
        use when querying the host.

     VARIABLE <rtraddr> <variable> <variabletype> <community>
        The <rtraddr> entry is the ip address of the router.  The
        <variable>  entry  is  the  name of the snmp variable you
        wish to monitor.  The <variabletype> entry is the type of
        the variable that the agent will return (such as Integer,
        IPAddr, etc.).  Finally, the <community> entry  specifies
        the SNMP community name to use when querying the entity.


CONFIGURATION FILE SAMPLE
     #
     #  Area 1
     #
     ROUTER Backbone/POP1    RTR1    Router1       1.2.3.4   public
     ROUTER Backbone/POP1    RTR2    Router2       1.2.3.5   public
     ROUTER Sites            Site1   Site1         1.2.3.6   public
     #
     #  Important Host
     #
     HOST Site/Site1   Host1  BigMachine  1.2.3.7  public
     #
     #  Monitor the default route
     #
     VARIABLE  1.2.3.5  1.3.6.1.2.1.4.21.1.1.0.0.0.0      IPAddr   public

----
Henry Clark                      Network Guy, OARnet
Ohio Supercomputer Center        Email: henryc@oar.net, Phone: (614) 292-6483 
1224 Kinnear Rd.                 
Columbus, OH  43212              #include <disclaimer.h>
-- 
Henry Clark                      Network Guy, OARnet
Ohio Supercomputer Center        Email: henryc@oar.net, Phone: (614) 292-6483 
1224 Kinnear Rd.                 
Columbus, OH  43212              #include <disclaimer.h>

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 21:34:06 GMT
From:      kwe@bbn.com (Kent W. England)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

In article <1991May28.212310.23424@Spies.COM> joshua@Spies.COM (Joshua 
Geller) writes:
> 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. 
> 
> Hey, I'd settle for one of the backbones. Backbones and regionals would 
 cause
> me to literally faint in ecstatsy. 

Even that is not so simple as it would seem.  For example, only a few 
people have actually seen a topology map of the new NSFnet T3 backbone.  
The public maps I see are a little "cloudy".   I'm not complaining, mind 
you, just noting that maps are hard for a number of reasons.

I think there is a IETF mapping working group underway or soon to happen 
that will be addressing some of the technical issues related to maps of 
the Internet.  But topology mapping is never going to be easy and topology 
maps are not routing maps, which is what most people really need to see.

--Kent

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 21:35:01 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   B&W, FTP, Intercon, Interlink, and TGV Utilities Agreement

In UNIX Today!, May 13, 1991, on page 10, there is a very
interesting article that discusses a project by the five
subject companies to develop a full-function network operating
system on top of TCP/IP.  I'm very interested in hearing more
about this project if any of the players involved would like
to share, either privately or publicly.

After reading the article, a number of questions come to mind:

1) Why did this group choose to create its own authentication, timing,
and other basic services?  Why not just implement the OSF services?
Was the desire to have a completely public-domain alternative to
the OSF services?

2) Why is Sun absent from the list of sponsoring companies?  
Since you are using their RPC for these services, it seems
like they have a lot to gain (publicity-wise, at least).

3) The article says that the initial project concentrates on mail
and print services.  Can someone explain exactly what is being done
here, and why are SMTP/POP and LPD-type utilities not sufficient
for the desired purpose?

This strikes me as an interesting agreement, somewhat in the spirit
of FTP's initial packet-driver effort.  With strong support from the
user community it might just succeed.

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 21:50:54 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's algorithms

In article <810026@hpcndpc.CND.HP.COM>, dhh@hpcndpc.CND.HP.COM (David Hanes)
 wrote:
>I am trying to locate any information concerning Van Jacobson's
>header prediction algorithms.

It's in RFC 1144.

-- 
<skl@wimsey.bc.ca>

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 22:47:46 GMT
From:      sfrazier@mcinix.UUCP (Steven E. Frazier)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   SLIP Speeds SCO

Speed on SLIP Lines.  If I had two unix machines and wanted to run
SLIP between them, could I run at 56K speed?  What would be the negatives
to it.  In other words, the async ports would have to be able to run at
56K, who makes multi port cards capable of 56K? I am curious about the
pros and cons of this.  Please email me your responces on this and let
me know if anyone is doing it now.

Thanks in advance

sfrazier@mcinix.vlink.com

 
-- 
Steven E. Frazier
 (614) 761-6612
  VNET 424-6612

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 22:53:57 GMT
From:      vturner@nmsu.EDU (Turner)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac.hardware,comp.sys.mac.comm
Subject:   Help!  Classic with a NuvoLinkSC interface won't RARP

Sorry to post this to so many groups, but I wasn't sure where to place it, and
I'm really stuck (along with NuvoTech Technical Support).

I'm running a Mac Classic with system 6.0.7, MacTCP 1.0.2 or 1.0.1 (either
one fails), NuvoLink SC 1.3.1, and Ethertalk 1.2.2 (phase I).  No inits of
any consequence.

So here's the story:  If I assign manually from MacTCP, all is well, and BYU
Telnet 2.3.4 comes up ok.  If I assign dynamically, The mouse hangs on the
opening screen of telnet.

I've tried the interface on a MacSE also, and it fails the same way.

I can see zones, and print to printers, etc.

I have checked and rechecked the ethernet number as it appears in the 
NuvoLink SC Setup application, and the entry is correct in the tables.

Other macs and PCs (one mac with an Asante card) can rarp fine on that
segment, so rarpd servers are answering the requests.

Does anyone have any suggestions?

I'd really appreciate any help anyone could give.  Is anyone out there
experiencing the same problem?  Or has anyone gotten this type of setup to
work with MacTCP assigning dynamically?

Any help would be greatly appreciated,

Thanks,

Vaughan

--
                     VaughAn Turner     Internet: vturner@nmsu.edu
     Networking/Workstation Support     Box 30001, Dept. 3AT
    Computer Center, Networking/WSC     Las Cruces, New Mexico
        New Mexico State University     88003-0001
               Bitnet: vturner@nmsu     UUCP: ucbvax!nmsu.edu!vturner
  Work: (505) 646-4244     FAX: (505) 646-5278      Home: (505) 522-3653

     Home Address: 1115 Larry Drive     Las Cruces, New Mexico 88001-5457

"...the first rule of engineering [is] to work with Earth's natural forces,
never against them."
                                                     "Earth"  by David Brin

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 91 23:55:16 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

jim@cs.strath.ac.uk (Jim Reid) writes:

[cross-posted to prime the flame war again...]

>In article <1367@exua.exeter.ac.uk> SAMcinty@exua.exeter.ac.uk (Scott McIntyre) writes:
>Resistance to change is a factor, but not a major one. What is more
>significant is that there is little expertise in the UK with running a
>national IP based network and it is the lack of suitably qualified and
>experienced people that makes things more awkward than they already are.

Yes and then again no Jim. [who me? equivocate?]

There was no experience of running a national IP network in Australia
and substantial experience with the VMS JANET code. From this base, a
national MULTI-PROTOCOL network  but primarily IP based was established
in under 1 year, and runs very very successfully.

I'm sorry to disagree with you publically Jim, but doing TCP/IP is
actually almost completely trivial. Nobody is obliged (or actually
should) connect to a backbone until they are compliant with the
standards (have a valid IP subnet, understand the DNS and routing) but
that doesn't prevent the backbone being created in a VERY short space
of time. Having done that, growth is pretty simple.

Based on my experience (pre 1987) IP introduction in JANET is almost
completely blocked by politics and bullsh. Technical issues are
smokescreens. The truth in your statement is that there is woeful ignorance
in UK campii about IP networking point blank.  Its not ignorance of running
a NATIONAL IP network, its ignorance of even running CAMPUS IP networks.

We did it here in under a year. Its run by a 2-man team in Canberra and
the goodwill of computer centres across the nation. Off-the-shelf technology,
code built into virtually ALL *nix, available for VMS, VM, No mess, no
fuss, no worries mate!

	-George

-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 00:08:55 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the rules for Object Instances?

I would have responded directly to the questioner, but the address full of !s
and dec.coms scared me off.  Besides, the answer may be of general interest.

SNMP object instancing is designed to be simple and regular, so, in a sense,
every object has an instance identifier, whether it can actually have multiple
instances or not.  To completely identify the object, that instance identifier
goes on the end of the object identifier.  For an object with only one
possible instance, such as sysDescr, the instance ID is 0.  For an object with
multiple instances, such as ifSpeed, the instance identifier suits the object
and is non-zero.  The instance identifier for an interface is ifIndex, a small
integer, which gets tacked onto the end of the ifSpeed object identifer to say
which instance you want.  A zero on the end of ifSpeed is not valid.  A
non-zero on the end of sysDescr is not valid.

So why is the observed behavior confusing?  It may be bugs or it may be agents
that are trying to be extremely tolerant.  It also may be the difference
between get and get-next.  Strictly speaking, for get and set you must supply
the entire object identifier, including instance identifier.  On the other
hand, get-next is so powerful, you can leave off as much of the object
identifier as you want to, and the agent will find what's lexically next.  A
handy result of this power is that you can get-next an object identifier with
the instance completely missing, and get-next will return the first instance
of that object.  Using that full object identifier in your next get-next will
get you the 2nd instance, and so on until there are no more instances and
you'll get whatever lexically follows the last instance.  You can thus
discover all the instance identifiers.

I hope that helps.  Once you're immersed in this stuff it's easy to forget
what it took to get that far under.

	Bob

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 00:44:03 GMT
From:      stu@tandem.com (Stuart G. Phillips)
To:        comp.dcom.lans,comp.protocols.tcp-ip,rec.radio.amateur.packet
Subject:   WIRELESS-DIGEST: Week ending 6/1/91

==============================================================================
Weekly digest for WIRELESS mailing list

Week ENDING June 1, 1991

This digest (or back issues) can be obtained by anonymous FTP to tandem.com
from the wireless directory.

The file wireless/wireless explains the purpose of the mailing list and
describes how to subscribe and post.

The WIRELESS mailing list is moderated by Stuart Phillips and Kevin Rowett.
==============================================================================

From: Stuart G. Phillips <stu@tandem.com>
Message-Id: <9105261841.AA26058@suntan.Tandem.COM>
Subject: Effects of multi-path propagation

There have been several recent papers (I can dig out the references if
anyones interested) both as submissions to the IEEE 802.11 committee and
the IEEE Trans. Comm on the amount of jitter caused by multi-path 
distortion.  Some of the work has been done by the cellular folks, the
rest by those working on Wireless LANs.

Although the cellular folks were working over terrestial paths of a few
kilometers and the WLAN folks over a few tens of meters, the results are
remarkably similar.  Multi-path distortion results in jitter between
100 and 200 nS.

A good analysis of the effects of muli-path propagation on jitter can be
found in IEEE 802.11/91-3 (Radio System multipath propagation analysis
leading to possibilities for mitigation - Chandos Rypinski).

To cut a long story short, multipath propagation results in two distinct
problems - fading and intersymbol distortion.  Some of the effects can
be overcome by diversity reception (using two or more antennas) but there
seems to be a fundamental issue.  Given 100-200 nS of jitter it would
seem to suggest that Wireless LANs are restricted in bandwidth to
something between 256 Kbps and 1 Mbps (assuming a jitter to data period
ratio of 10:1 or similar).

The simplest way to reduce the effects of multi-path propagation is to
use optical (line of sight) paths with narrow beamwidth antennas.  I 
suspect this is partly how Motorola gets its claimed bandwidth (being
at 18 GHz probably helps too :-) !

There are several products on the market that claim higher bandwidths
than my postulated 256 K - 1 Mbps range.  It would be interesting to
see the results of some field trials and the types of BER that result.

Does anyone have any results they would share or any comments (rebuttals
are fine too !) on the limitations on bandwidth resulting from multi-path ?

Stuart

BTW, the WIRELESS mailing list is now some 80 folks strong as of today !

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

From: "Jonathan M. Zweig" <zweig.PARC@xerox.com>
Date: 	Tue, 28 May 1991 10:12:35 PDT
Subject: Re: Effects of multi-path propagation


What is the characterization of the 100-200 nS jitter? When I use the term
jitter (I usually work in internetworking) I mean it as something like "the
uncertainty in how long it will take a packet to reach its destination." That
is, it may take 100 mS with a 20 mS jitter (whether this means 80/120 or
90/110 as the limits is another issue) to get through.

But in radio, I think the term might mean something else....

Anyway, intuitively it seems like in a given setup without fast-moving
reflectors and RFI sources and all, that the signal will settle down to a
particular standing-wave interference pattern and what you get is what you
get.  I don't see how, say, a 4 MHz sine-wave (or 4 GHz for that matter) would
arrive as anything other than a 4 MHz something-wave made up of all the
different phase/attenuation values from the multiple paths.  That is, I can't
see my bit-stream getting overlaid with itself differently at different times,
so once I get a signal that works, it works for a long (i.e. many bit-times)
time.  I can see how having the bit time be less than the difference between
the signal propagation times for the major signal paths would make things
unhappy -- but I would guesstimate that with 100-200nS difference (which sure
as heck can't happen if the signal only goes 30-50 feet!) you could push it to
5 MHz without too much fuss.

But then again, I'm no radio engineer....

-JohJonnhnyn MulMtultipaiptahth

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

From: bear@tcs.com (h.w. neff)
Subject: Re: Effects of multi-path propagation

# 
# >From zweig@parc.xerox.com Tue May 28 10:14:49 1991
# 
# -JohJonnhnyn MulMtultipaiptahth
#

effects ?- why, as with the quoted post, you see more than one copy
   of the information.
effects ?- why, as with the quoted post, you see more than one copy
   of the information.

8^)
8^)

levity quota now expired.

ttfn,
bear.

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

Date: Tue, 28 May 91 22:52:11 PDT
From: Stuart G. Phillips <stu@tandem.com>
Subject: Re: Effects on multi-path propagation

Jonathan Zweig <zweig.PARC@xerox.com> writes...
>What is the characterization of the 100-200 nS jitter? When I use the term
>jitter (I usually work in internetworking) I mean it as something like "the
>uncertainty in how long it will take a packet to reach its destination." That
>is, it may take 100 mS with a 20 mS jitter (whether this means 80/120 or
>90/110 as the limits is another issue) to get through.
>
>But in radio, I think the term might mean something else....
>

Well now.... think of the time it takes a bit to propagate from transmitter
to receiver; in actuality not much different from Ethernet.  Signals (RF or
otherwise) propagate at the speed of light (300 E6 m/s) in free space or
at about 0.6 C (C= speed of light in a vacuum aka free space) on a cable
(this modification ratio is called the velocity factor of the cable and
is quoted by the manufacturer).  Since we're talking wireless here, consider
the physical length of a bit - at 10 Mbps, one bit period is 30 meters
long (think of it as a wave train).  Another way to think of it is that the
bit takes 100 nS to travel 30 meters.

Now think about the effects of multi-pathing; since we're dealing with RF
from an antenna there will be several paths traversed by the wave train -
the direct (sometimes called optical) path and reflections caused by the
floor, ceiling, furniture, people .....  Rypinski's paper says that
a path difference of 0.1 times the bit length (or 3 meters) begins to
cause fading while more causes inter-symbol distortion.

Think of the wave train over the optical path; the bit takes 100 nS to
propagate from start to finish.  A reflected component of the wave train
shows up some delta time later (delayed by travelling a greater distance)
and finishes correspondingly later.  The late arrival causes the relected
component to "smear" into the next bit period.  If the time delay is
greater than 0.1 times the bit period it begins to corrupt the next
bit or symbols worth of data.  The effect is similar to phase induced
jitter since it creates an area of uncertainty at the beginning of the
bit.

Such jitter can occur over short paths (< 10 meters) and so creates
problems running at high speeds (back to my assertion of jitter not
exceeding 1/10 the bit period).

Sorry for the long reply but this is an example of the problems facing
the marriage of data comm and rf technology that gave rise to this
list (BTW now over 120 strong !).

Stu

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

From: Andrew Myles <andrewm@avalon.mqcs.mq.oz.au>
Subject: References
Date: Thu, 30 May 91 11:40:05 EST

G'day all,

Here are some references that I have already typed in to get things rolling:

1)      John Craick, Telecom Australia,  "The Paperless, Wireless, Peopleless
        Office: Human, Organisational and Social Issues", Telecommunications
        Journal of Australia Vol. 39, No. 3, 1989

2)      Dr John Ellershaw, Telecom Australia, "The Paperless, Wireless,
        Peopleless Office: Technology Trends in the Office",
        Telecommunications Journal of Australia Vol. 39, No. 3, 1989

3)      Malcolm H. Ross, Arthur D. Little International,  "The Paperless,
        Wireless, Peopleless Office: The Future Prospects for the Wireless
        Office" Telecommunications Journal of Australia Vol. 39, No. 3, 1989

4)      Alistair Fraser, Telecom Australia, Mike Buchanan, Communication
        Solutions, "The Paperless, Wireless, Peopleless Office: Telecom And
        the Value Added Services Evolution", Telecommunications Journal of
        Australia Vol. 39, No. 3, 1989

5)      P. Bernhard, Telecom Australia, "The Paperless, Wireless, Peopleless
        Office: Laying the Foundations of The Office Of the '90s",
        Telecommunications Journal of Australia Vol. 39, No. 3, 1989.
--

--------------------------------------------------------------------------------
E-Mail:         andrewm@avalon.mqcs.mq.oz.au || andrewm@mpce.mq.edu.au
In-Real-Life:   Andrew Myles
Organisation:   High Speed Networks Group, 
                Electronics Discipline,
                School of Mathematics, Physics, Computing and Electronics,
                Macquarie University, 
                Sydney, Australia 2109.
Telephone:      +61 2 8058439 (W), +61 2 8058983 (Fax), +61 2 446315 (H).
------------------------------------------------------------------------------

Date: Wed, 29 May 1991 18:47 MST
From: Aaron Leonard <LEONARD@Arizona.edu>
Subject: NCR's spread-spectrum FCC request to be denied?

Stu:: We do however have a distinct shortage of 
Stu:: contributions.  

Well, this new addition to the Wireless mailing list won't 
let his late arrival nor his lack of RF sophistication 
prevent him from contributing ... so here goes ...

We've been looking at the NCR spread-spectrum PC transceiver
cards as a potentially handy way to do some metro-area 
networking on the cheap.  (Our interest would be particularly 
in using them in unidirectional mode ... getting a couple of 
yagi antennas, finding a line of sight, and then use 
PC-Bridge to extend our LANs via the spread-spectrum.)

The pluses would be cheap (around $5K for all the hardware), 
quick to set up (supposedly no FCC approval a la microwave), 
fast (200Kbps??), and good distance (up to 5 miles?)

However, I just heard a rumor that the FCC is "on the verge" 
of denying NCR's petition to use that range of spectrum for 
its spread-spectrum application.  Supposedly the transceivers 
were only being allowed to operate in "experimental" mode, 
and supposedly the FCC is going to pull the plug on the 
experiment within the next couple of weeks.

1) Can anyone who knows more than I do (that is, anyone who 
knows anything at all) report on the FCC status of NCR's 
spread-spectrum products?

2) If the spread-spectrum stuff looks like a go FCC-wise, 
would anyone care to remark on the suitability of the NCR (or 
other) spread-spectrum transceivers for bridged or routed 
Ethernet?

Thanks,

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Telecommunications, Tucson AZ 85721

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

Date: Thu, 30 May 1991 08:41 EST
From: "John D. Balogh, PSU OTC, 814.863.1252" <JDB@ecl.psu.edu>
Subject: GUNNplexers for LAN use?
To: wireless@tandem.com

I just received a question from one of our student employees about the use
of GUNNplexers (10.2GHz typically-HAM-Radio-only device) for extending an
ethernet between two buildings that don't have fiber yet.

Any experience with these beasts?

I read articles about these devices in "QST" and "Ham Radio" more than 5 
years ago. Seems that they would be great for short-distance (less than
500 meters) line-of-sight wide-bandwith (more than the usual audio 4KHz)
applications. Just brew up an IF strip that has 20MHz bw and provide the
appropriate signaling on an FM detector so that collision detect wasn't
a problem, and away you go!

As I recall, they are quite temperature sensitive, but that can be overcome
with a styrofoam 6-pack cooler and a lightbulb/dimmer circuit.

Any suggestions are (probably) appreciated.

John Balogh, Data Engineer                     | Usual disclamers apply.
-----                                          +---------------------------
Penn State, Office of Telecommunications       | Your mileage may vary.
Internet: JDB@ECL.PSU.EDU                      | Eat lots of fruit.
Bitnet: JDB@PSUECL.BITNET                      | Be nice to your neighbors.
AT&Tnet: +1 814 863-1252 (with voicemailgizmo) | Keep the time :-)
Fax: +1 814 863-4092                           | Use standards.
SNAILmail: 205 Pine, Univ. Park, PA  16802     | Push for Interoperability.

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

From: scoggin@delmarva.delmarva.COM (John Scoggin)
Subject: Motorola Altair System
Date: Thu, 30 May 91 7:45:46 EDT

Does anyone on this mailing list have the Motorola Altair wireless Ethernet 
installed?  If so, how is it managed?  SNMP, proprietary, or not-at-all?
(don't laugh - we have a Motorola Computer-Aided Dispatch System which is
one or the most poorly designed systems on the planet, from a network
management standpoint!)

Also, how has reliability been?  Comparable to hard-wired.  How about
intereference from terrestrial 2GHz microwave?

Thanks --

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

From: Ron Gershon <gershon@vis.toronto.edu>
Subject: A question about this newsgroup
Date: 	Thu, 30 May 1991 09:43:04 -0400


Hi.

Just wondering if this newsgroup applies to powerline communications as
well. We, at Adaptive Networks, have developed yet another wireless
communication solution using the AC powerline, and offer LANs using this
module. Therefore I would be interested to know whether the membership
of this newsgroup is interested in this medium.

Thanks.

Ron Gershon
Adaptive Networks Ltd.
-----------------------------------------------------------------------------

From: Ron Gershon <gershon@vis.toronto.edu>
Subject: Info on Adaptive Networks' powerline communication products
Date: 	Thu, 30 May 1991 12:07:32 -0400


I didn't know my message will be posted directly to the list, nor did
I anticipate a lot of responses, so let me summarize what Adaptive
Networks has to offer.

Ron.

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

Adaptive Networks' patented AN192 technology transmits data at an
effective throughput of 19.2 Kbps over powerlines with the reliability of 
dedicated communications wiring. Designed into OEM products, it allows
them to network over existing powerlines, thus eliminating the cost and
hassle of installing wiring. An ISO standard for shipboard monitoring of
refrigerated cargo containers was awarded to Adaptive Networks in January
of this year over competing proposals from Westinghouse and NEC/Mitsubishi.

We provide board-level products, as well as self-contained standalones units. 
In the 4th quarter of this year we will have a 2-chip set version of the 
product.

Some of the current applications of the AN192:
	* School security system (time and attendance) in New York City
	* Shipboard monitoring of refrigerated containers
	* Materials handling through moving stacking cranes for storage
		and retrieval in an automated warehouse

Prices vary with quantities. For the 3" x 5" module (board), prices vary
from $650 per module for a quantity of 2, to $122 for quantities over 1000.
The standalone product is slightly more expensive. The 2-chip set is expected
to be in the double digit price range.

Product specifications:
	Network Configurations:
		* Token Bus
		* Master/Slave centrally controlled bus

	Powerline Interface:
		AN Isolation module protects against 
		powerline surges and spikes

	Network Size:
		Up to 65534 nodes

	User-effective throughput:
		19.2 kbps

	Bit Error Rate:
		< 1 x 10^-9

	Size (of module):
		3.05" x 5.20" x 0.45"

	Power Requirements:
		Voltage: +5 VDC and  +/- 12 to +/- 15 VDC
		Consumption: 5 Watts typical


Head office (including Marketing):            Toronto office (R&D):
	P.O.Box 1020 					223 Tansley Rd.
	Kendall Square Branch				Thornhill, Ontario
	Cambridge, MA 02142-0999			Canada, L4J 2Y8

	(617) 497-5150					(416) 882-1922
	(617) 787-8168 (fax)				(416) 881-8429 (fax)


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

From: chk@alias.com (C. Harald Koch)
Subject: Re: Powerline <wireless> Lans ?
Date: Thu, 30 May 91 10:44:12 EDT

> From: Ron Gershon <gershon@vis.toronto.edu>
>
> Just wondering if this newsgroup applies to powerline communications as
> well. We, at Adaptive Networks, have developed yet another wireless
> communication solution using the AC powerline, and offer LANs using this
> module. Therefore I would be interested to know whether the membership
> of this newsgroup is interested in this medium.

How much noise does your network generate on the power lines? We already
have several problems with noisy power here, from a braindead digital clock
that runs at about 8 times realtime to random computer crashes. The experts
claim that this is all caused by excessive noise on the power lines.
Expensive power filters have solved the problem on our critical machines,
but we aren't rich enough to put filters on all our electrical appliances.

I'm quite skeptical about AC powerline networks (and control systems like
BSR) because of the problems caused by power line noise. Here's your chance
to change my mind... :-)

-- 
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
Internet:    chk@alias.com      chk@gpu.utcs.toronto.edu      chk@chk.mef.org

-------------------------------------------------------------------------------
Date: Thu, 30 May 91 14:02:33 -0400 (EDT)
From: Anders.Klemets@cs.cmu.edu
Subject: Re: NCR's spread-spectrum FCC request to be denied ?

> Supposedly the transceivers 
> were only being allowed to operate in "experimental" mode, 
> and supposedly the FCC is going to pull the plug on the 
> experiment within the next couple of weeks.

Sounds like complete baloney to me, unless you are talking about some
NCR product other than the WaveLAN.

The WaveLAN's have a sticker that says "FCC ID: IMR915RLAN-1."
They operate at 2 Mbit/s on the 900 MHz band.
I have a BSD UNIX style driver for them that I run on Mach 2.5. FTP
gives a throughput of 120 kbyte/s at best. Just shipping UDP packets
gives a throughput of 130-150 kbyte/s on average.
Performance worsens if one tries to run more than two WaveLANs at the
same time, as might be expected.

I can make the driver source code available to anyone who has a MACH
source license. And I would be interested in knowing whether someone has
written an MSDOS packet driver for the WaveLAN.

Anders


------------------------------------------------------------------------------
Date: Thu, 30 May 91 14:36:19 -0400 (EDT)
From: Anders.Klemets@cs.cmu.edu
Subject: Fwd: NCR Unveils WaveLan Network

---------- Forwarded message begins here ----------

Message-ID: <YcBxIx200UfAI0YvpN@andrew.cmu.edu>
From: DowJones@andrew
Subject: NCR Unveils WaveLan Network
Date: Mon, 20 May 91 09:55:09 -0400 (EDT)

  ATLANTA -DJ- NCR Corp. said it unveiled a micro channel version of
WaveLan high-speed wireless local area network.   

  The company said in a press release that the network eliminates the
need for wiring to connect personal computers in office settings.   

  The company said that its WaveLan can be used with the vast majority
of network operating systems currently being shipped.   

  NCR WaveLan has a suggested retail price of $1,390 for the Network
Interface Card including Novell NetWare v3, NetWare v2 and Microsoft
Lan Manager drivers as well as the omnidirectional antenna.    
    9:54 AM


From matthew@ucscb.UCSC.EDU Thu May 30 13:31:17 1991
-----------------------------------------------------------------------------
Date: Thu, 30 May 91 13:26:03 -0700
From: matthew@ucscb.UCSC.EDU (Matthew Kaufman)
Subject: Re: GUNNplexers for LAN use ?

I've been thinking about this very thing myself. One should note
that amateur regulations on content are very restrictive, but
it seems like a device operating under the new FCC Part 15
intentional radiator rules on 24 GHz should work pretty well.
24 GHz is more affected by atmospheric water vapor and the power
limitation is 250 microvolts/meter measured at 3 meters, but it
seems that a short hop wouldn't be too difficult. The trick is
to build a receiver that can run at 10 MBps, of course, so the
microwave tranceiver can be used with standard ethernet hardware
instead of some sort of custom modem card or even T1, which are more
expensive. 
Low power (1-2 mW) 24 GHz gunn tranceivers can be had for about $70 new
and modulation is trivial, especially on those tranceivers with varactor
diode modulators, so if the cost of the IF/demod hardware could be
kept low, this might be one of the cheapest wireless network solutions
available

-matthew kaufman
 matthew@ucscb.ucsc.edu, or,
 kaufman@apple.com
----------------------------------------------------------------------------
From: scoggin@delmarva.delmarva.COM (John Scoggin)
Subject: Re: Powerline <wireless> Lans ?
Date: Thu, 30 May 91 17:32:27 EDT

>
>> From: Ron Gershon <gershon@vis.toronto.edu>
>>
>> Just wondering if this newsgroup applies to powerline communications as
>> well. We, at Adaptive Networks, have developed yet another wireless
>> communication solution using the AC powerline, and offer LANs using this
>> module. Therefore I would be interested to know whether the membership
>> of this newsgroup is interested in this medium.
>
>How much noise does your network generate on the power lines? We already
>have several problems with noisy power here, from a braindead digital clock
>that runs at about 8 times realtime to random computer crashes. The experts
>claim that this is all caused by excessive noise on the power lines.
>Expensive power filters have solved the problem on our critical machines,
>but we aren't rich enough to put filters on all our electrical appliances.
>
>I'm quite skeptical about AC powerline networks (and control systems like
>BSR) because of the problems caused by power line noise. Here's your chance
>to change my mind... :-)
>
>-- 
>C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
>Internet:    chk@alias.com      chk@gpu.utcs.toronto.edu      chk@chk.mef.org
>
>

I suspect that MOST of these problems may be related to equipment-generated
harmonic currents.  There was a recent bulletin to sites with multiple IBM
3090 mainframes relating to harmonics generated by these machines with their
MG sets causing MAJOR problems for UPS's.  We have seen this cuasing problems
with PC's and the like.

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>
----------------------------------------------------------------------------

Date: Thu, 30 May 91 17:29:12 -0700
From: woody@ucscb.UCSC.EDU (Bill Woodcock)
Subject: NCR Wavelanproduct line extended...

   ...to NetWare 3, and OS/2 at Comdex last week.  Also, they now support NDIS,
which is some kind of Microsoft standard that Vines and 3Com comply with.
They're shipping in December at $1,390 list.
This was on p.5 of Network World v.8, n.21.
                         
                        -Bill Woodcock
                         BMUG NetAdmin

________________________________________________________________________________
bill.woodcock.iv..woody@ucscb.ucsc.edu..2355.virginia.st..berkeley.ca.94709.1315
-------------------------------------------------------------------------------

Date: Thu, 30 May 91 17:23:43 -0700
From: woody@ucscb.UCSC.EDU (Bill Woodcock)
Subject: Re: NCR's spread-spectrum FCC request to be denied ?

Here's a little news item I wrote a couple of days ago for the ANMA Journal:

Motorola Cuts Prices on Altair

In the third week of May, Motorola announced that the prices of its
Altair wireless Ethernet products were being cut by nearly three
quarters.  The suggested retail price for the Altair Control Module
has been dropped from $3,995 to $995, while the User Module went from
$3,495 to $995.
                         
                        -Bill Woodcock
                         BMUG NetAdmin

________________________________________________________________________________
bill.woodcock.iv..woody@ucscb.ucsc.edu..2355.virginia.st..berkeley.ca.94709.1315
-------------------------------------------------------------------------------

Subject: CSMA/CA - a standard?
Date: Thu, 30 May 91 08:25:33 PDT
From: Paul Congdon <ptc@hprnd.rose.hp.com>


Hello,

Both NCR and Proxim boast the use of CSMA/CA.  It sounds
almost like a standard.  Is there a description of the access
protocol, or is it totally propriatry?

Paul

+---------------------------------+------------------------------------+
+     Paul Congdon                +     Mail Stop:  R3NF2              +
+     Network Architecture Lab    +     Email: ptc@hprnd.rose.hp.com   +
+     8000 Foothills Blvd         +     Phone: (916) 785-5753          +
+     Roseville, CA   95678       +     Fax:   (916) 786-9185          +
+---------------------------------+------------------------------------+

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

Date: Thu, 30 May 91 19:46:44 EDT
From: Russ Nelson <nelson@sun.soe.clarkson.edu>
Subject: NCR's spread-spectrum FCC request to be denied ?

   I can make the driver source code available to anyone who has a MACH
   source license. And I would be interested in knowing whether someone has
   written an MSDOS packet driver for the WaveLAN.

Alas, no.  NCR was supposed to send us a pair back in January, but we
haven't seen hide nor hair of them.  I've even called and bugged the
product manager about his promise, but he's always out of the office.
Maybe if more people call him and ask him for one.  His name is
Daryl Maddox, phone number is 513 445 1956.
-russ

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

From: Ron Gershon <gershon@vis.toronto.edu>
Subject: Re: noise introduced by powerline communication devices
Date: >Fri, 31 May 1991 10:50:27 -0400


C. Harald Koch (chk@dino.alias.com) asks: 

> How much noise does your network generate on the power lines? We already
> have several problems with noisy power here, from a braindead digital clock
> that runs at about 8 times realtime to random computer crashes. The experts
> claim that this is all caused by excessive noise on the power lines.
> Expensive power filters have solved the problem on our critical machines,
> but we aren't rich enough to put filters on all our electrical appliances.
> 
> I'm quite skeptical about AC powerline networks (and control systems like
> BSR) because of the problems caused by power line noise. Here's your chance
> to change my mind... :-)

Our technology employs advanced spread-spectrum techniques, incorporating 
an adaptive/wideband approach and noise-immune networking protocols
specifically developed for handling worst-case powerline noise and 
attenuation. We use the 150-400 kHz bands for our purposes, and our
transmission would seem like white noise to other systems. We put no more
than 1 Watt of power on the line. Consequently, none of the users of the 
AN192s has ever complained of computers crashing as a result of the AN192
transmitting in their sites. 

As for BSR and other systems, they do not offer bit error rates < 10^-9
as we do, and we have systems in the field to prove it. In fact, we are
currently developing a version which will be incorporated in a new commercial
automated electric utility meter reading network. This will definitely allow
for the use of the powerline as a communication medium, while recording
how much electricity is being used by all your electrical appliances...


Ron.
------------------------------------------------------------------------------

Date: Fri, 31 May 91 11:38:19 CDT
From: zawada@ncsa.uiuc.edu (Paul Zawada)
Subject: Re: Motorola Altair System


Well, we don't have the Altair system installed, but I had a Motorola
salesman here to demonstrate it.  I was skeptical that it was going to
work well, but I was really impressed!  It did everything they said it 
would.  It was pretty transparent, like the wire was there.  It worked 
through doors and down hallways very well.  (We did manage to push it 
to the limit by trying to bounce the signal around two corners, but you 
can only ask for so much...)

First of all, the Altair system is not protocol dependent.  Altair merely
forwards ethernet frames.  All it looks at is the ethernet addresses of
the hosts involved.  So if you have ethernet, Altair should work.
i.e. Altair dosen't care if you're running TCP/IP, Appletalk, OSI, etc.

One nice thing about the system is that the control module keeps track of 
the ethernet addresses connected to each user module.  This allows it to 
pass only necessary traffic accross the radio link. i.e. it works almost 
like a smart bridge.  Traffic between hosts on the user module does not 
get sent to the rest of the network.  Similarly ALL traffic on the control 
module's ethernet does not get passed to the user modules.  Each user 
module gets the traffic for the hosts attached to it.

As for system management, currently there is an RS232 port on the control
module.  Don't ask me what functions are available, since I did not get
a chance to play with that part of the system.  The salesman said that
SNMP was currently in the works.  I really don't know how much of an
issue this is, since the Altair system is pretty transparent.  It would
be nice to have SNMP, but since the devices are pretty much passive there 
isn't much you need to monitor other than if the link is up or down.   
(The user module has a green LED that blinks when it is searching for 
its control module and glows steadily when the link is up.  So you can 
tell if the connection is there or not, you just can't do it via the 
network.)  Is there such a thing like SNMP for ethernet cable?

Remember, I only had this thing demonstrated for me.  I don't have one
installed. (yet)  If it always works as well as it did for me those two
hours, I would be more than satisfied!  Hope this gives you some more 
info on the Altair system. 

--zawada

__
Paul J. Zawada, KB9FMN         |"This 'telephone' has too many shortcomings
zawada@ncsa.uiuc.edu           | to be seriously  considered as a  means of
Network Administrator          | communication.  The  device is  inherently
National Center for            | of no value to us..."  
   Supercomputing Applications |            -Western Union memo, 1877

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

Date: Fri, 31 May 91 12:41:59 BST
From: "Pete Lucas, NCS-TLC, Holbrook House, Swindon" <PJML@ibma.nerc-wallingford.ac.uk>
Subject: Power-line LANs.

Much of the problem noise that affects these systems infact comes from
switched-mode powersupplies (as used in almost every PC!).
These rectify the AC line current, and due to the short conduction-time
of the rectifiers, often result in a significant 3rd-harmonic current
flowing down the supply mains.
Also, being in effect a power-oscillator, harmonics etc. of the switching
waveform get superimposed on the AC line.
In an environment where many switching powersupplies are used, the 3rd
harmonic current can approach (or exceed!) the total current drawn at
the fundamental frequency; particularly in 3-phase systems the current in
the nominally 'unused' neutral line can be greater than the sums of the
currents on the three phases.
This not only upsets the electric utility companies, but can seriously
screw up systems that use the AC line cabling for data transmission.
There is likely to be forthcoming European legislation limiting the
allowed amount of waveform distortion caused by electrical equipment;
makers of PCs etc. will have to fit better filtering.

          Pete Lucas PJML@UK.AC.NWL.IA    PJML%IA.NWL.AC.UK@UKACRL

Please use the following addresses for reply:          +     \/Natural
                                                       +    \/\Environment
JANET    : PJML@UK.AC.NERC-WALLINGFORD.IBMA            +   \/\/Research
Internet : PJML%IA.NWL.AC.UK@NSFNET-RELAY.AC.UK        +  \/\/\Council
EARN     : PJML%UK.AC.NWL.IA@UKACRL                    +  NERC Computer Services
RADIO    : G6WBJ@GB7SDN.GBR.EU  {144.650MHz}           +   Holbrook House
SPAN     : STAR::\PJML%IA.NWL.AC.UK@NSFNET-RELAY.AC.UK +    Station Road
PHONE    : +44 (0)793 411613                           +     SWINDON SN1 1DE
FAX      : +44 (0)793 411503                           +      GREAT BRITAIN

          Pete Lucas PJML@UK.AC.NWL.IA    PJML%IA.NWL.AC.UK@UKACRL
-------------------------------------------------------------------------------

Date: Fri, 31 May 91 18:01:45 EDT
From: jdc@moscom.com (Jim Centanni)
Subject: Low Power No-License RF

Can someone please fill me in on the FCC requirements for low
power transmitters that do not require special FCC licenses?

At one time, no special licensing was required for transmitters
with an output power below 100 milliwatts. If this is still
valid, it might be possible to cover large facilities with
several transmitters, where a direct connection would be made to
each transmitter. Of course multi-path reception would become a
much bigger problem now if a receiving antenna could hear more
than one transmitter. However, it might still be worth looking
at.

Please advise restrictions, such as frequencies, ERP (effective
radiated power), modes of operation (switched carrier, AM, FM,
PSK, etc.), and other pertinent information, along with pros and
cons associated with this approach.

Jim Centanni
Moscom Corp.
(716) 385-6440

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

From: "Jonathan M. Zweig" <zweig.parc@xerox.com>
Subject: Re: CSMA/CD
Date: >Fri, 31 May 1991 15:10:26 PDT

I have been toying with the so-called hidden terminal problem, and have
written a tiny simulation that agrees with an analytic solution to the
following problem:

>Assume I have magic radios that have a 0 dB capture range; that
>is, a receiver is either in range of a transmitter or not. Further
>assume that the range is a fixed, constant distance.  If I have
>two randomly located stations that wish to transmit at me (i.e.
>they are both within range of me), what is the percentage likelihood
>that they will be within range of each other?

The question is of interest because whenever they are not within range of each
other, it is inconceivable that they could determine (via their receivers)
whether their transmissions to me are colliding -- they are hidden from each
other.

I won't bore the list with the math (the trick is to intersect the circle that
is within range of me with the circle that is within range of the first
station, then integrate the ratio of the intersection area to 2*pi for all the
distances between 0 and 1), but the answer that both the calculus gives me
(it's actually 3*sqrt(3)/4*pi) and the monte carlo simulation approximate is
0.586.

That is, 41% of the time (assuming the spatial distribution is uniform across
the circle that's within range of me) the two stations can't hear each other.
I thought that was an interesting number, and a bit higher than I would have
guessed.

So if anyone else out there is thinking about collision avoidance algorithms,
you can tattoo this on your arm.  Carrier sense is a waste of time in this
case.

(Of course it _isn't_ a waste of time in some cases of interest, such as
radios with nearly infinite range compared to the expected spatial
distribution of stations....)

-Johnny Hidden

------------------------------------------------------------------------------
Date: Sat, 1 Jun 91 00:29:05 -0700
From: woody@ucscb.UCSC.EDU (Bill Woodcock)
Subject: Re: Low Power No-License RF


          jdc@moscom.com (Jim Centanni) writes:
        > Can someone please fill me in on the
        > FCC requirements for low power
        > transmitters that do not require
        > special FCC licenses?
    
    
    The following two tables should help you relate the products out there
    to the current FCC bandwidth allotments.  They're from a recent column
    I wrote, primarily on the Apple PCS proposal.
                             
                            -Bill Woodcock
                             BMUG NetAdmin
    
    ______________________________________________________________________
    
    FCC-Approved Frequencies
    
    FCC Part 15.247: Unlicensed Spread Spectrum, 1.0W peak power.
    FCC Part 15.249: Unlicensed Low Power Radio, 0.75mW peak power.
    
        902.0-928.0MHz            26MHz total
        2,400.0-2,483.5MHz        83.5MHz total
        5,725.0-5,850.0MHz        125MHz total
        24.0-24.25GHz             250MHz total
    
    ______________________________________________________________________
    
    Device Specifications
    
        Vendor         Bandwidth      Throughput  Output        Range
    
        Cal. Microwave 902.0-928MHz   250Kbps     26MHz@1W      800-2700 ft.
        NCR            902.0-928MHz   2Mbps       26MHz@250mW   100-800 ft.
        Apple          1850-1990MHz   10Mbps      40MHz@1W      150-450 ft.
        Motorola       18.82-19.21GHz 10Mbps      2x50MHz@25mW  40 ft.
    
________________________________________________________________________________
bill.woodcock.iv..woody@ucscb.ucsc.edu..2355.virginia.st..berkeley.ca.94709.1315
-------------------------------------------------------------------------------

Date: Sat, 1 Jun 91 15:31:29 -0700
From: woody@ucscb.UCSC.EDU (Bill Woodcock)
Subject: Re: Low Power No-License RF

Motorola's Altair boxes are real.  NCR's WaveLan boxes are available now
for NetWare, I believe, and will be available for MicroChannel late this
year.  California Microwave's boxes are done, and waiting for FCC certification.
                         
                        -Bill Woodcock
                         BMUG NetAdmin

________________________________________________________________________________
bill.woodcock.iv..woody@ucscb.ucsc.edu..2355.virginia.st..berkeley.ca.94709.1315

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

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 08:29:51 GMT
From:      tjc@ecs.soton.ac.uk (Tim Chown)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

In <1991Jun3.235516.7634@brolga.cc.uq.oz.au> ggm@brolga.cc.uq.oz.au (George Michaelson) writes:

>jim@cs.strath.ac.uk (Jim Reid) writes:
>>In article <1367@exua.exeter.ac.uk> SAMcinty@exua.exeter.ac.uk (Scott McIntyre) writes:
>>Resistance to change is a factor, but not a major one. What is more
>>significant is that there is little expertise in the UK with running a
>>national IP based network and it is the lack of suitably qualified and
>>experienced people that makes things more awkward than they already are.
 
>Based on my experience (pre 1987) IP introduction in JANET is almost
>completely blocked by politics and bullsh. Technical issues are
>smokescreens. The truth in your statement is that there is woeful ignorance
>in UK campii about IP networking point blank.  Its not ignorance of running
>a NATIONAL IP network, its ignorance of even running CAMPUS IP networks.
 
>We did it here in under a year. Its run by a 2-man team in Canberra and
>the goodwill of computer centres across the nation. Off-the-shelf technology,
>code built into virtually ALL *nix, available for VMS, VM, No mess, no
>fuss, no worries mate!

Here at Southampton our Electronics and Computer Science departmental 
connections are all TCP/IP; we have 200+ nodes on our local network.
Now we're just about to have our campus network go live, and yes, it all
runs by Pink Book.  Our Computing Services who will adminster this beauty
have had it imposed on them from above by some national committee.  Yum.
Somewhere someone needs their head removing from their a**e !!!

	Tim
-- 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 09:16:23 GMT
From:      lyman@med.unc.edu (Lyman A. Ripperton III)
To:        comp.protocols.tcp-ip
Subject:   Re: PC TCP/IP packages


You might want to look at Clarkson University's TCP/IP package (CUTCP).
Available by FTP from omnigate.clarkson.edu.

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 12:12:02 GMT
From:      hutch@ssmct62.ssc.af.mil ("Capt E. Lee Hutchins")
To:        comp.protocols.tcp-ip
Subject:   Limiting Telnet Access

We have a 3B2 running Wollongon TCP/IP.  We need to limit telnet access
for some users, but NOT through disabling their accounts.

	I know that there is a ftp.users file for tfp.  Is there something
like that for telnet??

			thanx
				lee
-- 

==============================================================================

			Capt E. Lee Hutchins

USPost Office: HQ SSC/SSMCT          ||   Voice: AV 596-4555/4171
	       Gunter AFB, AL 36114  ||          COM: (205) 279-4555/4171
				     ||
email: hutch@ssmct62.ssc.af.mil      ||   FAX:   AV: 596-3262
		       		     ||	 	 COM: (205) 279-3262

     The views related here do not in any way represent the USAF or USGOV or 
GUNTER AFB, SSMCT or anyone else for that matter!

Go AIR FORCE BEAT Army, Navy or whoever else the FALCONS are playing this week!

		UNIX and X-Windows: the ONLY solution for REAL men 

==============================================================================

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 12:14:43 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: IBM's VNET

In article <2333157@MTS.RPI.EDU>, Daniel_Murphy@MTS.RPI.EDU says:
>
>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.

IBM now has a direct internet connection.
Their ids are user@node.vnet.ibm.com
Contact your collegues in IBM to get their ids and nodenames and remind them
to ask permission for use of the internet gateway.


>
>Daniel Murphy
>Communication Dept.
>Rensselaer Polytechnic Institute
>Troy, NY
>USA

Hank Nussbacher
Israel

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 13:06:00 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking experiences with FDDI interfaces for Sun's

What kind of experiences (reliability, installability, performance ...)
have folks had with the FDDI interfaces for Sun.
This would include Sun FDDI interface, CMC's, others?
thanks
tom
  dunigan@msr.epm.ornl.gov

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 13:07:15 GMT
From:      hinklenw@clvax1.cl.msu.edu (Nicholas W Hinkle)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP in Windows 3.0

I have had some luck with running Clarkson's TCP/IP package in Windows
3.0 enhanced and in a Dos full screen in OS/2. For both environments, I
defined the NIC setup in the Config.tel and did not use a packet driver.

I have tried it with the 3C523 packet driver with similar results but am
having problems with the NDIS packet driver emulator from FTP Inc.

I find it best to have Windows installed on the PC's hardisk and not
on a Server.

You'll find Clarkson's TCP/IP on sun.soe.clarkson.edu.

Good Luck.

/Nick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nicholas Hinkle                              hinklenw@ibm.cl.msu.edu
Social Science Research Bureau, MSU          hinklenw@MSU.Bitnet

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 13:32:17 GMT
From:      barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP and UDP checksums

Somebody asked:
> 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?

The TCP checksum is never optional (except in non-conforming
implementations, of course).  Here is an extract from RFC 1122, to add
weight to the requirement in RFC 793:

         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.

The TCP checksum will sometimes be all zeros but will never be all ones,
if it is calculated according to the method given in RFC 793.  I don't
know if an implementation is permitted to transmit all ones instead of a
zero TCP checksum, but the discussion of UDP checksums in RFC 1122
suggests (to me) that a sending TCP would be permitted to do this.

A UDP checksum, on the other hand, is optional, and a zero in the
checksum field of the packet indicate that a checksum was not
calculated.  If a UDP checksum is calculated as zero, RFC 768 says that
it must be transmitted as all ones to distinguish this case from the
absence of a checksum.  RFC 1122 has this to say:

         4.1.3.4  UDP Checksums

            A host MUST implement the facility to generate and validate
            UDP checksums.  An application MAY optionally be able to
            control whether a UDP checksum will be generated, but it
            MUST default to checksumming on.

            If a UDP datagram is received with a checksum that is non-
            zero and invalid, UDP MUST silently discard the datagram.
            An application MAY optionally be able to control whether UDP
            datagrams without checksums should be discarded or passed to
            the application.

            DISCUSSION:
                 Some applications that normally run only across local
                 area networks have chosen to turn off UDP checksums for
                 efficiency.  As a result, numerous cases of undetected
                 errors have been reported.  The advisability of ever
                 turning off UDP checksumming is very controversial.

            IMPLEMENTATION:
                 There is a common implementation error in UDP
                 checksums.  Unlike the TCP checksum, the UDP checksum
                 is optional; the value zero is transmitted in the
                 checksum field of a UDP header to indicate the absence
                 of a checksum.  If the transmitter really calculates a
                 UDP checksum of zero, it must transmit the checksum as
                 all 1's (65535).  No special action is required at the
                 receiver, since zero and 65535 are equivalent in 1's
                 complement arithmetic.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 13:46:18 GMT
From:      jpoller@netxcom.netx.com (Jack Poller)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the rules for Object Instances?

In article <23109@shlump.lkg.dec.com> jc@netrix.nac.dec.com writes:
#Here's my dumb question of the week: We have a bunch of people working
#with  SNMP,  and  one  thing  that  has people confused is the "Object
#Instance", which apparently is the name for the  funny  zero  that  is
#appended to most (but not all) Object Identifiers.  We have determined
#by experiment that with various agents lurking about on  the  network,
#this  extra  zero octet is sometimes required, sometimes optional, and
#sometimes forbidden.  But we haven't yet intuited the pattern, and TFM
#(the  RFCs,  Marshall  Rose's  "Simple Book", etc.) seem to think that
#this is so obvious that it isn't worth explaining. It isn't obvious to
#us, and existing agents seem to follow a variety of rules.
#
#Does  anyone  know  what the rules are for the use of this extra zero?
#When is it required?   When  is  it  forbidden?   Or  is  it  just  an
#idiosyncracy of the various agents?
#
#Also,  since  it  is  (in  our  experience)  always  zero, is there an
#explanation (other than sheer perversity ;-) that it is there at  all?
#Can it ever be nonzero?
#
#For instance, many agents require that the sysDescr  be  requested  as
#43.6.1.2.1.1.0  or  they  won't  respond,  while others don't need the
^^^^^
Assuming typo - should be 1.3.6.1.2.1.1.0

#zero.  (Some will also accept 1.3.6.1.2.1.1, but  that's  a  different
#problem.  :-)  There seems to be no obvious meaning to multiple (i.e.,
#different) values for this variable, so why would an instance ever  be
#needed?
#
#Is there some rule in the RFCs that covers this, so we  can  point  at
#some of the agents and say "You're doing it wrong" and possibly get it
#changed so they're all the same?  Or is it just a  weirdness  that  we
#have  to  learn  to live with?  It ain't easy writing clients when the
#agents out there are inconsistent.  But maybe  if  we  understood  the
#rules better...

A number of different problems appear to be occuring.

1. Two different access methods:
   Remember that SNMP supports both GET and GET-NEXT.  The get access
   method will access ONLY the explicitly named object instance.
   While the get-next access method will access the next object
   instance in lexicographical order from the named object instance

   get sysDescr            returns      ERROR
   get sysDescr.0          returns      sysDescr.0 = "SNMP Agent 1.1"
   getnext sysDescr        returns      sysDescr.0 = "SNMP Agent 1.1"
   getnext sysDescr.0      returns      sysUpTime.0 = 14123

   The confusion over the two access methods can lead to the
   assumption that the instance name is sometimes optional, as there
   are two methods to obtain the object instance for sysDescr.

2. Object Instance Naming Rules
   The best bet is to read the RFC's quite carefully, as the rules are
   well explained.  Since I have not dealt with this aspect in 2
   months, I won't try to confuse you.

3. Object Instance Names are often non-zero, especially when used in
   Tables.  Any easy table to study is the Address Translation Tables.

My suggestion to understanding this is to find or build a mib-tree
walker or browser.  A mib-tree walker that can take its return value
as the next argument for get-next would be ideal.  In this manner you
would be able to see the entire tree implemented by a given agent.
For instance:

     getnext 192.1.1.1 public system            sysDescr.0 = "SNMP Agent 1.1"
     getnext 192.1.1.1 public sysDescr.0        sysUpTime.0 = 123456
                   .....


Jack L. Poller
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jack L. Poller     (703) 749-2240    Telex 901976     G3 Fax (703) 749-2375
NetExpress, Inc., 1953 Gallows Road, Suite 300, Vienna, Virgina 22182
                           ...!uunet!netxcom!jpoller

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 15:56:43 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Printing to a terminal server


   Date: 3 Jun 91 18:39:05 GMT
   From: netcomsv!jbreeden@apple.com  (John Breeden)

   Does anyone know of a piece of code that will allow a Unix print queue
   to be redirected to a terminal server via telnet (like the peice of
   code that xyplex supplies with their terminal servers?). I'm trying to
   provide the same type of print services with a non-xyplex terminal
   server, hoping that someone has already invented this wheel).

Look in cisco's anonymous FTP area...I seem to remember some
non-system specific hacks to do similar things in there...

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

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 16:35:57 GMT
From:      bstring@MAINZ-EMH2.ARMY.MIL (BOB STRINGFIELD)
To:        comp.protocols.tcp-ip
Subject:   List subscription

sub tcp-ip Robert L. Stringfield

***********************************************************************
Robert (Bob) L. Stringfield, Computer Systems Analyst
Mainz Army Depot
Directorate, Management Information Systems (D/MIS)
ATTN:  SDSMZ-I
APO NY 09185
COML (No ETS or Autovon available): 06131-696328 (Germany)
FAX: 06131-696467
Electronic Mail:  bstring@mainz-emh2.army.mil
Alternative:  bstring%mainz-emh2.army.mil@wsmr-simtel20.army.mil
Truth:  IGNORANCE hates knowledge....

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 17:01:49 GMT
From:      bstring@MAINZ-EMH2.ARMY.MIL (BOB STRINGFIELD)
To:        comp.protocols.tcp-ip
Subject:   DDN Errlog


Can anyone tell me what this is, what causes it and how it can
be fixed.  Thanks
***************************TEXT BEGIN***********************
-rw-rw-rw-   1 root     root       69770 May 22 08:59 errlog.cur
 
Wed May 22 08:41:32 1991: Time exceeded in transit, code 0
Wed May 22 08:41:34 1991: Time exceeded in transit, code 0
Wed May 22 08:41:36 1991: Time exceeded in transit, code 0
Wed May 22 08:41:36 1991: Time exceeded in transit, code 0
Wed May 22 08:41:37 1991: Time exceeded in transit, code 0
Wed May 22 08:41:38 1991: Time exceeded in transit, code 0
Wed May 22 08:41:38 1991: Time exceeded in transit, code 0
Wed May 22 08:41:40 1991: Time exceeded in transit, code 0
Wed May 22 08:41:40 1991: Time exceeded in transit, code 0
Wed May 22 08:41:41 1991: Time exceeded in transit, code 0
Wed May 22 08:41:42 1991: Time exceeded in transit, code 0
Wed May 22 08:41:44 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:41:44 1991: Time exceeded in transit, code 0
Wed May 22 08:41:44 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:41:44 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:41:44 1991: Time exceeded in transit, code 0
Wed May 22 08:41:46 1991: Time exceeded in transit, code 0
Wed May 22 08:41:49 1991: Time exceeded in transit, code 0
Wed May 22 08:42:01 1991: intermediate: time out. index = 3, real ch# = 32. send msg
Wed May 22 08:42:01 1991: intermediate: time out. index = 4, real ch# = 2. send msg
Wed May 22 08:42:52 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:42:53 1991: Time exceeded in transit, code 0
Wed May 22 08:42:54 1991: Time exceeded in transit, code 0
Wed May 22 08:42:54 1991: Time exceeded in transit, code 0
Wed May 22 08:42:56 1991: Time exceeded in transit, code 0
Wed May 22 08:42:57 1991: Time exceeded in transit, code 0
Wed May 22 08:42:58 1991: Time exceeded in transit, code 0
Wed May 22 08:42:58 1991: Time exceeded in transit, code 0
Wed May 22 08:43:00 1991: Time exceeded in transit, code 0
Wed May 22 08:43:00 1991: Time exceeded in transit, code 0
Wed May 22 08:43:03 1991: Time exceeded in transit, code 0
Wed May 22 08:43:03 1991: Time exceeded in transit, code 0
Wed May 22 08:43:05 1991: Time exceeded in transit, code 0
Wed May 22 08:43:06 1991: Time exceeded in transit, code 0
Wed May 22 08:43:06 1991: Time exceeded in transit, code 0
Wed May 22 08:43:08 1991: Time exceeded in transit, code 0
Wed May 22 08:43:08 1991: Time exceeded in transit, code 0
Wed May 22 08:43:09 1991: Time exceeded in transit, code 0
Wed May 22 08:43:10 1991: Time exceeded in transit, code 0
Wed May 22 08:43:10 1991: Time exceeded in transit, code 0
Wed May 22 08:43:12 1991: Time exceeded in transit, code 0
Wed May 22 08:43:12 1991: Time exceeded in transit, code 0
Wed May 22 08:43:13 1991: Time exceeded in transit, code 0
Wed May 22 08:43:14 1991: Time exceeded in transit, code 0
Wed May 22 08:43:16 1991: Time exceeded in transit, code 0
Wed May 22 08:43:16 1991: Time exceeded in transit, code 0
Wed May 22 08:43:18 1991: Time exceeded in transit, code 0
Wed May 22 08:43:18 1991: Time exceeded in transit, code 0
Wed May 22 08:43:20 1991: Time exceeded in transit, code 0
Wed May 22 08:43:21 1991: Time exceeded in transit, code 0
Wed May 22 08:43:22 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:43:22 1991: Time exceeded in transit, code 0
Wed May 22 08:43:22 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:43:22 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:43:23 1991: Time exceeded in transit, code 0
Wed May 22 08:43:23 1991: Time exceeded in transit, code 0
Wed May 22 08:43:24 1991: Time exceeded in transit, code 0
Wed May 22 08:43:59 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:44:05 1991: intermediate: time out. index = 5, real ch# = 3. send msg
Wed May 22 08:44:29 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:44:29 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:44:29 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:45:02 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:45:32 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:45:32 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:45:32 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:45:41 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:45:42 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:46:11 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:46:11 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:46:40 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:46:41 1991: intermed: PK_REJECT chan 6
Wed May 22 08:46:41 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:46:41 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:46:41 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:47:10 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:47:12 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:47:23 1991: intermediate: time out. index = 0, real ch# = 32. send msg
Wed May 22 08:47:42 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:47:42 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:47:42 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:48:13 1991: PKT R 06 Reset Indication 0x0 0x1
Wed May 22 08:48:13 1991: PKT W 06 Reset Confirmation
Wed May 22 08:49:08 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:49:11 1991: Time exceeded in transit, code 0
Wed May 22 08:49:11 1991: Time exceeded in transit, code 0
Wed May 22 08:49:12 1991: Time exceeded in transit, code 0
Wed May 22 08:49:12 1991: Time exceeded in transit, code 0
Wed May 22 08:49:14 1991: Time exceeded in transit, code 0
Wed May 22 08:49:14 1991: Time exceeded in transit, code 0
Wed May 22 08:49:15 1991: Time exceeded in transit, code 0
Wed May 22 08:49:20 1991: Time exceeded in transit, code 0
Wed May 22 08:49:20 1991: Time exceeded in transit, code 0
Wed May 22 08:49:21 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:49:21 1991: Time exceeded in transit, code 0
Wed May 22 08:49:21 1991: Time exceeded in transit, code 0
Wed May 22 08:49:22 1991: Time exceeded in transit, code 0
Wed May 22 08:49:22 1991: Time exceeded in transit, code 0
Wed May 22 08:49:23 1991: Time exceeded in transit, code 0
Wed May 22 08:49:24 1991: Time exceeded in transit, code 0
Wed May 22 08:49:24 1991: Time exceeded in transit, code 0
Wed May 22 08:49:25 1991: Time exceeded in transit, code 0
Wed May 22 08:49:26 1991: Time exceeded in transit, code 0
Wed May 22 08:49:26 1991: Time exceeded in transit, code 0
Wed May 22 08:49:27 1991: Time exceeded in transit, code 0
Wed May 22 08:49:28 1991: Time exceeded in transit, code 0
Wed May 22 08:49:29 1991: Time exceeded in transit, code 0
Wed May 22 08:49:30 1991: Time exceeded in transit, code 0
Wed May 22 08:49:30 1991: Time exceeded in transit, code 0
Wed May 22 08:49:32 1991: Time exceeded in transit, code 0
Wed May 22 08:49:32 1991: Time exceeded in transit, code 0
Wed May 22 08:49:34 1991: Time exceeded in transit, code 0
Wed May 22 08:49:34 1991: Time exceeded in transit, code 0
Wed May 22 08:49:36 1991: Time exceeded in transit, code 0
Wed May 22 08:49:36 1991: Time exceeded in transit, code 0
Wed May 22 08:49:38 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:3
Wed May 22 08:49:38 1991: session: forced close tyx:3 and tcp chan 3.
Wed May 22 08:49:38 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:49:38 1991: Time exceeded in transit, code 0
Wed May 22 08:49:38 1991: Time exceeded in transit, code 0
Wed May 22 08:49:40 1991: Time exceeded in transit, code 0
Wed May 22 08:49:40 1991: Time exceeded in transit, code 0
Wed May 22 08:49:50 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:50:19 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:54:41 1991: intermed: PK_REJECT chan 5
Wed May 22 08:54:41 1991: intermed: PK_REJECT chan 5
Wed May 22 08:54:41 1991: session:tcpeval Opening state receive event 29
Wed May 22 08:54:43 1991: intermed: PK_REJECT chan 5
Wed May 22 08:54:45 1991: intermed: PK_REJECT chan 5
Wed May 22 08:54:51 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:04 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:06 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:09 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:09 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:12 1991: intermed: PK_REJECT chan 4
Wed May 22 08:55:12 1991: intermed: PK_REJECT: channel not S_OPENING!
Wed May 22 08:55:12 1991: session: ERROR: Remote no response after rtxed 15 times in (CLOSING) on tyx:8
Wed May 22 08:55:12 1991: session: forced close tyx:8 and tcp chan 8.
Wed May 22 08:55:12 1991: session: ERROR 29 (CLOSED)
Wed May 22 08:55:16 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:18 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:20 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:22 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:24 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:26 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:28 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:30 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:32 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:34 1991: intermed: PK_REJECT chan 5
Wed May 22 08:55:38 1991: intermed: PK_REJECT chan 5

And it goes on and on and on from here..

**********************TEXT END***************************

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 17:32:35 GMT
From:      WELDEN@JAGUAR.ESS.HARRIS.COM
To:        comp.protocols.tcp-ip
Subject:   Congestion Avoidance-Sources Needed

Thanks to those who responded to my request for assistance. I now need some
references to RFCs, etc which discuss the procedures and/or algorithms that
have been suggested be use with TCP:

   1. Jacobson
   2. Karels
   3. Karn

I would appreciate your suggestions.

Walter Elden, Harris Corp-GCSD
welden@jaguar.ess.harris.com
407/729-3661    407/729-2855 FAX

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 17:35:51 GMT
From:      jamin@JERICO.USC.EDU (Sugih Jamin)
To:        comp.protocols.tcp-ip
Subject:   Paper on Characteristics of TCP/IP Traffic

The following paper, to appear in ACM SIGCOMM '91, is available via 
anonymous FTP from jerico.usc.edu (128.125.51.6):

The file is ~ftp/pub/jamin/traffic/traffic.ps.Z  Be sure to use binary 
mode when doing the transfer.


__________________________________________________________________________
          Characteristics of Wide-Area TCP/IP Conversations

   Ramon Caceres+   Peter B. Danzig*  Sugih Jamin*  Danny J. Mitzel*

   *Computer Science Department, University of Southern California,
                    Los Angeles, California 90089-0782

          +Computer Science Division, University of California, 
                        Berkeley, California 94720

                        traffic@excalibur.usc.edu


                                 Abstract
  In this paper, we characterize wide-area network applications that 
use the TCP transport protocol.  We also describe a new way to model 
the wide-area traffic generated by a stub network.  We believe the 
traffic model presented here will be useful in studying congestion 
control, routing algorithms, and other resource management schemes 
for existing and future networks.   
  Our model is based on trace analysis of TCP/IP wide-area internetwork 
traffic.  We collected the TCP/IP packet headers of USC, UCB, and 
Bellcore networks at the point they connect with their respective 
regional access networks.  We then wrote a handful of programs to 
analyze the traces.  Our model characterizes individual TCP conversations 
by the distributions of: number of bytes transferred, duration, number of 
packets transferred, packet size, and packet interarrival time.
  Our trace analysis shows that both interactive and bulk transfer 
traffic from all sites reflect a large number of short conversations.  
Similarly, it shows that a very large percentage of traffic is 
bidirectional, even for bulk transfer.  We observed that interactive 
applications send significantly different amounts of data in each 
direction of a conversation, and that interarrival times for interactive 
applications closely follow a constant plus exponential model.  Half of 
the conversations are directed to a handful of networks, but the other 
half are directed to hundreds of networks.  Many of these observations 
contradict commonly held beliefs regarding wide-area traffic.

__________________________________________________________________________
Based on the workload characteristics reported in the paper, we would like
to build a wide-area workload model.  To that end, we need to collect more
traces.  If you are at a site on the Internet and are willing to assist us
in collecting wide-area traffic traces, please contact us at 
traffic@excalibur.usc.edu.

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 18:13:17 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Printing to a terminal server

Sorry, list.  I tried to reply directly to John, but the mailers couldn't sort
out his return address.  Besides, this is sort of general...

You may get close, but you won't quite be able to duplicate what we do as we
have a registration and call-back protocol that is unique to us (as far as I
know).  You might be able to set up something that will connect from the Unix
end and send, if the server is available, or you might be able to get it to
work with a permanent type connection.  The dynamic sharing with queued call
back is a bit harder, requiring cooperation from the terminal server.

I probably can't help you more than this, as I've pretty well exhausted my
store of knowledge on the subject, and we can only go so far in supporting
somebody else's terminal server.  :-)

	Bob

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 20:05:17 GMT
From:      mfreeman@cascade.Stanford.EDU (Martin Freeman)
To:        comp.sys.transputer,comp.protocols.tcp-ip,comp.protocols.misc,comp.dcom.lans.hyperchannel,comp.periphs,comp.graphics
Subject:   HOT CHIPS SYMPOSIUM III


           Just When You Thought It Was Safe To Go On Vacation:

                         HOT CHIPS SYMPOSIUM III
                  A Symposium on High-Performance Chips
                            (Advance Program)
 
                 Sponsored by the IEEE Computer Society
                 Technical Committee on Microprocessors

               Stanford University, Palo, Alto, California
                           August 26-27, 1991

Attend HOT Chips III, a symposium on high-performance chips, which will bring
together researchers and developers of chips used to construct high-performance
workstations and systems. Enjoy the informal format offering interaction with
speakers. This first two HOT Chips Symposiums were huge successes and prompted
articles in three special issues of IEEE Micro magazine. This year's HOT Chips
III will again bring you the latest developments in chip technology.

ORGANIZING COMMITTEE

General Chairman:            Martin Freeman, Philips Research
Program Co-Chairmen:         Forest Baskett, Silicon Graphics
                             John Hennessy,  Stanford University
Finance Chairman:            Hasan AlKhatib, Santa Clara University
Registration Chairman:       Robert Stewart, Stewart Research
Publication Chairman:        Nam Ling, Santa Clara University
Publicity Chairman:          Andrew Goforth, NASA Ames Research Center
Local Arrangements Chairman: Robert Stewart, Stewart Research


PROGRAM COMMITTEE

Forest Baskett, Silicon Graphics (Program Co-Chair)
John Crawford, Intel
David Ditzel, Sun Microsystems
John Hennessy, Stanford University (Program Co-Chair)
John Mashey, MIPS Computer Systems
Teresa Meng, Stanford University
Alan Smith, U.C. Berkeley

PROGRAM

August 26, 1991 - Dinkelspiel Auditorium


7:30 - 8:30	Onsite Registration

8:30 - 8:45	Welcome and Opening Remarks
		Martin Freeman, General Chair
  		Forest Baskett and John Hennessy, Program Co-Chairs

8:45 - 10:15	High-Performance Processors - I
		
		. Viking: A Superscalar SPARC Processor
		  Greg Blanck, Sun Microsystems &
		  Steve Krueger, Texas Instruments

		. R4000 Technical Overview
      		  Tom Riordan, MIPS Computer Systems

		. High-Performance PA-RISC Processor for "Snakes" Workstation
		  Mark Forsyth, Charles Kohlhardt, &
                  Ruby Lee, Hewlett Packard

10:15 - 10:45	BREAK

10:45 - 12:15	Highly Parallel Chips

		. The LIFE Family of High-Performance Single Chip VLIWs
		  Gerrit Slavenburg, Philips Research Palo Alto

		. The Message-Driven Processor
		  William Dally, J. Stewart Fiske, Waldemar Horwat, 
		  John Keen, Richard Lethin, Michael Noakes, & Peter Nuth
              	  MIT Artificial Intelligence Laboratory
		  D. Scott Wills
		  University of Central Florida
		  Andrew Chien
		  University of Illinois
		  Salim Ahmed, Paul Carrick, Roy Davison, Greg Fyler, 
		  Steve Lear, Mark Vestrich, & Ted Nguyen
		  Intel

		. The TRW CPUAX Superchip: A 4.1 Million Transistor CMOS CPU
		  A. Miscione, R. Almeida, H. Hennecke, & R. Mann
		  TRW Micro Electronics

12:15 - 1:45	LUNCH

1:45 - 3:15	High-Performance Processors - II

		. An 80 MHz 64-Bit Floating Point RISC Processor with
		  Direct DRAM Support
		  James Hesson, Micron Technology

		. The 80860XP: 2nd Generation of the i860(tm) RISC
		  Processor Family
		  David Perlmutter & Michael Kagan, Intel Israel

		. Beyond Claims of Free Transistors and Abundant
		  Instruction-Level Parallelism
		  Michael Smith, Stanford University

3:15 - 3:45	BREAK

3:45 - 5:15	Low Power and Low Cost

		. SPARC System Chipset
		  Greg Favor, Tera Microsystems
		
		. The SparKIT Chipset: How to Clone a Sparcstation
		  Mohammed Wasfi, LSI Logic Corporation

		. SMM, The "Virtual 386(tm)"
		  Dave Vannier, Intel

5:15 - 7:15	RECEPTION

7:30		EVENING PANEL SESSION: "Five Instructions Per Clock:
		Truth or Consequences"
		Alan Smith, U.C. Berkeley
		John Mashey, MIPS Computer Systems


August 27, 1991 - Dinkelspiel Auditorium


8:00 - 9:00	Onsite Registration

9:00 - 10:30	Communications

		. A GaAs 200 Mbps 64x64 Crosspoint Chip
		  Ron Cates, Vitesse Semiconductor

		. RN1: Low-Latency, Dilated, Crossbar Router
		  Henry Minsky, Tom Knight, Andre' DeHon

		. The NEURON Chip Family Architecture
		  Robert Dolin, Echelon

		. The Protocol Engine Chipset
		  Greg Chesson, Silicon Graphics

10:30 - 11:00	BREAK

11:00 - 12:30	Caches and Floating Point
	
		. R4000 Cache Design Tradeoffs and Performance
		  Earl Killian, MIPS Computer Systems

		. The Megacell Differentiated Floating Point Product Family
		  Merrick Darley, Don Steiss, Peter Groves, David Bural,
		  Maria Gill, & Tod Wolf
		  Texas Instruments

		. High-Integration 2nd Level Cache for the i486 CPU
		  Adi Gobert, Intel Corporation

12:30 - 2:00	LUNCH

2:00 - 3:30	Special Processors

		. C-Cube CL950 MPEG Video Decoder/Processor
		  Stephen Purcell, C-Cube Microsystems

		. A Smart Frame Buffer
		  Joel McCormack, DEC Western Research Laboratory

		. A High-Performance, Low-Cost Neural Chip
		  Gary Tahara, Inova Microelectronics

3:30 - 4:00	BREAK	


4:00 - 5:30	High-Performance Processors - III

		. National's Swordfish - A Superscalar with DSP
		  Reuven Marko & Motti Beck, National Semiconductor

		. H1: A Superscalar Pipelined CPU
		  Bob Krysiak, Richard Forsythe & Roger Sheperd
		  INMOS Ltd.

		. The Pinnacle SPARC Module
		  Raju Vegeshna, Ross Technology
		
5:30		Closing Remarks


HOUSING INFORMATION

Housing is available on the Stanford University campus in Stern Hall, a short
walk from Dinkelspiel Auditorium where the symposium will be held. Housing
is in student residences with central lavatory facilities and costs $40 per
night. A key deposit is required that will be refunded at checkout. Housing
arrangements on the Stanford campus must be mase by July 26.

Housing is also available at numerous hotels and motels on the peninsula in
Palo Alto, Menlo Park, Mountain View, and Los Altos close to Stanford
University.

If you would like additional housing information, please check the housing
information request box on the registration form.

QUESTIONS?

For more information on registration and local arrangements contact Dr. Robert
Stewart at (415) 941-6699 or r.stewart@compmail.com (use email after
June 1).

REGISTRATION FEES

                                     Postmarked by           Subsequent
                                        July 26             Registration

IEEE Computer Society                   $170                   $240
or ACM Member        

Non-Member                              $240                   $290

Full-Time Student                       $75                    $100


Instead of payment by check, registration may be charged to VISA or MasterCard.
Registration charged to a credit card may be FAXed to Dr. Robert Stewart at
(415) 941-6699.

REGISTRATION INCLUDES

* Attendance                        * Sunday evening wine & cheese reception
* One copy of the notes             * Monday evening reception
* Two luncheons                     * Coffee breaks
* Parking at Florence Moore Hall

On-site registration is available Sunday evening at the wine and cheese 
reception, and each morning at the symposium.

WINE & CHEESE RECEPTION

* Sunday, August 25 --- 5:00-7:00 PM
* Rodin Gardens, Stanford University
* A guided tour of the statuary will be provided.


=============================================================================


                      HOT CHIPS III REGISTRATION FORM


Name________________________________________________________________________

Affiliation_________________________________________________________________

Address_____________________________________________________________________

City/State/Zip______________________________________________________________

Country_____________________________________________________________________

Area Code/Phone #___________________________________________________________

Email Address_______________________________________________________________

Membership:       IEEE______          ACM_______

Membership Number___________________________________________________________

Check One:

______Check drawn on a U.S. Bank                    ______MasterCard
      Make Check Payable To:
      Hot Chips Symposium                           ______VISA

Name on Credit Card_________________________________________________________

Credit Card #_______________________________________________________________

Expiration Date_____________________________________________________________

Signature___________________________________________________________________

Amount Enclosed_____________________________________________________________

Mail To:

			Dr. Robert G. Stewart
			Stewart Research Enterprises
			1658 Belvoir Drive
			Los Altos, CA  94024


______Housing Information Requested

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 91 21:07:31 GMT
From:      hutch@SSMCT62.SSC.AF.MIL ("Capt E. Lee Hutchins")
To:        comp.protocols.tcp-ip
Subject:   Limiting Telnet Access V2

I need to clarify my request for info -

	I need to prevent people from REMOTE sites from accessing my
machine via telnet for this particular user.  

	The problem is we have some users using a pseudo-BBS running under
Informix and they are exiting by just closing the telnet connection.  The
BBS is not terminating and eventually the system crashes after 4 or 5 of
these ungraceful connections.

	So I need to do something with the daemon on my end to reget telnet
connections for that particular user.

	I hope this clarifies my request.
			thanx 
				lee
-- 

==============================================================================

			Capt E. Lee Hutchins

USPost Office: HQ SSC/SSMCT          ||   Voice: AV 596-4555/4171
	       Gunter AFB, AL 36114  ||          COM: (205) 279-4555/4171
				     ||
email: hutch@ssmct62.ssc.af.mil      ||   FAX:   AV: 596-3262
		       		     ||	 	 COM: (205) 279-3262

     The views related here do not in any way represent the USAF or USGOV or 
GUNTER AFB, SSMCT or anyone else for that matter!

Go AIR FORCE BEAT Army, Navy or whoever else the FALCONS are playing this week!

		UNIX and X-Windows: the ONLY solution for REAL men 

==============================================================================

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 00:08:02 GMT
From:      sundar@infmx.informix.com (Ramanathan Sundararajan)
To:        comp.protocols.tcp-ip
Subject:   Is there a news group for TLI ??


 Hi the whole GROOOP

 Is there a newsgroup for TLI?  
 It seems now lot of vendors are implementing TLI and does it mean future
 holds great for TLI protocol??


 Inquiring minds want to know in advance!!
                              ----------
Thanks in advance
       ----------- 
  Sundar

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 01:27:00 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)


Having posted, I decided I was being overly rude. 

I went out and did some snmp netstats on the results of traceroute and
other goodies. Suffice to say that a sweeping statement about the IP
capabilities of the UK universities as a whole is a gross
overgeneralization, and there are quite clearly (from the routing
matrices returned by the ciscos of the UK) people out there in JANET
who know *exactly* what they are doing.

My comments about politics were scarcely more useful. I think they are true,
but probably not worth saying. 

I'm interested in why layering over X.25 is being used, rather than MUXing
out bandwidth and using HDLC cards in the routers. would stealing 48k or 64k
splits from the X.25 lines really be that visible? The extra protocol
overheads of X.25-IP barely seem worth the cost savings to me. I'd rather
have the hardware anyday!

-To the networks people of the JANET TCP/IP group, I abjectly apologize
and take my (metaphorical) akubra off to you. I look forward to talk
sessions with family & friends over these links in the not-too-distant
future!

	-George

-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 05:57:32 GMT
From:      kzm@hls.com (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the rules for Object Instances?

Bob,

Your explanation was accurate, but you may have conveyed an impression 
you didn't intend:

>                                                          For an object with
> multiple instances, such as ifSpeed, the instance identifier suits the object
> and is non-zero.  

This is indeed true for ifSpeed.   However, there is nothing which prohibits
the definition of an instance identifier (i.e. a MIB table's INDEX variable)
which can take the value of zero.  

The closest to an example of this in the core MIB (i.e. MIB-II) is the 
IP Routing Table.  Instances of objects in the IP Routing Table take the
associated route's destination as their instance identifier.  For a 
"default route", the instance of each object has the instance identifier 
of 0.0.0.0 (i.e. four OID sub-identifiers each of which has the value 
of zero).

Keith.

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 09:00:13 GMT
From:      fkam@Asia.Sun.COM (francis kam)
To:        ba.internet,comp.protocols.tcp-ip
Subject:   Telenet/X25 Internet connection

I have a Sun box running SunLink X25 with a sync. modem to Telenet X25.

I want to establish that node as an IP point-to-point gateway on X25
to the Internet community via Telenet.

I presume that given the X25 address on an Internet node in the continental 
USA which is accessible at the X25 level via Telenet, I can establish
such a link and use that remote node as a gateway.

I now need to do two things: 

1) get an Internet domain from NIC;
2) arrange for such a remote node to tap onto.

Since I have never done this before and I'm doing this for a customer who
has already had Telenet X25 access (who's willing to pay subscription fee
for such a remote node), I would be grateful if someone out there could
give me some hints as to whether there are services like this and tap
point, and for how much?  (I also sent a mail to uunet asking similar
service)

My appreciation to any information.

-- Francis Kam
Sun Asia
Customer Service

Internet: francis.kam@asia.sun.com


--

Francis Kam
SUN Microsystems (Asia)
Sr. Software Engineer
francis.kam@asia.sun.com

* Disclaimer: 
  the opinion is strictly of my own, and in particular, NOT from my employer.

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 12:16:24 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Congestion Avoidance-Sources Needed

In <9106050941.AA15632@ucbvax.Berkeley.EDU> WELDEN@JAGUAR.ESS.HARRIS.COM writes:

>Thanks to those who responded to my request for assistance. I now need some
>references to RFCs, etc which discuss the procedures and/or algorithms that
>have been suggested be use with TCP:
 
>   1. Jacobson
>   2. Karels
>   3. Karn

Karn's algorithm is described in Karn & Partridge's paper in the Proc.
    SIGCOMM '87

Jacobson's work with Karels is described in Jacobson's paper in Proc.
    SIGCOMM '88

Craig Partridge
Editor, ACM SIGCOMM Computer Communication Review

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 12:31:19 GMT
From:      brenner@ucunix.san.uc.edu (David L. Brenner)
To:        comp.dcom.lans,comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Which products allow remote LAN dial-up access?

The company I'm working for is looking to buy a product that will allow
users to dial into our LAN.  Any information on such a product would 
help greatly.

Please e-mail me directly and I will post a summary in comp.dcom.lans.

Thanks in advance,
David Brenner
brenner@ucunix.san.uc.edu 
-- 
David L. Brenner                         brenner@ucunix.san.uc.edu
"Sorry, guys -- breaking into computers and writing a stupid virus
 doesn't make you a hacker.  It's not that easy."
  -- Robert Stevenson, Computerworld

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 13:08:53 GMT
From:      zzassgl@uts.mcc.ac.uk (Geoff Lane)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

In article <7957@ecs.soton.ac.uk> tjc@ecs.soton.ac.uk (Tim Chown) writes:
>Here at Southampton our Electronics and Computer Science departmental 
>connections are all TCP/IP; we have 200+ nodes on our local network.
>Now we're just about to have our campus network go live, and yes, it all
>runs by Pink Book.  Our Computing Services who will adminster this beauty
>have had it imposed on them from above by some national committee.  Yum.
>Somewhere someone needs their head removing from their a**e !!!
>	Tim


Aha! Another fan of the famous JNT!   The glorious committee which
insists that everyone uses Janet protocols and only now are being
dragged kicking and screaming into the mid 1970's.
We here at Manchester also have hundreds of TCP/IP equiped PCs and
workstations.  We run our own name servers etc but as soon as we
want to talk to some other site its back to the good old Janet
protocols across X25 lines.  If it were cheaper, or quicker or
more reliable then it would make sense - but it is not.  In its time
the Coloured book protocols were a worthwhile attempt to bring
some kind of organisation to computer networking when there were few
if any standards, but the world has rejected these ideas and gone for
something different.

It would make some sense if the Coloured Book protocol software was
freely available to anyone on request but it isn't.  I attempted to
get hold of the Pink Book s/w in order to port it to a new Unix machine
we installed. It appears that I have to ask Amdahl, the suppliers of the
hardware and OS, to place a contract with the S/W developers to port
Pinkbook to the UTS system (a version of Sys V Unix) and then I have to
ask the JNT to provide funds so we can then buy the ported s/w from
Amdahl!

Soon the agony will be over. By October (or sooner) there will be
no physical or technical reasons why the UK should not be fully connected
to the Internet.  If non-UK sites still cannot finger at least some
UK based systems then it will be due to politics pure and simple.

This flamette was brought to you by me the undersigned and only represents
the views of the users - not the administration - of this centre ;-)
-- 
Geoff. Lane.                                  Janet: zzassgl@uk.ac.mcc.cms
UTS Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 13:39:32 GMT
From:      grahamt@syma.sussex.ac.uk (Graham S Thomas)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

From article <7957@ecs.soton.ac.uk>, by tjc@ecs.soton.ac.uk (Tim Chown):
> 
> Here at Southampton our Electronics and Computer Science departmental 
> connections are all TCP/IP; we have 200+ nodes on our local network.
> Now we're just about to have our campus network go live, and yes, it all
> runs by Pink Book.  Our Computing Services who will adminster this beauty
> have had it imposed on them from above by some national committee.  Yum.
> Somewhere someone needs their head removing from their a**e !!!

When the Coloured Book software suite was conceived, it was (according
to my best information - correct me if I'm wrong) by no means clear that
TCP/IP would become as dominant as it has today.  In any case, the
Coloured Books were always seen as ultimately giving way to full OSI
protocols.  Again, the originators could not have forseen that OSI would
be such a long time a-comin', or that it could conceivably be threatened
by semi-open protocols like TCP/IP.

Admittedly, it might have taken a little too long for the JANET
management to face up to commercial realities (i.e. TCP/IP comes cheaper
and quicker for new machines) and user desires (the rest of the world -
exaggerating a bit - uses it, so why can't we?).  But early this year
the decision was taken to offer TCP/IP over JANET as a supplementary
protocol.  My impression at this April's JANET Networkshop was that
there is a lot of effort being put into its implementation, and there
are a lot of potential users keen to see that this effort doesn't flag.

So, hang on in there until (maybe) the beginning of '92.  Already, you can
transfer files to & from the Internet using uk.ac.ft-relay, and it's
possible to get an account on uk.ac.nsfnet-relay from which you can
telnet across the world.  So it's not all doom and gloom!

Graham
-- 
Graham Thomas, SPRU, Mantell Building, U of Sussex, Brighton, BN1 9RF, UK
Email: grahamt@syma.sussex.ac.uk   Phone: +44 273 678165   Fax: .. 685865

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 14:02:08 GMT
From:      jpoller@netxcom.netx.com (Jack Poller)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the rules for Object Instances? - mistake

In article <438@netxcom.netx.com> jpoller@netxcom.netx.com (Jack Poller) writes:
#In article <23109@shlump.lkg.dec.com> jc@netrix.nac.dec.com writes:

#   getnext sysDescr.0      returns      sysUpTime.0 = 14123
                                        ^^^^^^^^^^^^^^^^^^

    Sorry Folks, I made a mistake.  I did not have the mib in front of
    me.

    According to RFC1156 - MIB I, 

    sysDescr = { system 1 }
    sysObjectId = { system 2 }
    sysUpTime = { system 3 }

    Therefore

    getnext sysDescr.0    returns  sysObjectId.0 = ......
    getnext sysObjectId.0 returns  sysUpTime.0 = 12345

    because of the lexicographical orderings.  

    Sorry for any confusion

    Jack
    
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jack L. Poller     (703) 749-2240    Telex 901976     G3 Fax (703) 749-2375
NetExpress, Inc., 1953 Gallows Road, Suite 300, Vienna, Virgina 22182
                           ...!uunet!netxcom!jpoller

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 14:46:21 GMT
From:      psimpson@oucsace.cs.OHIOU.EDU (Pete Simpson)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

In article <EMV.91May31153318@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
>> 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.
>

	Are there maps at any other locations? I cannot reach this
site.

		thanks for the info-
						pete

-- 
Peter J. Simpson |Internet: psimpson@oucsace.cs.ohiou.edu |Gotten it up
Computer Science |Bitnet: TCOMGRD1 at OUACCVMB            |      lately??
Ohio University  |Amateur Radio: KB9DWN                   | 
Athens, Ohio     |                                        |Fly a Hobie!!

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 14:47:44 GMT
From:      van@EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   saturating an ethernet from 1000 miles away

A minor milestone in high-speed, long-haul networking happened
at the recent Educom National Net '91 conference in Washington,
DC:  TCP transfers from a Cray YMP at Pittsburgh Supercomputer
Center to a Sun Sparcstation-2 on the show floor ran at a
sustained rate of 10Mb/s (by `sustained' I mean sustained over
hundreds of megabytes of data transferred -- In one of the first
tests, we shipped 256MB from the PSC to DC in 3.9 minutes).  The
rough topology was:

	   FDDI            T3 backbone        Ethernet
	  100Mb/s            45Mb/s            10Mb/s
  PSC YMP -------> PSC ENSS --....--> DC ENSS ---------> SS-2

The limiting bandwidth was the show ethernet & we ran at that
bandwidth.  If we could have gotten in & out of the ENSS at >=
45Mb/s, we would have run at the 45Mb/s NSFNet backbone
bandwidth.  (Dave Borman's Cray TCP has been measured at over
300Mb/s.  My TCP on the SS-2 runs 48Mb/s through the loopback
interface (i.e., copying all the data twice, doing both sides of
the protocol & context switching on every packet) and should
easily sink or source >100Mb/s as soon as Sun comes up with a
decent high-speed network interface.)

The real milestone is that two completely independent
implementations of the RFC1072/RFC1185 "fat pipe" extensions,
one by Dave Borman of Cray Research for Unicos on the YMP & one
by me for an experimental TCP/IP running on the SS-2,
interoperated with no problems.  [This gave me no small measure
of joy:  Sun demonstrated their normal inability to supply system
source to academic sites & I didn't get a copy of 4.1.1 (the
only version of Sun OS that would run on a SS-2) until Friday of
the week before the show.  I spent a very long weekend
throwing out Sun's network & IPC code & replacing it with my
experimental 4.4BSD stuff and got a working kernel 45 minutes
before the movers came to crate up our lone Sparcstation-2 &
ship it from California to DC.  So the very first chance to
test my RFC1072 implementation against Dave Borman's was when we
got the machine uncrated & connected the SS-2 to the show net in
DC.  I was all resigned to another 36 hours of sleepless
debugging when, to my utter astonishment, the Cray &
Sparcstation flawlessly negotiated a 512KB window & timestamps,
then happily started exchanging data at a very high rate.
(Several other groups were busy setting up their demos.  I
started up my usual throughput test programs on the Cray & Sun
then looked down at the `recv' indicator light on the Cabletron
transceiver & noticed it was on solid -- I stared at it for at
least 30 seconds & it didn't even blink.  Right after that I
heard one of the Cornell people say ``What happened to the
network?  Our connection seems to have stopped.'' and I did my
best to look innocent while the test finished.)]

The big disappointment was that I was worried about what would
happen when the TCP congestion avoidance / recovery algorithms
started interacting with half a megabyte of stored energy
(in-transit data) in the pipe.  So I'd spend a bunch of time
tuning the Fast Retransmit and Fast Recovery algorithms & had a
bunch of instrumentation set up to watch how they'd perform.
But the damn T3 NSFNet refused to drop packets -- we shipped
slightly more than 30GB (roughly 22 million data packets) during
the three days of the show & the kernel network stats said that
6 were dropped.  Naturally, I wasn't watching for any of
these 6 & a 0.00003% loss rate wasn't enough test any of the
spiffy new algorithms.  Oh well, maybe next time I'll bring my
wire cutters and chop halfway through the cable to make things a
bit more interesting.

[The one interesting piece of behavior had to do with the
ethernet controller on the Sun:  The LANCE is a half-duplex
device so if it's receiving back-to-back ethernet packets it will
never attempt to transmit, even if it has data available to
send.  TCP will attempt to ack every other packet but, since new
data packets were arriving back-to-back from the ENSS, the ack
packets just got queued in the LANCE on the SS-2.  Since the
acks can't get out, eventually (after half a megabyte is sent)
the window on the Cray should close, it should stop sending
packets & the SS-2 should get to dump 180 back-to-back ack
packets, re-opening the window & restarting the data flow.  This
would have resulted in essentially the stop-and-wait performance
of a BLAST protocol but, fortunately, there seems to be a 128KB
buffer somewhere in the T3 NSFNet so after 90 data packets there
was a 30us pause, allowing the SS-2 LANCE to grab the ethernet,
dump 45 back-to-back acks, then start collecting the next 90
data packets.  So the window on the Cray never shut & the pipe
stayed full -- due to essentially an engineering mistake in the
network (a transcontinental T3 run at T3 needs at least half a
meg of buffer everywhere a queue can form).  This, incidentally,
is one reason why we used a half megabyte window instead of the
80KB window required to fill a 36ms RTT into 10Mb bandwidth-delay
product.]

Anyway, I'm writing this mostly to document that it happened &
to thank all the people at LBL, PSC, Merit, Cray & Sun that made
it happen.  I'm particularly grateful to Dave Borman for some
great Cray TCP software and to Geoff Baehr at Sun for battling
with the lawyers and getting us the system pieces we needed
(it's nice to know that at least part of Sun still ranks
engineering over bean counting).  And I am eternally grateful to
Wendy Huntoon of PSC & Elise Gerich of Merit who put in long,
long hours to get the new and almost untested PSC & NSF T3
connections up & running, then kept everything running smoothly
and essentially trouble free for the entire show.

 - Van Jacobson

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 16:30:54 GMT
From:      aaron@ahkcus.org (Aaron Y.T. Cheung)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Equip. providers info & expeirnece sought for building FDDI backbone

I'd appreciate equipment providers info & summary of experience
in building an FDDI LAN.  Number of host to be connected is
about 100, spread over a 3-story building.

In particular,
- What topologies are better choices
- Equipments and cost involved for setting up the LAN
- Info/cost about desktop interfaces to Sun's, Mac's & PC's
- What to watch out for

Alternatively, ethernet-over-fiber info & experience would also be helpful.

Thanks in advance,
/aaron. <aaron@ahkcus.org>

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 16:54:48 GMT
From:      poulson@cs.widener.edu (Joshua Poulson)
To:        comp.protocols.tcp-ip
Subject:   Getting a couple class "C" networks

Here at Widener we were planning on splitting up our network and using
filters a various points.  We want to assign entirely separate Class "C"
networks to various internal segments that will not be accessible from
the outside world (except through a router/filter/bridge) and will not
require access to the outside world.

Should I just make up numbers and wing it or should I register two new
Class "C" networks and be totally official in case one of my
routers/filters/bridges dies or works incorrectly.  

Doing things this way makes it easier since our original network is also
Class "C" and is getting crowded.  Don't flame me about Class "C" since
it wasn't my decision.

Thanks for any advice or suggestions.
-- 
Joshua R. Poulson                          [Joshua.R.Poulson@cyber.Widener.EDU]
"I speak only for myself, okay?"           [poulson@cs.Widener.EDU]
"It is better to play the game and lose than it is to argue about the
instructions." (Me, 1991)

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 17:03:31 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: What are the rules for Object Instances?

>Bob,
>
>Your explanation was accurate, but you may have conveyed an impression
>you didn't intend:

{Good stuff deleted}

>Keith

Actually, I said what I meant but I was slightly wrong.  Now I'll remember
that an instance identification can be zero.  It was a detail that never sunk
in.  Thanks for keeping it straight.

	Bob

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 19:29:30 GMT
From:      wright@hsi86.hsi.com (Gary Wright)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   The Art of Distributed Applications

Can anyone provide a publisher or ISBN number for this book?
The author is John Corbin.
-- 
Gary Wright                                                 ...!uunet!hsi!wright
3M Health Information Systems					  wright@hsi.com

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 20:40:15 GMT
From:      endrizzi@sctc.com (Michael Endrizzi )
To:        comp.protocols.tcp-ip
Subject:   Advice: CMC vs SBE


We are looking for an intelligent controller
, VME based with TCP/IP on-board processing.
We have narrowed the contenders to CMC and SBE.
If anyone has any comments to make on the vendors
we would appreciate hearing from you.


                        Dreez

=================================================================
=================================================================
               Michael J. Endrizzi
	            SCTC
	   1210 W. County Road E #100
	      Arden Hills, Mn. 55112
	        endrizzi@sctc.com
	          (612) 482-7425
	
*Disclaimer: The opinions expressed above are not of my employer
             but of the American people.
=================================================================
=================================================================

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 21:35:56 GMT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP checksums

In article <9105311628.AA24660@berserkly.cray.com> dab@BERSERKLY.CRAY.COM (David Borman) writes:
>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.

Err.., excuse me.  Those of us with hardware that actually does one's
complement (horrors!) arithmentic can depend on the hardware never
generating a -0 as the result of any arithmetic operation.  So, in
fact, I do get checksums computed with a value of 0x0000, which might
be turned into a 0xffff when you take the one's complement.

Of course, my hardware also have 9 bit bytes...

louie

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 91 22:52:34 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   traceroute hacking


 Has anybody hacked on traceroute to have it do a T_PTR query to the
nameserver for any Internet address that fails the gethostbyaddr() call?

 My intention is to have it give the names for the various gateways that a
packet goes through, not have bland numbers all over the place.  I've
started to do it, but I'd rather not spend two days refreshing myself on
network programming only to discover it's been done. :-)

Thanks for any ideas.

Brendan
-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
    Vanilla Ice == Richard VanWinkle .. hehe .. hohoho .. Hahahahahahahaha.

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 03:29:08 GMT
From:      fkam@sodium.Asia.Sun.COM (Francis Kam - Asia CS)
To:        comp.protocols.tcp-ip
Subject:   Telenet/X25  IP connection

I have a Sun box running SunLink X25 with a sync. modem to Telenet X25.

I want to establish that node as an IP point-to-point gateway on X25
to the Internet community via Telenet.

I presume that given the X25 address on an Internet node in the continental 
USA which is accessible at the X25 level via Telenet, I can establish
such a link and use that remote node as a gateway.

I now need to do two things: 

1) get an Internet domain from NIC;
2) arrange for such a remote node to tap onto.

Since I have never done this before and I'm doing this for a customer who
has already had Telenet X25 access (who's willing to pay subscription fee
for such a remote node), I would be grateful if someone out there could
give me some hints as to whether there are services like this and tap
point, and for how much?  (I also sent a mail to uunet asking similar
service)

My appreciation to any information.

-- Francis Kam
Sun Asia
Customer Service

Internet: francis.kam@asia.sun.com



--

Francis Kam
SUN Microsystems (Asia)
Sr. Software Engineer
francis.kam@asia.sun.com

* Disclaimer: 
  the opinion is strictly of my own, and in particular, NOT from my employer.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 06:00:36 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: traceroute hacking

In article <#W#-G5K@cs.widener.edu> brendan@cs.widener.edu writes:
> Has anybody hacked on traceroute to have it do a T_PTR query to the
>nameserver for any Internet address that fails the gethostbyaddr() call?

Don't hack traceroute, get a version of gethostbyaddr() that uses the
domain system.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 06:09:55 GMT
From:      deraadt@cpsc.ucalgary.ca (Theo de Raadt)
To:        comp.protocols.tcp-ip
Subject:   tiny tcp

Has anyone built tinytcp into a usable boot rom for a machine?
It would save me two or three days :-)
 <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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 06:24:15 GMT
From:      ccrth@lut.ac.uk (Rob Thirlby)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

Keywords: 

The decision to use IP tunelling rather than multiplexing our access
lines to janet reflects the very variable and unpredictable demand from
sites and the wide disparity of bandwidth of the access lines.  Also
many of us are hoping to use tunelling facilities in our existing kit
such as netcomm switches/ECB rather than buy unnecessary routers.

We are getting there.  The pilot scheme is being persued with vigour and
many sites such as mine will ensure that the pressure to offer a 
service is kept up!  After all isnt it said in religious circles
that late converts make the most devout members?

Yrs,

Rob Thirlby

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 09:15:20 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Need advice on good terminal servers

I'm looking at purchasing a terminal server and would like some
recommendations on which brands/models offer the best price/features
etc.

Also what features should I be looking for in a terminal server?


		Thanks,
			Stuart Szabo


-- 
Postal:    Co-Cam Computer Services              |  Stuart Szabo
	   18-22 Trenerry Cr                     |  sgs@rand.mel.cocam.oz.au 
           Abbotsford, VIC 3067                  |  +61 3 412-3411 (voice)      
	   Melbourne,  Australia                 |  +61 3 417-7857 (fax) 

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 10:13:33 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)



 >I'm interested in why layering over X.25 is being used, rather than MUXing
 >out bandwidth and using HDLC cards in the routers. would stealing 48k or 64k
 >splits from the X.25 lines really be that visible? The extra protocol
 >overheads of X.25-IP barely seem worth the cost savings to me. I'd rather

geo:

To split out bandwidth by muxing would be to pre-decide how much...
and would cost some for muxes... the current choice represents
expediency and manageablity...(though for more money, we could buy
snazzy controllable muxes).

the routers have 2Mbps lines to the backbone x.25 switches - we can
tune the amount shared twixt native x.25 and IP ... by varying clocks
etc...

for well engineered (read giant window & packet size) x.25 at 2Mbps,
you dont get x.25 window blocking IP, so minimal overhead and neet
enforcement of share... experience in other nets of IP on x.25 usually
had poor x.25 implementations (read window 2, max packet size 128),
and so negative comments from elsewhere are often (not always)
discounted (though less by me:-).

of course, I would prefer frame relay to X.25 full protocol, then
there wouldnt be weird interactions between retransmits at x.25 and
above IP, but we await this...in any case, since the backbone cable
plant has very low error rate, we see this rarely...more often is
interaction twixt congestion control inside the switch cloud, and
congestion avoidance twixt TCP end points...

Another path to IP involves the x.25 backbone switches running the IP
tunnel (and later migrating to run this over frame relay internally)
this is being tried/evaluated...as will be isdn & SMDS...

 jon
p.s. if you run an AFS filesystem that we can access, please let us
know - we are currently seeing the usual set of places
(transarc/cmu/mit etc etc) but would find it amusing to go even
further afield like as far as OZ:-)

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 13:06:45 GMT
From:      seger@bugend.edvina.se (Nils Segerdahl)
To:        comp.protocols.tcp-ip
Subject:   Stop subscription


Please remove me from the mailinglist.
--  
-------------------------------------------------------------------------- 
Nils Segerdahl                                         Cogito ergo Hack!

E-mail: seger@upsys.se  seger@edvina.se  seger@stacken.kth.se

UPSYS AB                                              home: (+46)18519588 
box 15103,                                          office: (+46)18261300 
S-750 15 Uppsala, SWEDEN                            pocket: (+46)10896503
-------------------------------------------------------------------------- 

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 13:45:16 GMT
From:      rstory@xopen.co.uk (Robert Story)
To:        comp.protocols.tcp-ip
Subject:   Re: Map of Internet

From article <6822@archive.BBN.COM>, by kwe@bbn.com (Kent W. England):
> In article <1991May28.212310.23424@Spies.COM> joshua@Spies.COM (Joshua 
> Geller) writes:
>> 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 
> 
> Even that is not so simple as it would seem.  For example, only a few 
> people have actually seen a topology map of the new NSFnet T3 backbone.  
> The public maps I see are a little "cloudy".   I'm not complaining, mind 
> you, just noting that maps are hard for a number of reasons.
 What is the new NSFnet T3 bacbone??
-- 

Regards,
	Robert.
----------------------------------------------------------------------------
Robert Story                                          X/Open Company Limited
UUCP : ...uunet!ukc!xopen!rstory                    Apex Plaza, Forbury Road
EMail: r.story@xopen.co.uk                         Reading, England, RG1 1AX
Voice: +(44) (0)734 508311                          FAX: +(44) (0)734 500110 

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 14:01:29 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: When will DDN switch to GOSIP?

There is a document "Army Open Systems Interconnection (OSI)
Interoperability and Transition Plan" that you should probably
try to get through Army channels.  I imagine it came from
USAISC at Ft Huachuca.  The people who did this would also have
access to various other DOD OSI transition information.

As for the DDN I would just briefly (and unofficially, but I
think accurately) state that the capability to support connectivity
through the PSN backbone between OSI systems has existed for some
time already.  There is really nothing to "switch" about the PSN
backbone, though some enhancements might be done for performance
reasons or to add features, should that seem to be necessary (this
is an open topic now), and appendages such as mailbridges, NIC, etc.,
do have to have OSI capabilities added eventually in order to make those
functions accessible to OSI users.

If you have boxes with GOSIP-compliant protocol stacks that include
X.25, you can connect them to the PSNs now, configure them to know
about each other and proceed to talk OSI between them.  The port
must have Basic service enabled (either basic only or basic+standard,
whatever you require).  The lack of GOSIP routing protocols has some
effects on what you can do (or more precisely, on how you can make
it happen and whether you will be glad you did) but the only real
functional limitation that comes to mind is that you can't talk pure
OSI to the non-DOD part of the Internet at the moment.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 15:34:06 GMT
From:      rubin@watson.ibm.com (Bill Rubin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In <9106021941.AA11777@ucbvax.Berkeley.EDU> NJG@CORNELLC.CIT.CORNELL.EDU ("Nick Gimbrone ", WIRDI: Whatever Is Right,  writes:
> >        Is anyone has any network printing solution for IBM TCP/IP with MVS
> Version 2 of the IBM TCP/IP code for VM and MVS include lpr/lpd support.

Sorry, Nick, you're only half correct.  VM V2 does have LPR/LPD, but for MVS
V2, all we announced was a 'Statement of Direction'.  That is IBMese for "we
don't have it (LPR/LPD) now, but we're going to in the future".

-- Bill rubin@watson.ibm.com
   IBM TJ Watson Research

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 15:41:56 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: B&W, FTP, Intercon, Interlink, and TGV Utilities Agreement

In article <42921@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:
> 1) Why did this group choose to create its own authentication, timing,
> and other basic services?  Why not just implement the OSF services?
> Was the desire to have a completely public-domain alternative to
> the OSF services?
> 

Yes, although I would rather call it open standards, than public-domain.

> 2) Why is Sun absent from the list of sponsoring companies?  
> Since you are using their RPC for these services, it seems
> like they have a lot to gain (publicity-wise, at least).
> 

Yes they do.  When they will "join" is not known.  I am relativly sure that 
they will at some point.

> 3) The article says that the initial project concentrates on mail
> and print services.  Can someone explain exactly what is being done
> here, and why are SMTP/POP and LPD-type utilities not sufficient
> for the desired purpose?
> 

Think of SMTP/POP as 1st generation applications/protocols.  Then it will 
become clearer what is being attempted.  Keep your eyes open around InterOp 91.

> This strikes me as an interesting agreement, somewhat in the spirit
> of FTP's initial packet-driver effort.  With strong support from the
> user community it might just succeed.

I think I speak for all.  We hope that this is true.


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 15:45:20 GMT
From:      rubin@watson.ibm.com (Bill Rubin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP software on VM

In <9106011041.AA23847@ucbvax.Berkeley.EDU> ROMANO@IVRUNIV.BITNET (Romano Rosponi) writes:
> Have I read right ?
> Is there a TCP/IP version 2 for VM ?
> (IBM has just offered us a TCP/IP V1.2 for VM).
>
> staying in doubt...

IBM's TCP/IP V1 for VM (product number 5798-FAL) was withdrawn from
marketing in the US on 12/28/90, as announced on 6/19/90.  Outside of the
US, it may have been a bit later, but I'd be very surprised if V1 was still
orderable.  The replacement product number is 5735-FAL.

Perhaps your IBMers just have their terminology wrong?  Even people here in
development mistakenly still call it Release 2 instead of Version 2.

-- Bill rubin@watson.ibm.com
   IBM TJ Watson Research

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 15:49:03 GMT
From:      Jswisher@HUACHUCA-EMH8.ARMY.MIL
To:        comp.protocols.tcp-ip
Subject:   Re:  When will DDN switch to GOSIP?

Gary,

You are incorrect when you stated that TCP/IP is NOT on the SMC contract.

              TCP/IP IS ON THE SMC Contract.
              
CLIN       DESCRIPTION        VENDOR       PRODUCT
0906CA     SMC DDN Host SW    Prime        EXL X.25 TCP/IP

It provides access to DDN and TCP/IP hosts.

By providing GOSIP, OpenNET, and TCP/IP products, the Prime EXL can
be used as a bridge between these different LAN architectures.


 _________________________________
*                                 *
*       CPT JOEL V. SWISHER       *
*            U.S. ARMY            *
*   COMPUTER ENGINEERING CENTER   *
* jswisher@huachuca-emh8.army.mil *
* DSN:821-2865 COMM:(602)533-2865 *
*_________________________________*

Received: from alamo by cochise.huachuca-emh8.army.mil id aa13838;
          5 Jun 91 18:54 MDT
Received: from alamo.huachuca-emh8.army.mil by alamo.huachuca-emh8.army.mil
          id aa13391; 5 Jun 91 18:32 MDT
Received: from nic.ddn.mil by alamo.huachuca-emh8.army.mil id aa13339;
          5 Jun 91 18:22 MDT
Received: from shafter-emh2.army.mil by NIC.DDN.MIL with TCP; Tue, 4 Jun 91 12:40:42 PDT
Received: by shafter-emh2.army.mil (sendmail(4.12)/R3-6.3(SMS))
	id AA12423; Tue, 4 Jun 91 09:44:49 hst
Received: by aprm (smail2.5)
	id AA18505; 4 Jun 91 09:42:41 HST (Tue)
To: tcp-ip@NIC.DDN.MIL
Subject: When will DDN switch to GOSIP?
Date: Tue Jun  4 09:42:39 1991
Message-Id: <9106040942.AA18505@aprm>
From: Gary Dunn <aprm%gd@SHAFTER-EMH2.ARMY.MIL>

Text: 

The Army Small Multiuser Computer (SMC) contract, awarded to EDS,
uses TP4 for the transport layer and supports Intel's OpenNET and the
new GOSIP protocols.  TCP/IP is not on the contract, but DDN
connectivity hardware and software are.

Is DoD making a move to change DDN from TCP/IP to GOSIP? If so, what is
the timetable?

  --Gary Dunn
    U.S. Army USARPAC DCSRM IMO

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

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 16:27:48 GMT
From:      richa@gnarly.WV.TEK.COM (Rich Ahrendt)
To:        comp.protocols.tcp-ip
Subject:   Novell - Banyon - TCP/IP - E-Mail

I manage an TCP/IP backbone and have been ask to connect a Novell net for
E-mail to the campus.  Has anyone any ideas on an E-mail package that
will interoperate with SMTP?  I have heard there is something new release 3
from Novell, anyone have it working?

		Rich
repl by e-mail: richa@orca.wv.tek.com 
  ************************  NETWorks Support  ************************
       Rich Ahrendt *  (503)685-2605 *  richa@orca.wv.tek.com 
       ComputerGraphicsGroup *** Tektronix Wilsonville,Oregon 

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 18:05:10 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: traceroute hacking

barmar@think.com wrote:
>In article <#W#-G5K@cs.widener.edu> brendan@cs.widener.edu writes:
>> Has anybody hacked on traceroute to have it do a T_PTR query to the
>>nameserver for any Internet address that fails the gethostbyaddr() call?
>
>Don't hack traceroute, get a version of gethostbyaddr() that uses the
>domain system.

 Or make sure the Berkeley resolv library you link it with is really the
Berkeley library, not Sun's resolv (for some reason I forgot to move
libresolv-bsd.a over to libresolv.a). <<cough>>

 Followups to /dev/null; flames to /dev/dsk/funny-farm, where I wanted to
take a trip to when I realized why gethostbyaddr() was failing.

Brendan
-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
    Vanilla Ice == Richard VanWinkle .. hehe .. hohoho .. Hahahahahahahaha.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 18:48:42 GMT
From:      Russ_Housley.McLean_CSD@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software for DOS PCs

I need source-level implementations of IP, ARP, and ICMP for the  MS-DOS /
PC-DOS environment.  I have located two vendors willing to sell me their source
code implementations of these protocols:  Wollongong and FTP Software.

Wollongong supports the WD8013 ethernet board that I have in 16-bit mode, but
their ICMP implementation does not provide Source Quench.

FTP Software requires that I use a packet driver to use the WD8013 ethernet
board in 16-bit mode, but their ICMP implementation provides Source Quench.

So far, these are the only differences I have been able to determine between
the two offers.  Would anyone on this mailing list care to share experience
with either of these implementations?

Thanks in advance for your assistance. And, please reply directly to me.

Russ

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 18:57:15 GMT
From:      philb@versyss.uucp (Phil Burtis)
To:        comp.protocols.tcp-ip
Subject:   Is there such a thing as a uucp daemon?

We are running SVR3.2 ATT Unix.  We have Interlan boards
and software.  We run TCP-IP (mostly telnet, ftp) and also
do some RFS over the net.  Would like to be able to have
uucp go over the net as well.  We've been told we need
a uucp daemon (uucpd?) and we don't know where to get it.
Interlan doesn't supply it, and ATT doesn't either.
Suggestions?  Thanks in advance for your time and reply.

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 19:15:00 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

Graham Thomas--

I'd be so fascinated to see an explanation of your depiction of TCP/IP
as "SEMI-open" [emphasis added] that I'd even forego the pleasure
of debating whether the originators of the "Coloured Books" SHOULD
have realized [or, more locally appropriate, realised] that OSI
would be a very long time in coming, in exchange.

cheers, map
-------

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 19:35:07 GMT
From:      aprm%gd@SHAFTER-EMH2.ARMY.MIL (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   Re: Strange slowness

Text: 
 --- Forwarding Mail ----------
Comment: 
I passed the posting about problems with an Intergraph to an associate;
here's his reply.

  --gd

 --- Enclosure ----------------
>From asbp%dmillard Fri Jun  7 14:54:10 1991
Received: by aprm (smail2.5)
	id AA03871; 7 Jun 91 14:54:08 HST (Fri)
To: aprm%gd
Subject: Re: Strange slowness
Cc: asbp%dmillard
Date: Fri Jun  7 14:52:17 1991
Message-Id: <9106071454.AA03871@aprm>
From: asbp%dmillard (OpenNET Mail)

Gary

        The problem is most likely poor TCP/IP on the I tergraph.  Likely
many, many, many retransmissions.  The guy should put an analyser on the 802.3

Dave


 --- End of Enclosure ---------

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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 91 23:33:29 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

I suspect that my lack of knowledge of the internal architecture of the
IP/X25 connections is the source of  some confusion for me. 

-I'm assuming that you are doing IP tunnels to one common endpoint
which is feeding into the Internet, and thus there is no "logical"
common backbone beyond a star-hub (a cisco in ulcc or ucl?).  

I'm also assuming that down the track this will not scale well, and
some degree of distribution of the load will prove neccessary. 

-That means that IP routing boxes will be inter-connecting to form a
backbone, and there WILL be some kind of shared usage of trunk lines.

Question: would *THAT* traffic be done using X.25 tunnels as well?

based on those assumptions you can now go and destroy all of what follows!

> ccrth@lut.ac.uk (Rob Thirlby) writes:
 
>The decision to use IP tunelling rather than multiplexing our access
>lines to janet reflects the very variable and unpredictable demand from
>sites and the wide disparity of bandwidth of the access lines.  Also
>many of us are hoping to use tunelling facilities in our existing kit
>such as netcomm switches/ECB rather than buy unnecessary routers.


I have some doubt thats going to prove "optimal" in the longer term, but
I also wonder if how individual campii connect into a backbone should
dictate how the backbone allocates its bandwidth? I wouldn't want the NSF
to allocate 48k trunks simply because AARN is only using 48k for the drops!

I think this depends on what you think the long-term implications of a
wide-band connectionless network are. What sort of dataflow down the
shared links do you expect?  If you tunnel each campus connection over
X.25, will some pool of JANET backbone X.25 routers do the right thing
with all the packets going to the US and onward?

I'd expect that the use of long-haul links will look very much the same
for you as they do for everybody else: NNTP, SMTP and FTP traffic will
be semi-continuous, with a layering of telnet and other small packet
traffic during "normal working hours". -That means that shared
resources will be blasted with big packets all flowing in pretty much
the same direction:

	outer-lying places to FTP archives
	outer-lying places to newsfeeds
	outer-lying places to mailhubs
	everywhere to the International fatpipes.

Surely having boxes which understand the IP addressing and co-elesce all
this into more optimal flow down HDLC is better than maintaining 1001 separate
X.25 tunnels all going to the same place?

>We are getting there.  The pilot scheme is being persued with vigour and
>many sites such as mine will ensure that the pressure to offer a 
>service is kept up!  After all isnt it said in religious circles
>that late converts make the most devout members?

Point taken. I must lay claim to fitting that pattern, I doubt if
anybody in the UK would recall me being exactly the most pro-TCP of
people. However like the small boy in the "Bubbles" advert:

	since using their soap, I have used no other.

I really hope the project continues to flourish. If I'm provoking any
anger please accept my apologies, it's a reflection of the long long time
this has been coming. -Roll on '92!

-George

-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 01:03:47 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Telenet/X25  IP connection

In article <1770@west.West.Sun.COM> fkam@sodium.Asia.Sun.COM
   (Francis Kam - Asia CS) writes:
>I have a Sun box running SunLink X25 with a sync. modem to Telenet X25.
>I want to establish that node as an IP point-to-point gateway on X25
>to the Internet community via Telenet.
>
>I presume that given the X25 address on an Internet node in the continental 
>USA which is accessible at the X25 level via Telenet, I can establish
>such a link and use that remote node as a gateway.
>
>I now need to do two things: 
>1) get an Internet domain from NIC;
>2) arrange for such a remote node to tap onto.

Let me quite from RFC1060.TXT: Assigned Numbers: See below.
I really have no idea how many of these assigned numbers are still in
use, but this is the network you should join.

/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
---------------------------------------------------------------------------
RFC 1060                    Assigned Numbers                  March 1990
Reynolds & Postel                                              [Page 49]

                         PUBLIC DATA NETWORK NUMBERS

One of the Internet Class A Networks is the international system of
Public Data Networks.  This section lists the mapping between the
Internet Addresses and the Public Data Network Addresses (X.121).

The numbers below are assigned for networks that are connected to the
Internet, and for independent networks.  These independent networks
are marked with an asterisk preceding the number.

Assignments:

      * Internet           Public Data Net    Description     References
      - --------------   -----------------   -----------      ----------
       014.000.000.000                       Reserved              [JBP]
       014.000.000.001   3110-317-00035 00   PURDUE-TN              [TN]
       014.000.000.002   3110-608-00027 00   UWISC-TN               [TN]
       014.000.000.003   3110-302-00024 00   UDEL-TN                [TN]
       014.000.000.004   2342-192-00149 23   UCL-VTEST              [PK]
       014.000.000.005   2342-192-00300 23   UCL-TG                 [PK]
       014.000.000.006   2342-192-00300 25   UK-SATNET              [PK]
       014.000.000.007   3110-608-00024 00   UWISC-IBM            [MS56]
       014.000.000.008   3110-213-00045 00   RAND-TN               [MO2]
       014.000.000.009   2342-192-00300 23   UCL-CS                 [PK]
       014.000.000.010   3110-617-00025 00   BBN-VAN-GW           [JD21]
      *014.000.000.011   2405-015-50300 00   CHALMERS              [UXB]
       014.000.000.012   3110-713-00165 00   RICE                 [PAM6]
       014.000.000.013   3110-415-00261 00   DECWRL               [PAM6]
       014.000.000.014   3110-408-00051 00   IBM-SJ                [SA1]
       014.000.000.015   2041-117-01000 00   SHAPE                 [JFW]
       014.000.000.016   2628-153-90075 00   DFVLR4-X25            [GB7]
       014.000.000.017   3110-213-00032 00   ISI-VAN-GW           [JD21]
       014.000.000.018   2624-522-80900 52   FGAN-SIEMENS-X25      [GB7]
       014.000.000.019   2041-170-10000 00   SHAPE-X25             [JFW]
       014.000.000.020   5052-737-20000 50   UQNET                 [AXH]
       014.000.000.021   3020-801-00057 50   DMC-CRC1              [VXT]
       014.000.000.022   2624-522-80329 02   FGAN-FGANFFMVAX-X25   [GB7]
      *014.000.000.023   2624-589-00908 01   ECRC-X25              [PXD]
       014.000.000.024   2342-905-24242 83   UK-MOD-RSRE          [JXE2]
       014.000.000.025   2342-905-24242 82   UK-VAN-RSRE           [AXM]
       014.000.000.026   2624-522-80329 05   DFVLRSUN-X25          [GB7]
       014.000.000.027   2624-457-11015 90   SELETFMSUN-X25        [BXD]
       014.000.000.028   3110-408-00146 00   CDC-SVL             [RAM57]
       014.000.000.029   2222-551-04400 00   SUN-CNUCE            [ABB2]
       014.000.000.030   2222-551-04500 00   ICNUCEVM-CNUCE       [ABB2]
       014.000.000.031   2222-551-04600 00   SPARE-CNUCE          [ABB2]
       014.000.000.032   2222-551-04700 00   ICNUCEVX-CNUCE       [ABB2]
       014.000.000.033   2222-551-04524 00   CISCO-CNUCE          [ABB2]
       014.000.000.034   2342-313-00260 90   SPIDER-GW            [AD67]
       014.000.000.035   2342-313-00260 91   SPIDER-EXP           [AD67]
       014.000.000.036   2342-225-00101 22   PRAXIS-X25A           [TXR]
       014.000.000.037   2342-225-00101 23   PRAXIS-X25B           [TXR]
       014.000.000.038   2403-712-30250 00   DIAB-TABY-GW          [FXB]
       014.000.000.039   2403-715-30100 00   DIAB-LKP-GW           [FXB]
       014.000.000.040   2401-881-24038 00   DIAB-TABY1-GW         [FXB]
       014.000.000.041   2041-170-10060 00   STC                  [TC27]
       014.000.000.042-014.255.255.254       Unassigned            [JBP]
       014.255.255.255                       Reserved              [JBP]

      The standard for transmission of IP datagrams over the Public Data
      Network is specified in RFC-877 [69].
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 01:29:36 GMT
From:      Andy.Linton@comp.vuw.ac.nz (Andy Linton)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)


In article <1991Jun3.235516.7634@brolga.cc.uq.oz.au>,
ggm@brolga.cc.uq.oz.au (George Michaelson) writes:

|> Based on my experience (pre 1987) IP introduction in JANET is almost
|> completely blocked by politics and bullsh. Technical issues are
|> smokescreens. The truth in your statement is that there is woeful ignorance
|> in UK campii about IP networking point blank.  Its not ignorance of running
|> a NATIONAL IP network, its ignorance of even running CAMPUS IP networks.
|>

My experience in the UK is a little more recent than George - I left in
mid 89 but I'd support his stance on this. The politics of the JNT with
regard to equipment purchases prevented people buying decent router
boxes to implement campus IP networks since they weren't "Protocol
Police approved". The network in Newcastle and Durham has changed since
I left but it wasn't ready then to be connected into the Internet. 

|> We did it here in under a year. Its run by a 2-man team in Canberra and
|> the goodwill of computer centres across the nation. Off-the-shelf
|> technology,
|> code built into virtually ALL *nix, available for VMS, VM, No mess,
|> no
|> fuss, no worries mate!

Snap, both our networks are smaller than the UK set up - we had things
running in a similar time scale, we don't have any full time staff as
yet and rely also on the goodwill of university computer centres and
government departments across the country.

I look forward to seeing the UK connected as I sure George does. I note
with interest the comment of one of my UK colleagues last week - I won't
name him - you never know who's listening (:-). Talking about the
experimental IP links in the UK, he said:

"With this sort of progress with luck we will be able to avoid falling yet
further behind the US networkwise!"

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 04:54:07 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip
Subject:   WIll function keys work with telnet over X25?

If I run an application through telnet over X25 will function keys
work ok?   Someone mentioned that function keys will behave erratically
or not work at all.  (Does X25 put one char per packet?)


		Thanks,
			Stuart Szabo

-- 
Postal:    Co-Cam Computer Services              |  Stuart Szabo
	   18-22 Trenerry Cr                     |  sgs@rand.mel.cocam.oz.au 
           Abbotsford, VIC 3067                  |  +61 3 412-3411 (voice)      
	   Melbourne,  Australia                 |  +61 3 417-7857 (fax) 

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 07:05:52 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '91 Registration form


Hi folks:
    
    The SIGCOMM Advance Program I sent around earlier didn't have the
registration forms.  Now we have the registration forms on-line and
consistent with RFC procedures, we offer both PostScript and ASCII
copies below.  Thanks to Ed Mumprecht at IBM Zurich for putting
these together.  [Note the Postscript version is designed for ISO
A4 paper, which may cause the last line or so to be lost on US
printers]

Craig

%----Postscript follows----Ascii is further down---------------
%!PS-Adobe-1.0
%%Title: GEM Document
%%Creator: GEM
%%Pages: (atend)
%%BoundingBox: 0 0 595 841
%%EndComments
% Copyright (C) Digital Research, Inc. 1986-1988. All rights reserved.
systemdict /setpacking known
{/svp currentpacking def true setpacking}if
/gemdict 250 dict def
gemdict begin

/bd{bind def}bind def
/ed{exch def}bind def

% User defined Start of Page procedure:  this operator will be
% executed at the beginning of each page output through GEM
% and is provided to allow user-defined page initialization.
/UserSoP{}bd

% Halftone screen spot function procedure array: this array is indexed
% into as follows: 0 = dot screen, 1 = line screen, 2 = ellipse screen,
% 3 = custom (user-definable) screen.
/ScreenProc[
	{ % Dot screen
		abs exch abs 2 copy add 1 gt{
			1 sub dup mul exch 1 sub dup mul add 1 sub}{
			dup mul exch dup mul add 1 exch sub}ifelse}bind
	{ % Line screen
		pop}bind
	{ % Ellipse screen
		dup 5 mul 8 div mul exch dup mul exch add sqrt 1 exch sub}bind
	{ % Custom screen
		dup mul exch dup mul add sqrt 1 exch sub}bind
	]def

/GEMINISUB{pop pop pop pop pop}bd
/GEMINIDOC{dup userdict exch known{cvx exec}{pop}ifelse
	/#copies ed settray
	statusdict /setpageparams known
	{statusdict begin 0 1 setpageparams end}{pop pop}ifelse}bd
/geminit{np 1 setlinejoin /mpf true def
	/cmat matrix def /smat matrix def /rmat matrix def
	/encstr 80 string def /patname null def /patbits null def gs}bd
/GEMMATSUB{pop pop pop pop gr 72 300 div exch div dup scale gs}bd
/GEMMATINI{/landscape ed /p3 ed /p2 ed /p1 ed
	gr 72 300 div exch div dup scale clippath pathbbox
	exch /prx ed exch dup /ply ed sub 1 add p3 sub 2 div ply
	add /ty ed dup prx exch sub 1 add p2 sub 2 div add
	landscape{p1 add}if ty translate landscape{90 rotate}if gs}bd
/gr /grestore load def
/np /newpath load def
/cp /currentpoint load def
/gi /getinterval load def
/lto /lineto load def
/mto /moveto load def
/cto /curveto load def
/clw /currentlinewidth load def
/gs /gsave load def
/greset{gr gs}bd
/settray{dup 0 lt mf dup 0 ge{tray}{pop}ifelse}bd
/mf{statusdict /manualfeed known
	{statusdict begin /manualfeed ed end}{pop}ifelse}bd
/tray{statusdict begin true
	product(Dataproducts LZR 1260)eq{not exch dup 2 gt{pop 0}if
		dup 0 eq{pop defaultpapertray}if setpapertray}if
	product(QMS-PS 1200)eq product(Silentwriter)eq or{not exch dup 1 gt
		{pop 0}if defaultpapertray exch 0 ne{3 exch sub}if
		setpapertray}if
	product dup(PrintServer 40)eq exch(QMS-PS 2400)eq or{
		not exch dup 2 gt{pop 0}if
		dup 0 eq{pop defaultpapertray}
		{dup defaultpapertray ge{1 add}if}ifelse setpapertray}if
	{statusdict /defaultpapertray known statusdict /setpapertray known and
		{defaultpapertray exch 0 ne{1 exch sub}if setpapertray}
		{pop}ifelse}if end}bd
/R{findfont begin currentdict dup maxlength dict begin
	{1 index /FID ne{def}{pop pop}ifelse}forall
	/FontName ed dup length 0 ne{
		/Encoding Encoding 256 array copy def 0 exch
		{dup type /nametype eq{
			Encoding 2 index 2 index put pop 1 add}
			{exch pop}ifelse}forall}if pop
	currentdict dup end end /FontName get exch definefont pop}bd
/gemenvec[8#200 /Ccedilla 8#201 /udieresis 8#202 /eacute 8#203 /acircumflex
	8#204 /adieresis 8#205 /agrave 8#206 /aring 8#207 /ccedilla
	8#210 /ecircumflex 8#211 /edieresis 8#212 /egrave 8#213 /idieresis
	8#214 /icircumflex  8#215 /igrave 8#216 /Adieresis 8#217 /Aring
	8#220 /Eacute 8#221 /ae 8#222 /AE 8#223 /ocircumflex 8#224 /odieresis
	8#225 /ograve 8#226 /ucircumflex 8#227 /ugrave 8#230 /ydieresis
	8#231 /Odieresis 8#232 /Udieresis 8#233 /cent 8#234 /sterling
	8#235 /yen 8#236 /currency 8#237 /florin 8#240 /aacute 8#241 /iacute
	8#242 /oacute 8#243 /uacute 8#244 /ntilde 8#245 /Ntilde
	8#246 /ordfeminine 8#247 /ordmasculine 8#250 /questiondown
	8#251 /quotedblleft 8#252 /quotedblright 8#253 /guilsinglleft
	8#254 /guilsinglright 8#255 /exclamdown 8#256 /guillemotleft
	8#257 /guillemotright 8#260 /atilde 8#261 /otilde 8#262 /Oslash
	8#263 /oslash 8#264 /oe 8#265 /OE 8#266 /Agrave 8#267 /Atilde
	8#270 /Otilde 8#271 /section 8#272 /daggerdbl 8#273 /dagger
	8#274 /paragraph
	8#300 /quotedblbase 8#301 /ellipsis 8#302 /perthousand 8#303 /bullet
	8#304 /endash 8#305 /emdash 8#306 /ring 8#307 /Aacute
	8#310 /Acircumflex 8#311 /Egrave 8#312 /Ecircumflex 8#313 /Edieresis
	8#314 /Igrave 8#315 /Iacute 8#316 /Icircumflex 8#317 /Idieresis
	8#320 /Ograve 8#321 /Oacute 8#322 /Ocircumflex 8#323 /Scaron
	8#324 /scaron 8#325 /Ugrave 8#326 /Uacute 8#327 /Ucircumflex
	8#330 /Ydieresis 8#331 /germandbls 8#332 /Zcaron 8#333 /zcaron
	8#334 /fraction 8#335 /space 8#336 /space 8#337 /space 8#340 /grave
	8#341 /acute 8#342 /circumflex 8#343 /tilde 8#344 /dieresis
	8#345 /ring 8#346 /cedilla 8#347 /caron
	version(23.0)eq{8#275 /space 8#276 /space 8#277 /space}
	{8#275 /copyright 8#276 /registered 8#277 /trademark}ifelse]def
/addfont{fonts exch fpt exch put /fpt fpt 1 add def}bd
/encfont{gemenvec exch fonts exch get dup encstr cvs length 1 sub encstr
	exch 1 exch getinterval cvn R}bd
/dpath{mto{lto}repeat}bd
/path{np dpath}bd
/addpath{lto{lto}repeat}bd
/rxy{.25 sub round .25 add}bd
/rpt{transform rxy exch rxy exch itransform}bd
/fa{np rpt mto 3{rpt lto}repeat}bd
/circle{np 0 0 1 0 360 arc}bd
/dot{gs np 2 copy mto lto 1 setlinecap stroke gr}bd
/rend{gs 1 setlinecap np mto cp 0.1 add lto stroke gr}bd
/rl{gs 1 setlinecap stroke gr}bd
/vl{dup /st ed dup apath exch get tx sub dup mul
	exch 1 add apath exch get ty sub dup mul add sqrt}bd
/doarrow{/rot ed /ty ed /tx ed 6 array currentmatrix
	tx ty translate clw 4 lt{4}{clw}ifelse dup scale rot rotate np
	0 0 mto -3 1.5 lto -3 -1.5 lto fill setmatrix}bd
/arpath{np apath 0 get apath 1 get mto 2 2 points 1 sub
	{dup apath exch get exch 1 add apath exch get lto}for}bd
/arrowline{/apath ed /lend ed /lbeg ed /len clw 3 mul def
	/points apath length def lbeg
	{apath 0 get dup /tx ed /x1 ed apath 1 get dup
		/ty ed /y1 ed true 2 2 points 1 sub
		{vl len ge{pop false exit}if}for
		{/lbeg false def /lend false def}
		{apath 2 apath st points st sub gi putinterval /r1 y1
			apath 3 get sub x1 apath 2 get sub atan def apath 0
			x1 r1 cos len mul sub put apath 1 y1 r1 sin len mul
			sub put /points points st 2 sub sub def}ifelse}if
	lend{apath points 2 sub get dup /tx ed /x2 ed
		apath points 1 sub get dup /ty ed /y2 ed
		true points 4 sub -2 0
		{vl len ge{pop false exit}if}for
		{/lbeg false def /lend false def}
		{/r2 y2 apath st 1 add get sub x2 apath st get sub
			atan def /st st 2 add def apath st x2 r2 cos len mul
			sub put apath st 1 add y2 r2 sin len mul sub put
			/points st 2 add def}ifelse}if
	lbeg{x1 y1 r1 doarrow}if lend{x2 y2 r2 doarrow}if arpath}bd
/ac{6 array currentmatrix xt yt translate xs ys scale}bd
/shorten{dup mul exch dup mul add sqrt clw 150 mul exch div}bd
/xang{dup 360 ge{360}{0}ifelse exch dup sin xs mul exch cos ys mul atan
	dup 360 lt{add}{exch pop}ifelse}bd
/arrowarc{/eang ed /bang ed /ys ed /xs ed /yt ed
	/xt ed /lend ed /lbeg ed ac np 0 0 1 bang xang
	eang xang arc setmatrix cp /y2 ed /x2 ed ac np 0 0 1 bang
	xang dup arc setmatrix cp /y1 ed /x1 ed lbeg
	{/bang bang xs ys shorten add def}if
	lend{/eang eang xs ys shorten sub def}if ac np 0 0 1 bang xang eang
	xang arc setmatrix gs stroke gr
	lend{x2 y2 cp y2 exch sub exch x2 exch sub atan doarrow}if
	lbeg{ac np 0 0 1 bang xang dup arc setmatrix x1 y1 cp y1 exch sub
		exch x1 exch sub atan doarrow}if}bd
/rbox{/ury ed /urx ed /lly ed /llx ed urx llx sub
	4 div dup 50 gt{pop 50}if /radius ed ury lly sub 4 div dup
	radius gt{pop radius}if /radius ed np urx radius sub ury mto llx
	ury llx lly radius arcto 4{pop}repeat llx lly urx lly radius arcto
	4{pop}repeat urx lly urx ury radius arcto 4{pop}repeat urx ury llx ury
	radius arcto 4{pop}repeat}bd
/marker{1 sub mdef exch get /mproc ed 32 div /msize ed
	{gs np translate msize dup scale mproc stroke gr}repeat}bd
/mdef[{0 0 mto 1 0 lto 1 1 lto 0 1 lto closepath}bind
	{-16 0 mto 16 0 lto 0 -16 mto 0 16 lto}bind
	{0 -16 mto 0 16 lto 13.9 8 mto -13.9 -8 lto 13.9 -8 mto
		-13.9 8 lto}bind
	{16 16 mto -16 16 lto -16 -16 lto 16 -16 lto closepath}bind
	{16 16 mto -16 -16 lto -16 16 mto 16 -16 lto}bind
	{16 0 mto 0 16 lto -16 0 lto 0 -16 lto closepath}bind]def
/bon{2 mul exch dup 3 1 roll 8 idiv add pstr exch get
	exch 8 mod 7 exch sub 1 exch bitshift and 0 ne}bd
/bpsf{1 add 8 mul cvi exch 1 add 8 mul cvi exch bon
	{/onb onb 1 add def 1}{/ofb ofb 1 add def 0}ifelse}bd
/frs{72 0 rmat defaultmatrix dtransform dup mul exch dup mul add sqrt}bd
/sus{/m cmat currentmatrix def /sm 32 dup smat scale def sm m m concatmatrix
	pop 1 0 m dtransform dup abs 0.1 gt{exch 90}{0}ifelse exch pop exch
	dup 0 lt{exch 180 add exch neg}if frs exch div exch /bpsf load
	setscreen}bd
/setpat{/onb 0 def /ofb 0 def sus{}settransfer ofb ofb onb add div setgray}bd
/ellpie{/pie ed /eang ed /bang ed /ys ed /xs ed
	/yt ed /xt ed 6 array currentmatrix xt yt translate xs ys
	scale np pie{0 0 mto}if 0 0 1 bang xang eang xang arc setmatrix}bd
/roundarc{gs 1 setlinecap cp np mto cp lto stroke gr}bd
/ss{currentscreen /scp ed /sca ed /scf ed
	dup 0 lt{pop}{ScreenProc exch get /scp ed}ifelse
	dup 0 lt{pop}{/sca ed}ifelse
	dup 0 le{pop}{/scf ed}ifelse
	scf sca /scp load setscreen}bd
/grayimg{{vrep 0.1 gt{/vrep vrep 1 sub def}{
			{currentfile token pop 0 eq
				{currentfile scan readhexstring pop pop exit}
				{/vrep currentfile token pop def}ifelse
			}loop}ifelse scan}image}bd
/fstimg{{vrep 0.1 gt{/vrep vrep 1 sub def}{
			{currentfile token pop 0 eq
				{currentfile scan readhexstring pop pop exit}
				{/vrep currentfile token pop def}ifelse
			}loop}ifelse scan}imagemask}bd
/decode{/patstring patlen string def /bonestr 1 string def
	{vrep 0.1 gt{/vrep vrep 1 sub def scan}
		{/spos 0 def
			{currentfile token pop currentfile token pop
				exch imop exch get exec spos smax ge
				{scan exit}if}loop}ifelse}imagemask}bd
/imop[{<ff> psc}bind
	{<00> psc}bind
	{currentfile patstring readhexstring pop psc}bind
	{1 exch 1 exch
		{pop currentfile bonestr readhexstring pop scan exch
			spos exch 0 get put /spos spos 1 add def}for}bind
	{1 sub /vrep ed}bind]def
/psc{dup length /plen ed exch -1 1
	{pop dup scan exch spos exch putinterval /spos spos plen add def}for
	pop}bd
/gtext{gs /msg ed /ty ed /tx ed tx ty translate trotate
	rotate 10 setflat horz halign get exec
	vert valign get exec np tx ty mto msg show tunder
	{cp cp extents pop pop 5 div dup neg setlinewidth [] 0 setdash 1.5 mul
		ty add /ty ed pop np pop ty mto tx ty lto stroke np mto}if
	gr}bd
/etext{gs translate trotate rotate /tx 0 def /ty 0 def
	{tx add dup /tx ed np ty mto show}repeat gr}bd
/jtext{/msg ed /sps ed /dx ed /ty ed /tx ed
	gs tx ty translate trotate rotate 10 setflat
	jhorz halign get exec vert valign get exec
	msg stringwidth pop dx exch sub sps 0 eq{pop 0}{sps div}ifelse
	/xsp ed msg jo gr}bd
/fet{gs translate /tx 0 def /ty 0 def
	{tx add dup /tx ed np ty mto show}repeat gr}bd
/fjt{/msg ed /sps ed /dx ed /ty ed
	gs ty translate 10 setflat /tx 0 def /ty 0 def
	msg stringwidth pop dx exch sub sps 0 eq{pop 0}{sps div}ifelse
	/xsp ed msg jo gr}bd
/tsel{tszabs{dup /FontBBox get aload pop exch pop dup 3 1 roll exch sub
	exch dup 0 eq{pop pop 1.25}{div}ifelse exch pop}{1}ifelse}bd
/sf{fonts tface get findfont tsel dup txscale mul exch tyscale mul
	matrix scale makefont setfont}bd
/jo{xsp exch 0 exch 32 exch np tx ty mto widthshow tunder
	{cp cp extents pop pop 5 div dup neg setlinewidth 1.5 mul ty add
	/ty ed []0 setdash pop np pop ty mto tx ty lto stroke np mto}if}bd
/horz[{/tx 0 def}bind
	{msg stringwidth pop -2 div /tx ed}bind
	{msg stringwidth pop neg /tx ed}bind]def
/extents{(_)bbox pop pop msg stringwidth pop (])bbox 3{exch pop}repeat}bd
/bbox{np 0 0 mto false charpath flattenpath pathbbox np}bd
/vert[{/ty 0 def}bind
	{extents -2 div /ty ed pop pop pop}bind
	{extents neg /ty ed pop pop pop}bind
	{extents pop pop neg /ty ed pop}bind]def
/jhorz[{/tx 0 def}bind
	{/tx dx -2 div def}bind
	{/tx dx neg def}bind]def
/symindex 12 def
/CR{/ah 0 def}bd
/LF{0 -50 translate}bd
/atext{gs np ah av mto
	show tunder{cp cp (_)bbox pop pop exch pop 5 div dup neg
	setlinewidth 1.5 mul add dup ah exch [] 0 setdash np mto lto
	stroke np mto}if cp pop /ah ed gr}bd
/colmap[
	[1 1 1]
	[0 0 0]
	[1 0 0]
	[0 1 0]
	[0 0 1]
	[0 1 1]
	[1 1 0]
	[1 0 1]
	[.5 .5 .5]
	[0 0 0]
	[.5 0 0]
	[0 .5 0]
	[0 0 .5]
	[0 .5 .5]
	[.5 .5 0]
	[.5 0 .5]
	]def
/sci{colmap exch get aload pop setrgbcolor}bd
/stint{/tint ed currentrgbcolor
	3{dup 0 eq{pop tint}if 3 1 roll}repeat setrgbcolor}bd

end
/vpdict 1 dict def
systemdict /setpacking known{svp setpacking}if
%%EndProlog
gsave
currentdict /gemdict known not {
/Times-Roman findfont 12 scalefont setfont newpath 72 700 moveto
(Error:  the GEM PostScript preamble is not available on your)show
newpath 72 686 moveto
(  printer.  Pre-download the preamble or include it with)show
newpath 72 672 moveto(  your print job.)show
newpath 72 658 moveto(This print job has been aborted.)show
showpage stop}if gemdict begin
668 914 0 1 /a4 GEMINIDOC geminit
1 2480 2481 3507 false GEMMATINI
/fonts 128 array def /fpt 0 def
/GCourier addfont
/GCourier-Bold addfont
/GCourier-Oblique addfont
/GCourier-BoldOblique addfont
/GHelvetica addfont
/GHelvetica-Bold addfont
/GHelvetica-Oblique addfont
/GHelvetica-BoldOblique addfont
/GTimes-Roman addfont
/GTimes-Bold addfont
/GTimes-Italic addfont
/GTimes-BoldItalic addfont
/Symbol addfont
/GAvantGarde-Book addfont
/GAvantGarde-BookOblique addfont
/GAvantGarde-Demi addfont
/GAvantGarde-DemiOblique addfont
/GBookman-Light addfont
/GBookman-LightItalic addfont
/GBookman-Demi addfont
/GBookman-DemiItalic addfont
/GHelvetica-Narrow addfont
/GHelvetica-Narrow-Oblique addfont
/GHelvetica-Narrow-Bold addfont
/GHelvetica-Narrow-BoldOblique addfont
/GPalatino-Roman addfont
/GPalatino-Italic addfont
/GPalatino-Bold addfont
/GPalatino-BoldItalic addfont
/GNewCenturySchlbk-Roman addfont
/GNewCenturySchlbk-Italic addfont
/GNewCenturySchlbk-Bold addfont
/GNewCenturySchlbk-BoldItalic addfont
/GZapfChancery-MediumItalic addfont
/ZapfDingbats addfont
/GAmericanTypewriter-Medium addfont
/GAmericanTypewriter-Bold addfont
/GBenguiat-Book addfont
/GBenguiat-Bold addfont
/GBodoni addfont
/GBodoni-Italic addfont
/GBodoni-Bold addfont
/GBodoni-BoldItalic addfont
/GBodoni-Poster addfont
/GCenturyOldStyle-Regular addfont
/GCenturyOldStyle-Italic addfont
/GCenturyOldStyle-Bold addfont
/GCheltenham-Book addfont
/GCheltenham-BookItalic addfont
/GCheltenham-Bold addfont
/GCheltenham-BoldItalic addfont
/GFranklinGothic-Book addfont
/GFranklinGothic-BookOblique addfont
/GFranklinGothic-Demi addfont
/GFranklinGothic-DemiOblique addfont
/GFranklinGothic-Heavy addfont
/GFranklinGothic-HeavyOblique addfont
/GFrizQuadrata addfont
/GFrizQuadrata-Bold addfont
/GGalliard-Roman addfont
/GGalliard-Italic addfont
/GGalliard-Bold addfont
/GGalliard-BoldItalic addfont
/GGaramond-Light addfont
/GGaramond-LightItalic addfont
/GGaramond-Bold addfont
/GGaramond-BoldItalic addfont
/GGlypha addfont
/GGlypha-Oblique addfont
/GGlypha-Bold addfont
/GGlypha-BoldOblique addfont
/GGoudy addfont
/GGoudy-Italic addfont
/GGoudy-Bold addfont
/GGoudy-BoldItalic addfont
/GHelvetica-Light addfont
/GHelvetica-LightOblique addfont
/GHelvetica-Black addfont
/GHelvetica-BlackOblique addfont
/GHelvetica-Condensed-Light addfont
/GHelvetica-Condensed-LightObl addfont
/GHelvetica-Condensed addfont
/GHelvetica-Condensed-Oblique addfont
/GHelvetica-Condensed-Bold addfont
/GHelvetica-Condensed-BoldObl addfont
/GHelvetica-Condensed-Black addfont
/GHelvetica-Condensed-BlackObl addfont
/GKorinna-Regular addfont
/GKorinna-KursivRegular addfont
/GKorinna-Bold addfont
/GKorinna-KursivBold addfont
/GLetterGothic addfont
/GLetterGothic-Slanted addfont
/GLetterGothic-Bold addfont
/GLetterGothic-BoldSlanted addfont
/GLubalinGraph-Book addfont
/GLubalinGraph-BookOblique addfont
/GLubalinGraph-Demi addfont
/GLubalinGraph-DemiOblique addfont
/GMachine addfont
/GMelior addfont
/GMelior-Italic addfont
/GMelior-Bold addfont
/GMelior-BoldItalic addfont
/GNewBaskerville-Roman addfont
/GNewBaskerville-Italic addfont
/GNewBaskerville-Bold addfont
/GNewBaskerville-BoldItalic addfont
/GOptima addfont
/GOptima-Oblique addfont
/GOptima-Bold addfont
/GOptima-BoldOblique addfont
/GOrator addfont
/GOrator-Slanted addfont
/GParkAvenue addfont
/GPrestigeElite addfont
/GPrestigeElite-Slanted addfont
/GPrestigeElite-Bold addfont
/GPrestigeElite-BoldSlanted addfont
/Sonata addfont
/GSouvenir-Light addfont
/GSouvenir-LightItalic addfont
/GSouvenir-Demi addfont
/GSouvenir-DemiItalic addfont
/GTrumpMediaeval-Roman addfont
/GTrumpMediaeval-Italic addfont
/GTrumpMediaeval-Bold addfont
/GTrumpMediaeval-BoldItalic addfont
/svobj save def
%Begin page
UserSoP
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset -75 3581 2555 3581 2555 -75 -75 -75 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 43 3492 1612 3492 1612 -7 43 -7 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 43 3492 708 3492 708 2843 43 2843 np mto lto lto lto clip np
118 3417 634 3417 634 3004 118 3004 fa
colmap 1 [0 0 0 ] put
1 sci
gs eofill gr
/tface 5 def
5 encfont
/mpf true def
colmap 0 [1 1 1 ] put
0 sci
/tszabs false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
/trotate 0 def
/halign 0 def
/valign 0 def
/tunder false def
sf
148 3329 409 1 (SIGCOMM '91)fjt
148 3235 433 2 (Sept. 3-6, 1991)fjt
148 3142 190 0 (Z\201rich)fjt
148 3048 346 0 (Switzerland)fjt
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 553 3492 1614 3492 1614 2543 553 2543 np mto lto lto lto clip np
/tface 5 def
colmap 1 [0 0 0 ] put
1 sci
/tszabs false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
/trotate 0 def
/halign 0 def
/valign 0 def
/tunder false def
sf
657 3329 717 2 (Tutorial and Conference)fjt
657 3235 814 2 (Advance Registration Form)fjt
/tface 8 def
8 encfont
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
657 3157 467 3 (Deadline: August 5, 1991)fjt
/tface 9 def
9 encfont
sf
657 3057 475 4 (Please send this form to:)fjt
/tface 8 def
sf
657 2966 496 2 (SIGCOMM' 91 Secretariat)fjt
657 2916 168 1 (P.O. Box)fjt
657 2858 838 2858 838 2857 657 2857 fa
gs eofill gr
657 2866 181 1 (CH-8340 )fjt
838 2858 969 2858 969 2857 838 2857 fa
gs eofill gr
/tface 9 def
sf
838 2866 131 0 (Hinwil)fjt
/tface 8 def
sf
657 2816 217 0 (Switzerland)fjt
657 2766 73 0 (Tel:)fjt
758 2766 298 4 (+41 1 937 24 47)fjt
1106 2766 396 2 (\(Mrs. Anne Schicker\))fjt
657 2716 81 0 (Fax:)fjt
758 2716 298 4 (+41 1 938 15 57)fjt
657 2666 129 0 (e-mail:)fjt
894 2666 608 0 (SIGCOMM91@clients.switch.ch)fjt
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 43 2692 1613 2692 1613 -7 43 -7 np mto lto lto lto clip np
/tface 9 def
colmap 1 [0 0 0 ] put
1 sci
/tszabs false def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
/trotate 0 def
/halign 0 def
/valign 0 def
/tunder false def
sf
148 2574 1094 8 (Please use typewriter or block letters in black writing.)fjt
/tface 8 def
sf
1242 2574 268 1 ( Alternatively,)fjt
148 2524 1213 12 (you may register by electronic mail or by fax to the address
 above.)fjt
118 2465 1539 2465 1539 2459 118 2459 fa
gs eofill gr
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 2383 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
( )42 ( )42 ( )42 ( )11 (.)18 (s)40 (M)42 ( )0 8 195 2383 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 474 2383 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
( )42 ( )42 ( )42 ( )11 (.)18 (s)15 (r)40 (M)42 ( )0 9 522 2383 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 816 2383 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
( )42 ( )42 ( )42 ( )18 (s)17 (s)13 (i)40 (M)42 ( )0 9 864 2383 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 1162 2383 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(.)15 (r)41 (M)42 ( )0 4 1209 2383 fet
148 2291 199 1 (Last Name)fjt
653 2291 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 2214 352 2 (First Name, Initials)fjt
653 2214 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 2137 86 0 (Title)fjt
653 2137 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 2060 350 0 (Organization/Dept.)fjt
653 2060 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
653 1983 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
653 1906 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1829 106 0 (Street)fjt
653 1829 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
653 1752 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1674 297 2 (City, Zip \(State\))fjt
653 1674 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1597 149 0 (Country)fjt
653 1597 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1520 125 1 (Phone )fjt
653 1520 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1443 80 1 (Fax )fjt
653 1443 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 1366 306 1 (EMAIL Address)fjt
653 1366 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
( )16 (r)20 (e)23 (b)35 (m)23 (u)33 (N)11 ( )15 (r)21 (e)22 (b)36 (m)20
(e)41 (M)11 ( )40 (M)41 (M)33 (O)30 (C)33 (G)16 (I)25 (S)11 ( )15 (r)23
(o)11 ( )41 (M)30 (C)33 (A)0 29 148 1289 fet
900 1289 608 27 ( . . . . . . . . . . . . . . . . . . . . . . . . . . .)fjt
118 1244 1539 1244 1539 1238 118 1238 fa
gs eofill gr
/tface 9 def
sf
(e)20 (c)25 (n)20 (e)20 (r)20 (e)15 (f)26 (n)22 (o)33 (C)0 10 148 1162 fet
/tface 8 def
sf
(\))23 (1)22 (9)23 (9)23 (1)11 ( )11 (,)23 (6)11 ( )23 (o)13 (t)11 ( )23
(4)11 ( )11 (.)13 (t)22 (p)21 (e)25 (S)15 (\()11 ( )0 21 370 1162 fet
(1)23 (9)10 ( )12 (,)22 (5)11 ( )11 (.)23 (g)23 (u)33 (A)10 ( )20 (e)16
(r)22 (o)16 (f)20 (e)30 (B)0 17 798 1162 fet
(1)22 (9)11 ( )11 (,)23 (6)10 ( )11 (.)23 (g)23 (u)33 (A)10 ( )16 (r)20
(e)12 (t)16 (f)33 (A)0 16 1215 1162 fet
(.)13 (r)15 (f)25 (S)0 4 1058 1105 fet
(.)13 (r)25 (F)25 (S)0 4 1438 1105 fet
(r)20 (e)23 (b)36 (m)20 (e)40 (M)0 6 148 1020 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
908 1020 47 0 (q)fjt

/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)23 (0)11 (.)23 (0)23 (0)23 (4)42 ( )0 7 955 1020 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 1298 1020 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (0)23 (5)42 ( )0 7 1345 1020 fet
(r)21 (e)22 (b)36 (m)20 (e)41 (M)15 (-)23 (n)22 (o)33 (N)0 10 148 935 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
908 935 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)23 (0)11 (.)23 (0)23 (0)23 (5)42 ( )0 7 955 935 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 1298 935 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (0)23 (6)42 ( )0 7 1345 935 fet
(\))12 (t)23 (n)20 (e)23 (v)20 (e)11 ( )13 (l)20 (a)13 (i)20 (c)23 (o)17
(s)12 ( )12 (t)23 (u)23 (o)22 (h)13 (t)12 (i)33 (w)16 (\()11 ( )18 (s)12
(t)23 (n)20 (e)23 (d)23 (u)12 (t)25 (S)0 31 148 850 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
908 850 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)23 (0)11 (.)23 (0)23 (7)23 (1)42 ( )0 7 955 850 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 1298 850 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (7)23 (1)42 ( )0 7 1345 850 fet
148 752 1362 10
(Includes one copy of the proceedings, lunches, and coffee during intervals)fjt
148 702 776 6 (plus the social event on Thursday evening.)fjt
(n)23 (o)18 (s)15 (r)20 (e)26 (P)10 ( )23 (g)23 (n)12 (i)23 (y)23 (n)20
(a)23 (p)35 (m)23 (o)20 (c)20 (c)33 (A)11 ( )15 (r)23 (o)15 (f)11 ( )12
(t)23 (n)20 (e)23 (v)28 (E)11 ( )12 (l)21 (a)12 (i)20 (c)23 (o)25
(S)0 36 148 610 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
1298 610 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (5)23 (8)23 ( )42 ( )0 7 1345 610 fet
118 573 1539 573 1539 567 118 567 fa
gs eofill gr
/tface 9 def
sf
(s)12 (l)23 (a)12 (i)21 (r)22 (o)16 (t)25 (u)26 (T)0 9 148 490 fet
/tface 8 def
sf
(\))13 (l)20 (a)12 (i)16 (r)22 (o)13 (t)23 (u)12 (t)11 ( )23 (y)20 (a)23
(d)11 ( )13 (l)12 (l)23 (u)15 (f)12 ( )20 (a)11 ( )18 (s)12 (i)12 ( )12
(l)20 (a)13 (i)15 (r)23 (o)12 (t)23 (u)13 (t)11 ( )23 (h)20 (c)20 (a)20
(e)16 (\()11 ( )23 (1)22 (9)23 (9)23 (1)11 ( )11 (,)23 (3)11 ( )12 (.)12
(t)23 (p)20 (e)25 (S)12 ( )11 (,)0 54 323 490 fet
(.)13 (r)25 (F)25 (S)0 4 1438 490 fet
(.)22 (1)0 2 148 405 fet
(y)13 (t)12 (i)15 (r)23 (u)20 (c)21 (e)25 (S)11 ( )23 (k)15 (r)23 (o)33
(w)12 (t)21 (e)33 (N)0 16 236 405 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
1298 405 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (0)23 (5)42 ( )0 7 1345 405 fet
(.)22 (2)0 2 148 320 fet
(s)33 (N)33 (A)28 (L)11 ( )23 (d)20 (e)20 (e)23 (p)25 (S)11 ( )23 (h)23
(g)12 (i)33 (H)11 ( )23 (d)22 (n)21 (a)10 ( )18 (s)23 (k)15 (r)23 (o)33
(w)12 (t)21 (e)33 (N)11 ( )20 (a)20 (e)15 (r)33 (A)11 ( )23 (n)20 (a)13
(t)12 (i)13 (l)23 (o)22 (p)23 (o)15 (r)13 (t)20 (e)41 (M)0 46 236 320 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
1298 320 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (0)23 (5)42 ( )0 7 1345 320 fet
(.)22 (3)0 2 148 235 fet
(d)22 (n)21 (a)11 ( )11 (,)20 (y)23 (g)22 (o)13 (l)23 (o)22 (n)23 (h)20
(c)21 (e)25 (T)11 ( )11 (,)20 (e)15 (r)23 (u)13 (t)20 (c)20 (e)13 (t)12
(i)23 (h)20 (c)15 (r)33 (A)16 (\()11 ( )17 (s)23 (k)15 (r)23 (o)33 (w)13
(t)20 (e)33 (N)11 ( )41 (M)28 (T)28 (A)0 43 236 235 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
1298 235 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(0)22 (0)12 (.)22 (0)23 (0)23 (5)42 ( )0 7 1345 235 fet
(\))23 (g)23 (n)12 (i)13 (l)12 (l)20 (e)23 (d)23 (o)40 (M)12 ( )20 (e)20
(c)23 (n)20 (a)36 (m)15 (r)23 (o)15 (f)15 (r)20 (e)26 (P)0 22 236 178 fet
148 108 1343 11
(Includes one copy of the tutorial notes, lunch, and coffee during
 intervals.)fjt
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 1579 3492 2201 3492 2201 2870 1579 2870 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 62 3473 1594 3473 1594 33 62 33 np mto lto lto lto clip np
5 setlinewidth
5 setlinewidth
113 3419 119 3419 119 86 113 86 fa
colmap 1 [0 0 0 ] put
1 sci
gs eofill gr
113 3422 1543 3422 1543 3416 113 3416 fa
gs eofill gr
113 89 1543 89 1543 83 113 83 fa
gs eofill gr
1537 3419 1543 3419 1543 86 1537 86 fa
gs eofill gr
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
%End page
showpage svobj restore gr
gs /svobj save def
%Begin page
UserSoP
greset -75 3581 2555 3581 2555 -75 -75 -75 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 43 3492 1612 3492 1612 -7 43 -7 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 43 3492 1613 3492 1613 -7 43 -7 np mto lto lto lto clip np
/tface 9 def
9 encfont
colmap 1 [0 0 0 ] put
1 sci
/tszabs false def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
/trotate 0 def
/halign 0 def
/valign 0 def
/tunder false def
sf
(s)21 (e)25 (h)18 (s)12 (i)45 (W)11 ( )12 (l)23 (a)12 (i)21 (c)20 (e)25 (p)25
(S)0 14 148 3346 fet
/tface 8 def
8 encfont
sf
(\))22 (d)21 (e)15 (r)12 (i)18 (s)20 (e)23 (d)11 ( )16 (f)12 (i)15 (\()12 ( )0
13 435 3346 fet
(.)13 (r)25 (F)25 (S)0 4 1438 3346 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 3261 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(s)23 (g)23 (n)12 (i)23 (d)20 (e)20 (e)21 (c)22 (o)16 (r)22 (p)12 ( )15 (f)23
(o)11 ( )23 (y)22 (p)23 (o)31 (C)11 ( )20 (a)15 (r)13 (t)23 (x)28 (E)0 25 236
 3261 fet
(0)22 (0)12 (.)22 (0)23 (8)0 5 1410 3261 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 3176 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(n)23 (o)12 (i)13 (t)20 (a)23 (d)23 (o)35 (m)36 (m)22 (o)21 (c)20 (c)33 (A)9
( )15 (r)12 (i)21 (a)22 (h)21 (c)12 (l)20 (e)21 (e)22 (h)44 (W)0 24 236 3176 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
1228 3176 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(n)20 (a)12 (i)16 (r)20 (a)12 (t)21 (e)22 (g)21 (e)28 (V)42 ( )0 11 1275 3176
 fet
118 3139 1539 3139 1539 3133 118 3133 fa
gs eofill gr
148 3031 315 1 (Total Remittance)fjt
( )11 (.)16 (r)25 (F)25 (S)0 5 650 3031 fet
788 3031 720 32 ( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
( )0 1 148 3006 fet
148 2951 977 10 (The remittance of your registration has to be made in )fjt
/tface 9 def
sf
1125 2951 252 1 (Swiss Francs)fjt
/tface 8 def
sf
1376 2951 57 1 ( by)fjt
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 2859 89 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
236 2859 1146 9 (Send a check in Swiss Francs to the SIGCOMM'91 Secretariat)fjt
236 2809 328 1 (\(address overleaf\))fjt
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 2718 89 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
236 2718 1267 8
(International direct bank transfer to \(state \251SIGCOMM '91,
 Z\201rich\252\):)fjt
236 2618 499 3 (Union Bank of Switzerland)fjt
236 2568 185 0 (R\224merhof)fjt
236 2518 168 1 (P.O. Box)fjt
827 2518 328 1 (Account Number:)fjt
1282 2518 230 0 (822.192.02P)fjt
236 2459 417 2459 417 2458 236 2458 fa
gs eofill gr
236 2468 181 1 (CH-8030 )fjt
417 2459 551 2459 551 2458 417 2458 fa
gs eofill gr
/tface 9 def
sf
417 2468 134 0 (Z\201rich)fjt
/tface 8 def
sf
827 2468 219 1 (Swift Code:)fjt
1155 2468 358 2 (UBSWCH  ZH80H)fjt
236 2418 217 0 (Switzerland)fjt
827 2418 116 0 (Telex:)fjt
1201 2418 311 2 (817 390 UBSCH)fjt
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 2326 89 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
236 2326 1142 6
(Credit cards \(Visa, EuroCard, MasterCard, American Express\))fjt
236 2234 374 2 (Name \(block letters\))fjt
653 2234 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
236 2157 263 2 (Place and date)fjt
653 2157 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
236 2080 174 0 (Signature)fjt
653 2080 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
236 2003 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(a)18 (s)13 (i)33 (V)42 ( )0 5 283 2003 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 2003 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(d)15 (r)21 (a)30 (C)23 (o)15 (r)23 (u)28 (E)42 ( )0 9 697 2003 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
236 1953 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(d)15 (r)21 (a)30 (C)15 (r)21 (e)12 (t)18 (s)20 (a)41 (M)42 ( )0 11 283 1953 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 1953 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(s)18 (s)20 (e)15 (r)23 (p)23 (x)28 (E)11 ( )23 (n)20 (a)20 (c)13 (i)15 (r)20
(e)36 (m)33 (A)42 ( )0 17 697 1953 fet
236 1861 150 0 (Number)fjt
653 1861 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
236 1784 279 1 (Expiration date)fjt
653 1784 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
118 1740 1539 1740 1539 1734 118 1734 fa
gs eofill gr
/tface 9 def
sf
148 1657 350 1 (Hotel Reservation)fjt
/tface 8 def
sf
498 1657 476 4 ( \(Deadline: July 20, 1991\))fjt
148 1565 1362 11
(Hotel reservation can be made by indicating the desired hotel category and)fjt
148 1515 1362 13
(the type of room below. It will be confirmed by the Z\201rich Tourist
 Office)fjt
148 1465 1362 11
(\(VVZ\). Block reservations have been made in several hotels in the center)fjt
(.)35 (m)20 (a)16 (r)12 (t)16 ( )22 (y)23 (b)16 ( )22 (d)21 (e)22 (h)21 (c)20
(a)20 (e)15 (r)16 ( )23 (y)12 (l)13 (i)17 (s)21 (a)20 (e)15 ( )21 (e)22 (b)16
( )23 (n)20 (a)20 (c)16 ( )20 (e)20 (c)23 (n)20 (e)15 (r)21 (e)15 (f)23 (n)22
(o)21 (c)15 ( )20 (e)23 (h)13 (t)15 ( )15 (f)23 (o)16 ( )22 (n)23 (o)13 (i)12
(t)20 (a)21 (c)22 (o)13 (l)15 ( )21 (e)22 (h)28 (T)16 ( )11 (.)23 (h)20 (c)13
(i)15 (r)23 (\201)28 (Z)15 ( )16 (f)22 (o)0 72 148 1415 fet
148 1365 1128 9 (Payment for accomodation must be made directly at the
 hotel.)fjt
148 1274 835 8 (Rates are in Swiss Francs per room and night.)fjt
357 1224 358 1224 358 1047 357 1047 fa
gs eofill gr
644 1224 645 1224 645 1047 644 1047 fa
gs eofill gr
932 1224 933 1224 933 1047 932 1047 fa
gs eofill gr
1219 1224 1220 1224 1220 1047 1219 1047 fa
gs eofill gr
150 1048 1507 1048 1507 1047 150 1047 fa
gs eofill gr
357 1048 358 1048 358 771 357 771 fa
gs eofill gr
644 1048 645 1048 645 771 644 771 fa
gs eofill gr
932 1048 933 1048 933 771 932 771 fa
gs eofill gr
1219 1048 1220 1048 1220 771 1219 771 fa
gs eofill gr
149 1225 1508 1225 1508 1224 149 1224 fa
gs eofill gr
149 771 1508 771 1508 772 149 772 fa
gs eofill gr
149 1225 150 1225 150 771 149 771 fa
gs eofill gr
1508 1225 1507 1225 1507 771 1508 771 fa
gs eofill gr
170 1173 167 0 (Category)fjt
381 1173 239 1 (Single Room)fjt
431 1123 139 0 (without)fjt
435 1073 132 0 (shower)fjt
669 1173 239 1 (Single Room)fjt
748 1123 81 0 (with)fjt
722 1073 132 0 (shower)fjt
947 1173 257 1 (Double Room)fjt
1006 1123 139 0 (without)fjt
1010 1073 132 0 (shower)fjt
1235 1173 257 1 (Double Room)fjt
1323 1123 81 0 (with)fjt
1297 1073 132 0 (shower)fjt
176 996 23 0 (*)fjt
176 946 46 0 (**)fjt
176 896 68 0 (***)fjt
176 846 91 0 (****)fjt
176 796 114 0 (*****)fjt
(0)23 (8)22 ( )12 ( )15 (-)11 ( )23 (0)23 (6)22 ( )0 9 414 996 fet
(0)23 (0)22 (1)12 ( )15 (-)11 ( )23 (1)23 (8)22 ( )0 9 414 946 fet
493 896 15 0 (-)fjt
493 846 15 0 (-)fjt
493 796 15 0 (-)fjt
701 996 174 2 (100 - 135)fjt
701 946 174 2 (136 - 150)fjt
701 896 174 2 (151 - 180)fjt
701 846 174 2 (181 - 220)fjt
680 796 216 1 (220 upward)fjt
(0)23 (1)22 (1)12 ( )15 (-)11 ( )23 (0)23 (8)22 ( )0 9 989 996 fet
989 946 174 2 (111 - 140)fjt
1068 896 15 0 (-)fjt
1068 846 15 0 (-)fjt
1068 796 15 0 (-)fjt
1276 996 174 2 (141 - 160)fjt
1276 946 174 2 (141 - 160)fjt
1276 896 174 2 (161 - 180)fjt
1276 846 174 2 (181 - 220)fjt
1255 796 216 1 (220 upward)fjt
148 677 167 0 (Category)fjt
650 677 266 2 (Type of Room)fjt
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 602 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(*)42 ( )0 2 195 602 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 602 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(m)22 (o)23 (o)31 (R)11 ( )20 (e)13 (l)22 (g)23 (n)13 (i)25 (S)42 ( )0
12 697 602 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 552 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(*)23 (*)42 ( )0 3 195 552 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 552 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(m)22 (o)23 (o)31 (R)11 ( )20 (e)13 (l)22 (b)23 (u)23 (o)33 (D)42 ( )0
12 697 552 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 502 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(*)22 (*)23 (*)42 ( )0 4 195 502 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 452 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(*)23 (*)22 (*)23 (*)42 ( )0 5 195 452 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 452 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(r)21 (e)33 (w)22 (o)23 (h)18 (s)11 ( )23 (h)12 (t)13 (i)33 (w)42 ( )0
12 697 452 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
148 402 47 0 (q)fjt
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(*)23 (*)23 (*)22 (*)23 (*)42 ( )0 6 195 402 fet
/tface 34 def
/mpf false def
/txscale 1500 3 mul 72 div def /tyscale 1500 3 mul 72 div def
sf
(q)0 1 650 402 fet
/tface 8 def
/mpf true def
/txscale 1100 3 mul 72 div def /tyscale 1100 3 mul 72 div def
sf
(r)21 (e)33 (w)22 (o)23 (h)18 (s)11 ( )13 (t)22 (u)23 (o)23 (h)12 (t)13 (i)33
(w)42 ( )0 15 697 402 fet
148 311 229 1 (Arrival Date)fjt
653 311 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 233 239 1 (Arrival Time)fjt
653 233 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
148 156 280 1 (Departure Date)fjt
653 156 855 38
( . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 .)fjt
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 1579 3492 2201 3492 2201 2870 1579 2870 np mto lto lto lto clip np
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
greset 62 3473 1594 3473 1594 33 62 33 np mto lto lto lto clip np
1 setlinewidth
5 setlinewidth
5 setlinewidth
113 3419 119 3419 119 86 113 86 fa
colmap 1 [0 0 0 ] put
1 sci
gs eofill gr
113 3422 1543 3422 1543 3416 113 3416 fa
gs eofill gr
113 89 1543 89 1543 83 113 83 fa
gs eofill gr
1537 3419 1543 3419 1543 86 1537 86 fa
gs eofill gr
greset -300 3806 2781 3806 2781 -301 -300 -301 np mto lto lto lto clip np
%End page
showpage svobj restore gr
gs /svobj save def
%Begin page
UserSoP
svobj restore gr end grestore
%%Trailer
%%Pages: 2
%%EOF

-----ASCII version------------------------

- -----------------------------------------------------------------------------
              SIGCOMM '91, Sept. 4-6, 1991, Zurich, Switzerland
              TUTORIAL AND CONFERENCE ADVANCE REGISTRATION FORM
- -----------------------------------------------------------------------------

Please send this form to:
    SIGCOMM' 91 Secretariat
    P.O. Box
    CH-8340 Hinwil
    Switzerland

    Tel:     +41 1 937 24 47   (Mrs. Anne Schicker)
    Fax:     +41 1 938 15 57
    E-mail:  SIGCOMM91@clients.switch.ch

Please use typewriter or block letters in black writing. Alternatively,
you may register by ELECTRONIC MAIL or by FAX to the address above.
For registration by electronic mail use this form.

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

Indicate one of:      Ms. ...    Mrs. ...   Miss ...   Mr. ...
                      (do not change the number of lines)
Last Name             .......................................................
First Name, Initials  .......................................................
Title                 .......................................................
Organization/Dept.    .......................................................
                      .......................................................
                      .......................................................
Street                .......................................................
                      .......................................................
City, Zip (State)     .......................................................
Country               .......................................................
Phone                 .......................................................
Fax                   .......................................................
EMAIL Address         .......................................................
ACM or SIGCOMM Member Number           ......................................

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

CONFERENCE (Sept. 4 to 6, 1991)
Indicate with an 'X' the           | Before Aug. 5, 91  |  After Aug. 6, 91 |
applicable item:                   | SFr.               |  SFr.             |
                                   ------------------------------------------
Member                             | 400.00        ...  |  500.00       ... |
Non-Member                         | 500.00        ...  |  600.00       ... |
Student (without social event)     | 170.00        ...  |  170.00       ... |
                                   ------------------------------------------
Social Event for Accompanying Person                    |   85.00       ... |
                                                        ---------------------

Includes one copy of the proceedings, lunches, and coffee during intervals
plus the social event on Thursday evening.


SPECIAL WISHES (if desired)
Indicate with an 'X' the applicable item:               |  SFr.             |
                                                        ---------------------
Extra Copy of proceedings                               |   80.00       ... |
Wheelchair Accommodation                                |    0.00       ... |
Vegetarian                                              |    0.00       ... |
                                                        ---------------------

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

TUTORIALS, Sept. 3, 1991 (each tutorial is a full day tutorial)
Indicate with an 'X' the applicable item:               |  SFr.             |
                                                        ---------------------
1.   Network Security                                   |  500.00       ... |
2.   Metropolitan Area Networks and High Speed LANs     |  500.00       ... |
3.   ATM Networks (Architecture, Technology, and        |  500.00       ... |
     Performance Modelling)                             ---------------------

Includes one copy of the tutorial notes, lunch, and coffee during intervals.

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

Total Remittance                                     SFr. ..........

The remittance of your registration has to be made in Swiss Francs by

a)  Send a check in Swiss Francs to the SIGCOMM'91 Secretariat
    (address above)

b)  International direct bank transfer to:
    (state SIGCOMM '91, Zurich)

    Union Bank of Switzerland
    Roemerhof
    P.O. Box                                  Account Number:    822.192.02P
    CH-8030 Zurich                            Swift Code:       UBSWCH ZH80H
    Switzerland                               Telex:           817 390 UBSCH

c)  Credit cards (Visa, EuroCard, MasterCard, American Express)

    Name (of card holder)  .................................................
    Place and date         .................................................
    Visa ...  |   EuroCard ...  |   MasterCard ...  |   American Express ...
    Number                 .................................................
    Exp.date               .................................................

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

Hotel Reservation (Deadline: July 20, 1991)

Hotel reservation can be made by indicating the desired hotel category and
the type of room below. It will be confirmed by the Zurich Tourist Office
(VVZ). Block reservations have been made in several hotels in the center of
Zurich. The location of the conference can be easily reached by tram.
Payment for accomodation must be made directly at the hotel.

Rates are in Swiss Francs per room and night.

- ----------------------------------------------------------------------------
| Category |  Single Room  |  Single Room  |  Double Room  |  Double Room  |
|          |    without    |     with      |    without    |     with      |
|          |    shower     |    shower     |    shower     |    shower     |
- ----------------------------------------------------------------------------
| *        |    60 -  80   |   100 - 135   |    80 - 110   |   141 - 160   |
| **       |    81 - 100   |   136 - 150   |   111 - 140   |   141 - 160   |
| ***      |       -       |   151 - 180   |       -       |   161 - 180   |
| ****     |       -       |   181 - 220   |       -       |   181 - 220   |
| *****    |       -       |   220 upward  |       -       |   220 upward  |
- ----------------------------------------------------------------------------

Indicate with an 'X' the applicable category and type of room:
    Category                    Type of Room
    *      ...                  Single Room    ...
    **     ...                  Double Room    ...
    ***    ...
    ****   ...                  with shower    ...
    *****  ...                  without shower ...

    Arrival Date           .................................................
    Arrival Time           .................................................
    Departure Date         .................................................

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

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 11:01:21 GMT
From:      pjd@eagle.inesc.pt (Paulo Jorge Delgado)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   AS/400 TCPIP


Hello net:

I am installing an AS/400 on a TCPIP network, but it seems that the IBM AS/400
TCPIP implementation does not support remote printing. I would like to be able
to direct an AS/400 output queue to an Novell 3.11 printer or an Unix printer.
IBM will sell me another solution - PC-Support - but I would like very much
to stick to TCPIP. So, any sugestions? Are there any non-IBM TCPIP solutions
for the AS/400? Yes I have heard about Mitek and I've requested some info
from them, but are there others? Is there any product I can get to add remote
printing to the IBM TCPIP?
Thanks in advance.
--
 Paulo Jorge Delgado
 INESC, Lisboa, Portugal
 Email: pjd@eniac.inesc.pt

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 13:03:21 GMT
From:      pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE)
To:        comp.protocols.tcp-ip
Subject:   MOTIF for Sun

I am looking for an implementation of MOTIF for Sun (preferably freeware or PD).
Any hint?

I am also looking for an X server for IBM/PC ( to make an X terminal out of
a PC)

Thanks for any help

Jean-Jacques Pansiot,  Universite Louis Pasteur, Strasbourg, FRANCE
7, rue Descartes  67084 STRASBOURG CEDEX FRANCE
Email: pansiot@isis.u-strasbg.fr

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 14:00:00 GMT
From:      turnerb@IMO-UVAX5.DCA.MIL ("turner, betsy")
To:        comp.protocols.tcp-ip
Subject:   DDN GOSIP Plans


   D C A           I N T E R O F F I C E   M E M O R A N D U M

                                        Date:      07-Jun-1991 08:17am EST
                                        From:      Betsy Turner 
                                                   TURNERB 
                                        Dept:      DCSO/DISDA
                                        Tel No:    285-5040/AV356 (703)

TO: See Below

Subject: DDN GOSIP Plans                                                                                                                                             

Mr. Gary Dunn,

I received your inquiry on DDN GOSIP Plans from Roger Fradenburg, BBN 
and George Bradshaw, DCA (thanks guys from passing to me).  My name is 
Betsy Turner and I am working GOSIP Implementation for COL Thacher, DDN 
Program Manager.  George Bradshaw, DCEC, is the primary supporting 
engineer.  

Currently, DDN can support GOSIP X.25 host to host communications.  
Subscribers could use the DDN as the transmission medium to communicate 
directly GOSIP X.25 to GOSIP X.25.  Our implementation plans (still in 
working phase) are to posture the network to support GOSIP 
internetworking (TP4/CLNP).  Our DDN Pilot Internet (10 cisco IP 
routers) have the capability to do TP4/CLNP but are not currently 
configured to do so.  As you may be aware, the routing and directory 
standards are not fully mature but are expected to be so in GOSIP V3 
due around next year for draft publication.  We are currently querying 
the Services/Agencies for their GOSIP router plans over the next couple 
years in order to adequately plan the support required.

Our "tentative" plans then are thus, we could implement TP4/CLNP during 
FY 92 if subscribers express the requirement for support.  We would 
"all" have to live with some limited services; i.e. static routing 
tables, limited interoperability with DOD Standardard communications 
(I'll address more later), etc.  We anticipate COTS products based on 
the mature routing/directory standards within 1 to 2 years after the 
appropriate GOSIP version is published/mandated.  In summary, our 
implementation plans will be based on/affected by, the state of the 
standardization efforts, availability of COTS products, level of any 
DDN development required (should be little if any), feedback from S/A 
on their GOSIP plans/timeframes, and of course, availablity of funding.

Our plans also call for providing some number of Application Layer 
Gateways, to ensure GOSIP/DOD Standard email and file transfer systems 
interoperate.  This AL GW does protocol conversions between the two 
standards (GOSIP X.400/DOD SMTP and GOSIP FTAM/DOD FTP).  We have a 
prototype AL GW and support at Navy Computer and Telecommunications 
Station (NCTS) Wash D.C. (old NARDAC folks recently reorganized).  
Again, the routing and directory services are not fully 
mature/automated but we have tasking with the NCTS folks to provide 
support to users as requested.  NCTS has an OSI Lab and have been 
actively researching/testing OSI and have gained valuable experience 
that they share with us thru our InterService Support Agreement with 
them.  A side note, we are currently planning testing with the Marine 
Corps, Quantico, to test their GOSIP systems using DDN and the 
Application Layer Gateway (performance stress test).  We anticipate 
that for performance and perhaps management considerations AL GW 
may/should be a local asset in some cases (a study is being done this 
FY) but DDN PMO has been tasked by ASDC3I to provide some number of the 
boxes on DDN for backup and support to users who would not have AL GWs 
locally for a variety of reasons.

In summary, our plans are to posture the network to support both GOSIP 
and DOD standard communications user until such time that all S/A are 
transitioned to GOSIP, and to provide interoperability for the GOSIP 
and DOD standard file transfers and email systems.  We hope to complete 
our engineering analysis, based on GOSIP V2, shortly and begin near 
term implementation planning.

Thanks for your interest in our plans.  Hope I have provided some 
clarification for you and others in the community.  If we can be of 
assistance in your GOSIP plans let us know; and of course, please keep 
us advised of your timeframes so we can ensure we have the DDN postured 
to support your requirements.

Betsy Turner
DDN PMO
DCA Code DISDA
DSN  356-5040 (soon to move to X-5218)
Comm 703-285-5040 (5218 approx 2 weeks)

George Bradshaw
DCEC
DDN Systems Engineering Division
703-487-3029


Distribution:

TO:  APRM%GD@SHAFTER-EMH2.ARMY.MIL        ( REMOTE )
CC:  TCP-IP@NIC.DDN.MIL                   ( REMOTE )
CC:  RFRADENB@BBN.COM                     ( REMOTE )
CC:  TKENNEDY@WSMR-EMH05.ARMY.MIL         ( REMOTE )
CC:  CAIN@RIGEL.DCA.MIL                   ( REMOTE )
CC:  TONTONOZ@EDN-VAX.DCA.MIL             ( REMOTE )
CC:  George Bradshaw                      ( BRADSHAWG )
CC:  COONEY@WNYOSE.NCTSW.NAVY.MIL         ( REMOTE )
CC:  KENNY@NEMS.DT.NAVY.MIL               ( REMOTE )
CC:  CCOX@WNYOSE.NCTSW.NAVY.MIL           ( REMOTE )

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 15:19:21 GMT
From:      brown@OSI540SN.GSFC.NASA.GOV (Vickie Brown)
To:        comp.protocols.tcp-ip
Subject:   Ethernet/IEEE 802.3/ISO 8802-3



Can someone please direct me to an explanation of the similarities 
and differences among Ethernet and IEEE 802.3 and ISO 8802-3 ?
The documents aren't readily available to me.

Thank you in advance,
Vickie

-----------------------------------------------------------------------
  Vickie Brown                  e-mail: brown@osi540sn.gsfc.nasa.gov
  Computer Sciences Corp.       voice:  301-572-8796  CSC
  System Sciences Division              301-937-0760  CSC
  4600 Powder Mill Road                 301-286-9102  NASA/Goddard
  Beltsville, MD 20705  USA     fax:    301-937-0818  CSC
------------------------------------------------------------------------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 15:25:45 GMT
From:      carson@bcars190.bnr.ca (Carson Cheung)
To:        comp.protocols.tcp-ip
Subject:   SNMP MOSY

The following questions are related to SNMP
but since I don't know of such a news group,
here they are:

From "The Simple Book" by Marshall T. Rose,
there is a MOSY compiler for reading ASN.1
definitions of a MIB module.  Does anyone know
where we could FTP it (if it is public domain)?


Is it true that most vendors provide a soft copy
of their MIB definition that a MOSY compiler
can understand?


Is there a place where MIB I and MIB II exists
in a form that MOSY can compile?

Thanks, in advance!

Carson Cheung

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 15:43:24 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        comp.protocols.tcp-ip
Subject:   Re: AS/400 TCPIP

In article <1991Jun7.105906.75@eagle.inesc.pt> pjd@eagle.inesc.pt (Paulo Jorge Delgado) writes:
>I am installing an AS/400 on a TCPIP network, but it seems that the IBM AS/400
>TCPIP implementation does not support remote printing. I would like to be able
>to direct an AS/400 output queue to an Novell 3.11 printer or an Unix printer.
>IBM will sell me another solution - PC-Support - but I would like very much
>to stick to TCPIP. So, any sugestions? Are there any non-IBM TCPIP solutions
>for the AS/400? Yes I have heard about Mitek and I've requested some info
>from them, but are there others? Is there any product I can get to add remote
>printing to the IBM TCPIP?

we are about to do the same kind of connection.

my thoughts on this would be to have the 400 put the print job into a file,
ftp the file to the novell pc or unix box.

on the novell pc or unix box, have a program which scans the directory for
new files and submit them to the local print facility.

we are looking at getting a 50 ppm ion printer, it uses this scheme for
print queuing.

BTW: if you need info on how to ftp to your pre-3.11 novell networks, look
into the PCIP, NCSA Telnet, CUTCP, KA9Q type PC <-> TCP/IP programs.
(see comp.protocols.tcp-ip.ibmpc or something like that)

these are freely available, with source in most cases.

a commercial alternative would be FTP Inc.'s PCTCP package.
-- 
[ 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     ]

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 15:47:08 GMT
From:      koff@hpfcbig.SDE.HP.COM (Caroline Koff)
To:        comp.protocols.tcp-ip
Subject:   anyone heard of BBS?

Hi,

I'm trying to obtain an address/phone number of a company in the U.S.
called BBS that sells or supports protocol verification or conformance
test tools for TCP/IP.  If you know, please reply to me.  Thank you!

--Caroline Koff
koff@fc.sde.hp.com

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 16:35:04 GMT
From:      josh@groucho.UUCP (Joshua Sakov)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP sources


I am looking to implement tcp/ip inside an embedded system using the
Motorola 68302 (68000) processor. Can someone direct me as to where I
can get the code for the following:

1. TCP/IP
2. PPP
3. SNMP

Thanks,

Josh.

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 17:17:25 GMT
From:      MAC@psuvm.psu.edu (Michael A. Contino)
To:        comp.protocols.tcp-ip
Subject:   ten bit subnet mask question.

We are considering using a ten bit subnet mask, 255.255.255.192, for a
soon to be installed Class B network.  Ten bits of subnet provides enough
subnets of the right size, seems technically good to do and is supportable
on our routers.

Are there problems with a ten bit subnet mask or reasons not to use such a
mask?

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 18:20:55 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   gethostbyaddr(1)   (was: Confirming DNS name - what I really meant)

In article <895@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
[about telneting to the smtp port to get a host's FQDN]

I wrote a script to automate this.  'gethostbyaddr' works as follows:

1) It runs nslookup and does a PTR query.

2) If that fails, it does a telnet to the SMTP port.

3) If that fails, it telnets to the SMTP port of every host on that
network (class D is assumed) looking for one that identifies itself
with a FQ network name.  This is appended to a non-FQ host name if one
was found in step 2.  Otherwise it is returned, as is.

As each name is generated, it is translated back to an address (with
nslookup) for verification.  If a name is successfully translated back
to an address, the process stops.

You may smirk at step 3, but it is quite effective.  Many hosts use
mail software "as delivered" from the factory.  Similarly, some hosts
are non-responsive (X terminals, PCs, etc).  However, there is almost
always one host per net (such as the official mail gateway) that is
configured to do the SMTP greeting with its FQDN.

I'm not particularly proud of the idea, but it works and is very handy
for network debugging.  We've recorded 2200 different hosts in our ftp
log this year.  Only 4 of them failed to be mapped back this way.

For those 4 hosts, there is actually a step 2.5 - since step 3 can take
a while, the script telnets to the NIC and looks up various forms of the
network address.  (This virtually always works though it can be fairly
inaccurate if it has to go all the way back to, say, a class B address.)

The script has various options to control how much effort it uses.
(It does not load the network, however while writing it I was greatly
concerned that it would.)

As an example, 137.204.57.34 does not have an in-addr.arpa entry.  It
responds by smtp as "deis34.noname".  nslookup is used to verify that
this is meaningless.  The script then finds that 137.204.57.33 is
"deis33.cineca.it" so it posits that the original host is
"deis34.cineca.it".  Again, nslookup is used to verify, this time
successfully.

"gethostbyaddr" has various forms of verbosity, ranging from saying
only a FQDN to a complete description of how it figured it out.  The
script is included 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

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 18:49:29 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: KNET 200


    Date:    Thu, 16 May 1991 22:38 MDT
    From:    "Frank J. Wancho" <WANCHO@wsmr-simtel20.army.mil>
    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


  [ Views and Opinions Expressed are mine.             ]
  [ This is neither endorsement, critique, or "expert" ]  
  [ analysis - just empirical fact.                    ]

The box is old and the software dated, but you can use 
the K200 as a local ethernet channel attachment running TCP/IP.
Please note:( from prior efforts in this area)

() I would not use the version you have.
() It has proven inter-operability, and is a viable alternative,
   if you have support or source code ! 
() If you don't have to program it and are just talking using FTP
   and Telnet ( some of the timers and algorithms we found to be
   rigid, but that was back in '89-90 ) then you can iteroperate 
   with quite a number of vendors.
() The programmatic interfaces required much debugging. I built
   on top of these the second  time ( implementation ) around.

Below are some remnants of mental notes regarding the above.

The version you mentioned , 2.7 (software), is outdated and 
no longer supported ( Unless you bought the source ). It had 
quite a few bugs too.This was true as of early '90 time frame. 
I am told 3.0 is ready with 3.1 in beta by people doing work in 
this area.  

There were a great many functional enhancements we proposed
( at the time ) that went into 3.0 and subsequent point 
releases.There was a major architectural change that allowed one
KNET virtual machine to have multiple ethernet drivers
( node names and corresponding IP addresses ). Thus, you
could have an IBM host addressable by more than one IP
number. This becomes a requirement on large mainframes
( e.g.3090's running . It was proven that the K200 and not the
IBM channel would be the bottleneck , when it came to service
access. Application servers running on top of KNET eventually 
needed more than one K200 as the number of clients (seats) you had
doing large, megabyte(s), data transfers increased.
  
Configuration was not a problem as long as you had a SUN
workstation that did routing on your network. You just pointed
your KNET virtual machine ( "vianode" ) at it, for routing purposes.
IBM to IBM routing was taken care of by KNET. They had RIP, but
we never configured or used it. 

Mail worked via the 'Notes' facility and showed up as a file in
your virtual rdr. You had to have several SMTP VM's running.

The programmming interfaces were written in assembler on the 
version you have.
Version 3.0 had support for 'C', I think. They were also event
driven with no socket calls. Process to process event notification 
was via ECB posting and IUCV calls. BTW, the SAS compiler C level 
has support for both of thes functions. We went with the low-level
calls because of the need for multiple sessions from a single
server. And the interface  portions of the servers had to port to
multiple systems.

KNET TCP/IP was innovative ( circa '84 ) as a result you 
might find it a bit rigid in it's implementation.
 
IBM's implementation is working to be RFC compliant and that work
appears to be ongoing. It's not TCP/IP heaven ( there are bugs from
what I here ). But no doubt, the support and service will be there.





   George Williams

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 19:16:14 GMT
From:      jqj@duff.uoregon.edu (JQ Johnson)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   MacTCP routing question

Can anyone familiar with the internals of MacTCP explain how MacTCP
routing works?  From the MacTCP Programmer's Guide I conclude that for
Ethernet-connected Macs it "supports" RIP and a default route that can be
statically configured (in the obvious place in the CDEV).  My question is
"what does 'supports' really mean?"

How much of RIP does MacTCP support?  Is it like the braindead Kboxes that
look only at the size and source IP address of the RIP packet, or is it
more like Unix "routed -q"?

From the MacTCP Administrator's Guide, one gets the impression that the
implementation is even worse than that in a Fastpath, and that MacTCP
might simply use as its current default gateway the address of the host
from which it has most recently received a RIP packet of any form.

Does MacTCP maintain a full routing table similar to the one used by BSD
with host/network/default and RIP-derived/static/ICMP-derived route
distinctions?  Assuming that MacTCP has been told a correct subnet mask
(by static configuration or by bootp data), does MacTCP correctly store
subnet routes?  Does MacTCP even pay attention to ICMP redirects (I assume
yes since MacTCP doesn't report them to the application along with other
ICMP messages), and if so does it time them out?

I assume that MacTCP maintains a traditional ARP cache.  Does it time out
ARP entries?

Since being a RIP listener requires that one process IP broadcasts, what
broadcast addresses does MacTCP pay attention to?  Presumably the local
broadcast address, {-1,-1,-1}.  How about the network broadcast address
{net,-1,-1} and the subnet broadcast address {net,sub,-1}?  How about
old-style 0-filled "broadcast" addresses?

Do the answers to any of the above questions depend on whether it's the
current MacTCP 1.0[12] or the new version expected to be released in a
month or so? 

-- 
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

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 19:50:35 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun6.185715.16350@versyss.uucp>, philb@versyss.uucp (Phil Burtis) writes:
|> We are running SVR3.2 ATT Unix.  We have Interlan boards
|> and software.  We run TCP-IP (mostly telnet, ftp) and also
|> do some RFS over the net.  Would like to be able to have
|> uucp go over the net as well.  We've been told we need
|> a uucp daemon (uucpd?) and we don't know where to get it.
|> Interlan doesn't supply it, and ATT doesn't either.
|> Suggestions?  Thanks in advance for your time and reply.

Uucp doesn't need a daemon. uucico is started by /bin/login when the
calling system logs into the target machine. uucico is also started
on the outgoing side periodically (indirectly) cron.

	-John Kalucki

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 22:29:36 GMT
From:      syserror@bugs.zoo
To:        comp.protocols.tcp-ip
Subject:   File arguments too long!

Greetings,

Sometimes when using FTP, after using an 'mget *.xyz'  I get
the message 'File arguments too long' whereupon none of the get 
or put commands will function anymore. Others have also reported
the problem. Yet nowhere have I seen it documented. Does anyone
have an explanation for this odd behavior? Is it a bug?

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 91 23:57:36 GMT
From:      mbh@copsw33.UUCP (Marc Hasson)
To:        comp.protocols.tcp-ip
Subject:   (re)Request for Ethernet addresses by Vendor

As MURPHY would predict, I deleted a posting from a few weeks back that
contained the 3-byte values assigned to Ethernet card vendors.  NOW I have
a use for such a listing, of course!

Would someone be so kind as to E-mail me a copy of what was posted or what
they consider a reasonably good list of Ethernet address block assignments?

Thank-you....
            
             
   --Marc Hasson


UUCP mail: suntzu!tdat!mbh@sun.com

U.S. mail: Teradata
           100 N. Sepulveda Blvd.
           El Segundo, Ca. 90245

Phones:    213-524-6062 (direct)
           213-524-5000 (main)
           213-524-0009 (FAX)

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 91 07:05:18 GMT
From:      cheriton@PESCADERO.STANFORD.EDU (David Cheriton)
To:        comp.protocols.tcp-ip
Subject:   Computer Communications Course at Stanford


I'm not sure this announcement is considered appropriate for this mailing list,
but hopefully there is enough interest on this list to warrant/excuse.
  I am teaching a short course entitled "Computer Communication: Principles and
Practice" July 22-26th, 1991 at Stanford University as part of the Western
Institute for Computer Science Program.  The course is open to, and intended
for, technical people who plan to work with protocols, networks, etc. and
want to get up to speed quickly.
  Please contact Joleen Barnhill@hudson.Stanford.EDU for more registration
details.  I can provide a more detailed course outline on demand.
   David Cheriton

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 91 17:27:10 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   Waterloo TCPPORT

There was some talk about this program on the net a few weeks ago.
I only caught the end of it and so am not entirely sure how it is used.
I take it that it is not a "terminal server" in that it provides a 
serial port to telnet capability, more that it provides a way of remoting
a serial port across an ethernet, is that right?
I got the executables archive only to find that it contained no docs and
I don't want to get the source (mail costs me 5 cents a kilobyte plus the
phone call here!) just for "how to use" info. The info line produced by
the program is a bit bizarre - the program seems to think it is called
SERTN, not TCPPORT and says "useage: SERTN host port program options".
Not helpful.
Anyone out there using this program and if so what for and how!
Thanks
Andrew
-- 

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

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 91 21:12:32 GMT
From:      ade@clark.edu (Adrian Miranda)
To:        comp.protocols.tcp-ip
Subject:   ethernet slide lock problems

Recently, we seem to have started having problems with the slide
lock that connects the AUI drop cable from the CISCO router to the
transceiver.  Periodically, the Cisco will start reporting:

%LANCE-5-LOSTCARR: Unit 0, lost carrier.  Transceiver problem?

There is nothing visibly wrong with the slide lock on the transceiver,
but if I fiddle with it, the errors always seem to go away.  I assume
therefore the slide lock is at fault, though if anyone has other
suggestions, please let me know.

I recall that some time ago, there was a discussion in this newsgroup
about problems with slide locks.  Perhaps someone kept an archive
of this that they could mail me?  I am particularly interested in methods
of replacing the slide lock altogether - I believe one or two people
said this was possible.

Since this has already been thrashed out recently, please email
responses.  I will summarize if it seems appropriate.

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

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 91 00:59:32 GMT
From:      davecb@nexus.yorku.ca (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun6.185715.16350@versyss.uucp>, philb@versyss.uucp (Phil Burtis) writes:
| We are running SVR3.2 ATT Unix.  We have Interlan boards
| and software.  We run TCP-IP (mostly telnet, ftp) and also
| do some RFS over the net.  Would like to be able to have
| uucp go over the net as well.  We've been told we need
| a uucp daemon (uucpd?) and we don't know where to get it.
| Interlan doesn't supply it, and ATT doesn't either.
| Suggestions?  Thanks in advance for your time and reply.

  Well, some peope don't know about it, but there really is a uucpd,
which negotiates a uucp channel over tcp/ip.
  If this is what you want, it's from Berkeley 4.x for BSD-derived systems,
and presumably is part of HoneyDanBer UUCP from AT&T...  I have HDB with
a uucpd on my Sun.

--dave
-- 
David Collier-Brown,  | davecb@Nexus.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  |  Today's featured dish:
CANADA. 416-223-8968  |      Sun-dried alligator.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 91 03:09:35 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun9.005932.17584@newshub.ccs.yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  Well, some peope don't know about it, but there really is a uucpd,
>which negotiates a uucp channel over tcp/ip.
>  If this is what you want, it's from Berkeley 4.x for BSD-derived systems,
>and presumably is part of HoneyDanBer UUCP from AT&T...  I have HDB with
>a uucpd on my Sun.

 Unfortunately for those whose UUCP comes without uucpd, you probably can't
use versions which might be publicly available.  Using uucpd you will
run into trouble right about the time uucico tries to change the terminal
characteristics to raw mode.  You need a uucico which is built to first
check if its stdin/stdout is a socket.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 91 06:36:32 GMT
From:      gilgalad@caen.engin.umich.edu (Ralph Seguin)
To:        comp.protocols.tcp-ip,comp.sources.wanted,misc.wanted
Subject:   WANTED: PD TCP-IP

Hi.  I'm looking for a PD implementation of TCP-IP with sockets (of course :)
It needs to be device independent (ie, serial line, ethernet, FDDI, what have
you :).  Standard clients (ftp, telnet, rlogin, ...) are not necessary, but
would be nice.  I'd like to use this as the basis for an X implementation for
the Amiga.

			Thanks, Ralph

Ralph Seguin			gilgalad@caen.engin.umich.edu
536 South Forest Apt. #915	gilgalad@zip.eecs.umich.edu
Ann Arbor, MI 48104		(313) 662-4805

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 91 17:43:38 GMT
From:      dorner@pequod.cso.uiuc.edu (Steve Dorner)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP routing question

In article <1991Jun7.191614.17253@ns.uoregon.edu> jqj@duff.uoregon.edu (JQ Johnson) writes:
>How much of RIP does MacTCP support?

I've never known MacTCP 1.0.1 to listen to RIP.  I always have to configure
a static route.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 91 19:52:20 GMT
From:      stu@tandem.com (Stuart G. Phillips)
To:        comp.protocols.tcp-ip,comp.dcom.lans,rec.radio.amateur.packet
Subject:   WIRELESS digest available

The weekly digest for the WIRELESS mailing list is now available on
tandem.com through anonymous FTP.  The digest can be found in

	wireless/digest-060891


==============================================================================
Weekly digest for WIRELESS mailing list

Week ENDING June 8, 1991

This digest (or back issues) can be obtained by anonymous FTP to tandem.com
from the wireless directory.

The file wireless/wireless explains the purpose of the mailing list and
describes how to subscribe and post.

To subscribe to the mailing list, send a mail message to 
'listserv@tandem.com' with the following line in the body:

	add <your e-mail address> wireless

for example:

	add jblow@sum.domain.org wireless

The e-mail address *must* be fully qualified with the full domain name.

The WIRELESS mailing list is moderated by Stuart Phillips and Kevin Rowett.
==============================================================================

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 01:43:27 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   FTP for MacTCP?

I asked a while ago about this, but only got a few confused replies.
I have a stock Mac II machine with Ethertalk card, and MacTCP 1.0.1.
I am currently using NCSA Telnet 2.2-TCP for communications, but there
_still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
from the Mac to a remote host for file transfer.  I do *not* want to
telnet to that host and start a reverse-FTP session like with the non-TCP
Telnet and 2.3 Telnet.  Telnet and FTP exist as two different programs for
the MSDOS machines, doesn't it exist for the Macintosh?  Where?

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

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 07:09:11 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Extension on SIGCOMM Election


I called ACM last Friday to find out the status of the SIGCOMM Elections
(I'm a candidate) and learned that the deadline for returning SIGCOMM
ballots has been extended to the 30th of June because, due to a mailing
goof, international ballots were not sent out airmail and thus only recently
reached international SIGCOMM members.

Unfortunately, ACM has no mechanism for notifying SIGCOMM members of the
extension in time.  Thus this note.

So, if you are a SIGCOMM member, and have not yet sent in your SIGCOMM ballot,
you still have time.  If you threw out your ballot figuring that it wouldn't
get to ACM in time, contact Pat Ryan (patryan@acmvm.bitnet) to arrange to
cast your vote.  Note that ACM can arrange to take your vote via FAX if
necessary.  I know I speak for all the SIGCOMM candidates in encouraging
you to vote.

Please do not contact me with election issues as I am an interested party.

Thanks,

Craig Partridge

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 07:38:44 GMT
From:      bof@vieta.math.uni-sb.de (Patrick Schaaf)
To:        comp.protocols.tcp-ip
Subject:   Ether-X25-Ether, strange(?) delays

Hi Netlanders!

I'm rather new to the internals of TCP but willing to learn.
In my environment here I encounter a problem I cannot completely
understand, and I hope for some hints (or even solutions).


The environment:

  Two Ethernets connected through a very slow (9600bps) PSN X.25 link,
  with a Sun 3/80 running sunlink x25manager on our side and a Cisco
  on the other.
  My machine: A DOS PC running a derivate of the BSD4.3 TCP/IP (indirectly
  connected to our ether via a 1MB D-Link Lan, but this shouldn't matter).
  Remote machine: Another Sun 3/80 (btw, both Suns mentioned are 4.0.3EXP)


The problem:

  I rlogin from my machine to the Sun on the distant Ethernet. I run
  some applications (e.g. nn) producing one screenful of data at a time.
  After some time and some amount of data (screens) transferred, output
  stops somewhere. It then normally takes about 10 seconds to continue.
  I attribute this to multiple retransmissions stuck "in" the X.25 link
  causing several retransmits and the retransmission timer going up due
  to Karn's algorithm.

  What I don't understand is this: Once in a while, the transmission seems
  to stop completely (doesn't continue for minutes). Watching the X.25
  packet counts (vcstat on our Sun) shows that some packets are going out
  from here but no reaction comes in. When I then open a second connection
  to the same machine through the same link (originating from another
  PC on the same net), IT WORKS, at rather normal (low) speed (until I
  burst again).

  NB: Normally I (my connections) am the only one using that particular
  X.25 link (which is a permanent SVC), but it might be that the full stop
  occurs at some time when somebody else just did something.


The Questions:

  - Is it possible for Sun's TCP implementation to explode retransmission
    timeouts to minutes' frequency?
  - Is it possible to make TCP work better (smoother) in such an extreme
    environment, and if, how (explanations based on the 4.3BSD code would
    be best).
  - Is there a possibility to monitor the RTT estimates on the distant
    Sun? I would be very interested to study the delays.
  - Did I forget to ask something relevant?


Thank you in advance for your help
  Patrick

--
Patrick Schaaf, SysAdm at the Math Dept., University of Saarbruecken, Germany,
                aka bof@math.uni-sb.de
All relevant signature standards ignored...

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 15:21:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   PD SMTP Packages for PD TCP/IP

Hi, netlanders!

	Forgive me if this is the inappropriate list, but are there any 
SMTP packages for PCs with NCSA Telnet or another PD TCP/IP packages? 

	Currently, we have NCSA Telnet and FTP Software's PC/TCP.  The 
PC/TCP offers the ability to send and receive mail at the PC, which is not 
possible for NCSA Telnet with 2.2 or 2.3b10 versions.  The NCSA users must 
telnet into a host which supports mail to send and receive mail.  From a 
strictly human standpoint, the sentiment may be simplified by the comment 
"If they can do it, I want to, too!".

	Technically, it is my understanding that NCSA for DOS (as opposed to 
Apple and whatever else) does not support any mail capabilities.  If this is 
a "given", and NCSA has no plans in the near-future to offer SMTP options, 
the next question becomes "How can users of NCSA send and receive mail and do 
so independent of logging into another host?" I suspect somewhere in the land 
of Internet exists a PD SMTP package which will work with NCSA Telnet, or 
perhaps some other PD TCP/IP package.  I am asking for pointers, redirects, or 
a simple "No such package exists." 

	NCSA Telnet users, while quite loyal to their package, will consider 
another PD package which will provide VT100 emulation and Tektronix 4014 
emulation as well.  The need for 4014 is being replaced by a need for 3270 
emulation, so a package which would offer both is preferable.  The need to 
work on the 3c501, 3c503, and WD80003E is a must, and NDIS drivers will be 
very welcome.

	I would appreciate whatever insights, recommendations, or warnings 
anyone is willing to give.  In the event this is deemed to be of interest to 
others, the list as a return address is fine with me.  

	Thanks.
							Kathy
							Rinehart@AEDC-VAX.AF.MIL

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 15:45:42 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun9.030935.27196@mp.cs.niu.edu>
	rickert@mp.cs.niu.edu (Neil Rickert) writes:
>Using uucpd you will run into trouble right about the time uucico tries to
>change the terminal characteristics to raw mode.  You need a uucico which
>is built to first check if its stdin/stdout is a socket.

Or my `uucpm' daemon which sits on the other side of a pty from uucico.
I announced availability of a test version last week over in
comp.unix.sysv386, and sent out copies last weekend.  It was written
for and tested under SCO UNIX and XENIX, but it sounds like some folks
plan to try it in other environments.  I'd be glad to send out copies.
There has been enough interest that I will probably post it to the
net after a shakedown period.

-- 
Chip Rosenthal     <chip@chinacat.Unicom.COM>  |  Don't play that
Unicom Systems Development      512-482-8260   |    loud, Mr. Collins.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 16:50:45 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: Ether-X25-Ether, strange(?) delays

From article <bof.676539524@vieta.math.uni-sb.de>, by bof@vieta.math.uni-sb.de (Patrick Schaaf):
[...]
> The Questions:
> 
>   - Is it possible for Sun's TCP implementation to explode retransmission
>     timeouts to minutes' frequency?

From my experience: yes, though other TCP (notably 4.2bsd) are even worse
and have the problem of coming to a full stop completely.

>   - Is it possible to make TCP work better (smoother) in such an extreme
>     environment, and if, how (explanations based on the 4.3BSD code would
>     be best).

I've never tried to fiddle around in the kernel for this purpose.
My simple solution was alway to use X28/X29 instead of telnet for those
slow X.25 based connections (for ftp it really doesn't matter how fast
it is).

>   - Is there a possibility to monitor the RTT estimates on the distant
>     Sun? I would be very interested to study the delays.

Use 'ping -s'

>   - Did I forget to ask something relevant?

If the PC is DOS based, the TCP/IP may not really be 4.3 derived and may
have problems with reassembling fragmented IP frames. This leads
to the effect that TCP connections hang absolutely even though more
IP traffic over the same SVC is still floating.

Don't use x25manager, use x25mgr which comes with SunNet X.25 7.0.
Try to fiddle with the MTU on both the cisco and the sun side, use
the same value on both ends. (RFC877 specifies 576 as a minimum, but
for faster interactive performance you may prefer 128).

Use the maximum available X.25 packet size for the link.
Use window size 7 if negotiatable.

Best question: ask for a faster link. The sun can handle up to 64kbps if
it's a sun4 (over the cpu ports).
(This is not the general purpose answer for overloaded or misworking
circuits, but for 9600 IP/X.25 links it is).

Hope that helps a little
---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless
             bandwidth - the final frontier.

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 18:23:51 GMT
From:      aprm%gd@SHAFTER-EMH2.ARMY.MIL (Gary Dunn)
To:        comp.protocols.tcp-ip
Subject:   What is NFSNET?

Text: 

Excuse my ignorance, but I've seen a few references to NFSNET here
recently and don't know what that refers to.  Here in the Islands, we
still use the Coconut Wireless to carry important stuff, like surf
reports, fishing tips; you know, the stuff that really counts.  High
tech doesn't do well in our corrosive air, and then there's all that
sand...

Can someone please enlighten this island boy?
 
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                      |
                                        /
 
	"We have probed the earth, excavated it, 
	burned it, ripped things from it, buried 
	things in it. . . .That does not fit my 
	definition of a good tenant.  If we were 
	here on a month-to-month basis, we would 
	have been evicted long ago." 
		Rose Elizabeth Bird 

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

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 18:44:00 GMT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

>I asked a while ago about this, but only got a few confused replies.
>I have a stock Mac II machine with Ethertalk card, and MacTCP 1.0.1.
>I am currently using NCSA Telnet 2.2-TCP for communications, but there
>_still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
>from the Mac to a remote host for file transfer.  I do *not* want to
>telnet to that host and start a reverse-FTP session like with the non-TCP
>Telnet and 2.3 Telnet.  Telnet and FTP exist as two different programs for
>the MSDOS machines, doesn't it exist for the Macintosh?  Where?


Check out the InterCon TCP/Connect II package for the Mac.  It has
everything a full suite Internet host should have including SMTP, Telnet,
client and server FTP, finger, SNMP, POP, NFS, and much more.  I was
impressed by the product.  This is NOT a public domain package.  The full
package is about $750.  Quantity discounts are available as well as you
can pick and choose the features you want.


L. Michael Sabo
dockmaster.ncsc.mil

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 19:38:54 GMT
From:      werner@pandora.inesc.pt (Werner Hans Peter Vogels)
To:        comp.protocols.tcp-ip
Subject:   how to arp for a non local address.

I would like to use arp to resolve some other addresses then those of the
local network. I have my own arp daemon to respond to these questions, but I
fail to set up the environment correctly that the right questions are made.

If I do a "route add net 224.0.0.0 mymachine 0" (yes, I am experimenting with
multicast IP) not only the address resolution for this address goes through
arps but all the other address resolutions as well. (we have a "route add 0
gateway 2" standard routing for the outside world)

What should I do to make the address resolution for a number of networks
go through arp and all other will be send to the gateway.

Thanks in advance.

--
Werner Vogels

Distributed Systems Group / Projecto de Automatizacao Industrial
INESC - Instituto de Engenharia de Sistemas e Computadores
Rua Alves Redol, 9-6o - 1000 Lisboa - Portugal
Tel: +351 1 545150 ext 280, Fax: +351 1 525843, e-mail: werner@inesc.inesc.pt

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 20:10:46 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Board Level Ethernet/TCP/IP Products

Several weeks back I posted an inquiry about boards that integrated
an Ethernet interface with a TCP/IP implementation. In particular I
asked about peoples' experiences with products from Motorola, CMC,
and SBE, and asked for pointers to other implementations.

When the smoke cleared, there were only two vendors, CMC and SBE, that
really offered what we wanted. From the responses it's clear that there
is lots of good hardware out there for what we want; few people griped
about board performance. The TCP/IP was a different issue entirely.

I spoke to several vendors and tried to collect technical documentation
and recommendations from users for their TCP/IP products. Here are the
highlights:

SBE --

Not very well known in the Internet community. They've shipped hundreds
of boards running TCP/IP, and they seem to be used primarily on private
networks. Their product is based on the Spyder implementation, which
they've modified. I talked to two OEMs, both very enthusiastic about
the product and with the quality of support they received from SBE.
None of the users seem to have much experience running connections
on the Internet or even through gateways, though.

I reviewed the technical documentation. The board's interface is very
streams-like: they pass streams data structures between the host and
the TCP board. SBE provides hooks into every level of their protocol
stack to allow for such things as specifying gateways or even
for implementing non-standard protocol stacks. To do so you open a
channel/socket with the appropriate "device" identifier. The OEMs who
worked with the SBE board said that their driver interface was pretty
easy to work with, though one of them only needed to recompile SBE's
Unix compatible driver.

CMC --

It was obvious from my mail that CMC is well known. I also got responses
from CMC employees on the Net. The general form of non-employee messages
was "We tried them two years ago, their protocol software was buggy, and
they didn't fix things very fast." I passed this perception along to
the guys at CMC. They said their software has vastly improved in the
past couple of years, and their employees evidently use it routinely
for interacting with the Internet. We also heard from their sales rep
that they're trying to improve their handling of customer problems by
setting up deadlines by which problems are supposed to be addressed
and resolved.

I reviewed CMC's technical documentation, too. The board's interface
takes essentially the opposite approach to SBE: their interface uses
fixed size ring buffers similar to those used by the Ethernet LANCE
chip. They use the ring buffers for communication between the two
processors, and use a bunch of auxiliary queues and channel structures
with flow control ring buffers that are maintained separately by each
processor. Like SBE, CMC provides access to different layers of the protocol
stack, though they limit such usage to specific channels/sockets in their
interface. One respondent claimed that they had trouble building a driver
to do streams with this interface, though CMC now offers such a driver.

Interphase --

We communicated at length with Interphase. They provided several thick
manuals about their TCP/IP, none of which applied to what we were
looking for. They claim that they have a product with a board-resident
TCP/IP implementation, but ultimately they could not provide us with a
document describing the interface. They said it was "in preparation."

Motorola --

Different people at Motorola told us different stories. Evidently they
used to sell the CMC product with a Motorola label on it. Now they
are said to have some relationship with Interphase. They advertise
the MVME374, a board that claims in its tech sheets to support TCP/IP.
Maybe so, but the current version isn't completely resident on the board.
We called off our search for a Motorola product since we couldn't find
a technical manual describing an on-board solution.

Single Board Alternatives --

Several respondents recommended a sort of "component assembly" approach,
like getting a board-resident monitor (VxWorks, pSOS, OS-9, etc) and
running with a TCP/IP on top of one of them. A couple of people had
personal experience with such things and claimed that the right set
of components would outperform any of the prepackaged TCP/IP boards.
However, you'd then typically have to do your own implementation of
an interprocessor communications protocol for handling the socket
interactions.

Many thanks to those in Net.Land who responded to my request for info.

Rick.
smith@sctc.com    Arden Hills, Minnesota

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 23:53:26 GMT
From:      slf@well.sf.ca.us (Sharon Lynne Fisher)
To:        comp.protocols.snmp,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Managing heterogeneous LANs


I'm doing a story for LAN Magazine about how users are managing
heterogeneous networks *today*.  If you are such a user, and would be
willing to talk to me for the story, please respond here or send me mail.
Thanks!

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 91 23:56:27 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

>  If this is what you want, it's from Berkeley 4.x for BSD-derived systems,
>and presumably is part of HoneyDanBer UUCP from AT&T...  I have HDB with
>a uucpd on my Sun.

The Sun version of "uucpd" came from 4.xBSD, not from AT&T.  The HDB in
SunOS 4.1 has a lot of stuff from the H of HDB in it; its support for
UUCP-over-TCP is among that stuff (as is support for the "max grade"
stuff).

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 00:11:41 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

>Uucp doesn't need a daemon. uucico is started by /bin/login when the
>calling system logs into the target machine.

Well, that's *one* way "uucico" can get started; however, it's not the
*only* way.  The 4.xBSD UUCP-over-TCP mechanism doesn't involve a normal
login from the calling system to the target machine; instead, the
calling "uucico" makes a TCP connection to some particular TCP port on
the remote machine (normally port 540), which connects it to the UUCP
daemon on the target machine.

The UUCP daemon prompts for a login name, reads that, prompts for a
password, reads that, and does the same checks that "login" does (it
originally didn't do so; that was added later), and then directly runs
"uucico".  The two UUCPs then communicate using a protocol such as the
"t" protocol, running on top of TCP, rather than the "g" protocol used
over asynchronous serial lines (although you can run UUCP-over-TCP on a
connection that passes over an asynchronous serial line using SLIP or
PPP, of course...).

Now, as the person who asked the original question is running SVR3.2,
the above doesn't necessarily apply.  S5R3.2's UUCP has its *own* way of
doing UUCP over various transport layers; it uses TLI, which achieves
its goal of transport independence, in part, by not supporting any form
of host-name-to-address translation, and requires you, from what I've
seen, to put long strings of hex digits representing a transport-level
address into the Systems file.  (S5R4, with the aid of run-time dynamic
linking, actually admits host+service-to-address translation into the
Wonderful World of TLI; whether its UUCP makes use of that, or still
requires hex digits in the Systems file, I don't know.)

That address is the address of the "listener" process on the remote
machine, which is a somewhat bizarre sort of network daemon that
requires those who want to connect to it to send an identifier for the
service to which they want to connect as *data* over the connection,
rather than letting you simply say "this transport address belongs to
this service" - or, at least, it did so in the S5R3's I've seen; perhaps
they've replaced it with something rational (or, at least, capable of
supporting normal Internet-style services) in S5R3.2.

The "listener" would occupy the same niche in that scheme of
UUCP-over-TCP as "uucpd" does in a BSDish scheme.  There may well be
documentation somewhere in the S5R3.2 documentation set on how to set
that up, unpleasant long strings of hex digits and all....

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 01:28:01 GMT
From:      mark@monitor.plymouth.mi.us (Mark Harris)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and NFS software for Interactive UNIX

I am interested in hearing people's opinions on the best TCP/IP software,
and the best NFS software, available for the 386 or 486 running Interactive
UNIX.

The board level TCP products sound attractive, but how noticeable is the
speed advantage?  And which of the products are the fastest and most
reliable?  How do Interactive's own TCP and NFS products compare with
those available from other vendors?  I have heard rumors that Interactive's
NFS is buggy, but can anyone confirm or deny that it is any more buggy than
anyone else's?  Any comments would be most appreciated.

Mark Harris
mark@monitor.plymouth.mi.us

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 12:10:41 GMT
From:      hoagland@mailer.cc.fsu.edu (Jim Hoagland)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

In article <30989@hydra.gatech.EDU> ce1zzes@prism.gatech.EDU (Eric Sheppard)
writes:
>I asked a while ago about this, but only got a few confused replies.
>I have a stock Mac II machine with Ethertalk card, and MacTCP 1.0.1.
>I am currently using NCSA Telnet 2.2-TCP for communications, but there
>_still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
>from the Mac to a remote host for file transfer.  I do *not* want to
>telnet to that host and start a reverse-FTP session like with the non-TCP
>Telnet and 2.3 Telnet.  Telnet and FTP exist as two different programs for
>the MSDOS machines, doesn't it exist for the Macintosh?  Where?
>
>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
>


  There is a nice hypercard stack at sumex-aim.stanford.edu called HyperFTP. It
works great with MacTcp.

 Jim Hoagland
 Florida State University
 Tallahassee, Florida 32306

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 13:01:22 GMT
From:      mrb@mitre.org
To:        comp.protocols.tcp-ip
Subject:   IEEE 802.3 Driver for Xircom Adapter

I am currently looking for a way to attach a Zenith Supersport Laptop to
an IEEE 802.3 LAN using a Xircom pocket Ethernet adapter.  At this time,
Xircom does not have an IEEE 802.3 compatible driver.  Any suggestions/
work arounds would be greatly appreciated.

Michael R. Brown
The MITRE Corporation
Bedford, MA  01730
(617) 271-7998 

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 18:33:42 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote:
>In article <1991Jun9.030935.27196@mp.cs.niu.edu>
>	rickert@mp.cs.niu.edu (Neil Rickert) writes:
>>You need a uucico which is built to first check if
>>its stdin/stdout is a socket.
>
>Or my `uucpm' daemon which sits on the other side of a pty from uucico.

Due to the number of requests, I just posted this to alt.sources.

-- 
Chip Rosenthal     <chip@chinacat.Unicom.COM>  |  Don't play that
Unicom Systems Development      512-482-8260   |    loud, Mr. Collins.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 19:02:29 GMT
From:      ken@slhisc.uucp (Ken Stamm)
To:        comp.sys.mac.comm,comp.protocols.tcp-ip
Subject:   Re: MacTCP routing question

In article <1991Jun9.174338.23613@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>In article <1991Jun7.191614.17253@ns.uoregon.edu> jqj@duff.uoregon.edu (JQ Johnson) writes:
>>How much of RIP does MacTCP support?
>
>I've never known MacTCP 1.0.1 to listen to RIP.  I always have to configure
>a static route.

Funny, my MacTCP 1.0.1 seems to listen quite well to RIP packets put out by
a cisco router on my net, and I can get to any host on our internet without
static routing entries...
-- 
Ken Stamm (uunet.uu.net!slcpi!slhisc!ken) (212)341-3868

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 19:51:47 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: File arguments too long!

In article <1991Jun7.222936.24697@ucselx.sdsu.edu> syserror@bugs.zoo writes:
>Sometimes when using FTP, after using an 'mget *.xyz'  I get
>the message 'File arguments too long' whereupon none of the get 
>or put commands will function anymore.

It may help to know what system you are getting this on.  I would bet
money that it's a unix box and that you have a LOT of files called
xxx.xyz.  There are fixed limits to the size of the argument list in
unix.  BSD's ftpd just forks a process to get the list.  As part of
the process, the file names get expanded.  In this expansion, there
are so many files that this fixed limit gets exceded, hence the error
message.  I'd say that it is a BUG since there are no arbirary limits
imposed by the FTP protocol.

The reason that none of the get/put comands work anymore is that there
was "garbage" on the FTP command connection, so everything gets out of
sync.  I'd maintain this is also a bug since a conforming server
shouldn't do this either.

A work around?  I'm not sure if there is one.  Maybe you can use
shorter filenames.  Or CD to the directory where the files are (after
all, mget * takes up a lot less space than mget
/usr/home/graphics/imp/foo/bar/bas/bang/* since the path isn't
repeated for each element.  You may try grouping the remote files by
type in some way.

Warner
-- 
Warner Losh		imp@Solbourne.COM
Free to a good home: 10,000 Miller Moths.  Must promise not to breed them.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 19:55:31 GMT
From:      dberry@sei.cmu.edu (Daniel Berry)
To:        comp.protocols.tcp-ip
Subject:   Historical questions on Ethernet


I am not in the networks area. Hence there are a number of historical questions
I have which I cannot easily answer.

Please send me either answers or pointers to where the information is
published..

1. Were the first massive non-Xerox-private installations of Ethernet in
universities (as opposed to commercial customers)?

2. Regardless of where Ethernet was installed first, did its installation
at universities contribute (e.g., as with UNIX) to its commercial success?

3. Did Ethernet connectivity to the Internet influence Ethernet growth?

4. What equipment was used to connect LANs to the Internet's WAN?

5. Was there any particular Ethernet equipment that succeeded primarily
because it was able to connect LANs to the Internet's WAN? If so, were the
first external installations of this equipment at universities?

6. What is the current size of the Internet and all networks connected to
it (any measure, e.g., no of nodes)?

Thanks
Dan
Prof. Daniel M. Berry, Computer Science Department, Technion, Haifa 32000 ISRAEL
+972-4-294325, DBERRY@TECHSEL.bitnet dberry@cs.technion.ac.il
Dr. Daniel M. Berry, Software Engineering Institute, Carnegie Mellon Institute
Pittsburgh, PA 15213, +1-412-268-7778 dberry@sei.cmu.edu FAX:+1-412-268-5758

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 20:05:09 GMT
From:      mt@cleo.cs.wisc.edu (Manolis Tsangaris)
To:        comp.protocols.tcp-ip
Subject:   SL/IP under MAC-TCP

Netters,

Do you know if MAC-TCP can support SL/IP? The version that comes 
with MacX 1.2, has only Ethernet support, whereas the manual pages
show a dialog of the ``Connection Tool'' that can use ethertalk, localtalk
or serial line.

Thanks

--mt

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 20:27:31 GMT
From:      hwajin@daahoud.wpd.sgi.com (Hwa-jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Board Level Ethernet/TCP/IP Products

>>>>> On 10 Jun 91 20:10:46 GMT, smith@sctc.com (Rick Smith) said:

Rick> SBE --

VxWorks which includes 4.3 tahoe TCP/IP runs on SbeVlane as well.  The
performance for this configuration is really good (price/performance
wise), definitely worth checking out.  Applications written for
VxWorks can run directly on-board using the socket library.

Rick> Motorola --

Rick> Different people at Motorola told us different stories. Evidently they
Rick> used to sell the CMC product with a Motorola label on it.

Motorola used to re-sell ENP-10 as MVME330.  They started pushing MVME374
a few years ago.

Rick> Now they are said to have some relationship with Interphase.
Rick> They advertise the MVME374, a board that claims in its tech
Rick> sheets to support TCP/IP.  Maybe so, but the current version
Rick> isn't completely resident on the board.  We called off our
Rick> search for a Motorola product since we couldn't find a technical
Rick> manual describing an on-board solution.

MVME374 has on-board 68020 and Motorola has pSOS based realtime OS
that has TCP/IP support for it.  Motorola Unix driver (STREAMS) for
this board talks to the CE/BPP (common environment/buffered pipe
protocol) code that gets downloaded to the board.  This is similar to
other vendor's approaches.  In general, this kind of solution doesn't
yield a very good performance.  The overhead of talking to the
software running ethernet board from the host + data copying over VME
costs quite a bit, and prohibits any possible driver level
optimizations.  Perhaps that's why so many smart people seem to be
attracted to simple on-board shared memory style network interfaces.

Rick> Single Board Alternatives --

Rick> Several respondents recommended a sort of "component assembly" approach,
Rick> like getting a board-resident monitor (VxWorks, pSOS, OS-9, etc) and
Rick> running with a TCP/IP on top of one of them. A couple of people had
Rick> personal experience with such things and claimed that the right set
Rick> of components would outperform any of the prepackaged TCP/IP boards.
Rick> However, you'd then typically have to do your own implementation of
Rick> an interprocessor communications protocol for handling the socket
Rick> interactions.

If your application can be ported to the board-resident monitor/OS
that supports TCP/IP and controls the ethernet chip directly, the
performance of your end product will be much better.  Portability is
pretty high in case of VxWorks, but I haven't used pSOS or OS-9
solutions.  If your application cannot be ported, communication
between the board software and host software can be implemented as you
suggested, and the communication overhead over the bus will be
typically lower than the overhead required for communication between
the driver and the board.

*hwajin

--
protocol engines inc.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 21:46:24 GMT
From:      ehrlich@cs.psu.edu (Dan Ehrlich)
To:        comp.protocols.tcp-ip
Subject:   ppp or cslip or slip on Sun 4/110 and SPARCstation2

Hello,

I am working with some people at U of Pitt EE to try and get a SLIP link up
between a Sun 4/110 (running 4.1.1) here at Penn State and a SS2 (running
4.1.1B) at U of Pitt.  There will be TrailBlazer T1600s at both ends by
tomorrow morning (isn't FedEx wonderful? :-).

We have had no luck making PPP talk between two SS2s in the same room and
just assumed that PPP does not run on an SS2.  Is this the case?  If not,
are there any changes that need to be made for the SS2?

As we are running short of time we would like to be able to fall back to
running SLIP (or compressed SLIP) if PPP does not work.  Can someone supply
me with the appropriate settings for a TrailBlazer T1600 that will be used
to run SLIP and/or PPP?  Any and all help would be appreciated.  Please
reply by e-mail and I will summarize back to this list.

Thanks!
--
Dan Ehrlich - Sr. Systems Programmer - Penn State Computer Science
<ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 91 22:04:57 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

In article <1991Jun3.163841.4114@bwdls61.bnr.ca> mleech@bnr.ca (Marcus Leech) writes:
> Has anyone done an authenticated SMTP, and if so, is there an RFC in
>   existence that describes it?

RFC 931, the Authentication Server, provides enough additional security
to stop those pesky undergraduates from forging mail (at least without a
network machine of their own). You can get my implementation of RFC 931
for BSD machines in stealth.acf.nyu.edu:pub/hier/inet/rfc931/authd.3.01.
You can make sendmail (5.61, 5.65, possibly others) understand RFC 931
by applying sendmail-patches-djb, available from the same place; after
the patch, $F in an H line in sendmail.cf will print the remote user
name for any SMTP connection.

> I realize that this breaks the existing SMTP philosophy of allowing any
>   SMTP to connect to any other.  I'm thinking of corporate internets, rather
>   than "the INTERNET".

RFC 931 can be used over any part of the Internet. In fact, it's the
only working freely available wide-area TCP authentication code I know
of. If you do want to restrict access to the local net or to
authenticated connections, you can use my attachport (comp.sources.unix
volume 22) or shuctld (coming very soon to a source group near you).

---Dan

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 01:13:51 GMT
From:      eps@TOASTER.SFSU.EDU (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <8295@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>Now, as the person who asked the original question is running SVR3.2,
>the above doesn't necessarily apply.  S5R3.2's UUCP has its *own* way of
                ^^^^^^^^^^^
>doing UUCP over various transport layers; it uses TLI

That's only one of the options.  There are several others
in the source code, including a BSD 4.2-style sockets
implementation that does a getservbyname("uucp", "tcp").
It all depends on what's #defined in parms.h at compile time.

Will it interoperate with BSD uucpd?  Not out of the box.  For
one, AT&T's code uses 'e' protocol rather than 't' protocol over
TCP connections.

					-=EPS=-

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      Wed, 12 Jun 91 03:38:24 GMT
From:      datta@ee.utah.edu (Sanchaita Datta)
To:        comp.protocols.tcp-ip
Subject:   Network management for routers



Hi, 
I am new to the net management world. I have a few questions 
about Network Management for routers.

1.  Why is the 68000 microprocessor the preferred choice
    for routers?
2.  What are the advantages of using 68000 for snmp agent 
    for routers?
3.  Are there public domain sources for:
     -- UDP/IP stack
     -- SNMP agents for routers and HUBs

All the info. I can get would be greatly appreciated.

Thanx
Sanchaita
datta@ee.utah.edu


-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 03:49:14 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE 802.3 Driver for Xircom Adapter

In article <1991Jun11.130122.15791@linus.mitre.org> mrb@mitre.org writes:

   I am currently looking for a way to attach a Zenith Supersport Laptop to
   an IEEE 802.3 LAN using a Xircom pocket Ethernet adapter.  At this time,
   Xircom does not have an IEEE 802.3 compatible driver.  Any suggestions/
   work arounds would be greatly appreciated.

They would have one if they weren't such scum (see below).  The
Clarkson packet driver collection now (as of the 9.x release) supports
802.3 packets (courtesy of Eric && Colin at BYU).  But Xircom opted
out of the Clarkson packet driver project...

I wrote some skeleton software to assist people writing network
drivers.  It's copyrighted using the FSF's GPL.  Xircom donated one of
their pocket Ethernet adapters to Brad Clements in our computing
center.  He used their object module and wrote some of his own code,
and linked it to my skeleton.  They were not happy when Brad told them
that the copyright required that they release their source code.  And
I insisted that they do so.  So we came up with a compromise -- they
would give the source to anyone who signed a nondisclosure agreement.
I thought that was reasonable (at the time), and agreed to it.  So
they went on distributing it.  Then I heard that they had reneged on
our agreement, and that they were writing their own proprietary packet
driver.  However, they continued to distribute the one derived from my
code so I called for a boycott of their products.  Legal action
wouldn't be useful, because I have no money to sue them, and they've
been making lots of money off their adaptors.  And even the boycott
isn't going to accomplish much because the people who need packet
drivers aren't a large part of their business.

So, I guess they get away with their theft.

There are alternatives to their products, made by D-Link.  D-Link's
products are cheaper, and there is a packet driver for the DE-600
thinwire adapter (at least).  I have found D-Link to be a very
responsive company.  For example, they supply a sticker for their
internal adapters that explains the jumper positions.  This is
unusual, and very handy.

USA			UK			International
D-Link Systems, Inc	D-Link (U.K.) Ltd.	Datex Systems, Inc.
5 Musick		23A lyttelton Rd	15-4, FL
Irvine, CA  92718	London, N2 0DN		No. 1, Fu Hsing North Rd.
USA			UK			Taipei, Taiwan, R.O.C.

--
--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

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 07:52:44 GMT
From:      sl@wimsey.bc.ca (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun11.183342.23051@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes:
>In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote:
>>In article <1991Jun9.030935.27196@mp.cs.niu.edu>
>>	rickert@mp.cs.niu.edu (Neil Rickert) writes:
>>>You need a uucico which is built to first check if
>>>its stdin/stdout is a socket.
>>
>>Or my `uucpm' daemon which sits on the other side of a pty from uucico.
>
>Due to the number of requests, I just posted this to alt.sources.

I've tried this and it works quite well on SCO UNIX and SCO XENIX. I'm now feeding
someone a news feed over a double PPP link. Looks something like:

	SCO UNIX <-> router <-> router <-> router <-> SCO XENIX
                             ^          ^
                             |          |
			     PPP        PPP

The outside lines are ethernet. The inside two links are PPP running over a V.32bis
/V.42bis and V.32 connection respectively.

The problem now is that with SCO's uucico you can only use the "g" packet level
protocol. This is blessed with small packets (64 bytes data) and a small window size
(3, can be adb'd up to 7). The end result is truly amazing throughput :-) About 102
cps with windowsize of 3 and 170 with windowsize 7.

Anyone feel like building uucp spoofing into uucpm and uucpd :-) (aka Trailblazer
uucp spoofing). 

I also heard a rumour that a uucp replacement was announced at a Dallas BOF, any
details? A replacement uucico would certainly do the trick.

Anyway we now get to knock SCO (and other 386 vendors) for not including a uucp daemon
when we can see how easy it is to implement AND for being so totally short sighted 
that they didn't include any protocols other than the standard "g" protocol. It's
one thing to not port something (like uucp[md]) but presumably they actually had to
turn off linking in the alternate protocols.

I dream of a day when van-bc has all the networking facilities available on a Sun. 

Maybe I should start looking for a Sparc Clone. Might be the only way to get
proper networking. I sometimes wonder if the Intel UNIX market will survive the
attack of the Killer Micros (as embodied by various RISC UNIX systems).

-- 
Stuart Lynne	Computer Signal Corporation, Canada
		...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca 

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 12:04:18 GMT
From:      RICHER@VAX.DARPA.MIL (Ira Richer)
To:        comp.protocols.tcp-ip
Subject:   symposium


please circulate this announcement as widely as possible within your
organization and to others that might be interested.  any registrations
received within the next week or so should be honored at the reduced
rate.

ira richer

___________________________________________________________________


Invitation to: 
Symposium on Gigabit Networks
Sponsored by DARPA, DOE, NASA, NSF
- --------------------------

MAJOR ADDRESSES BY:

John Armstrong, VP for Sci and Tech, IBM;

Solomon Buchsbaum, Senior VP, Tech Systems, AT&T Bell Labs;

John Rollwagen, Chairman and CEO, Cray Research;

Raymond Smith, Chairman and CEO, Bell Atlantic; and 

Eugene Wong, Associate Director, Office of Sci and Tech Policy, Exec     
  Office of the Pres

July 15, 16 and 17, 1991
Grand Hyatt, Washington, DC
- --------------------------

OBJECTIVE:

Research and development efforts are underway across the network 
community to design and build networks that run at speeds on the 
order of one gigabit (one billion bits) per second or more.

These new ultraspeed networks are enabling new and exciting 
applications in science, business and education.  But many 
challenges face their designers in areas of technology, architecture 
and desired functionality.

Moreover, open issues exist in both the business and policy arenas.  
Resolution of these challenges and issues will determine the shape 
of these future ultraspeed networks.

The symposium has been created to provide an overview of the 
current state-of-the-are in gigabit networks, and to provide in-
depth discussions of the critical issues facing designers, users, 
policymakers and planners.
- ----------------------

ORGANIZERS:

General Chairman:  Ira Richter, DARPA

Program Chairman:  Albert Vezza, MIT

Steering Committee:
Francis Balint, NOAA
John Cavallini, DOE
Darleen Fisher, NSF
Daniel Masys, NLM
Kevin Mills, NIST
Joan Novak, EPA
Elaine Stout, USGS
Anthony Villasenor, NASA

Technical Program Committee:

Geoffrey Baehr, Sun Microsystems
Alan Baratz, IBM
Bill Buzbee, NCAR
David Farber, Univ. of Pennsylvania
Richard Gitlin, AT&T Bell Labs
Robert Kahn (Chairman), CNRI
Leonard Kleinrock, UCLA
F. Thomas Leighton, MIT
John Ousterhout, UC Berkeley
Stewart Personick, Bellcore
Daniel Swinehart (V. Chairman), Xerox
David Walden, BBN
Richard Watson, Lawrence Livermore, National Labs
William Wulf, Univ of Virginia

- - --------------------------------------------------------
PROGRAM;

Switching Technology	
Chairman: Eric Nussbaum, Bellcore (retired)
State-of-the-art of switching technology - Key issues in switch design
such as scaling, architec- ture, engineering tradeoffs and commercial
viability- Perspectives of telecommunications and computer vendors

WANs, MANs, LANs and PANs
Chairman: Vinton Cerf, CNRI
Architecture, technology and standards for wide area, metropolitan
area, local area and personal area gigabit networks - Network
interconnection issues

Theoretical Considerations
Chairman: Leonard Kleinrock, UCLA
Algorithmic concepts and theoretical results impacting design and
performance of ultraspeed networks - Critical issues of network
stability, control routing, resource allocation and performance
analysis

Business and Policy Challenges
Chairmen:  Ira Richer, DARPA and William Wulf, U. of Virginia
Double session covering perspectives of users, cariers, technology
suppliers, and government policy makers - Business, economic,
regulatory,plan- ning and standards issues concerning the emergence of
gigabit networks

System Software Services
Chairman: Duane Adams, CMU
Focus on models for system software to support gigabit networks -
operating systems, protocol implementations, programming techniques
for distributed systems, and distributed system

Future Applications
Chairman:  Michael Dertouzous, MIT
Untapped applications of ultraspeed networks for education and
training, business and commerce finance and banking, science and
technology, and entertainment and other consumer services

Host and Network Interfacing
Chairman: Gregory Chesson, Silicon Graphics
Interconnecting host computers and networks - Design options for
computer interfaces,, outboard processors, network adapters and
controllers - speed and efficiency considerations

Digital Video and Imaging 
Chairman: David Walden, BBN 
Role of digital video and imaging systems in the context of ultraspeed
networks - Key issues of production, storage, processing, distribution
and display of digital video and images - Digital video standards -
Overview of the state-of the-art digital video

Implications for Scientific Research
Chairman: Sidney Karin, San Diego Supercomputer Center
Impact of gigabit networks in advanced scientific research - Role on
the university campus and in the research community - Examples from
the physical and medical sciences

Optical Networks
Chairman:  Paul Henry, AT&T
State-of-the-art of optical network technology - Optical devices,
optical systems, and architectural implications of optical networks -
Advantages and disadvantages of these optical networks vs. electronic
ones - Viability of optical networks.

Attendance will be limited and registration accepted on a first 
come, first served basis.

Please return the Registration Form with your payment today to take 
advantage of the reduced rate of $495.

- - -----------------------------------------------------
Symposium of Gigabit Networks
c/o Laboratory for Computer Science
Massachusetts Institute of Technology
545 Technology Sq., Room 103
Cambridge, MA  02139
617-253-5852
 
July 15-17, 1991
$495 - Registration postmarked by June 15, 1991
$595 - Registration postmarked after June 15, 1991

Name:
Title:
Company:
Department:
Address:
City:
State:
Zip:
Telephone:
Fax:
Email:

Method of Payment -

____Credit Card  
Account No. - Expiration Date - Cardholder's Signature

  Amex:_________________________________________________

  Mastercard:___________________________________________

  VISA:_________________________________________________

____Check enclosed, payable to SYMPOSIUM ON GIGABIT NETWORKS





-------

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 12:18:38 GMT
From:      sonneveld@pttrnl.nl
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.modems
Subject:   X.21 card for PC with support for TCP/IP and X-windows on top of it.

From:	IN%"pttrtl!maatman@hp4nl.nluug.nl" 12-JUN-1991 11:44:04.99
To:	RE_Sonneveld@pttrnl.nl
CC:	
Subj:	

Received: from dnlunx.local by pttrnl.nl; Wed, 12 Jun 91 11:42 MET
Received: from pttrtl by hp4nl.nluug.nl with UUCP via EUnet id AA11760
 (1.15/2.14); Wed, 12 Jun 91 11:18:00 MET
Received: from sun017. by pttrtl (4.1/SMI-4.0) id AA01978; Wed, 12 Jun 91
 11:07:14 +0200
Date: Wed, 12 Jun 91 11:07:14 +0200
From: pttrtl!maatman@hp4nl.nluug.nl
To: RE_Sonneveld@pttrnl.nl
Message-id: <9106120907.AA01978@pttrtl>
X-Envelope-to: sonneveld

To: RE_Sonneveld@pttrnl.nl
Subject: News

Hoi Rolf,

Hierbij weer eens het verzoek om een news-bericht te distribueren.
Ik vraag dat deze keer namens Peter Leydekkers. Aangezien onze 
aansluiting op NLnet nog enige tijd op zich laat wachten, houden 
wij nog even onze UUCP aansluiting waarmee het niet mogelijk is
news te distribueren. Vandaar mijn verzoek. Als je de antwoorden
niet direct naar Peter kunt sturen mag je ze ook naar mij toe sturen,
ik zorg dan wel dat ze bij Peter terecht komen.

Reuze bedankt alvast,

Hans

----------------------------------------------------------------------
Hans Maatman ( pttrtl!maatman@hp4nl.nluug.nl )
PTT Research Tele-informatics
PO Box 15000, 9700 CD Groningen, The Netherlands 
Phone: +31 50 821069  Fax: +31 50 122415
----------------------------------------------------------------------

>>>>>>>>>
Graag wereldwijde distributie naar de volgende news groepen:

comp.protocols.tcp-ip
comp.protocols.iso
comp.dcom.modems
comp.lans
comp.telecom

>>>>>>>>>

         Hello,
         
         For a projekt we try to get the following stack of
         hard/software working together for a MS-DOS PC:
         
         X-windows 
         ---------
         TCP/IP
         ---------
         X.21 
         ---------
         IDN
         
         
         Until now we could not find an X.21 card for the MS DOS PC on 
         which we could use standard TCP/IP software in order to use 
         X-windows. 
         We are looking for a complete stack from X.21 upto x-windows 
         commercially available. However, if you now a better stack, 
         except that X.21 and X-windows are necessary, please let me 
         know! 
         If so do you know a commercial produkt to fullfill our 
         requirements?
         
         Thanks in advance,
         
         Peter Leydekkers
         
         ===============================================================
         Peter Leydekkers (pttrtl!leydekke@hp4nl.nluug.nl)
         PTT Research Tele-informatics
         P.O. BOX 15000 
         9700 CD Groningen
         The Netherlands
         PHONE: +31 50 821169          FAX: +31 50 122415
         ===============================================================

-- 

                               Rolf Sonneveld
                             -= PTT Research =-
                              The Netherlands

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 12:47:10 GMT
From:      dln@crosfield.co.uk (#dave norman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip.ibmpc
Subject:   WANTED - TCP/IP Sources


Hello everybody

Appologies if I haven't posted to the correct groups.


We need to implement TCP/IP inside an embedded system
running VRTX based on AMD 29000's - Gulp !.


Has anybody heard of a TCP/IP implementation running under VRTX ?
if so, where can I obtain the sources ?

Alternatively can anyone please direct me as to where I can get
the source code for a portable implementation of TCP/IP, so we can
do the job ourselves.

Any other tips or hints would be greatly appreciated.


Please contact me via e-mail with any replies


							Many thanks

							   Dave Norman


| Dave Norman                            | Phone :  +44 442 230000 ext 3354 |
| Crosfield Electronics Ltd              | Fax   :  +44 442 232301          |
| Three Cherry Trees Lane,               | email :  dln@crosfield.co.uk     |
| Hemel Hempstead, Herts. HP2 7RH, U.K.  |                                  |

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 12:50:03 GMT
From:      straka@cbnewsc.att.com (richard.j.straka)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

In article <30989@hydra.gatech.EDU> writes:
>I asked a while ago about this, but only got a few confused replies.
>I have a stock Mac II machine with Ethertalk card, and MacTCP 1.0.1.
>I am currently using NCSA Telnet 2.2-TCP for communications, but there
>_still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
>from the Mac to a remote host for file transfer.  I do *not* want to
>telnet to that host and start a reverse-FTP session like with the non-TCP
>Telnet and 2.3 Telnet.  Telnet and FTP exist as two different programs for
>the MSDOS machines, doesn't it exist for the Macintosh?  Where?

A Mac Application package, Versaterm 4.5, along with being a plain, old serial
terminal emulator, also provides Telnet and FTP services over TCP.  Emulation
of the Telnet driver is VT100.  TEK4014 emulation is also provided.  A
separate application also provides a telnet "server" for all Macs connected
via a local AppleTalk network through the Ethernet TCP port.  All this for
<$100US mail order.  Can you beat that?

SDA
-- 
Richard Straka  AT&T Bell Laboratories, IH-6K311
UUCP:     att!ihlpf!straka       INTERNET: richard.straka@att.com
-------------------------------------------------------------------------------
MSDOS:   All the wonderfully arcane syntax of UNIX(R), but without the power.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 13:57:06 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: vendor provided Packet Drivers


    BUT... I have a client that is demanding a dual stack (IP and IPX) PC
    solution that is fully vendor provided/vendor supported....
    
At least Interlan, Hughes LAN Systems, Schneider & Koch, Gateway, Acer and
IMC Networks all have supported Packet Drivers and Netware which runs with
them (there are half a dozen more board vendors with supported packet drivers,
but I don't know if they have their own Netware drivers or rely on the BYU
stuff - ask them).  I wouldn't expect any of the vendors to support the use
of their own Netware with someone else's board, though.
    
3Com and Spry both have supported modules which allow Netware to run on NDIS
drivers (and NDIS is presumably as likely to be 'well supported' by the
average board vendor as ODI is).  We support the version of the DIS_PKT
adapter module that we ship with our commercial PC/TCP product (but we
don't support the version we released as freeware, or Joe Doupnik's improved
version).  TWG, Sun and B&W will presumably support their own products
running on an NDIS driver as well.  We're working on an ODI-to-Packet-Driver
converter module which we intend to support when sold with PC/TCP.  You
know about Novell's product on ODI.

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

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 14:33:23 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE 802.3 Driver for Xircom Adapter


    ....  At this time, Xircom does not have an IEEE 802.3 compatible driver.
    
You don't say what you mean by "802.3 compatible".  If you mean compatible
at the hardware level, that shouldn't be an issue: the "802.3-ness" of an
Ethernet at the hardware level is subtle and very hard to distinguish from
v2 Ethernet.  The worst problem you'd have would be ensuring that you have a
compatible transceiver (heartbeat vs. no heartbeat) to plug into.  In any
case, the software driver doesn't care a fig whether the cable is 802.3 or
v2 Ethernet

If what you mean is "capable of sending and receiving packets with a 'length'
instead of an 'ethertype', with an 802.2 header appended", that is a software
issue.  Much depends on what upper-layer protocols you want to use, and which
vendor supplies the protocol stack.  All of the DOS shared-driver specs
support 802.2 formats in one way or another, although the Packet Driver spec
uses a separate Class (11), which Xircom may not have implemented yet.

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

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 14:36:46 GMT
From:      steve@sics.se (Steve Pink)
To:        comp.protocols.tcp-ip
Subject:   Re: Van Jacobson's algorithms


In article <1991Jun03.215054.5023@wimsey.bc.ca> skl@wimsey.bc.ca (Samuel Lam) writes:


   In article <810026@hpcndpc.CND.HP.COM>, dhh@hpcndpc.CND.HP.COM (David Hanes)
    wrote:
   >I am trying to locate any information concerning Van Jacobson's
   >header prediction algorithms.

   It's in RFC 1144.

   -- 
   <skl@wimsey.bc.ca>

RFC 1144 describes TCP header compression.  Jacobson's TCP header
prediction can be found in ACM Computer Communication Review, Volume 20,
Number 2, April 1990.

Steve

--
Stephen Pink
Swedish Institute of Computer Science
PO Box 1263, S-164 28 KISTA, SWEDEN	Internet: steve@sics.se
Tel: +46 8 752 15 59	Ttx: 812 61 54 SICS S	Fax: +46 8 751 72 30
Home Tel: +46 8 38 60 15

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 15:07:35 GMT
From:      tjs@MSC.EDU (Tim Salo)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE 802.3 Driver for Xircom Adapter

> Date: 12 Jun 91 05:49:14 GMT
> Subject: Re: IEEE 802.3 Driver for Xircom Adapter
> 	[...]
> They would have one if they weren't such scum (see below).  
> 	[...]
> Then I heard that they had reneged on our agreement [...]
> 	[...]
> However, they continued to distribute the one derived from my
> code so I called for a boycott of their products.
> 	[...]
> So, I guess they get away with their theft.
> 	[...]
> --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.

Please move this to a more appropriate forum, such as the courts.

I have no idea what the actual facts are in this case, but software 
copyright contains lots of grey areas, (e.g., when is software a 
derivative work?).  I doubt further discussion here will enlighten me.

At least in court some third party (not me) can listen to arguments 
and render an opinion based on some understanding of the facts and the law.

Your counsel may also be able to advise you about libel.

Tim Salo
tjs@msc.edu

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 15:20:45 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

straka@cbnewsc.att.com (richard.j.straka) writes:

>In article <30989@hydra.gatech.EDU> writes:
>>I am currently using NCSA Telnet 2.2-TCP for communications, but there
>>_still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
>>from the Mac to a remote host for file transfer.  
 
>A Mac Application package, Versaterm 4.5, along with being a plain, old serial
>terminal emulator, also provides Telnet and FTP services over TCP.  Emulation
>of the Telnet driver is VT100.  TEK4014 emulation is also provided.  


 OK, all this INCLUDING FTP (yes as you want it ) it's available on
 BYU Version of NCSA Telnet, I don't remember where I get it.
 It is really the same as NCSA BUT it has an extra ftp botton on the open secion
 menu.

 I search for it and it seems to be in 130.186.34.6 in /download/ncsa/telnet/mac

 I hope this helps....

 See you

Jose A. Vela A.
josevela@mtecv2.mty.itesm.mx

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 15:26:09 GMT
From:      erdwing@sol.biostat.med.umich.edu (Erdwing Coronado)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

In article <30989@hydra.gatech.EDU>, ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:
> 
> I asked a while ago about this, but only got a few confused replies.
> I have a stock Mac II machine with Ethertalk card, and MacTCP 1.0.1.
> I am currently using NCSA Telnet 2.2-TCP for communications, but there
> _still_ is no FTP.  By FTP, I mean I want to initiate an FTP session
> from the Mac to a remote host for file transfer.  I do *not* want to
> telnet to that host and start a reverse-FTP session like with the non-TCP
> Telnet and 2.3 Telnet.  Telnet and FTP exist as two different programs for
> the MSDOS machines, doesn't it exist for the Macintosh?  Where?
> 
> 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
> 
> 
I have used XferIt with good results. It is available from anon ftp
at msdos.archive.umich.edu and/or mondo.engin.umich.edu.
It has some annoying features (redraws its windows every few
minutes, etc) but its graphical interface is intuitive.
It runs over MacTCP. (I normally run NCSA Telnet 2.3 with 3-4
Unix sessions open, POPMail, XferIt, NewsWatcher and MacX at
the same time in a Mac IIci with little hassle).
Oh, XferIt and NewsWatcher are shareware.
Erdwing

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 16:01:56 GMT
From:      bergum@SRC.Honeywell.COM (David Bergum)
To:        comp.protocols.tcp-ip
Subject:   TTL problems

ATT WIN/TCP 3.2 running on 3B2 SYSV 3.2.3 has a wired in TTL of 15 for IP
packets.  This doesn't get you anywhere worth going to these days.  Anyone
kknow of a fix for this limitation?
      A
-----/|\---------------------------------------+
-   / | \   Bergum@CIM-VAX.Honeywell.COM       |
-  /__|__\  Dave Bergum [MN26-3190]            |
-  t--'--/   2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~  (612)870-5839                     |
-----------------------------------------------+

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 16:09:52 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   looking for a paper by Fletcher and Watson in Computer Networks vol 2.

Hi netlander,
        I am looking for a paper by Fletcher and Watson as follow:

        "Mechanisms for a Reliable Timer-based Protocol"
        - By Fletcher, J.G., and Watson, R.W.
        Computer Networks, Vol. 2,
        1978,
        pp. 271-290.

        I could not get it from the library because it is too old. I will
appreciate if anybody can send me a copy either by email or postal mail. I
need it quite urgently and I think this is the fatest way to get help. I am
sorry if I abused this net. Thanks a lot.

Regards.

Beng-Hang Tay (email: taybengh@nusdiscs.btinet)

Postal address :
Department of Information Systems and Computer Science
National University of Singapore
Kent Ridge Crescent
Singapore 0511
Republic of Singapore

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 16:51:33 GMT
From:      garethh@sadss (Gareth Howell )
To:        comp.protocols.tcp-ip
Subject:   Subnetting a very large population

Hi all,
I wonder if someone can help me with a tricky problem I am trying to come to 
grips with.

I have the (un)enviable taks of coming up with an Internet Addressing 
Strategy for the UK Department of Social Security's internet (note small 
'i':-). This comprises (or soon will) 2500+ Ethernet LANs: each with 
anything from 4-50 PCs, Unix application servers and gateways on them; all 
interconnected using the Government Data Network (X.25 (1980)). Most of the 
operational systems use OSI protocols, but there is a significant amount of 
IP traffic, mainly for SNMP HUB and BRIDGE and host management on the LANs.

What I need is a sanitory way to split up the population to ease number 
allocation and permit local administration of each LAN. What I have come up 
with is this, and I would like comments (good or bad :-):

Allocate a single non-subnetted Class B address to the X.25 GDN (2500+ hosts).
Allocate a number of Class B addresses to clusters of LANs, and subnet each 
of these networks in accordance with RFC950 and RFC1219.

I have one outstanding issue relating to this, and that is whether dynamic 
routing protocols will cope with this environment. Specifically, will a host 
on LAN 'A' (which is a subnet of network 'X') be able to reach a host on LAN 
'B' (which is a subnet of network 'Y') by routing across the GDN. The 
problem seems to be whether the routing tables in LAN 'A's GDN gateway, 
know that to get to LAN 'B' you have to go to LAN 'B's GDN gateway: which 
implies that LAN 'A's gateway (on network 'X'), knows the subnet mask of 
network 'Y'. I'm not sure this is possible; but the alternatives of 
allocating a single Class A network address to cover the lot, or allocate 
2500+ Class C addresses + 1 Class B address (for the GDN) are either 
impractical, or unmanageable (and anti-social if we advertise 2500+ networks 
to the core!!! ).

Any ideas?
Gareth Howell
garethh%sadss.uucp@ukc.ac.uk (I think that's the best route for mail)

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 16:56:53 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: SL/IP under MAC-TCP

In article <mt.676670709@cleo>, mt@cleo.cs.wisc.edu (Manolis Tsangaris) writes:
> Netters,
> 
> Do you know if MAC-TCP can support SL/IP? The version that comes 
> with MacX 1.2, has only Ethernet support, whereas the manual pages
> show a dialog of the ``Connection Tool'' that can use ethertalk, localtalk
> or serial line.
> 
> Thanks
> 
> --mt

No.  Currently it does not.  Once the next version comes out there are several 
companies who are working on SLIP and PPP for MacTCP, so keep your eyes open.


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 17:55:49 GMT
From:      fyang@nysnet.nys.GOV (Frank Yang)
To:        comp.protocols.tcp-ip
Subject:   testing

please ignore !

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 18:03:15 GMT
From:      drubin@prism.poly.edu (Dave Rubin)
To:        comp.protocols.tcp-ip
Subject:   Re: TTL problems

In article <1991Jun12.160156.22669@src.honeywell.com> bergum@SRC.Honeywell.COM (David Bergum) writes:
>ATT WIN/TCP 3.2 running on 3B2 SYSV 3.2.3 has a wired in TTL of 15 for IP
>packets.  This doesn't get you anywhere worth going to these days.  Anyone
>kknow of a fix for this limitation?

This parameter can be changed in the kernel.

In the file /etc/master.d/ip: change the IP_TTL parameter.  
I changed it from 0x0f to 0x2f which seems to work fine.
Then rebuild the IP and KERNEL drivers and reboot /etc/system for the change
to take effect (let me know if you need more details).

--
Dave Rubin
Polytechnic University
drubin@prism.poly.edu

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 18:18:39 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Board Level Ethernet/TCP/IP Products

I recently posted that summary of information about TCP/IP products:

>Several weeks back I posted an inquiry about boards that integrated
>an Ethernet interface with a TCP/IP implementation. ...

I forgot to include a key bit of information from my original request..
I surveyed products exclusively for the VME bus. Apologies for
any confusion that may have resulted.

Rick.
smith@sctc.com        Arden Hills, Minnesota.

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 20:01:05 GMT
From:      johnw@group1.uucp (John Wheeler)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   SCO Unix 16-bit cards

After repeated calls to SCO, which, by the way, has the LONGEST
queing mechanism I've ever encountered, I have been able to find
_NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find
it hard to believe that I can get 16-bit drivers for a simple MS-DOS
machine but *NOT* for our multi-gigabyte SCO hosts!!!!

Does ANYBODY know of any 16-bit drivers for SCO Unix?
(WD 8013 preferred)....


Thanks!
-- 
________  John Wheeler - Informix-4GL / SQL * Unix * Broadcast Audio Production
 \rrrr/   Group One Ltd.
   \/     San Francisco

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 20:31:36 GMT
From:      lcuff@spectrum.CMC.COM (Leonard Cuff)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <8295@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:

>S5R3.2's UUCP has its *own* way of doing UUCP over various transport layers; 
>it uses TLI.

<lengthy (correct) background deleted>

>The "listener" would occupy the same niche in that scheme of
>UUCP-over-TCP as "uucpd" does in a BSDish scheme.  There may well be
>documentation somewhere in the S5R3.2 documentation set on how to set
>that up, unpleasant long strings of hex digits and all....

There is indeed documentation:  The manual I'm looking at has a title
"AT&T Enhanced TCP/IP WIN/3B Release 3.0 Installation and Administration
Guide for the AT&T 3B2 Computers" and it has a section "Setting up TCP/IP
for WIN/3B for UUCP" that describes exactly this procedure.  Those long
hex strings are ugly, but a program "rfsaddr" is supplied to take a host name
and shove the "0x00020401" onto the front of your host name's IP address thus
eliminating a bit of typing.

AT&T chose port number 1025 (0x401) for their network listener service,
but RFC 1060 (Assigned numbers) lists port 1025 as "blackjack".  Can anybody
explain this?  Is blackjack an alias for AT&T?    1/2 :-)
-- 
Leonard Cuff                 lcuff@cmc.com                         

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 20:32:47 GMT
From:      beach@SERVER.AF.MIL (Darrel Beach)
To:        comp.protocols.tcp-ip
Subject:   Re: DDN GOSIP Plans

betsy,
  We're using the Milnet to transport OSI protocols between some Unisys
systems(all on node 204) and some systems on our LAN at Gunter AFB.  We're
using a cisco AGS with static NSAP to net address maps.  It works.  The
Unisys guys tell us their system uses Standard X.25 for both OSI and DoD
suites rather than trying to distinguish between basic and standard.  It
such a trivial thing I'm amazed people worry much about it...

darrel beach sends...
---------
Darrel Beach	       	     beach@server.af.mil	snail-mail:
SAIC Montgomery
Network Systems Engineer     205-279-4075        	SSC/SSMT
USAF DDN Program Office	     AV: 446-4075       	Gunter AFB, AL 36116

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 20:56:26 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

<RFC 931 can be used over any part of the Internet. In fact, it's the
<only working freely available wide-area TCP authentication code I know
<of. If you do want to restrict access to the local net or to
<authenticated connections, you can use my attachport (comp.sources.unix
<volume 22) or shuctld (coming very soon to a source group near you).

Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy
Enhanced Mail (PEM)?  My understanding was that this service was going 
into effect very soon throughout the Internet.

Maybe someone with more knowledge on these subjects could clarify
the following issues:

1) Does PEM address all of the security and authorization issues for
sending mail on the Internet?

2) Is PEM the preferred approach for building security into private
company Internets as well?

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 21:09:08 GMT
From:      kovar@eclectic.com (David C. Kovar)
To:        comp.protocols.tcp-ip
Subject:   Miniumum hardware required to support SLIP connection?


  If one wanted to add dialup SLIP capability to a network, what is
the minimum set of hardware required? You definitely need a modem,
Telebit TrailBlazer, for example, but after that ... what? A Cisco
router will do the trick, but is there anything less expensive?
Basically, I'd like to be able to attach a modem to the phone line,
the modem to a piece of hardware, the hardware to the Ethernet, and,
with a minimum of configuration, be able to dial into that modem and
establish a SLIP connection. Any suggestions would be most appreciated.
Thanks, in advance!

-David

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 21:17:34 GMT
From:      ken@dali.cc.gatech.edu (Ken Seefried iii)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In article <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:
>
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>(WD 8013 preferred)....
>

I've been running WD8013's under 3.2v2 and ODT 1.1 for quite some
time.  The boards are recognised at boot time as 8013's (and not
8003's) and the drivers see the additional memory (16k as opposed to
8k).  I've never done any empirical tests to determine how much faster
the '13's are than the '03's, but they do seem to be supported.

In addition, I recall at least one of the supported 3Com boards is
16-bit (3c505?).  I've never used it, though, as we we're soured on
3Com after the 3c301 and 3c503 cards.

Lastly, I'm under the vauge recollection that Racal makes a 16-bit
ethernet card for SCO using their own drivers.  Memory might be
failing me, though.

--

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

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 21:51:48 GMT
From:      jimm@ima.isc.com (Jim McGrath)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In article <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:
>After repeated calls to SCO, which, by the way, has the LONGEST
>queing mechanism I've ever encountered, I have been able to find
>_NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find
>it hard to believe that I can get 16-bit drivers for a simple MS-DOS
>machine but *NOT* for our multi-gigabyte SCO hosts!!!!
>
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>(WD 8013 preferred)....
>
Racal Interlan has a driver for both ISC and SCO for the NI6510.  It

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 91 22:14:44 GMT
From:      jimm@ima.isc.com (Jim McGrath)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In article <1991Jun12.215148.6484@ima.isc.com> jimm@ima.isc.com (Jim McGrath) writes:
>>
>Racal Interlan has a driver for both ISC and SCO for the NI6510.  It
>
That got truncated somehow.  This is what I meant to post.

Racal Interlan has a driver for both ISC and SCO for the NI6510.  It
works with Interactive Unix, but I haven't tried it with SCO :^).

Jim

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 06:58:02 GMT
From:      rodney@picasso.cssc-syd.tansu.oz.au (Rodney Campbell)
To:        comp.protocols.tcp-ip
Subject:   Setting up a number of Class C Networks - How?

We am having a number of problems attempting to set up a number of Class C
subnets (both local and remote networks) on a Class B address and we were
hoping that someone may have done this and would be able to help me.

We have a class B address (149.135) to use for a network.
We wish to create a number of networks:
  1) A Local research subnet on a separate class C address. (149.135.44)
  2) on the same physical ethernet a class C subnet containing a number of
  file servers ( this may later be moved to a different physical net for
  load sharing ). (149.135.36)
  3) A local contract staff subnet on a Class C. (149.135.48)
  4) A local PC network on a separate Class C. (149.135.56)
  5) A local MAC network via a Webster Multiport Gateway on the same Class
  C. (149.135.56) 
  6) A network for machines which will be connected to the outside world.
  (149.135.32) 

We also have a number (3-4 at the moment) of sites with basically a
similar configuration (different Class C subnets under the same Class B
address) which will be linked together using WAN lines to a Multiport
MultiProtocol Router at each site.

The UNIX networks are basically all Sun/Solbourne SPARC Based machines
running SunOS 4.0.3 to 4.1.1. We also have (locally) a Sun SPARC with two
ethernet interfaces - one on the Research Net (149.135.44) and the other
interface going to a network of diskless machines etc. (149.135.40). This
machine will be a slave YP server to the main server(s) on the Server
Network (149.135.36).

Now the problem is that SunOS defaults all of this to a Class B network
which is fine for the local network except that all traffic goes everywhere
which defeats the purpose of the subnetting. (BTW each physical ethernet
will eventually be plugged into a separate ethernet port of the Multiport
Router). Also when the separate sites are connected I don't want all the
traffic to go everywhere.

I would much rather all of this be a number of class C networks that can
all talk to each other easily and to varying degrees.

How do I set up things like /etc/networks /etc/netmasks /etc/rc.boot
/etc/rc.local and ifconfig and route and NIS (any others???) to work so
that: 
      1) NIS which goes to subnets (149.135.36, 149.135.40, 149.135.44,
      149.135.48, {149.135.32}) still works.
      2) Any machine on these nets can talk to any other machine on any
      other net.
      3) The same physical nets with multiple class C nets on it can
      coexist happily and transparently - eg broadcasts etc.
      4) I can run DNS. (later).

Also if anyone has an Idea about setting up the Webster Multiport Gateway
to work with this setup?

Also the broadcast address on Suns defaults to NET.0 is this right or
should it be NET.255?

Can replies be sent to me directly and I will summarise.
				       Thanks in Advance,
						 Rodney...

_______________________________________________________________________________
Rodney Campbell	- Telecom Aust |MHSnet: rodney@cssc-syd.tansu.oz.au
Network Services               |Snail : 8th Floor, 91 York Street, Sydney 2000.
Customer Applications Research |  or PO Box A226, Sydney South 2000, Australia.
        & Development          |Phone : +61 (0)2 364 3345   Fax: +61 2 262 3813

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 09:20:09 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Need a read news (rrn type of thing) client for VMS

How can remotely read the news from a vms box.  The news resides on
another unix box.  Is there something like rrn which will run on
the Vax?

		Thanks,
			Stuart Szabo


-- 
Postal:    Co-Cam Computer Services              |  Stuart Szabo
	   18-22 Trenerry Cr                     |  sgs@rand.mel.cocam.oz.au 
           Abbotsford, VIC 3067                  |  +61 3 412-3411 (voice)      
	   Melbourne,  Australia                 |  +61 3 417-7857 (fax) 

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 13:27:15 GMT
From:      rosen@rosen.enet.dec.com ("Eric C. Rosen  13-Jun-1991 0926")
To:        comp.protocols.tcp-ip
Subject:   Re: Printing to a terminal server


	This is in response to John Breeden's question about Unix software
that facilitates printing via telnet to a terminal server port.  I've recently
written a print filter that does just that, and I am including its source code
here for anyone that would like to try it out.

	I wrote this with the DECserver 300 in mind, but it should work with
any terminal server that is capable of accepting incoming connections and
mapping them to particular physical ports.  It does not use any proprietary or
vendor-specific protocols.  The filter does assume that the terminal server
will initiate at least one Telnet negotiation after connection setup, but this
would be easy to change if necessary.

	The introductory comments below explain how to set up the printcap 
file so as to invoke this filter properly.  I've tested this on Ultrix, on
MIPS' RISC/os (running with BSD compatibility), and on a 1986 version of
SUN/os.  However, I haven't tested it with other vendors' terminal servers.

	If anyone cares to try this out, please contact me directly with any
comments or problems.

Eric Rosen


/*
  This program is used to enable the "lpr" command to cause data to be sent
  to a printer that is attached to a Telnet terminal server port.

  The program is offered only as a "proof of concept"; its testing has not
  been extensive, it cannot be claimed to be "production quality software",
  and its author's Unix network programming skills are somewhat rusty.

  The procedures for using this program are somewhat different, depending on
  whether it is to be run on an Ultrix system or on a different kind of Unix
  system.

NON-ULTRIX SYSTEMS

  On non-Ultrix systems, this program is intended to be called both as an
  output filter and an input filter from lpd.  It should  be specified as the
  argument to both the "of" and the "if" parameter of a printcap entry.

  The program requires command line arguments which are not passed by lpd.
  Many Unix systems do not allow command line arguments to be passed explicitly
  in the "if" and "of" lines of a printcap entry.  The work-around is to have
  the "if" and "of" entries refer to shell scripts.  Within the shell scripts,
  any arguments can be passed.

  For example, the following printcap entry has been used successfully:

  telprt:\
        :lp=/dev/null:\
	:sd=/usr/spool/lpd5:\
	:of=/pathname/output_filter_script:\
	:if=/pathname/input_filter_script:

  The shell script "/pathname/output_filter_script" should be something like
  the following:

  #! /bin/sh
  exec /pathname/thisprogram o printer_host printer_port relay_port

  except that:

        "/pathname/thisprogram" would be replaced by the actual pathname
        and file name of the executable of this program,

	"printer_host" would be replaced by the name or IP address of the
	DECserver 300 to which the printer is attached (if a name is used,
	it can be in /etc/hosts or in the Domain Name Service),

	"printer_port" would be replaced by the TCP Port Number which has
	been assigned to the Telnet Listener on the DS300 which is associated
	with the printer (note that this the the TCP Port Number, not the
	physical port number); this can be a decimal number like 2010, or
	a "service name" which appears in /etc/services

	"relay_port" would be replaced by a TCP Port Number which is not
	otherwise in use on this host system.  A GIVEN PRINTCAP ENTRY
	MUST HAVE A UNIQUE RELAY_PORT NUMBER.

  The shell script "/pathname/input_filter_script" should be something like
  the following:

  #! /bin/sh
  exec /pathname/thisprogram i this_host relay_port

  except that:

        "/pathname/thisprogram" would be replaced by the actual pathname
        and file name of the executable of this program,

        "this_host" would be replaced by the name or IP address of the host
	on which this program is to run (i.e., the host from which we are
	printing, NOT the host to which the printer is attached)

	"relay_port" would be replaced with the SAME VALUE that appears for
	relay_port in output_filter_script.


  So an actual output_filter_script might be:

  #! /bin/sh
  exec /usr/users/rosen/bin/betterfilter o tantn1 2010 3000

  and an actual input_filter_script might be:

  #! /bin/sh
  exec /usr/users/rosen/bin/betterfilter i  dsuser 3000

  I've used these scripts to print from the host called "dsuser" to a printer
  on the DS300 called "tantn1", where Telnet Listner TCP Port Number 2010 on
  that DS300 has been assigned to that printer.

  When you install these shell scripts, there are a few things to remember:

        Make them executable (with "chmod ugo+x" )!

	Get the pathnames right, both in the shell scripts and in the
	printcap entry!

	Don't forget the first command line argument ("i" or "o").

	Make sure the same relay_port number is provided in both shell
	scripts, and that it is not otherwise in use on your host (at least
	check that it does not appear in /etc/services).

	Getting the printcap entry exactly right may take some experimenting.
	Some Unix systems like :lp=/dev/null:, some like :lp=:, and some like
	it if you just omit the "lp" entry entirely.
	
  Once this is all setup, the command "lpr -Ptelprt" will send data to the
  printer which is attached to the terminal server whose name is "tantn1",
  and which has been associated with a Telnet Listener at TCP Port 2010 on
  that terminal server.  It will use the directory /usr/spool/lpd5 as the
  spooling directory.

  Of course, you will replace the "sd" entry in the printcap file with one
  that specifies the spooling directory you actually want to use for this
  printer, and you will make sure that that directory really exists before you
  try to print anything.

  This printcap entry can appear on any number of non-Ultrix Unix systems,
  and those systems will  contend for the use of the printer.  While any one
  system is using the printer, the others will not be able to connect to it.
  In this case, they will retry periodically, using exponential backoff.  The
  parameters:

       BASE_RETRY_INTERVAL, MAX_RETRY_INTERVAL, and MAX_RETRY_TIMES_TO_PRINTER

  in the source code govern the retry algorithm.  These default to 10 seconds,
  with infinite retries at a maximum retry interval of one hour.

  As an alternative, you can set up one system to be the main spooler for the
  printer, and have other systems send their printjobs to the main spooler.
  This is entirely a matter of customer preference.  If the main spooler is
  the system whose name is "prowlr", the other systems would have printcap
  entries like:

  telprt:\
        :lp=:\
        :sd=/usr/spool/lpd3:\
	:rm=prowlr:\
	:rp=telprt:


  The very same printer can also be accessed, using LAT, from VMS systems.
  Once any of the Unix systems succeeds in opening a connection to the printer,
  all files   queued on that system will be printed, and then the connection
  will be closed.

ULTRIX SYSTEMS

  Setting the system up to use this program is a bit simpler if you have an
  Ultrix V4 system.  In this case, the program is only invoked as an output
  filter; however, several additional entries in the printcap file are needed.

  It has been used successfully with printcap entries such as the following:

    telprt:\
        :sd=/usr/spool/lpd5:\
	:ct=network:\
	:uv=psv1.0:\
        :of=/pathname/thisprogram x tantn1 2010:

  With this printcap entry, the command "lpr -Ptelprt" will send data to the
  printer which is attached to the terminal server whose name is "tantn1",
  and which has been associated with a Telnet Listener at TCP Port 2010 on
  that terminal server.  It will use the directory /usr/spool/lpd5 as the
  spooling directory.  (We assume in this example that "/pathname/thisprogram"
  is the executable resulting from compiling this program.)

  Of course, you will replace the "sd" entry in the printcap file with one
  that specifies the spooling directory you actually want to use for this
  printer, and you will make sure that that directory really exists before you
  try to print anything.

  Don't forget the "x" as the first argument to the program in the "of" line
  of the printcap entry, and make sure you get the pathname right.

  This printcap entry can appear on any number of Ultrix systems, and those
  systems will  contend for the use of the printer.  While any one system is
  using the printer, the others will not be able to connect to it. In this
  case, they will retry periodically, using exponential backoff.  The
  algorithms and parameters are the same as those described above for
  non-Ultrix systems.

  Any number of systems should be able to contend for the use of the printer,
  whether they are Ultrix systems, other Unix systems, or VMS systems using
  LAT.

PROGRAM OPERATION

  To describe the way in which this program works, it is necessary to first
  describe the principles of operation of the Unix Line Printer Daemon (lpd).
  First, we will describe its operation on non-Ultrix systems.
  
  When lpd sees that there are files on its queue for the printer, it forks an
  output filter.  It creates a pipe to the output filter, and binds it to the
  output filter's standard input.  It then creates a banner page for the first
  file on the queue, and sends the banner page down the pipe to the output
  filter.  It indicates the end of the banner page by sending a two-byte
  sequence consisting of ascii code 25 followed by ascii code 1.  The daemon
  then waits for the output filter to suspend itself.

  When the output filter detects the end of the banner page, it must suspend
  itself by sending itself SIGSTOP (the equivalent of ^Z in the csh).  When
  lpd detects that the output filter has suspended itself, it forks an input
  filter.  It creates a pipe to the input filter, and binds it to the input
  filter's standard input.  It then reads the first file on the queue from the
  spooling directory, and sends it down the pipe to the input filter.  When
  the file has been completely transmitted, lpd closes the pipe.  It then waits
  for the input filter to exit.

  The input filter knows that it has received the complete file when it detects
  that its standard input has been closed.  When the input filter has finished
  processing the file, it must exit.

  When lpd detects that the input filter has exited, it causes the output
  filter to resume, by sending it SIGCONT.  It then creates a banner page
  for the next file on the queue, and sends it to the output filter.  The
  above procedures are repeated until the queue is empty.  When the queue is
  empty, lpd closes the pipe to the output filter.  This causes the output
  filter to see that its standard input has been closed, at which point the
  output filter exits.

  Note that one  output filter process is used for an entire queue's worth of
  files, but a separate input filter process is used for each individual file.

  Each filter indicates a normal exit by supplying an exit status of 0.  This
  indicates to lpd that the data it gave to the filter was printed success-
  fully.  If either filter supplies an exit status of 1, lpd will leave the
  current file at the head of the queue, and try again later to print it.  If
  the filter which exited with a non-zero status was the input filter, lpd
  will send SIGINT to the output filter.
  
  For the purpose of printing via Telnet to a DS300, we have adopted the
  following design.  Only the output filter actually communicates with the
  printer.  That is, only the output filter opens a Telnet connection to
  the DS300.  Since the output filter process exists until the print queue is
  emptied, the Telnet connection is opened once, and remains open until all
  the files are queued.

  The input filter does not communicate directly with the printer.  Instead,
  any data which it receives from lpd is passed via a "back door" to the
  output filter.  The output filter takes this data from the input filter
  and passes it to the printer via the exissting Telnet connection.  The input
  filter uses a TCP connection to pass the data to the output filter.  That is,
  the input filter makes a TCP connection to its own host, at the specified
  "relay_port".

  Actually, at the time that the input filter wants to send the data to the
  output filter, the output filter is supposed to be suspended.  So before the
  output filter suspends itself, it forks a child process, and it is this child
  to which the input filter actually sends the data.  The child and its parent
  share the Telnet connection to the DS300 with no problems.

  When the output filter first opens the Telnet Connection, it waits for the
  DS300 to initiate Telnet Negotiations.  It then completes these negotiations
  successfully.  It then obtains data, one character at a time, from either lpd
  or from the input filter.  It "telnetizes" that character if necessary, and
  then sends it to the printer.  By "Telnetizing" a character, we mean that it
  doubles characters with ascii code 255, and that it replaces linefeeds with
  carriage return, line feed pairs, as required by the Telnet protocol.  Any
  Telnet negotiations which the terminal server may initiate at any time will
  be properly responded to by the output filter.

  Most of the TCP packets generated will be maximum size, for most efficient
  use of the network.

  If the Telnet connection breaks while printing is in progress, the output
  filter will exist with a status of 1, thereby informing lpd that the
  printing was not successful.  The daemon will then retry the same
  file later; files will not be lost when the Telnet connection breaks.

  The output filter tries to keep the Telnet connection open until all the
  data has been printed.  This maximizes the probably of getting the file
  reprinted automatically if the terminal server or printer fails after the
  last of the data has been transferred, but before printing is complete.
  However, with the DECserver 300, a failure while the last 500 bytes of data
  are being printed may not be recoverable.

  We do assume here that the attached printer needs no processing of the
  data.  If it does, that processing would need to be done first, and the
  result piped into this program.  It should be possible to do this with
  a suitable combination of shell scripts and pipelines.

  On Ultrix systems, with the printcap entry set up as described above for
  Ultrix, the situation is quite a bit simpler.  The Ultrix lpd will invoke
  this program only as an output filter, and will invoke it independently for
  each file.  Both the banner page and the data for each file gets sent to
  a single process.

  This program writes error messages to the syslog, using  the "debug"
  priority.  If the symbol DEBUG1 is defined, messages about the inter-process
  communication are logged.  If the symbol DEBUG2 is defined, messages about
  the number of characters read, written, and internally buffered are written.
*/

#define _BSD
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <syslog.h>
#include <stdio.h>
#include <netdb.h>
#include <ctype.h>
#include <sys/file.h>
#include <sys/time.h>
#include <signal.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/wait.h>

#define DEBUG1

#define FOREVER while(1)

/* booleans */
#define FALSE 0
#define TRUE 1
#define DONTFLUSH FALSE

/* exit status values */
#define REPRINT 1
#define OKAY 0
#define ENDOFBANNER 2

/*
  How many seconds we will wait before exiting after we close the Telnet
  connection to the printer.  This period should allow all outstanding data
  to be printed, unless the printer is currently XOFF'ing the DS300.
*/  
#define DISCONNECTTIMER 10

/*  Parameters governing retries, if the input filter has trouble connecting
    up with the output filter
*/
#define BASE_RETRY_INTERVAL 10
#define MAX_RETRY_TIMES_TO_PRINTER 0
#define MAX_RETRY_TIMES_TO_OF 10
#define MAX_RETRY_INTERVAL 3600    
  
/* Input and Output Buffer Sizes */
#define INBUFSIZE 1024
#define OUTBUFSIZE (2*INBUFSIZE)    

/* are we running as an input filter or as an output filter */
#define IF 0
#define OF 1
#define UF 2
#define INPUT_FILTER (filtertype == IF)
#define OUTPUT_FILTER (filtertype == OF)
#define ULTRIX_FILTER (filtertype == UF)

/* ascii codes with special significance to Telnet */
#define CR '\r'
#define LF '\n'
#define IAC 255
#define WILL  251
#define WONT 252
#define DO 253
#define DONT 254
#define TIMINGMARK 6
#define BINARY 0

/* state values for responding to Telnet Option Negotiations */
#define DATA 0
#define IACSCAN 1
#define OPTION 2    

/* state values for lpd "end of banner" detection */
#define CTRLY 1    

#define CAN_READ_FROM_LPD (can_read & lpd_mask)
#define CAN_READ_FROM_TCP (can_read & tcp_mask)    

extern int errno;

char *signalnames[] =
    {
     "", "SIGHUP", "SIGINT", "SIGQUIT", "SIGILL", "SIGTRAP",
     "SIGIOT", "SIGEMT", "SIGFPE", "SIGKILL", "SIGBUS", "SIGSEGV", "SIGSYS",
     "SIGPIPE","SIGALRM", "SIGTERM", "SIGURG", "SIGSTOP", "SIGTSTP", "SIGCONT",
     "SIGCHLD", "SIGTTIN", "SIGTTOU", "SIGIO", "SIGXCPU", "SIGXFSZ",
     "SIGVTALRM","SIGPROF", "SIGWINCH", "SIGLOST", "SIGUSR1", "SIGUSR2"
    };


int
    tcp_connection = 0,    /* file descriptor representing socket for making
		              outgoing tcp connection; for output filter,
			      connection is to printer, for input filter,
			      connection is to output filter */

    listener,              /* file descriptor representing socket for
			      receiving incoming tcp connection (used only by
			      output filter, while waiting for input filter
			      to make connection */

    lpd_fd = 0,           /* file descriptor for reading characers from lpd;
			     of course, this is the standard input */

    flags,                /* control flags for socket */

    anyaddr = INADDR_ANY, /* for listener, address on which we will receive
			     incoming connections */

    addrlen,              /* for listener, length of anyaddr */

    printer_addr;

int
    lpdstate = DATA,        /* lpd "end of banner detected" state variable */

    telnetstate = DATA,     /* Telnet Option Negotiations state variable */

    binarytransmit = FALSE; /* whether the DS300 has put the Telnet connection
			       into binary transmission mode */
    
int extra_chars;            /* keeps track of extra characters inserted by
			       "Telnetizing" the data */

struct sockaddr_in
    listen_addr,           /* the output filter is listening for connections
			      to this address */
    incoming_addr,         /* the address of the input filter, when it make
			      a TCP connection to the output filter */
    outgoing_addr;         /* in the output filter, this is the address of
			      the printer; in the input filter, this is the
			      address of the output filter */
                   
               
int retrycount,            /* keeps track of number of tries to open TCP
			      connection; used for exponential backoff */

    max_retries,           /* maximum number of attempts to open TCP
			      connection, 0 means no maximum */

    newfile,               /* this is TRUE if we haven't yet sent the printer
			      any characters from the file we are currently
			      trying to print */

    printjobnumber,        /* the number of files that have been printed */

    filtertype;            /* are we running as input filter or as output
			      filter? */

unsigned char answer[3];   /* construct answer to Telnet Option Negotiations */

unsigned char from_net[INBUFSIZE],   /* buffer for holding data received
					from net */
    
              from_lpd[INBUFSIZE],   /* buffer for holding data received from
					lpd */

              to_tcp[OUTBUFSIZE];    /* buffer for holding data to be sent
					to printer */

int to_tcp_start = 0,  /* start of unsent data in to_tcp */
    to_tcp_end = 0,    /* offset for placing NEXT character in to_tcp */
    tcp_data = 0,      /* amount of internally buffered data for TCP */
    tcp_maxseg;        /* TCP Maximum Segment Size; used to ensure that we
			  send maximum size packets when possible */

int tcp_blocking = FALSE;

struct timeval poll; /* used as arg to "select" when we want to poll
			   rather than block */

int lpd_mask,  /* file descriptor mask (for select routine) for data from
	          lpd (standard input) */
    tcp_mask;  /* file description mask (for select routine) for data to/from
		  the tcp connection */

struct servent
    *sp_printer, /* TCP "Service" (Port Number) for outgoing connections (used
		    by output filter to connect to printer, or by input filter
		    to connect to output filter */
    *sp_relay;   /* TCP "Service" (Port Number) for incoming connections (used
		    by output filter to accept connection from input filter */

struct hostent *hp; /* Host Address for outgoing connections */

struct protoent *pp;

/* Signal Handling Routines */
int interruption();
int disconnection();

int child; /* Used by output filter to hold PID of child process which receives
	      data from input filter */

unsigned char iac = IAC,
              cr = CR,
              lf = LF;

main(argc, argv)
    int argc;
    char *argv[];
    {
     int n_read;     /* return value from read call, # of bytes read */
     int n_from_lpd; 

     int i;
     int pid;
     int pr_chr_result, firstchar, lpd_data;

/* Used by output filter while waiting for child process to terminate */
     union wait child_status;
     int *exit_status = (int *)&child_status;

/* masks for the select routine */
     int can_read;

     char *host, *service, *relayservice;


     openlog(argv[0], LOG_PID);
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Telnet Print Filter Starting Up");
#endif
/*
  These signals cause termination with the REPRINT status, so that lpd will
  try again.
*/
     signal(SIGHUP, interruption);
     signal(SIGINT, interruption);
     signal(SIGQUIT, interruption);
     signal(SIGTERM, interruption);

     signal(SIGILL, interruption);
     signal(SIGTRAP, interruption);
     signal(SIGIOT, interruption);
     signal(SIGEMT, interruption);
     signal(SIGFPE, interruption);
     signal(SIGBUS, interruption);
     signal(SIGSEGV, interruption);
     signal(SIGSYS, interruption);
     signal(SIGXCPU, interruption);
/*
  Signals to ignore.
*/
     signal(SIGCONT, SIG_IGN);
     signal(SIGURG, SIG_IGN);
     signal(SIGALRM, SIG_IGN);
     signal(SIGVTALRM, SIG_IGN);
     signal(SIGWINCH, SIG_IGN);
     signal(SIGPROF, SIG_IGN);

/*
  We get this signal if the TCP connection breaks and we then try to write
  to it.  This causes termination with REPRINT status.  We really just ignore
  this signal (except for debugging purposes).
*/
     signal(SIGPIPE, disconnection);

     poll.tv_sec = 0;
     poll.tv_usec = 0;


     if (argc < 2) printhelp();
     switch(argv[1][0])
	 {
	  case 'i':
	      filtertype = IF;
	      break;

	  case 'o':
	      filtertype = OF;
	      break;

	  case 'x':
	      filtertype = UF;
	      break;

	  default:
	      printhelp(); /* terminates program, never returns */
	 }

     switch(filtertype)
	 {
	  case IF:
          case UF:
	      if (argc < 4) printhelp();
	      host = argv[2];
	      service = argv[3];
	      break;

	  case OF:
	      if (argc < 5) printhelp();
	      host = argv[2];
	      service = argv[3];
	      relayservice = argv[4];
	      break;
	 }	  

     closelog();
     openlog(INPUT_FILTER ? "Telnet IF" :
	     (OUTPUT_FILTER ? "Telnet OF" : "Telnet UF"), LOG_PID);
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Started as %s Filter",
	    INPUT_FILTER ? "Input" : (OUTPUT_FILTER ? "Output" : "Ultrix"));
#endif

/*
  Look up host name and service name for outgoing TCP connection, and convert
  them into a destination IP address and a remote TCP Port Number
*/
     init(host, service);
/*
  If running as Output Filter, must set up TCP Port Number on which to listen
  for connection from Input Filter
*/  
     if (OUTPUT_FILTER) init_relay(relayservice);
/*
  Initialize some globals
*/  

     retrycount = 0;
     newfile = TRUE;
     extra_chars = 0;
     printjobnumber = 0;
     max_retries =
	 INPUT_FILTER ? MAX_RETRY_TIMES_TO_OF : MAX_RETRY_TIMES_TO_PRINTER;
     lpd_mask = 1 << lpd_fd;
     firstchar = 0;
     lpd_data = FALSE;

/*
  Create socket for outgoing TCP connection, set it up with destination
  address, and open the TCP connection.
*/  
reconnect:
     make_connection();

/*
  If running as Output Filter or as Ultrix Filter, wait for peer to initiate
  Telnet Option  Negotiations.  We're assuming here that this will happen,
  which is true in the case of the DS300 and most other systems.  This
  prevents us from sending any data in the case where the peer's TCP has
  accepted the connection, but its Telnet is going to refuse it (perhaps
  because the printer is busy).
*/
     if (OUTPUT_FILTER || ULTRIX_FILTER)
	 {
	  can_read = tcp_mask;
	  select(16, &can_read, NULL, NULL, NULL);
	 }
/*
  Now we're ready to enter the main loop.
*/  
     FOREVER
	 {
/*
  Output Filter or Ultrix Filter should hang until there is something to read
  from net; Input Filter shouldn't try to read from net, since it's really
  talking to the output filter.
*/  
	  can_read = lpd_mask;
	  if (OUTPUT_FILTER || ULTRIX_FILTER) can_read |= tcp_mask;
	  select(16, &can_read, NULL, NULL, NULL);

	  if (CAN_READ_FROM_TCP)
	      {
	       n_read = read(tcp_connection, from_net, 1024);
	       if (n_read <= 0)
/*
  Select says that there is data to read, but when we try to read it, we get
  back nothing; this means that the TCP connection has closed unexpectedly.
  If the printing of the file has no yet begun, keep trying to reconnect.  If
  we are in the middle of printing, terminate, and signal lpd that the file
  needs to be reprinted.
*/
		   {
		    syslog(LOG_DEBUG, "TCP Read Error: %m");
		    if (INPUT_FILTER || !newfile) terminate(REPRINT);
		    goto reconnect;
		   }
/*
  We have data from the net.  We will ignore everything except Telnet Option
  negotiations.
*/
	       for (i = 0; i < n_read; ++i) do_options(from_net[i]);
/*
  Continue in this loop until there is no more data to read from the net.
*/
	       continue;
	      }

/*
  If we're here, there is no  data to read from net, but there is data to
  read from lpd.  Before we take it, let's see if we can write it to the
  outgoing TCP connection.  We'll hang in a select until either (a) we can
  write to the outgoing TCP connection, or (b) there's more to read from
  the net.
*/  
	  can_read = wait_on_tcp(OUTPUT_FILTER || ULTRIX_FILTER);

/*
  If there's more to read from the net, let's go handle it immediately.
*/
	  if (can_read) continue;

/*
  If we get here, then we know:

          a) There is nothing to read from the net.
	  b) The lpd daemon has something for us to read.
	  c) It is possible to write to the outgoing TCP connection.

  So let's get the data from lpd and write it to the TCP connection.  We read
  up to 1024 bytes at a time from lpd.  We try to write them out to the TCP
  connection so that maximum size TCP segments are used; this makes the most
  efficient use of network bandwidth.

  We get a character from lpd by reading from standard input, i.e., file
  descriptor 0.  If read returns 0, then lpd has closed the standard input,
  and the print job is complete.

  However, if there is already something in the from_lpd buffer, don't read
  anything new from lpd until we empty out what we already ahve.
*/  
	  if (lpd_data) goto datafromlpd;

	  n_from_lpd = read(lpd_fd, from_lpd, 1024);

	  if (n_from_lpd == 0)
	      {
#ifdef DEBUG1
	       syslog(LOG_DEBUG, "Standard Input Closed");
#endif
#ifdef DEBUG2
	       if (INPUT_FILTER || ULTRIX_FILTER)
		   syslog(LOG_DEBUG,
			  "Telnetizing used %d extra chars", extra_chars);
#endif
	       if (OUTPUT_FILTER || ULTRIX_FILTER) handshake_and_finish();
/*
  Before we let the Input Filter terminate, make sure it's delivered all
  characters to the Output Filter
*/  
	       flush_tcp();
	       terminate(OKAY);
	      }

	  if (n_from_lpd < 0)
	      {
	       syslog(LOG_DEBUG, "LPD Read Error: %m");
	       terminate(REPRINT);
	      }
/*
  We've got characters from lpd.  Go process each character.
*/

#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Read %d chars from lpd", n_from_lpd);
#endif
	  lpd_data = TRUE;
	  newfile = FALSE;
datafromlpd:
	  can_read = NULL;
	  for (pr_chr_result = OKAY;
	       (firstchar < n_from_lpd) && (pr_chr_result == OKAY);
	       ++firstchar)
	      {
	       can_read = wait_on_tcp(OUTPUT_FILTER || ULTRIX_FILTER);
	       if (can_read) break;
	       pr_chr_result = process_character(from_lpd[firstchar]);
	      }

/*
  If we haven't processed all the data from lpd yet, but there's more to read
  from the net; go take care of it.  In this case, firstchar is set to the
  place in from_lpd where we want to resume.

  If (firstchar == n_read), we've emptied the from_lpd buffer, so reset
  firstchar back to 0.
*/  
	  if (firstchar == n_from_lpd)
	      {
	       firstchar = 0;
	       lpd_data = FALSE;
	      }
	  if (can_read) continue;

/*
  If pr_chr_result returns ENDOFBANNER (which should happen only when running
  as an Output Filter),then we have finished printing the banner page.  Now we
  will have to suspend for awhile so that lpd can give the actual file data to
  the Input Filter.  (Of course, the Input Filter will relay it back to us via
  the child process we are about to fork,  but lpd doesn't know that.)

  If pr_chr_result returns anything else, then we just resume getting more
  characters from lpd.
*/  
	  if (pr_chr_result != ENDOFBANNER) continue;
/*
  Before we fork the child process, make sure we've really given TCP all the
  data we've seen so far.
*/  
	  flush_tcp();
#ifdef DEBUG1
	  syslog(LOG_DEBUG, "Suspending Job %d", ++printjobnumber);
#endif
	  
/* Fork a child process to receive the data from the input filter.  The
   communication from the input filter is completely handled in the relay
   subroutine.
	     
   N.B.: The child process NEVER returns from the relay subroutine.
*/
	  child = relay();

/* If we're here, we must be the parent process.  So we suspend ourself, until
   lpd sends us a SIGCONT
*/
	  kill(getpid(), SIGSTOP);

/* Now that we're here, we know that lpd has sent us SIGCONT */
#ifdef DEBUG1
	  syslog(LOG_DEBUG, "Resuming after job %d", printjobnumber);
#endif
/* Don't do anything until we are sure that the child process has completed */
	  pid = wait(&child_status);
	  if (pid != child)
	      {
#ifdef DEBUG1
	       syslog(LOG_DEBUG, "Wrong Child!");
#endif
	       terminate(REPRINT);
	      }
#ifdef DEBUG1
	  syslog(LOG_DEBUG, "Child has Terminated");
#endif

/* If the child's exit status is OKAY, we can go on to the next file to be
   printed.  Otherwise, we exit too, passing the child's exit status up to
   lpd.
*/
	  *exit_status /= 256;
	  *exit_status &= 0xff;
	  if (!WIFEXITED(child_status))
	      {
	       syslog(LOG_DEBUG, "Abnormal Child Termination");
	       terminate(REPRINT);
	      }
	  if (*exit_status != OKAY) terminate(*exit_status);

/* Whew, that file is printed, now we can continue with the next file */
          flush_tcp();
	  newfile = TRUE;
#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Telnetizing generated %d extra chars.",
		 extra_chars);
#endif
	  extra_chars = 0;
	  if (lpd_data) goto datafromlpd;
	 } /* FOREVER */
    }

 
delay(interval, max_interval, retries, max_retries)
    int interval, /* base retry interval */
	max_interval; /* don't let the interval get longer than this */
    int *retries,  /* the number of attempts we've already made */
	max_retries; /* maximum number of attempts to make, or 0 for no
			limit */
    {
     int later;

     if ((*retries)++ == 0) return; /* first attempt, no delay */
     if (max_retries && (*retries > max_retries))
	 {
	  syslog(LOG_DEBUG, "Exceeded max retries (%d), exiting", max_retries);
	  exit(REPRINT);
	 }
     later = interval << (*retries - 2);
     if (later > max_interval) later = max_interval;
     syslog(LOG_DEBUG, "Will try again in %d seconds", later);
     sleep(later);
    }
 
/*
  This subroutine is called when we read something from the net.  It ignores
  everything except Telnet Option Negotiations.
*/  
do_options(byte_from_net)
    unsigned char byte_from_net;
    {
     int i, can_write_to_net, n_written;

     switch(telnetstate)
	 {
	  case DATA:
	      /* If IAC found, enter IACSCAN state */
	      if (byte_from_net == IAC) telnetstate = IACSCAN;
	      break;
	  case IACSCAN:
	      /* If WILL, WONT, DO, DONT found, prepare to send back an
		 agreeable answer: enter OPTION state.  Otherwise, we will
		 ignore the Telnet Command, and reenter DATA state. */
	      switch(byte_from_net)
		  {
		   case WILL:
		       answer[1] = DO;
		       break;
		   case DO:
		       answer[1] = WILL;
		       break;
		   case WONT:
		       answer[1] = DONT;
		       break;
		   case DONT:
		       answer[1] = WONT;
		       break;
		   default:
		       telnetstate = DATA;
		       break;
		  }
	      if (telnetstate == IACSCAN)
		  {
		   answer[0] = IAC;
		   telnetstate = OPTION;
		  }
	      break;
	 case OPTION:
	      /* Answer is complete, send it back. */
	      telnetstate = DATA;
	      answer[2] = byte_from_net;
	      if (answer[2] == BINARY)
		  {
		   switch(answer[1])
		       {
		        case WILL:
			    binarytransmit = TRUE;
			    break;
			case WONT:
			    binarytransmit = FALSE;
			    break;
			default:
			    break;
		       }
		  }
	      for (i = 0; i < 3; ++i)
		  {
		   wait_on_tcp(FALSE);
		   /* We block until we can write the reply */
		   n_written = write_tcp(answer[i], DONTFLUSH);
		   /* terminate if connection closes */
		   if (n_written != 1)
		       {
			syslog(LOG_DEBUG, "TCP Write Error 3: %m");
			terminate(REPRINT);
		       }
		  }
    break;
	}
    }
 
/*
  This subroutine is invoked when we try to write to a dead TCP connection
*/  
disconnection()
    {
#ifdef DEBUG1
     syslog(LOG_DEBUG, "SIGPIPE received");
#endif
    }
 
/*
  This routine is called in order to force all internally buffered data out to
  TCP.  It blocks until successful.
*/  
flush_tcp()
    {
     int can_write;

     while(tcp_data)
	 {
#ifdef DEBUG2
	  can_write = tcp_mask;
	  select(16, NULL, &can_write, NULL, &poll);
	  if (!can_write)
	      syslog(LOG_DEBUG, "Waiting to flush TCP (%d)",tcp_data);
#endif
	  can_write = tcp_mask;
	  select(16, NULL, &can_write, NULL, NULL);
#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Attempting to flush TCP");
#endif
	  push_tcp();
	 }
    }
 
/*
  This routine is called when lpd has finished sending us data (i.e, standard
  input is closed).  We make an attempt to keep the connection open until all
  the data has actually been printed.

  To do this, we first handshake with the terminal server by sending a "DO
  TIMING-MARK" command, and we wait to receive its "WONT TIMING-MARK" command
  back in response.  There can still be about 500 characters left in the
  terminal server which haven't yet printed out, so we wait 10 more seconds,
  which will usually be enough.
*/
handshake_and_finish()
    {
     unsigned char byte_from_net, cmd;
     int i, n;
     
     flags &= ~FNDELAY;
     fcntl(tcp_connection, F_SETFL, flags);  /* make socket blocking */
     answer[0] = IAC;
     answer[1] = DO;
     answer[2] = TIMINGMARK;
     for (i = 0; i < 3; ++i)
        {
	 wait_on_tcp(FALSE);
	 write_tcp(answer[i], i == 2);
	}
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Starting Handshake");
#endif

     FOREVER
	 {
	  n = read(tcp_connection, &byte_from_net, 1);
	  if (n < 1)
	      {
	       syslog(LOG_DEBUG, "TCP Read Error 1: %m");
	       terminate(REPRINT);
	      }
	  if (byte_from_net != IAC) continue;
	  n = read(tcp_connection, &cmd, 1);
	  if (n < 1) 
	      {
	       syslog(LOG_DEBUG, "TCP Read Error 2: %m");
	       terminate(REPRINT);
	      }
	  if ((cmd != DO) && (cmd != DONT) && (cmd != WILL) && (cmd != WONT))
	      continue;
	  n = read(tcp_connection, &byte_from_net, 1);
	  if (n < 1)
	      {
	       syslog(LOG_DEBUG, "TCP Read Error 3: %m");
	       terminate(REPRINT);
	      }
	  if (byte_from_net != TIMINGMARK) continue;
	  if ((cmd != WONT) && (cmd != WILL)) continue;
#ifdef DEBUG1
	  syslog(LOG_DEBUG, "Handshake Complete");
#endif
	  break;
        }
     /*
       Now, in a DS300, there can be at most 512 characters backed up at the
       printer.  Let's wait 10 seconds and hope that the printer is not
       XOFFing us
     */
     close(tcp_connection);
     sleep(DISCONNECTTIMER);
    }
  
/*
  This subroutine sets up the host address and port number data structures
*/  
init(host, service)
    char *host, *service;
    {
     pp = getprotobyname("tcp");

     set_port(service, &sp_printer);
/*
  If a host name was given, this will find it either in /etc/hosts or via
  the Domain Name Service.  If an IP address was given, it is used.
*/
     if (isalpha(host[0]))
	 {
	  hp = gethostbyname(host);
	  if (!hp)
	      {
	       syslog(LOG_DEBUG, "Can't Find Host %s: %m", host);
	       exit(REPRINT);
	      }
	  return;
	 }
     printer_addr = inet_addr(host);
     hp = gethostbyaddr(&printer_addr, sizeof(printer_addr), AF_INET);
     if (hp) return;
     sethostent(NULL);
     hp = gethostent();
     hp -> h_addrtype = AF_INET;
     hp -> h_length = 4;
     hp -> h_addr = (char *) &printer_addr;
    }
 
/*
  This subroutine initializes the socket structure used for outgoing TCP
  connections.
*/
init_outgoing()
    {
     bzero((char *)&outgoing_addr, sizeof(outgoing_addr));
     bcopy(hp->h_addr, (char *)&outgoing_addr.sin_addr, hp->h_length);
     outgoing_addr.sin_family = hp->h_addrtype;
     outgoing_addr.sin_port = sp_printer -> s_port;

     if (tcp_connection) close(tcp_connection);
     tcp_connection = socket(AF_INET, SOCK_STREAM, 0);
     if (tcp_connection < 0)
	 {
	  syslog(LOG_DEBUG, "Can't Create Outgoing TCP Socket: %m");
	  exit(REPRINT);
	 }
     tcp_mask = 1 << tcp_connection;

     flags = fcntl(tcp_connection, F_GETFL);
     flags &= ~FNDELAY; /* make socket blocking, for connect */
     fcntl(tcp_connection, F_SETFL, flags);
    }
 
/*
  This subroutine is used by the Output Filter to listen for a connection from
  the Input Filter
*/
init_relay(service)
    char *service;
    {
     char *any = (char *)&anyaddr;
     int bind_retries = 0;

     listener = socket(AF_INET, SOCK_STREAM, 0);
     if (listener < 0)
	 {
	  syslog(LOG_DEBUG, "Can't create socket for Listener: %m");
	  exit(REPRINT);
	 }

     bzero((char *)&listen_addr, sizeof(listen_addr));
     bcopy(any, (char *)&listen_addr.sin_addr, 4);
     listen_addr.sin_family = AF_INET;
     set_port(service, &sp_relay);
     listen_addr.sin_port = sp_relay -> s_port;

     while (bind(listener, &listen_addr, sizeof(listen_addr)) < 0)
	 {
	  syslog(LOG_DEBUG, "Can't bind address to listener: %m");
	  delay(BASE_RETRY_INTERVAL, MAX_RETRY_INTERVAL, &bind_retries, 0);
	 }
     if (listen(listener, 1) < 0)
	 {
	  syslog(LOG_DEBUG, "Can't set up listener: %m");
	  exit(REPRINT);
	 }
    }

 
/*
  This subroutine handles those signals which terminate the process
  prematurely.
*/  
interruption(signo)
    int signo;
    {
     syslog(LOG_DEBUG, "interrupted by signal %d (%s)",
	    signo, signalnames[signo]);
     terminate(REPRINT);
    }

 
/*
  This subroutine makes outgoing TCP connections.
*/  
make_connection()
    {
     int optlen = sizeof(tcp_maxseg);
     int maxseg_opt;

     init_outgoing();
     delay(BASE_RETRY_INTERVAL, MAX_RETRY_INTERVAL,
	   &retrycount, max_retries);

     while (connect(tcp_connection,
		    (char *)&outgoing_addr,
		    sizeof(outgoing_addr))
	    < 0)
	 {
	  syslog(LOG_DEBUG, "Can't Open Outgoing TCP Connection: %m");
	  delay(BASE_RETRY_INTERVAL, MAX_RETRY_INTERVAL,
		&retrycount, max_retries);
	  init_outgoing();
	 }
     syslog(LOG_DEBUG, "Outgoing TCP Connection Made");
     flags |= FNDELAY;
     fcntl(tcp_connection, F_SETFL, flags); /* make socket non-blocking */

     maxseg_opt = 0;
#ifdef TCP_MAXSEG
     maxseg_opt = TCP_MAXSEG;
#endif
#ifdef TCPOPT_MAXSEG
     maxseg_opt = TCPOPT_MAXSEG;
#endif

     if (!maxseg_opt ||
	 (getsockopt(tcp_connection, pp -> p_proto, maxseg_opt,
		    (char *) &tcp_maxseg, &optlen) < 0))
	 {
	  tcp_maxseg = 512;
#ifdef DEBUG1
	  syslog(LOG_DEBUG, "TCP MSS = %d (default)", tcp_maxseg);
#endif
	 }
#ifdef DEBUG1
        else syslog(LOG_DEBUG,"TCP MSS = %d (dynamic)", tcp_maxseg);
#endif
    }
 
printhelp()
    {
     syslog(LOG_DEBUG, "Invalid Command Line Arguments");
     syslog(LOG_DEBUG, "\ti thishost relayport");
     syslog(LOG_DEBUG, "\to printerhost printerport relayport");
     syslog(LOG_DEBUG, "\tx printerhost printerport");
     exit(REPRINT);
    }
 
/*
  This subroutine is called to process each character received from lpd.  If
  its ascii value is 255, Telnet protocol requires that it be doubled.  If
  it is a linefeed, Telnet protocol requires that it be converted into a
  carriage return followed by a linefeed (unless the binary option has been
  enabled by the peer).  This subroutine also checks for the "end of banner"
  sequence ^Y^A from lpd.
*/  
/*
  We've got a character from lpd.  
*/
process_character(byte_from_lpd)
    int byte_from_lpd;
    {
     int n_written;
     
     switch(byte_from_lpd)  /* Process the Character */
	 {
	  case IAC:
	      /* Double the IACs. */
	      n_written = write_tcp(iac, DONTFLUSH);
	      ++extra_chars;
	      break;
		   
	  case LF:
	      /* LF --> CR LF, unless binary transmission enabled */
	      if (!binarytransmit)
		  {
		   n_written = write_tcp(cr, DONTFLUSH);
		   ++extra_chars;
		  }
	      break;

	  case CR:
	      /* CR --> CR NUL, unless binary transmission enabled */
	      if (!binarytransmit)
		  {
		   n_written = write_tcp(cr, DONTFLUSH);
		   byte_from_lpd = '\0';
		   ++extra_chars;
		  }
	      break;

	  case '\031':
	      if (OUTPUT_FILTER)
		  {
		   lpdstate = CTRLY;
		   return(OKA

push_tcp()
    {
     int n_written, n_to_write, last_to_write, can_write;
     
     if (!tcp_data) return(0);

     last_to_write = to_tcp_start + tcp_data - 1;
     if (last_to_write >= OUTBUFSIZE) last_to_write = OUTBUFSIZE - 1;
     n_to_write = last_to_write - to_tcp_start + 1;
     can_write = tcp_mask;
     select(16, NULL, &can_write, NULL, &poll);
     if (!can_write)
	 {
	  n_written = 0;
	  if (!tcp_blocking)
	      {
	       tcp_blocking = TRUE;
#ifdef DEBUG2
	       syslog(LOG_DEBUG, "TCP Blocked");
#endif
	      }
	 }
       else {
	     n_written = write(tcp_connection, &to_tcp[to_tcp_start],
			       n_to_write);
	     if (tcp_blocking)
		 {
		  tcp_blocking = FALSE;
#ifdef DEBUG2
		  if (n_written) syslog(LOG_DEBUG, "TCP Unblocked");
		    else syslog(LOG_DEBUG, "Blocking Confusion!");
#endif
		 }
	    }
     if (n_written < 0)
	 {
	  if (errno != EWOULDBLOCK)
	      {
	       syslog(LOG_DEBUG, "TCP Write Error: %m");
	       terminate(REPRINT);
	      }
	    else n_written = 0;
	 }

     if (n_written == 0) return(0);
     
#ifdef DEBUG2
     if (n_written > 0)
	  syslog(LOG_DEBUG, "Wrote %d bytes (%d-%d) of %d to TCP",
		 n_written, to_tcp_start, to_tcp_start+n_written-1, tcp_data);
#endif

     tcp_data -= n_written;

#ifdef DEBUG2
     syslog(LOG_DEBUG, "%d bytes still buffered for TCP", tcp_data);
#endif

/*
  Adjust to_tcp_start for wraparound, so next push works properly
*/  
     to_tcp_start += n_written;
     if (to_tcp_start >= OUTBUFSIZE) to_tcp_start -= OUTBUFSIZE;
/*
  If we have flushed all the data in the internal buffer, we will start
  accumulating data at the beginning again.
*/  

     if (!tcp_data) to_tcp_start = to_tcp_end = 0;

     return(n_written);
   }
 
/*
  This subroutine is called by the Output Filter after each Banner Page.  It
  forks a child process which gets the file to be printed from the Input
  Filter, and sends it out the TCP Connection to the printer.

  N.B.: Data received from the Input Filter has already been Telnetized.
*/  

int relay()
    {

     int from_if;
     int can_read_from_if;
     int if_mask;
     int i, n, n_written;
     int pid;
     int accept_retries = 1;
     unsigned char bytes_from_if[1024];

#ifdef DEBUG1
     syslog(LOG_DEBUG, "Forking Child Process");
#endif
     pid = fork();
/*
  Parent process returns immediately.
*/  
     if (pid != 0) return(pid);
     
/*
  Child Process continues here, and NEVER returns from this routine.
*/
     closelog();
     openlog("Telnet OF Child", LOG_PID);
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Child running");
#endif
     addrlen = sizeof(incoming_addr);
/*
  Listen for the connection from the Input Filter.
*/  
     while ((from_if = accept(listener, &incoming_addr, &addrlen)) < 0)
	 {
	  syslog(LOG_DEBUG, "Accept Failed: %m");
	  delay(BASE_RETRY_INTERVAL, MAX_RETRY_INTERVAL,
		&accept_retries, MAX_RETRY_TIMES_TO_OF);
	 }
/*
  Now read from the input filter, and write out to the printer
*/
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Connection from IF received");
#endif
     if_mask = 1 << from_if;
     FOREVER
	 {
	  can_read_from_if = if_mask;
	  select(16, &can_read_from_if, NULL, NULL, NULL);
	  n = read(from_if, bytes_from_if, 1024);
#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Read %d from IF", n);
#endif
	  if (n == 0)
	      {
#ifdef DEBUG1
	       syslog(LOG_DEBUG, "OF sees IF terminate");
#endif
	       flush_tcp();
	       terminate(OKAY);
	      }
	  if (n < 0)
	      {
	       syslog(LOG_DEBUG, "Read from IF failure");
	       terminate(REPRINT);
	      }
	  for (i = 0; i < n; ++i)
	      {
	       wait_on_tcp(FALSE);
	       n_written = write_tcp(bytes_from_if[i], DONTFLUSH);
	       if (n_written < 0)
		   {
		    syslog(LOG_DEBUG, "Internal Write Error 2");
		    terminate(REPRINT);
		   }
	      }
	 }
    }
     
/*
  This subroutine sets up port number data structures
*/  

set_port(service, sp)
    char *service;
    struct servent **sp;
    {
     int port;
     short *port_high = (short *)&port;
/*
  If a service name was given, look it up in /etc/services.  If it's not
  alphabetic, it must be a TCP port number.  Look up the port number in
  /etc/services, but if it's not there, use it anyway.
*/
     if (isalpha(service[0]))
	 {
	  *sp = getservbyname(service, "tcp");
	  if (!*sp)
	      {
	       syslog(LOG_DEBUG, "Can't Find Service %s: %m", service);
	       exit(REPRINT);
	      }
	  return;
	 }
     port = 0;
     sscanf(service, "%d", port_high);
     *port_high = htons(*port_high);

     /* Don't quite know what I'm doing here, but it seems to work on 
	big-endian machines and on those horrid little-endian machines too.
     */

     *sp = getservbyport(port, "tcp");
     if (!*sp)
	 {
	  *sp = (struct servent *) malloc(sizeof (struct servent));
	  (*sp) -> s_port = port;
	  (*sp) -> s_proto = "tcp";
	 }
    }
 
terminate(exit_status)
    int exit_status;
    {
#ifdef DEBUG1
     syslog(LOG_DEBUG, "Terminating with Status %d", exit_status);
#endif
     if (child) kill(child, SIGINT);
     close(tcp_connection);
     exit(exit_status);
    }
 
/*
  Since TCP is flow controlled, we can't always write to it whenever we want.
  This routine is called when we need to block until it is possible to write.
  Logically, we consider that it is "possible to write" as long as the
  internal buffer is not full.
  
  If the argument is TRUE, however, the routine will return if there is data
  to read from the network as well.
*/  

wait_on_tcp(need_to_read)
    int need_to_read;
    {
     int can_write_to_tcp;
     int can_read_from_tcp;

     if (need_to_read)
	 {
	  can_read_from_tcp = tcp_mask;
	  select(16, &can_read_from_tcp, NULL, NULL, &poll);
	  if (can_read_from_tcp) return(can_read_from_tcp);
	 }
     if (tcp_data < OUTBUFSIZE) return(NULL);
     while (tcp_data >= OUTBUFSIZE)
	 {
	  if (need_to_read) can_read_from_tcp = tcp_mask;
	    else can_read_from_tcp = NULL;
	  can_write_to_tcp = tcp_mask;
#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Waiting to write to TCP");
#endif
	  select(16, &can_read_from_tcp, &can_write_to_tcp, NULL, NULL);
	  if (can_write_to_tcp)
	      {
#ifdef DEBUG2
	       syslog(LOG_DEBUG, "TCP now writable");
#endif
	       push_tcp();
	      }
	  if (can_read_from_tcp) return(can_read_from_tcp);
	 }
     return(NULL);
    } 
 
/*
  This subroutine is called to "logically" output a byte to the printer.
  If its second argument is FALSE, it ordinarily just stores the byte in its
  own buffer.  Once it has accumulated enough bytes to fill a maximum size TCP
  segment, it automatically delivers those bytes to TCP.
  
  If the second argument is TRUE, all bytes in the buffer will be given to TCP.
*/

write_tcp(byte, flush)
    unsigned char byte;
    int flush;
    {
     if (tcp_data >= OUTBUFSIZE)
        {
	 syslog(LOG_DEBUG, "Multiple writes to full buffer!");
	 errno = EWOULDBLOCK;
	 return(-1);
	}
     to_tcp[to_tcp_end++] = byte;
     ++tcp_data;
#ifdef DEBUG2
     if (tcp_data == OUTBUFSIZE)
	 syslog(LOG_DEBUG, "Internal buffer full, start = %d",
		to_tcp_start);
#endif
     if (to_tcp_end == OUTBUFSIZE)
	 {
#ifdef DEBUG2
	  syslog(LOG_DEBUG, "Internal Buffer Wrapping, start = %d",
		 to_tcp_start);
#endif
	  to_tcp_end = 0;
	 }
     if (flush) flush_tcp();
         else if (tcp_data >= tcp_maxseg) push_tcp();
     return(1);
    }

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 13:39:30 GMT
From:      mjw@wasp.eng.ufl.edu (Michael J. Wohlgemuth)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In article <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:
>
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>

When we got our copy of SCO TCP/IP, it had 3 drivers with it.  Two
were supported (wd8003e & 3c503) and one was unsupported (3c505).
I don't have a 3c505, so I don't know how well the unsupported
driver works, but it is there.  It may be that they aren't telling
you simply because they don't support it.  Anyway, it is pretty
pathetic that we can't get a supported 16-bit driver from them.

Mike

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 14:21:04 GMT
From:      dsc3jwa@csd200.nmdsc.nnmc.navy.mil (Jim Allor)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Exterior Gateway Protocol (EGP)

Does anyone have information on Pulbic Domain software that runs 
Exterior Gateway Protocol (EGP) on an AT&T 3B2/600G or even other 
software that we could port to a 3B2.

Please responses to:  dsc3jwa@nmdsc20.nmdsc.nnmc.navy.mil
I'll compile the info and post it at a later date.

Thanks in advance,
Jim Allor
Naval Medical Data Services Center
INTERNET:  dsc3jwa@nmdsc20.nmdsc.nnmc.navy.mil

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 15:12:18 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip
Subject:   Re: Miniumum hardware required to support SLIP connection?

kovar@eclectic.com (David C. Kovar) writes:


>  If one wanted to add dialup SLIP capability to a network, what is
>the minimum set of hardware required? You definitely need a modem,
>Telebit TrailBlazer, for example, but after that ... what? A Cisco
>router will do the trick, but is there anything less expensive?
>Basically, I'd like to be able to attach a modem to the phone line,
>the modem to a piece of hardware, the hardware to the Ethernet, and,
>with a minimum of configuration, be able to dial into that modem and
>establish a SLIP connection. Any suggestions would be most appreciated.
>Thanks, in advance!

  
 I think that NOS program from ka9q could solve your problem.

 You just need a PC with an ethernet card, a serial card, this programm and
  two packet drivers ( one for the ethernet card and another for the SLIP in
  the serial port )


Jose A. Vela Avila
josevela@mtecv2.mty.itesm.mx
 I.T.E.S.M

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 16:20:35 GMT
From:      davew@viper.gvg.tek.com (David White)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: Request for experience with Telebit Netblazer

In article <1991Jun13.134237.25324@newshub.ccs.yorku.ca>,
davecb@nexus.yorku.ca (David Collier-Brown) writes:
|>
|>  Anyone have experiecne with the netblazer?  I'm looking at a
|>possible slip service and/or the very pedestrian use of the terminals
|>as a dilin gateway to our local network's machines.

I am also interested in the Netblazer.  I have seen several requests
for experiences with this product, but no replies of note.  One of the
things I am concerned about is the ability of the device to handle
multiple 38.4 sessions, SLIP, PPP and Telnet and also be able to
handle routing functions since it is using only a 386SX processor
(correct me if this has changed).  I believe that you can assign
a password for each user up to a maximum of X users.  Anyone know
what the value of X is?

Are there any plans to upgrade the product to support port rates
of greater than 38.4?

I would also be interested in any experience with using V.32bis
modems with this product since Telebit doesn't have one.  What
types of V.32bis modems have been used and how well do they work
with the Netblazer?

If anyone has any other recommendations for a terminal server with full
modem control on the ports that supports SLIP, PPP, FTP, Telnet, DNS, and
SNMP, I would be interested in the configurations and performance.

If anyone has received replies to previous requests for real life
experiences with the Netblazer, I think it would be valuable if they
could post a summary of the replies.  Thanks in advance,
-------             
Dave White	Grass Valley Group, Inc.   VOICE: +1 916.478.3052
P.O. Box 1114  	Grass Valley, CA  95945    FAX: +1 916.478.3887
Internet: davew@gvgpsa.gvg.tek.com 
UUCP: ...uunet!tektronix!gvgpsa.gvg.tek.com!davew

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 19:03:36 GMT
From:      datta@uts.amdahl.com (Diptish Datta)
To:        comp.protocols.tcp-ip
Subject:   Wanted - Info on public domain TCP/IP source


Hi netters,
Can anyone give me a pointer to public domain IP, TCP/UPD, ARP, ICMP
source - preferably in 'C'? I would like to have something with a well 
defined interface so that I could develop applications on top of TCP/UDP.

Any pointers to and comments on such beasts would be very helpful.

Thanking all of you in advance,

-Diptish Datta                      <datta@uts.amdahl.com>
 Amdahl Corp., Santa Clara, CA      408-992-2365

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 19:30:12 GMT
From:      fyang@nysnet.nys.GOV (Frank Yang)
To:        comp.protocols.tcp-ip
Subject:   ATT TCP/IP WIN/3B Help Needed !

Hi NetExperts :

   I'm a novice on TCP/IP. Forgive me if this is an inappropriate posting.
   We installed AT&T TCP/IP Win/3b on our ATT 3B2 machine running on StarLan 
10 NAU. But we have problem when we run netstart to start up the program. The
error messages look like this :

unknown host nysnet
can't determine my internet address/usr/etc/inetinit: config line #13: Failed to
 link netstart failed.

   "nysnet" is our machine's official host name.
   No matter how I changed the networks/hosts files setting or even removed
the /etc/hosts and /etc/networks files, I still got this same message. 
    As I know, inetinit is started by anentry in the file S86win3b when the
netstart program is executed. Inetinit looked for a configuration file
/usr/etc/inetinit.cf. 
   Here is the content of inetinit.cf file :

#
# Stream configuration file for win3b as used by inetinit.
#
# This is the standard stream configuration for a machine configured with a
# single Ethernet interface (ni).
#
#ifname lowerdev        upperdev     hostname
#
en0     /dev/ni/clone0  /dev/arp0       0
en0     /dev/arp        /dev/ip0        0
lo0     /dev/loop       /dev/ip0        me
0       /dev/ip         /dev/udp0       0
0       /dev/ip         /dev/tcp0       0
0       /dev/ip         /dev/raw0       0


   The followings are some other configuration/information :

   - no nameserver or resolver is configured during installation
   - only this machine is installed with ATT 10Base5 NI board and Win/3b
     sofrware ( that means there's only one host running tcp/ip )
   - NI board was tested ok by running the program nitest for Loop-Around test,
     ( so I assumed it's not a H/W's problem ??? )
   - niinfo return :
       Board   Major   State   Physical Address   Subnetwork Type [default]
       -----   -----   -----   ----------------   -------------------------
         0      10      UP       800010030001     ETHERNET [same]
   - hostid : 0


   Any suggestion will be appreciated.
   Thanks !   

                                                       Frank Yang.

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 22:25:59 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

In article <43225@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy
>Enhanced Mail (PEM)?  My understanding was that this service was going 
>into effect very soon throughout the Internet.

PEM is basically plain ol' SMTP mail, but the message text is RSA encrypted
for transmission over the net.  You have to have an encrytor on your
end, and the other end has to have a decryptor.

Its use is strictly voluntary, and unless both sender and recipient
implement it, it's not very useful.

>Maybe someone with more knowledge on these subjects could clarify
>the following issues:
>
>1) Does PEM address all of the security and authorization issues for
>sending mail on the Internet?

No, PEM for example does not solve mail forging, for example.  Again,
it simply encrypts (presumably sensitive) mail text.

 //=========================================================================\\
||       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...    ||
 \\==========================================================================//

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 91 23:24:06 GMT
From:      kozowski@ohsu.edu (Eric Kozowski)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT TCP/IP WIN/3B Help Needed !

In article <538@nysnet.nys.GOV> fyang@nysnet.nys.GOV (Frank Yang) writes:
>Hi NetExperts :
>
>   I'm a novice on TCP/IP. Forgive me if this is an inappropriate posting.
>   We installed AT&T TCP/IP Win/3b on our ATT 3B2 machine running on StarLan 
>10 NAU. But we have problem when we run netstart to start up the program. The
>error messages look like this :
>
>unknown host nysnet
>can't determine my internet address/usr/etc/inetinit: config line #13: Failed to
> link netstart failed.
>
>   "nysnet" is our machine's official host name.

Add an entry in the /etc/hosts file for nysnet.

-- 
Eric Kozowski         
kozowski@ohsu.edu
Networks & Computing Dept.
Oregon Health Sciences University

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 00:44:43 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   Re: Miniumum hardware required to support SLIP connection?

From: "David C. Kovar" 
> If one wanted to add dialup SLIP capability to a network, what is
> the minimum set of hardware required? You definitely need a modem,
> Telebit TrailBlazer, for example, but after that ... what? A Cisco
> router will do the trick, but is there anything less expensive?
> Basically, I'd like to be able to attach a modem to the phone line,
> the modem to a piece of hardware, the hardware to the Ethernet, and,
> with a minimum of configuration, be able to dial into that modem and
> establish a SLIP connection. Any suggestions would be most appreciated.
> Thanks, in advance!

You've just describe the exact specifications of an existing product 
available from Telebit known as a "NetBlazer".  It consists of a 
Trailblazer modem and a mid-power router in a single box with an ethernet
interface. Once configured it will handle dialing in and establishing 
a SLIP or PPP connection. My interest in it stems from its ability to
automatically bring up line when a IP datagam is received, and subsequently
take down the line when idle. (just like the "dialupip" SLIP s/w available)

I'm not aware of any other routers which will initiate phone connections
automatically, but that doesn't mean that they're not working on it..

/John

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 00:51:53 GMT
From:      kdenning@genesis.Naitc.Com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   SNMP monitoring software -- available in the PD?

Good evening!

We're looking for SNMP software for our Sun and other machines.  Does such a
beast exist in the public domain (or in a reusable form), and if so, does
anyone have a pointer to a suitable FTP site for it?

Thanks!

-- 
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.

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 01:19:54 GMT
From:      glass@postgres.Berkeley.EDU (Adam Glass)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.iso
Subject:   Is Apollo token ring ISO 802.5?


In the documentation I have from Apollo they refer to the token ring
they support as "Apollo Token Ring", not as ISO 802.5 token ring?  Is
it ISO or not?  If not, what document describes it?

Also, where can I find a standard that discusses the transmission of
IP datagrams over 802.5?

later,
Adam Glass
--
Adam Glass                           |Internet: glass@postgres.Berkeley.EDU
various roles at Berkeley	     |Home    : glass@Chaos.org

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 01:26:15 GMT
From:      DAVID@wcc.govt.nz (David Richards)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over LAT is it possible?

Does anybody know if this is possible
Running a serial line to TCP/IP through a (LAT) LTAxxxx: device
We have WINS/TCP

+----------+    +----------+
| MicroVax |    |DECserver |
|   3800   |    |   200    +------ TCP/IP ???
+----+-----+    +----+-----+
     |               |
     |   Ethernet    |
-----+---------------+------

Please reply to the list
Thanks in advance.

David

P.S. My return address is screwed, please SEND not REPLY, to "david@ccc.govt.nz"
If mail bounces, try "david%ccc.govt.nz@wcc.govt.nz"

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 01:26:20 GMT
From:      ROBERT@VM1.MCGILL.CA (Robert Craig)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for experience with Telebit Netblazer

T
 >

An organization here in Quebec has been evaluating the NetBlazer
for possible use on our regional network.  The contact's address
is kinley@crim.ca (hope he doesn't curse me too much for this!).

Robert Craig                          domain: robert@vm1.mcgill.ca
Senior Network Analyst                bitnet: robert@mcgill1
McGill University Computing Centre    Tel: (514) 398-3710
805 Sherbrooke St. W.                 FAX: (514) 398-6876
Montreal, Quebec H3A 2K6              CORISQ: (514) 398-RISQ

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 02:32:45 GMT
From:      chooper@cc.curtin.edu.au (Todd Hooper)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.tcp-ip
Subject:   Re: FTP for MacTCP?

In article <.0A-CCD@engin.umich.edu>, erdwing@sol.biostat.med.umich.edu (Erdwing Coronado) writes:

> I have used XferIt with good results. It is available from anon ftp
> at msdos.archive.umich.edu and/or mondo.engin.umich.edu.

Definitely get the version from mondo.engin.umich.edu...the version at info-mac
is still fairly out of date and is nowhere near as nice.

For the record, the version I've got from mondo is XferIt 1.4b2 which is the
latest and greatest as far as I know.

> It runs over MacTCP. (I normally run NCSA Telnet 2.3 with 3-4
> Unix sessions open, POPMail, XferIt, NewsWatcher and MacX at
                                    ^^^^^^^^^^^
> the same time in a Mac IIci with little hassle).
> Oh, XferIt and NewsWatcher are shareware.

I've never heard of NewsWatcher. Where can I get it from?

Todd

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 03:45:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   Have question dealing with ip and dec to ibm connectivity

Dear Folks,

I have a request, I am looking for IBM sites using 3090 systems running
MVS/ESA and connecting to DEC VMS hardware using TCP/IP.  A local site is 
having a problem getting info from IBM on how to best to do this.  This 
has been done, the issues are how, with what and so on. 


Right now they are looking for some general info such as IBM products needed, 
third party software or hardware that could be used etc.  Any info to get
this project off of ground zero would be helpfull.  If you do not mind let
me know if a brief phone call could be made for additional info.  The folks
who are interested in this info are not on the net.

If you need additional info let me know.

jim jones

jrjones@alex.stkate.edu

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 05:33:53 GMT
From:      was@gdwb.oz.au (Warren Stokes)
To:        comp.protocols.tcp-ip
Subject:   Help with Annex SLIP & PCroute




I am having some trouble using my recently purchased Annex IIe for a SLIP
link connecting two class B networks.  The setup is as follows:


		128.184 Class B 
--------------------------------------------------------------------------
               |
	       |
          -----------
	  | PCroute | 			PCroute is 2.2
	  -----------
	       |   128.184.201.1
	  -----------
	  | Modem   |
	  -----------
	       |
	       |
	       |
	       |  Leased line
	       |
	       |
	  -----------
	  | Modem   |
	  -----------
	       |   128.184.201.2
         -------------				--------------
	 | Annex IIe |				|  Sun       |
	 -------------				--------------
	       |   138.19.4.3			       |  138.19.1.10
	       |				       |
------------------------------------------------------------------------------
		138.19 Class B


Pinouts for Annex port to modem are as follows:

Annex Port		Modem DB25

   TxD			   2
   RxD			   3
   RTS			   4
   CTS			   5
   Gnd			   7
   DCD			   8
   DTR			  20


Setup for Annex is:

Annex network administrator R5.0.3 Apr 23, 1990
annex daffy.ts:
                   inet_addr: 138.19.4.3
              pref_load_addr: 138.19.1.1
              pref_dump_addr: 0.0.0.0
              load_broadcast: Y
                  image_name: ""
                 subnet_mask: 255.255.0.0
              broadcast_addr: 255.255.255.255
           load_dump_gateway: 0.0.0.0
               name_server_1: dns
             pref_name1_addr: 138.19.1.1
               name_server_2: dns
             pref_name2_addr: 138.19.1.10
        nameserver_broadcast: N
             host_table_size: 64
           pref_secure1_host: 0.0.0.0
           pref_secure2_host: 0.0.0.0
          security_broadcast: Y
               vcli_security: N
          network_turnaround: 2
             enable_security: Y
          load_dump_sequence: net
                ipencap_type: ethernet
           server_capability: none
                 syslog_mask: none
             syslog_facility: log_local7
                 syslog_host: 0.0.0.0
                  cli_prompt: "annex: "
                   motd_file: "motd"
        timezone_minuteswest: 300
            daylight_savings: usa
              time_broadcast: N
                    max_vcli: unlimited
                    password: "<set>"
                     acp_key: "<unset>"
               vcli_password: "<unset>"
                      routed: Y
                       rwhod: Y
        min_unique_hostnames: Y
               ring_priority: 0


Setup for annex port running slip is:

annex daffy.ts port 3:
                       speed: 9600
                   data_bits: 8
                   stop_bits: 1
                      parity: none
                 imask_7bits: N
               control_lines: both
                        type: hardwired
                        mode: slip
            forwarding_timer: 0
            inactivity_timer: off
              port_multiplex: N
             allow_broadcast: Y
           max_session_count: 3
          input_flow_control: eia
            input_start_char: ^Q
             input_stop_char: ^S
         output_flow_control: eia
           output_start_char: ^Q
            output_stop_char: ^S
          ixany_flow_control: N
                  long_break: Y
                 short_break: Y
                   attn_char: ^@
                   user_name: ""
                      prompt: ""
                    term_var: ""
           input_buffer_size: 1
         bidirectional_modem: N
        default_modem_hangup: N
                    location: ""
           input_is_activity: Y
          output_is_activity: N
          reset_idle_time_on: input
                cli_security: N
            connect_security: N
        port_server_security: N
           dedicated_address: 0.0.0.0
              dedicated_port: telnet
            newline_terminal: N
            leap_protocol_on: N
                        echo: Y
                map_to_lower: N
                map_to_upper: N
                  char_erase: Y
                  line_erase: Y
               hardware_tabs: Y
                  erase_char: ^?
                  erase_word: ^W
                  erase_line: ^U
              redisplay_line: ^R
               toggle_output: ^O
               telnet_escape: ^]
          slip_local_address: 128.184.201.2
         slip_remote_address: 128.184.201.1
            slip_subnet_mask: 255.255.255.0
         slip_load_dump_host: 0.0.0.0
                 slip_metric: 1
             slip_allow_dump: Y
              cli_inactivity: off
               port_password: "<unset>"
         broadcast_direction: port



On the Annex, the gateways file is:

host 128.184.201.1 gateway 138.19.4.3 metric 1 hardwired
net 128.184.0.0 gateway 138.19.4.3 metric 2 hardwired
net 128.184.0.0 gateway 128.184.201.1 metric 1 hardwired

I also did the following on the sun - 138.19.1.10.  (Note that
the network 138.19 is NOT subnetted.)

route add net 128.184.201.0 138.19.4.3 1



With all the above set up I can ping 128.184.201.1 successfully when
on a VCLI port on the annex but cannot ping the same address from the
sun (138.19.1.10).  The ping from the sun does increase the CharTx
count on the annex port used for SLIP so the routing seems correct.
Also from the other end (128.184.0.0), pings to 128.184.201.2 do not
work but again using the stats command I can see the CharRx count
increase with each ping packet.

Has anyone successfully run a configuration like this?
Is there any known incompatibilities between Annex SLIP and PCroute?
Can anyone see anything wrong with my setup?


Sorry about the length of this!!

Thanks
Warren Stokes
Geelong and District Water Board


--
Warren Stokes			Geelong & District Water Board
Phone: +61 52 262598		61-67 Ryrie St Geelong
Fax:   +61 52 218236		Victoria 3220 Australia

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 05:37:04 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

In article <1991Jun13.222559.7574@bronze.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes:
>[PEM's] use is strictly voluntary, and unless both sender and recipient
>implement it, it's not very useful.

So is RFC 931.  RFC 931 is on more hosts than PEM.  There are a LARGE
number of hosts that don't use RFC 931.

Warner
-- 
Warner Losh		imp@Solbourne.COM
Free to a good home: 10,000 Miller Moths.  Must promise not to breed them.

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 06:51:51 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting a very large population

In article <m1TF42w163w@sadss> garethh@sadss (Gareth Howell ) writes:
>I have the (un)enviable taks of coming up with an Internet Addressing 
>Strategy for the UK Department of Social Security's internet (note small 
>'i':-). This comprises (or soon will) 2500+ Ethernet LANs: each with 
>anything from 4-50 PCs, Unix application servers and gateways on them; all 
>interconnected using the Government Data Network (X.25 (1980)). Most of the 
>operational systems use OSI protocols, but there is a significant amount of 
>IP traffic, mainly for SNMP HUB and BRIDGE and host management on the LANs.
>
>What I need is a sanitory way to split up the population to ease number 
>allocation and permit local administration of each LAN. What I have come up 
>with is this, and I would like comments (good or bad :-):
>
>Allocate a single non-subnetted Class B address to the X.25 GDN (2500+ hosts).
>Allocate a number of Class B addresses to clusters of LANs, and subnet each 
>of these networks in accordance with RFC950 and RFC1219.

I am involved with defining a similar network in this country.
Ours is worse, in that most of the X.25 connections are dial-up
on-demand (inbound-only).

The proposed solution in our network is to hierachically define all of
the address space in a number of class B networks, one per region, with
the physical X.25 WAN appearing in segments of each class B net.
The regions are each headed up by an IP router, and these routers
(which will probably all be co-located with a major hub in the
X.25 network) will be connected via a backbone LAN.

Each leaf PC only needs a default route to the Ether side of the leaf
gateway. Each leaf gateway only needs a default route via X.25 to the
regional router. The regional router needs to know the subnet numbers,
subnet masks and X.25 addresses of all the ethernet segments within the
region. But anything outside the region can be routed by net number
(without subnets).

To make this work, an IGP must be used which can communicate masks with
all routes, but the whole cluster can connect to the outside world by
EGP and only tell the core about the regional class B numbers.

Note, that things would have been defined very differently if the
wide area network had been managed primarily for IP use and had had an
established DDN-like IP-to-X.25 address mapping.

I hope this is helpful. Feel free to contact me by email. The above is
probably as much as is useful to the world.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 08:31:22 GMT
From:      jel@xerver.data.nokia.fi (Jerry Lahti)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

SCO TCP/IP 1.1.3 (and probably also ODT 1.1) contains a driver for
Western Digital adapters which recognizes a WD8013.  It has worked
without problems in our machine and the performance is much better
than with 3COM Etherlink II (TCP throughput is over 300 KB/sec against
at most 180 KB/sec with Etherlink II).  The driver which came with
the older TCP/IP versions supported only the 8-bit WD adapters.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 10:55:16 GMT
From:      jj@dcs.leeds.ac.uk (J Jackson)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Vendor Hardware Address Ranges


I know this is a FAQ, apologies, but can someone point me to an
uptodate list of Vendor Hardware address ranges?

many thanks
=======================================================================
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.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 10:58:00 GMT
From:      mah@wu-wien.ac.at (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun12.075244.26984@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes:
|> In article <1991Jun11.183342.23051@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes:
|> >In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote:
|> >>In article <1991Jun9.030935.27196@mp.cs.niu.edu>
|> >>	rickert@mp.cs.niu.edu (Neil Rickert) writes:
|> >>>You need a uucico which is built to first check if
|> >>>its stdin/stdout is a socket.
 
|> The problem now is that with SCO's uucico you can only use the "g" packet level
|> protocol. This is blessed with small packets (64 bytes data) and a small window size
|> (3, can be adb'd up to 7). The end result is truly amazing throughput :-) About 102
|> cps with windowsize of 3 and 170 with windowsize 7.


Some uucico's can use the 'f' protocol which is a royal cludge for 
X25 PAD connections, and in use on quites some sites on this side of the
pond. 'f' Protocol means: Escape all characters below space or above 127,
append a checksum, and do flow control via XON/XOFF. Ack's are only sent
after a whole file is done.

Now if you could coerce uucico running the 'f' proto over a TCP socket, 
througput should be much better. Unfortunately, few manufacturers have 
picked it up (HP for sure, dont know about others). Definitely not the
PC unix crowd.

|> I dream of a day when van-bc has all the networking facilities available on a Sun.

I just inquired ATT Unix Europe for BNU source alone, to do such things.
They wont sell it without SystemV R4 attached to it, and at $100.000.-
thats beyond scope for the application in question. Seems like they are 
dedicated to kill uucp. 

-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

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 11:36:37 GMT
From:      uwek@yedik.han.de (Uwe Kallmeyer)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

johnw@group1.uucp (John Wheeler) writes:
>Does ANYBODY know of any 16-bit drivers for SCO Unix?

Yes. Me. The german company "Schneider &  Koch"  sells  a  16-Bit
"G16"-card.   They  also  supply  drivers  for this card for SCO,
Interactive an AT&T. I ordered one and expect to test it in july.
So mail me around end of july for details.

	uwek

>Thanks!
You're welcome.

-- 
char name[] = "      Uwe Kallmeyer, Wendenring 32, D-3300 Braunschweig      ";
char uucp[] = "            uwek@yedik.han.de || Ph.: 0531-344841            ";
char motl[] = "          Satori is real (unless declared integer).          ";

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 14:28:00 GMT
From:      barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett)
To:        comp.protocols.tcp-ip
Subject:   RFC 931 "Not Recommended" (Re: Authenticated SMTP, anyone done one?)

In article <17169:Jun1122:04:5791@kramden.acf.nyu.edu>,
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> RFC 931, the Authentication Server, provides enough additional security
> to stop those pesky undergraduates from forging mail (at least without a
> network machine of their own). You can get my implementation of RFC 931
> for BSD machines in stealth.acf.nyu.edu:pub/hier/inet/rfc931/authd.3.01.
> You can make sendmail (5.61, 5.65, possibly others) understand RFC 931
> by applying sendmail-patches-djb, available from the same place; after
> the patch, $F in an H line in sendmail.cf will print the remote user
> name for any SMTP connection.

I could find only two references to authentication protocols in RFC1200,
and both are marked "Experimental" and "Not Recommended".  Why?

How seriously should people take the suggestion that experimental
protocols should not be implemented without coordination with their
developers?

" Network Working Group                          Internet Activities Board
" Request for Comments: 1200                             J. Postel, Editor
" Obsoletes: RFCs 1140,                                         April 1991
"      1100, 1083, 1130
" 
" 
" 
"                     IAB OFFICIAL PROTOCOL STANDARDS
" 
" [...]
" 
"    4.1.4.  Experimental Protocol
" 
"       A system should not implement an experimental protocol unless it
"       is participating in the experiment and has coordinated its use of
"       the protocol with the developer of the protocol.
" 
" [...]
"
"    4.2.5.  Not Recommended Protocol
" 
"       These protocols are not recommended for general use.  This may be
"       because of their limited functionality, specialized nature, or
"       experimental or historic state.
" 
" [...]
" 
" 6.6.  Experimental Protocols
" 
" Protocol   Name                                     Status           RFC
" ========   =====================================    =============== ====
" [...]
" COOKIE-JAR Authentication Scheme                    Not Recommended 1004
" [...]
" AUTH       Authentication Service                   Not Recommended  931
" [...]

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 14:53:39 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip,comp.mail.sendmail
Subject:   Re: More problems with sendmail/IDA and DECnet

I added the tcp-ip newsgroup to the distribution. Follow-ups to
comp.protocols.tcp-ip

The discussion concerns if it is useful to have an /etc/svc.conf file.
I mentioned that GE's mail gateway has the equivalent, so that we
don't advertise any addresses in the 3.0.0.0 network (which is
unconnected to the Internet).

In article <kre.676867753@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au 
(Robert Elz) writes:

>I disagree - there's no problem sending back (properly allocated)
>numbers if someone queries for them, regardless of whether they are
>reachable or not.  I would have no problem getting back a 3.a.b.c
>address were I to ask for the IP address of grymoire.crd.ge.com.

Well, I may be missing the fine points, but I believe NYSERNET, et. al.
do not like to see any packets addressed to the 3.* network.
This causes unnecessary traffic, and people monitor such packets and
let us know if we are "leaking" anything when we should not be doing so.

If we make the 3.* addresses available (i.e. "A" Records) while
advertising a "*.ge.com MX record to crdgw1.ge.com on its Class C
network, we could cause a lot of problems on the Internet. I believe.



--
Bruce G. Barnett	barnett@crdgw1.ge.com	uunet!crdgw1!barnett

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 15:25:38 GMT
From:      van@HORSE.EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   another TCP/IP traffic study paper available for anonymous ftp

A new tech report (LBL-30840):

  "Measurements and Models of Wide Area TCP Conversations"
   by Vern Paxson, LBL Computer Systems Engineering Group

is available for anonymous ftp from ftp.ee.lbl.gov (128.3.254.68),
file tcpmeasurements.ps.Z (this is a 1MB compressed postscript file).
This study is similar to that described in the recently
announced paper by Danzig, et.al., of USC.  However, a much more
efficient means of data capture was employed (described in the
paper) which allowed the collection & analysis of every
conversation in to and out of the LBL campus over a period of
two months, rather the the two hour period of the USC study.
This greater temporal scope allowed the investigation of
long-term TCP/IP traffic variation (i.e., hourly, daily, weekly
and monthly).  It also allowed a detailed investigation of the
geographic distribution of traffic.  (This and other studies
have shown that there is substantial short term correllation in
conversation patterns and it is not possible to reliably assess
geographic distribution from samples spanning less than a few days.)

The abstract of the paper is attached.

 - Van

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

                 Abstract

This paper describes measurements of all of the wide area
network TCP conversations between the Lawrence Berkeley
Laboratory (LBL) and the rest of the world for the months of
November, 1990, and March, 1991.  Some 500,000 conversations
were recorded, encompassing 11 different major protocols.  We
look at aggregate characteristics of these conversations, both
overall and by TCP protocol (e.g., smtp, ftp), computing the
distributions of amount of data transferred, network bandwidth
used, conversation lifetimes and conversation interarrival
times.  Temporal traffic variation is also investigated, showing
the variation of number of active conversations and network
bandwidth utilization over periods of 24 hours, 7 days and 30
days.  Long term variation is also investigated by separately
analyzing November and March data (which reveals a 10-20%
increase in almost all aggregate traffic characteristics in just
four months).  We classify each conversation geographically and
discover that the connectivity of the conversations was
remarkably rich, including traffic to 48 of the 50 states in the
U.S. and 23 foreign countries.  Finally, we develop a number of
models for describing conversations of the various protocols.
From these models we can more readily assess how each protocol
is used and how the use changes as network utilization grows.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 16:39:35 GMT
From:      csg@pyramid.pyramid.com (Carl S. Gutekunst)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.iso
Subject:   Re: Is Apollo token ring ISO 802.5?

>In the documentation I have from Apollo they refer to the token ring
>they support as "Apollo Token Ring", not as ISO 802.5 token ring?

The Apollo Domain token ring is proprietary. All technical information about
it was guarded like the family jewels for almost a decade. Several vendors
approached Apollo in the early 80's to license their token ring technology,
but Apollo either refused or put the price tag out of reach (depending on
whose story you listen to). Eventually Apollo realized that "open systems"
were taking over the market place, and they published the ring spec; but by
then no one was interested in it any more.

<csg>

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 17:30:28 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

On 5 Jun 91 13:39:32 GMT, grahamt@syma.sussex.ac.uk (Graham S Thomas) said:

grahamt> When the Coloured Book software suite was conceived, it was
grahamt> (according to my best information - correct me if I'm wrong) by
grahamt> no means clear that TCP/IP would become as dominant as it has
grahamt> today.

On this I would disagree. At the time the CB were done, the *only* large
scale network, especially in the academic sector, was the ARPAnet. There
were *no* ISO style networks in widespread use, in the academic sector.

Also, the DARPA was funding a lot of efforts to produce networking
ARPAnet software for a large variety of machines, software that was,
thanks to US govmt. practice, freely available.

The JNT chose unproven, incomplete technology for which there was no
ready made software, against proven, well established technology for
which there was a large and growing mass of ready made software.

This was clear even without the benefit of hindsight. Anybody who used
the ARPAnet knew that at its time it was simply unique, it did work
well, and its technology had several years of advantage on anything
else.

grahamt> In any case, the Coloured Books were always seen as ultimately
grahamt> giving way to full OSI protocols.  Again, the originators could
grahamt> not have forseen that OSI would be such a long time a-comin',

You mean that somebody at the time did not realize that an incomplete
set of protocols still being actively being discussed and designed was
not 'a long way in coming'. I find this astonishing. Especially as
ARPAnet protocols were not only already discussed and designed, they
were also already implemented.

It is a well known fact that international standadization is already a
slow process when the standard sanctifies existing technology, and
delays become even more dramatic when the technology has to be developed
by the standards bodies themselves.

There is also the obvious political observation that, just like ISDN,
monopolistic PTTs, especially in Europe, have no interest in rushing new
technology to the market, because it means throwing away a lot of
existing investment, when there is no need, because the market has to
bear what the PTT decides.

X.25 networking has been boycotted with great zeal by all/most European
PTTs, just like any form of data traffic (which has been boycotted in
the USA by AT&T, as Tanenbaum notes), and this was very well known among
observers of the telecom scene.

Your information, IMNHO, seems to imply that the originators of JANET
were naive idealists with thoroughly unrealistic optimistim on the
maturity and development speed of ISO technology. Amusing :-(.

grahamt> or that it could conceivably be threatened by semi-open
grahamt> protocols like TCP/IP.

Ah, now we understand. By 'semi-open' you are possibly implying that the
ARPAnet suite of procols had the fatal defect of being designed under
the auspices of and controlled by somebody else than the cosy club of
European PTTs, which could slow down its development at will, but by a
relatively efficient Agency of the US Govmt...

After all JNT is something that emanates from the British Govmt., which
at the time was also the owner of the local PTT. As they say "a
synergetic partnership :-).
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 18:10:15 GMT
From:      kdenning@genesis.Naitc.Com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   SNMP second try

I wasn't explicit enough in my first request (this is obvious).

We are looking for the following:

1)	Xwindows-based display software which can map networks and monitor
	SNMP-capable hosts, routers, and gateways.  Ideally it should be
	able to do "dynamic discovery" of nodes (lots of possible ways to do
	this, from community name transmissions to broadcasts).  Some of
	the things we'd like are:

	o)	Four or five "status levels" at each level of the tree, 
		including "green" (up and ok), "yellow" (traffic level
		warnings, low water marks for disk capacity, collision rates
		over some metric, CPU over some metric, etc), "orange" 
		(disk high water marks, bad collision problems, etc) and
		"red" (node unreachable, etc).  Preference is to be able to
		ignore errors or warnings on some nodes (ie: I don't care if
		the PCs are unreachable or go "offline", but the servers are 
		another matter entirely!)

	o)	Active polling and passive SNMP community listening modes.

	o)	Ability to keep a database so it doesn't have to
		"dynamically discover" every time it's started.

	o)	Runnable from more than one location at once (concurrent
		monitoring).

	o)	Writes logs of status updates somewhere configurable (this
		is intended to interface with a program I'm working on to
		take proactive action on some conditions -- ie: try to reboot 
		a panic'd server).

	o)	Mapping capability (what connects to where) based on network
		numbers and the like.

	o)	Multi-level display modes (See HP OpenView for an idea of
		what I'm talking about here).

	o)	Warnings, errors, and the like configurable as to their
		severity and response action (ie: what turns a box "red").

I'm sure there's more, but this is a start.


SNMPD Software:

1)	BSD and System V software to run on a workstation or server that
	provides SNMPD services and reporting complient with the MIB
	standards.  HP has this on their 800 series "minis" -- and it works
	quite well.  Is there a >working< PD version of this?  I've looked
	at the MIT stuff and the like, and it looks like a skeleton for
	development rather than something that can be put to use.


Commercial, Freeware, PD, Shareware and every other kind of ware considered.
Basic consideration for the display side is machine-independance if
possible (which probably means source code is needed); the SNMPD stuff
needs to be in source so I can put it on many different makes of machines).

Any help or pointers appreicated!

--
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.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 18:13:51 GMT
From:      dale@interlan.Interlan.COM (Dale B)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

>In article <1991Jun12.215148.6484@ima.isc.com> jimm@ima.isc.com (Jim McGrath) writes:
>>>
>>Racal Interlan has a driver for both ISC and SCO for the NI6510.  It
>>
>That got truncated somehow.  This is what I meant to post.
>
>Racal Interlan has a driver for both ISC and SCO for the NI6510.  It
>works with Interactive Unix, but I haven't tried it with SCO :^).
>
>Jim

It works just as well with SCO as it does with ISC, and hopefully that's
perfectly!
Dale

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 18:45:27 GMT
From:      dale@interlan.Interlan.COM (Dale B)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

>After repeated calls to SCO, which, by the way, has the LONGEST
>queing mechanism I've ever encountered, I have been able to find
>_NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find
>it hard to believe that I can get 16-bit drivers for a simple MS-DOS
>machine but *NOT* for our multi-gigabyte SCO hosts!!!!
>
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>(WD 8013 preferred)....
>
>
>Thanks!
>-- 
>________  John Wheeler - Informix-4GL / SQL * Unix * Broadcast Audio Production
> \rrrr/   Group One Ltd.
>   \/     San Francisco

Email to you bounced.  Anyway, last I heared SCO was supposed to be supporting
the NI6510, a 16 bit bus master card from Racal InterLan that is supposedly the
fastest 16 bit ethernet card on the market.  You get an SCO STREAMS driver with
the card.  If you can't get any info out of SCO, call us at 800-LAN-TALK or
drop me some email at dale@interlan.interlan.com.
Dale

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 20:23:40 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: vendor provided Packet Drivers

In article <9106121357.AA28590@ftp.com>, jbvb@ftp.com wrote:
>> ... I have a client that is demanding a dual stack (IP and IPX) PC
>> solution that is fully vendor provided/vendor supported....
>At least Interlan, Hughes LAN Systems, Schneider & Koch, Gateway, Acer and
>IMC Networks all have supported Packet Drivers and Netware which runs with
>them ...

Western Digital also provides a pair of Netware/Packet drivers
which can co-exist with each other and share the same Ethernet
card concurrently.  You just need to SHGEN your IPX with their
Netware driver.  When their Packet driver starts it will check
to see if their Netware driver is already active, and if so it
will use the Ethernet through it.

Thus for the WD cards there should be no need for the BYU stuff.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 21:46:03 GMT
From:      moliver@shadow.pyramid.com (Mike Oliver)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.iso
Subject:   Re: Is Apollo token ring ISO 802.5?

In article <GLASS.91Jun13171954@arcadia.postgres.Berkeley.EDU> glass@postgres.Berkeley.EDU (Adam Glass) writes:
>Also, where can I find a standard that discusses the transmission of
>IP datagrams over 802.5?

You need good ol' RFC 1042 ... it describes IP and ARP over 802.3,
802.4 and 802.5 MACs.

1042	Postel, J.B.; Reynolds, J.K.  Standard for the transmission of IP
	datagrams over IEEE 802 networks.  1988 February; 15 p. (Format:
	TXT=35201 bytes)  (Obsoletes RFC 948)

Cheers, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 21:53:19 GMT
From:      leonard@arizona.edu
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over LAT is it possible?

In article <9106142259.AA20670@golem.wcc.govt.nz>, DAVID@wcc.govt.nz 
(David Richards) writes:
> Does anybody know if this is possible
> Running a serial line to TCP/IP through a (LAT) LTAxxxx: device
> We have WINS/TCP
> 
> +----------+    +----------+
> | MicroVax |    |DECserver |
> |   3800   |    |   200    +------ TCP/IP ???
> +----+-----+    +----+-----+
>      |               |
>      |   Ethernet    |
> -----+---------------+------
> 
> Please reply to the list

I have done this with good success, by using LATCP
on the VMS system to create a LAT "application port"
and a "SLIP service".  I set the port on the DECserver
to be dedicated to autoconnect to the SLIP service.
I then used SLIP (using TGV's MultiNet TCP/IP package)
to talk IP over the pseudo-terminal.

It worked well for us, though TGV tells me that this 
configuration is "not supported" and "can crash VMS"
due to problems with the LAT driver.  I don't know whether 
this scheme would work with the Wollongong product.  (Does
Wolly support SLIP?)

Send me mail if you want more info.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Telecommunications, Tucson AZ 85721

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 22:02:21 GMT
From:      BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Network management for routers


    1.  Why is the 68000 microprocessor the preferred choice
	for routers?

Flat address space well suited toward embedded applications requiring
large memory.  While the 386 might be made itno a reasonable router,
it has not been available for nearly as long as the 68000.  Nor have
the various RISC processors.

Network byte order == computer byte order for most popular protocols.

Many routers are based on BSD unix, which was widely available for 68000
architectures long before other processors.  Cisco's original router was
very similar to a SUN-1, for example (cisco being essentially the "other
half" of Stanford's SUN project) (hardware-wise.  The cisco software isn't
at all derived from unix.)

Better C compilers available (consequence of preceeding comment.)


    2.  What are the advantages of using 68000 for snmp agent 
	for routers?

I suspect that ASN.1 is sufficiently complicated that it removes any
particular advantage the 68k might have had.  That doesn't mean it isn't
still a better overall choice - a router has to do more than run SNMP.


    3.  Are there public domain sources for:
	 -- UDP/IP stack
	 -- SNMP agents for routers and HUBs

BSD TCP is sort of public domain, as are a number of PC packages for
the MAC, Amiga, etc.  A bunch of free software is available for BSD
unix, including some SNMP implementations from MIT and CMU.

BillW
-------

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 22:14:51 GMT
From:      dente@els.ee.man.ac.uk (Colin Dente)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.iso
Subject:   Re: Is Apollo token ring ISO 802.5?

In article <GLASS.91Jun13171954@arcadia.postgres.Berkeley.EDU> glass@postgres.Berkeley.EDU (Adam Glass) writes:
>
>In the documentation I have from Apollo they refer to the token ring
>they support as "Apollo Token Ring", not as ISO 802.5 token ring?  Is
>it ISO or not?  If not, what document describes it?

No - Apollo Token Ring (ATR) is *not* ISO.  Apollo does, however,
support 802.5 token rings as well - so you can have two different
token ring boards in your apollo.

The best reference (well - the only one I know of) for details of the
ATR is probably (hang on while I go over to my bookcase) I.E.E.E.
Jounal on Selected Areas in Communications, Volume 1, Nr. 5; November
1983, pp 842-857.

>
>Also, where can I find a standard that discusses the transmission of
>IP datagrams over 802.5?

Beats me ;-)

Colin

--
  Colin Dente                     | JANET: dente@uk.ac.man.ee.els
  Manchester Computing Centre     | ARPA:  dente@els.ee.man.ac.uk 
  University of Manchester, UK    | UUCP:  ...!mcsun!ukc!manchester!dente 
                 ... I am the one you warned me of ...

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 22:30:21 GMT
From:      suresh@uts.amdahl.com (Suresh Padmanabhan)
To:        comp.protocols.tcp-ip
Subject:   Re: File arguments too long!



From postnews Fri Jun 14 15:26:52 1991
> In article <1991Jun7.222936.24697@ucselx.sdsu.edu> syserror@bugs.zoo writes:
> >Sometimes when using FTP, after using an 'mget *.xyz'  I get
> >the message 'File arguments too long' whereupon none of the get 
> >or put commands will function anymore.
> 
 
>> A variable is used to limit the number of file-arguments when wildcard
>> expansion is performed. I have encountered that same message when this
>> variable was defined as a short. This value gets initialized to a value
>> greater than the defined storage and thereby becomes negative. The
>> solution is to define this variable as an unsigned int.

------

suresh

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 22:33:54 GMT
From:      carroll@ssc-vax (Jeff Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over LAT is it possible?

In article <9106142259.AA20670@golem.wcc.govt.nz> DAVID@wcc.govt.nz (David Richards) writes:
>Does anybody know if this is possible
>Running a serial line to TCP/IP through a (LAT) LTAxxxx: device
>We have WINS/TCP

What you propose is not possible.

What you need is a third party terminal server that handles both TCP and LAT.
These are available in the USA for as little as $1500, and the technology 
can now be said to be mature.



-- 
Jeff Carroll		carroll@ssc-vax.boeing.com

"...and of their daughters it is written, 'Cursed be he who lies with 
any manner of animal.'" - Talmud

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 91 23:04:40 GMT
From:      rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius)
To:        comp.protocols.tcp-ip
Subject:   Re:  SNMP second try

--> From tcp-ip-RELAY@NIC.DDN.MIL Fri Jun 14 18:46:21 1991
--> From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!Firewall!genesis!kdenning@ucbvax.Berkeley.EDU  (Karl Denninger)
--> Organization: AC Nielsen Co., Bannockburn IL
--> Subject: SNMP second try
--> Sender: tcp-ip-relay@nic.ddn.mil
--> To: tcp-ip@nic.ddn.mil
--> 
--> I wasn't explicit enough in my first request (this is obvious).
--> 
--> We are looking for the following:
--> 
--> 1)	Xwindows-based display software which can map networks and monitor
--> 	SNMP-capable hosts, routers, and gateways.  Ideally it should be
--> 	able to do "dynamic discovery" of nodes (lots of possible ways to do
--> 	this, from community name transmissions to broadcasts).  Some of
--> 	the things we'd like are:
--> 
--> 	o)	Four or five "status levels" at each level of the tree, 
--> 		including "green" (up and ok), "yellow" (traffic level
--> 		warnings, low water marks for disk capacity, collision rates
--> 		over some metric, CPU over some metric, etc), "orange" 
--> 		(disk high water marks, bad collision problems, etc) and
--> 		"red" (node unreachable, etc).  Preference is to be able to
--> 		ignore errors or warnings on some nodes (ie: I don't care if
--> 		the PCs are unreachable or go "offline", but the servers are 
--> 		another matter entirely!)
--> 
--> 	o)	Active polling and passive SNMP community listening modes.
--> 
--> 	o)	Ability to keep a database so it doesn't have to
--> 		"dynamically discover" every time it's started.
--> 
--> 	o)	Runnable from more than one location at once (concurrent
--> 		monitoring).
--> 
--> 	o)	Writes logs of status updates somewhere configurable (this
--> 		is intended to interface with a program I'm working on to
--> 		take proactive action on some conditions -- ie: try to reboot 
--> 		a panic'd server).
--> 
--> 	o)	Mapping capability (what connects to where) based on network
--> 		numbers and the like.
--> 
--> 	o)	Multi-level display modes (See HP OpenView for an idea of
--> 		what I'm talking about here).
--> 
--> 	o)	Warnings, errors, and the like configurable as to their
--> 		severity and response action (ie: what turns a box "red").
--> 
--> I'm sure there's more, but this is a start.
--> 
--> 
--> SNMPD Software:
--> 
--> 1)	BSD and System V software to run on a workstation or server that
--> 	provides SNMPD services and reporting complient with the MIB
--> 	standards.  HP has this on their 800 series "minis" -- and it works
--> 	quite well.  Is there a >working< PD version of this?  I've looked
--> 	at the MIT stuff and the like, and it looks like a skeleton for
--> 	development rather than something that can be put to use.
--> 
--> 
--> Commercial, Freeware, PD, Shareware and every other kind of ware considered.
--> Basic consideration for the display side is machine-independance if
--> possible (which probably means source code is needed); the SNMPD stuff
--> needs to be in source so I can put it on many different makes of machines).
--> 
--> Any help or pointers appreicated!
--> 
--> --
--> 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.
--> 
I think you'll find alot of pointers to SNMP-compliant applications ( some
free ) in RFC ( request for comment ) number 1147. It's a little old,
but gives quite a # of anonymous ftp sites for snmp source code and 
more. Check it out.

Rog.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 01:25:02 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <1991Jun14.105800.28984@swdsrv.edvz.univie.ac.at>
	mah@wu-wien.ac.at writes:
>Now if you could coerce uucico running the 'f' proto over a TCP socket, 
>througput should be much better. Unfortunately, few manufacturers have 
>picked it up (HP for sure, dont know about others). Definitely not the
>PC unix crowd.

SCO has `g' and nothing else.  Interactive has `g' and `e'.  One person
mentioned they moved a copy of uucico from their ISC to SCO machine
to eek out some better TCP/IP performance, and it worked.  (This was
done using the `uucpm' daemon - not the builtin TLI stuff ISC provides.)

>I just inquired ATT Unix Europe for BNU source alone, to do such things.
>They wont sell it without SystemV R4 attached to it, and at $100.000.-
>thats beyond scope for the application in question. Seems like they are 
>dedicated to kill uucp. 

AT&T has done a fine job of driving a stake through the heart of any
troff future with their DWB3.1 pricing strategy.  Maybe the same folks
are responsible for the BNU marketing.

-- 
Chip Rosenthal     <chip@chinacat.Unicom.COM>  |  Don't play that
Unicom Systems Development      512-482-8260   |    loud, Mr. Collins.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 03:41:58 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

In article <43225@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
> <RFC 931 can be used over any part of the Internet. In fact, it's the
> <only working freely available wide-area TCP authentication code I know
> <of. If you do want to restrict access to the local net or to
> <authenticated connections, you can use my attachport (comp.sources.unix
> <volume 22) or shuctld (coming very soon to a source group near you).
> Then what is the purpose of RFCs 1113, 1114, and 1115 on Privacy
> Enhanced Mail (PEM)?

PEM is not, and for the next several years will not be, a freely
available system. It also is not a link-level SMTP authentication
protocol, as the original poster was asking for; it is an end-to-end
privacy protocol. However wondeful PEM might be, it is not available
now, in a form that works on most machines on the Internet. RFC 931 is,
in a tiny package with every compile/install step completely automated.

Basically, you can put RFC 931 on a BSD mail server now. For free. If
you apply the sendmail patch, every mail message coming through the
system will be marked with a username with at least as much security as
the IP address in every packet. Your users won't notice the change, but
you'll suddenly be able to trace forgeries much more easily---or you can
just chop all forgeries tomorrow morning. None of this is true of PEM.

---Dan

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 03:59:57 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

In article <1991Jun14.053704.1059@solbourne.com> imp@solbourne.com (Warner Losh) writes:
> In article <1991Jun13.222559.7574@bronze.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes:
> >[PEM's] use is strictly voluntary, and unless both sender and recipient
> >implement it, it's not very useful.
> So is RFC 931.  RFC 931 is on more hosts than PEM.  There are a LARGE
> number of hosts that don't use RFC 931.

Sure, but the beauty of a link-level security protocol is that you can
add it in bits and pieces. If you add RFC 931 support at just one mail
exchanger, you've suddenly made every message through that exchanger a
bit more secure. If a year from now someone's message happens to wend
its way through several RFC 931 sites, forgeries are suddenly that much
more difficult.

It would help if more vendors supported RFC 931. I've offered my
implementation (as well as the sendmail and talk patches) to Sun and
Berkeley, but they don't seem to understand how it's better than
Kerberos. (Two answers: immediate availability of a simple, working
implementation; wide-area network support.) I'd love to help people add
RFC 931 support to their programs; I'm happy to report that the new ftpd
release from Chris Myers will include RFC 931 authentication as an
option.

---Dan

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 04:10:20 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 931 "Not Recommended" (Re: Authenticated SMTP, anyone done one?)

In article <1991Jun14.142800.27168@Daisy.EE.UND.AC.ZA> barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) writes:
> I could find only two references to authentication protocols in RFC1200,
> and both are marked "Experimental" and "Not Recommended".  Why?

Basically, because they haven't been widely enough field-tested. (This
requirement rarely applies to the pet protocols of established IETFers;
it does make some sense that Party babies should get ahead... :-) )

As soon as some vendor adopts any RFC 931 code, I'll submit my revision
of the RFC and propose that it advance in status.

> How seriously should people take the suggestion that experimental
> protocols should not be implemented without coordination with their
> developers?

Answer 1: You mean someone takes that seriously? Uh-oh.

Answer 2: I hereby extend to all current and prospective users of RFC
931 this offer to become part of My Experiment. Of course, My Experiment
does not require anyone's active participation, as it is a low-profile,
long-term project. In fact, it's so low-profile that you shouldn't even
bother letting me know that you're part of it. Just use the code. :-)

Seriously, I am conducting a large-scale Internet survey, to see how
many hosts on the directly connected net support various TCP protocols,
including RFC 931. This should provide an interesting alternative
(old-fashioned, I guess) viewpoint to the recursive DNS searches
currently in vogue.

---Dan

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 15:51:23 GMT
From:      grahamt@syma.sussex.ac.uk (Graham Thomas)
To:        comp.protocols.tcp-ip
Subject:   IP and Coloured Book Software in the UK

(I sent the following to Michael by mail.  He thought that it, and his
reply, raised points that were worth a wider airing.  So here goes..)

Michael Padlipsky wrote:
> 
> Graham Thomas--
> 
> I'd be so fascinated to see an explanation of your depiction of TCP/IP
> as "SEMI-open" [emphasis added] that I'd even forego the pleasure
> of debating whether the originators of the "Coloured Books" SHOULD
> have realized [or, more locally appropriate, realised] that OSI
> would be a very long time in coming, in exchange.
> 
> cheers, map
> -------

Ah.  First I'd have to know whether you consider TCP/IP to be completely
open or completely closed!  Maybe I shouldn't have said 'open' and
should have said 'semi-standard' or something.  What I meant was, TCP/IP
is available for lots of different machines, and is common in certain
economic sectors, especially in education, (and not in others - here at
least, SNA rules the roost in banking), but it's not been ratified by
international standards committees.

But do tell me why the creators of Coloured Book software should have
realised, in the late 1970's, that TCP/IP would be ahead of OSI in 1991.

I should say that I don't have any stake in this - I'm a user rather
than a network designer.  I do have a social science interest in how
networks and standards are developed.  My own view is that, given what
they started from, the creators of JANET did well to build a unified
academic network in the UK by 1985.  The world has now changed, and some
of the choices that seemed good at the time have proved to be unviable
in the longer term.  I'd like to hear other people's views.

Cheers,

Graham

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 91 19:34:41 GMT
From:      DMM@UGA.CC.UGA.EDU (David Matthews-Morgan)
To:        comp.protocols.tcp-ip
Subject:   Re: vendor provided Packet Drivers

Jim has tested the packet driver that comes with the newer WD cards (as
has Joe Doupnik of Kermit fame); both indicate that the Clarkson packet
drivers and BYU IPX work better.  I will review the issue with Jim.

         David

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 91 11:06:40 GMT
From:      mah@wu-wien.ac.at (Michael Haberler)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   ISC 2.2.1 TCP bug and VJ header compression interaction


There's a known bug in ISC 2.2.1 TCP which causes bad IP headers to be
sent. It usually causes just unnecessary retransmissions. It's said to be
fixed in the next release of ISC tcp

But: if you run SLIP to a gateway which has Van Jacobson header compression
enabled (like KA9Q with "attach slip ...." with the 'v' option), these
bad IP headers also cause the remote gateway to switch to VJ compression.

Consequently all TCP connections time out, UDP still works as VJC only 
is done for TCP headers. Disabling VJ on the gateway flushes the mail 
queue...

- 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

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 91 14:56:34 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: vendor provided Packet Drivers


In article <9106152148.AA07661@ucbvax.Berkeley.EDU> DMM@UGA.CC.UGA.EDU (David Matthews-Morgan) writes:
>Jim has tested the packet driver that comes with the newer WD cards (as
>has Joe Doupnik of Kermit fame); both indicate that the Clarkson packet
>drivers and BYU IPX work better.  I will review the issue with Jim.
>
>         David


I got a Western Digital EtherCard Plus Elite last week. The packet driver that
comes with it crashes in Windows. The readme file for the driver that came
with it says that sine this card uses a new chip, you HAVE to use the
new driver. Yet the old driver seems to work fine and their own driver
most certainly does invariably crash big time. You figure this out!
And if you do, PLEASE POST.

Doug McDonald

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 00:55:11 GMT
From:      stjohns@umd5.umd.edu (Mike St. Johns)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 931 "Not Recommended" (Re: Authenticated SMTP, anyone done one?)

In article <6201.Jun1504.10.2091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

   In article <1991Jun14.142800.27168@Daisy.EE.UND.AC.ZA> barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett) writes:
   > I could find only two references to authentication protocols in RFC1200,
   > and both are marked "Experimental" and "Not Recommended".  Why?

   Basically, because they haven't been widely enough field-tested. (This
   requirement rarely applies to the pet protocols of established IETFers;
   it does make some sense that Party babies should get ahead... :-) )

Speaking as both the author of RFC931 and a charter member of the
IETF... AND as a member of the Security Area Advisory Group of the IETF...

I wrote RFC931 as an experiment and an exercise in writing an RFC back
in the days when there weren't as many being published.  The
functionality of RFC931 was very limited and in any case has been
subsumed by two other very good protocols - KERBEROS and SNMP.
Kerberos provides a much better authentication mechanism while SNMP
provides the mechanism for retrieving general data from a host.

Admittedly, SNMP does not have the MIB variables written to extract
931 data, but the mechanism is there.  Given a choice, I'd rather have
someone write an experimental MIB covering user data than implement 931.


   As soon as some vendor adopts any RFC 931 code, I'll submit my revision
   of the RFC and propose that it advance in status.

If you have a revision, submit it now as an internet draft - send it
to Steve Crocker - Security Area Directory for the IETF
(crocker@tis.com).  Almost anything can enter the standards track -
RFC931 could enter today as a Proposed Standard - no experience with
the protocol is necessare for this step.

   > How seriously should people take the suggestion that experimental
   > protocols should not be implemented without coordination with their
   > developers?

   Answer 1: You mean someone takes that seriously? Uh-oh.

Please take this seriously - its given us great benefits in the past.
Instead of 5 virtually identical but non-interoperable transport
protocols (ala OSI) we have 2, each with a distinct category of
service. 





Its gratifying to see that someone actually reads the old RFC's, and I
appreciate all the work Dan has put into his implementation, but if I
could put a stake through the heart of 931, I would do it - its just
too limited.

Mike

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 01:05:13 GMT
From:      stu@tandem.com (Stuart G. Phillips)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   WIRELESS: Weekly digest available

The WIRELESS mailing list is for techical discussion on all aspects of
wireless LANs such as...

	Propagation
	Media access and control
	RF technology
	Specialized protocols
	.....



==============================================================================
Weekly digest for WIRELESS mailing list

Week ENDING June 15, 1991

This digest (or back issues) can be obtained by anonymous FTP to tandem.com
from the wireless directory.

The file wireless/wireless explains the purpose of the mailing list and
describes how to subscribe and post.

To subscribe to the mailing list, send a mail message to 
'listserv@tandem.com' with the following line in the body:

	add <your e-mail address> wireless

for example:

	add jblow@sum.domain.org wireless

The e-mail address *must* be fully qualified with the full domain name.

The WIRELESS mailing list is moderated by Stuart Phillips and Kevin Rowett.
==============================================================================

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 03:59:35 GMT
From:      chrisdu@sco.COM (Chris Durham)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards


In article <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>(WD 8013 preferred)....

SCO provides the LLI Driver EFS (Link Level Interface Driver Enhanced Feature
Supplement), for SCO TCP/IP 1.1.3 and Open Desktop 1.1. This disk contains
a driver for the Western Digital 16 bit Elite series ethernet cards, as
well as a driver for the Excelan 205T ethernet card.

You can order this EFS through your normal sales channels or directly from
SCO Telesales at 1-800-SCO-UNIX....

>Thanks!

You're welcome


-- 
Chris Durham					chrisdu@sco.COM
Technical Support				...!{uunet,ucscc}!sco!chrisdu
The Santa Cruz Operation			

"'cause you either live life, bruises, skinned knees and all, or you
turn your back on it and start dying."

			-Captain Christopher Pike, _Star Trek_ "The Cage"

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 04:25:42 GMT
From:      rwskubow@GRAND.WATERLOO.EDU (Rog Skubowius)
To:        comp.protocols.tcp-ip
Subject:   Re:  SNMP monitoring software -- available in the PD?

--> From tcp-ip-RELAY@NIC.DDN.MIL Sat Jun 15 10:50:04 1991
--> From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!Firewall!genesis!kdenning@ucbvax.Berkeley.EDU  (Karl Denninger)
--> Organization: AC Nielsen Co., Bannockburn IL
--> Subject: SNMP monitoring software -- available in the PD?
--> Sender: tcp-ip-relay@nic.ddn.mil
--> To: tcp-ip@nic.ddn.mil
--> 
--> Good evening!
--> 
--> We're looking for SNMP software for our Sun and other machines.  Does such a
--> beast exist in the public domain (or in a reusable form), and if so, does
--> anyone have a pointer to a suitable FTP site for it?
--> 
--> Thanks!
--> 
--> -- 
--> 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.
--> 
Check out RFC1147 --> lots of PD stuff...

Rog.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 07:32:13 GMT
From:      igb@fulcrum.bt.co.uk (Ian G Batten)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

In article <PCG.91Jun14183028@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
> On 5 Jun 91 13:39:32 GMT, grahamt@syma.sussex.ac.uk (Graham S Thomas) said:
> 
> grahamt> When the Coloured Book software suite was conceived, it was
> grahamt> (according to my best information - correct me if I'm wrong) by
> grahamt> no means clear that TCP/IP would become as dominant as it has
> grahamt> today.
> 
> On this I would disagree. At the time the CB were done, the *only* large
> scale network, especially in the academic sector, was the ARPAnet. There
> were *no* ISO style networks in widespread use, in the academic sector.

But were there TCP networks either?  My understanding is that at the
time the CBen were being written, the majority of the ARPAnet was
running NCP.  TCP was certainly not the proven technology that it is
now.  Remember that TCP was first seriously available in 4.2bsd.  I
don't have an easy feel for when ``most'' Universities would have had
something running 4.2bsd, but I feel certain that the number of Computer
Centres who would have traded their big iron for a 780 running 4.2bsd
was vanishingly small.  That may be right or wrong, but it is a fact.

Additionally the PTTs, especially BT, were installing shed-loads of
8 bit X25.  IP over X25 was inefficient to put it mildly and without a
massive Military-Industrial complex (TM) there was no way that a
datagram infrastructure was going to be installed. (**)

(*) Did you know the post office still has a class A IP number from the
early days of EPSS?

(**) Unless you had voted SERC out and taken the MOD instead.  Remember
who funded most of US Computer Science through that period?

ian

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 07:52:42 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.archives.admin,comp.protocols.tcp-ip,comp.org.eff.talk,ba.internet
Subject:   building an interstate (data) highway with no roadmaps


do you ever get the feeling that all this NREN stuff is going to
build us a network that's extraordinarily fast but impossible to use?
mitch kapor, in his "building the open road: policies for the national
public network" [*], compares the existing mess in the current state of
the art at cataloging and describing the services available on the
net today as "like a giant library with no card catalog".

who is going to provide the moral equivalent of the rand-mcnally road
atlas, the texaco road maps, the aaa trip-tiks?  what we have now is
much more like the old Lincoln Highway, with painted markings on trees
and oral tradition that helps you get through the rough spots on the
road.

efforts by existing commercial internet providers have been mediocre
at best.  none appear to be much interested in mapping out the network
beyond the immediate needs of their customers.  if you consider that
one of the roles of a commercial internet provider is to provide
access to software archives, and then you take a look at the state of
the software archives on uunet.uu.net and uu.psi.com, you see enormous
duplication, strange and hard to understand organizations of files, no
aids in finding materials beyond a cryptic "ls-lR" file, and dozens if
not hundreds of files which are stale and out of date compared with
the One True Version maintained by the author of the documents. [&]
Visiting these places is like reading magazines at a dentist's office,
you know that what you're reading was new once a few weeks or months
ago.

efforts by nsf-funded network information centers have been similarly
muddled and half-useful.  if you read the Merit proposal to NSFnet
closely, you saw plans for GRASP (Grand interface to SPIRES) which was
going to be the ideal delivery mechanism for information about the
NSFnet to users of the net.  Promises promises.  What you do have from
nis.nsf.net is a stale collection of out of date maps [%], a bunch of
traffic measurement aggregate numbers [#], and some newsletters[=].  the work
at nnsc.nsf.net isn't all that much better.  part of the problem is
reliance on volunteered information -- the general approach to network
information gathering appears to be not much more than send out a
survey, wait, tabulate the responses.  very little of this work is
what you would call "pro-active", that's why chapter 3 (archives)
lists just 26 of the over 1000 anonymous FTP sites and mail-based
archive servers available on the net. [?] (Think of it as a road atlas
that shows less than 1 road in 40 and you'll get the right idea.)

that's not to say that there aren't skilled people out there, it's
just that they're generally not supplied with resources adequate to
the task they're facing.  you aren't seeing organizations like ANS,
which seems to be flush with cash and hiring skilled people left and
right, hiring anyone with the archivist skills of a (say) Keith
Peterson.  you aren't seeing innovative applications like "archie", a
union list catalog of FTP sites around the globe, funded as part and
parcel of NSF infrastructure; it's being done in Canada, with no
guarantee to continued existence if it starts to swamp their already
soggy USA-Canada slow link or if they need the machine back. [+] you
don't see nic.ddn.mil hosting the arpanet "list of lists" anymore,
they didn't like the contents so it's gone. [@]  the internet library
guides are run as best they can by individuals, and they're in the
form of long ascii lists of instructions on how to connect rather than
an interactive front-end that would make the connections for you --
not that the technology isn't there, just that no one has a mission
and the resources to provide them. [!]

so what do we end up with?  a very fast net (in spots) with a "savage
user interface" [*].  multi-megabit file transfers, you can get
anything you want in seconds, but no way to find it.  regional
networks spending large amounts of federal dollars on bandwidth but
very little on ways to use it effectively.  a vast, largely uncharted
network, with isolated pockets of understanding here and there, and no
one yet who has appeared with any of the proper incentives and
resources to map it out.

-- 
Edward Vielmetti, MSEN Inc. 	moderator, comp.archives 	emv@msen.com

references for further study:

[*] eff.org:/npn/.  discussion in comp.org.eff.talk.
[@] ftp.nisc.sri.com:/netinfo/interest-groups.
    see also dartcms1.dartmouth.edu:siglists
    and vm1.nodak.edu:listarch:new-list.*
    discussion in bit.listserv.new-list.
[!] vaxb.acs.unt.edu:[.library], also
    nic.cerf.net:/cerfnet/cerfnet_info/internet-catalogs*
    discussion in comp.misc and bit.listserv.pacs-l.
[+] see discussion in comp.archives.admin.  archie information can be
    found in quiche.cs.mcgill.ca:/archie/doc/
[%] in nis.nsf.net:maps.  note that several are as old as 1988.
    no readily apparent newsgroup for discussion.
[#] in nis.nsf.net:stats.
    no readily apparent newsgroup for discussion.
[=] in nis.nsf.net:linklttr.  no convenient way to search through them
    short of downloading the whole set.
[&] for instance, see 
    uunet.uu.net:/sitelists/ (empty)
    uunet.uu.net:/citi-macip/ (CITI has withdrawn this code)
    uu.psi.com:/pub/named.ca (out of date named cache file still shows
			      nic.ddn.mil as root nameserver)
    discussion in comp.archives.admin
[?] nnsc.nsf.net:/resource-guide/chapter.3/.
    note that many entries have not been updated since 1989.
    discussion in comp.archives.admin.

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 11:50:11 GMT
From:      exspes@gdr.bath.ac.uk (P E Smee)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

In article <PCG.91Jun14183028@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>Also, the DARPA was funding a lot of efforts to produce networking
>ARPAnet software for a large variety of machines, software that was,
>thanks to US govmt. practice, freely available.

But not always outside the States -- owing to various 'technology
transfer' regulations, including CoCom.  And, the fairly arbitrary
nature of CoCom means that outside the US, you've got to be a bit
leery of using things which were funded by the US military, since
even if they are available today, they may not be tomorrow.

>The JNT chose unproven, incomplete technology for which there was no
>ready made software, against proven, well established technology for
>which there was a large and growing mass of ready made software.

Except, this 'large mass' of software has some serious deficiencies (as
compared with notional IP specs -- particularly, in terms of subnet
masking.  It also contains many well-known security holes, which may
not have been so important when only real ARPA-approved sites were
netted, but becomes more so as the net becomes more open.  (Anyone
using any of the 'r' commands, or NFS write-mode mounts, is more or
less asking to be hit, among other things.)

Also, the underlying structure of addresses makes address management a
royal pain.  And, in some places (e.g. here) we do not have available,
for cultural reasons, the large mass of student employees which a
typical US University used to handle all this drudgery.  (Mind you, the
ISO NSAP addresses seem to have gone overboard in the other direction.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 14:07:58 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps


in the medium term, this may be helped a bit by the massive effort in
the ietf directory group...

in the longer term, shared file systems with clever chaching and
replication, and shared window systems,
and good navigation tools will be needed too...

shared filesystem technology
will obviate the need for 
(ftp foo.bar; ls; cd dirX)* 
type activity,
but will lead to semi-efficient 
find -print 

shared window systems could lead to very fast combined help desk/bboard 
functionality ... instead of day lonmg exchanges like...
mail fred "where'sA"; 
repl bloggs "in docs/goo.tar.Z" on fiasco.obscureUniversity.ac.uk
repl fred "what do i do with .tar.Z files?

by (pure) cooincidence, we have just been talking about rationalising
ftp (re-)distribution here via AFS...as one example of order out of chaos

the greatest hope is that the library/information service people who
are used to terra-reference searchspaces will go on increasing their
involvement the way they have started (e.g. our UCL/London
librarians just ran a video conference last week over part of the 
internet to talk to some MIT and other librarians)...

jon

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 16:12:42 GMT
From:      clw@MERIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

The Directory Group at MERIT, Chris Weider and Mark Knopper, are starting
to address some of these issues.  I do think that Directory Services are
a good medium term answer, and we're starting to put everything which
fits the X.500 philosophy into X.500....
Chris

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 16:42:50 GMT
From:      jqj@DUFF.UOREGON.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

I think online directory services are only one aspect of the problem that
EMV raised.  I'm not convinced that a global shared file system will help
too much (a shared file system uniting AFS/unix with Novell, Appleshare,
and typical IBM mainframe file systems is still several years away, and
you still need to know how to navigate through that gigantic file
system!), except by improving/regularizing the user interface.  I'm also
not convinced that we should expect the CNI or library folks to rescue us
(unless you believe that the research-library card catalog model is the
right one for dynamic network information).

From my perspective, EMV's important point is that there is no equivalent
of a AAA (or any other national Automobile Association) to provide travel
information services, personalized maps, triptics, towing services, motel
certifications, etc. for normal people (rather than hackers like us). 
Perhaps what we need is a users' group that is tied to international
networking rather than to a particular computer vendor or even to a
particular internet or particular protocol stack.  "American Networking
Association" anyone?

Where should I turn for advice about where I might take my family for its
next network vacation?

Come to think of it, in addition to a AAA analog, perhaps we need an AA
analog too.  "Networkers Anonymous" to help those poor souls who have
become adicted to cyberspace.

[p.s. please note the lack of :-).  I'm more serious than it appears.]

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

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 16:59:06 GMT
From:      messingr@KODAK.COM (Rich Messinger x24361 B83, Rm 1146, RL, 02203)
To:        comp.protocols.tcp-ip
Subject:   Where is source for CMU TCP for VAX

Hi Netlanders,
	I have a person here in Kodak that has an old version of the CMU-TCP
	for the VAX and would like to know if there is a place to get the
	lastest and greatest off of the Internet via anonymous FTP.

	Can anyone help me help him.
	You can send replaies directly to me and I will collect answers 
	for the whole network.

Rich Messinger
Eastman Kodak

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 17:05:33 GMT
From:      fyang@nysnet.nys.GOV (Frank Yang)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT TCP/IP WIN/3B Help Needed !

In article <1991Jun13.232406.21723@ohsu.edu>, kozowski@ohsu.edu (Eric Kozowski) writes:
> In article <538@nysnet.nys.GOV> fyang@nysnet.nys.GOV (Frank Yang) writes:
> >Hi NetExperts :
> >   I'm a novice on TCP/IP. Forgive me if this is an inappropriate posting.
> >   We installed AT&T TCP/IP Win/3b on our ATT 3B2 machine running on StarLan 
> >10 NAU. But we have problem when we run netstart to start up the program. The
> >error messages look like this :
> >
> >unknown host nysnet
> >can't determine my internet address/usr/etc/inetinit: config line #13: Failed to
> > link netstart failed.
> >
> >   "nysnet" is our machine's official host name.
> 
> Add an entry in the /etc/hosts file for nysnet.

I did, but it won't let me do it. Win/3B replied : 

   Name nysnet already exists

  ( I did this from win3bmgmt -> addhost menu. )

At this time, /etc/hosts file only has its original entry :
 
   127.1  me  loopback localhost

Then I directly used vi to add a nysnet entry to /etc/hosts file, I still got
an error message ( can't remember what it was ) from inetinit.

Could anyone help me out of this ?
Thanks !


Frank Yang.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 17:35:46 GMT
From:      bjork@NISC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Where to get the list-of-lists


You can send a message to mail-server@nisc.sri.com with a line

send netinfo/interest-groups

...in the message body. This will return the seven hundred thousand
character file to you in itty bitty pieces.

You can also use anonymous FTP via ftp.nisc.sri.com, directory
netinfo, file interest-groups.

--Steven

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 19:00:34 GMT
From:      kent@BBN.COM (Steve Kent)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

Larry,

	A few comments in response to our recent message about PEM and
what facilities it provides:

	- PEM operates in conjunction with SMTP and RFC 822 mail.  It
is compatible with both and thus can be used to protect any RFC 822
message that can be sent via SMTP mail relays.  Use of PEM is strictly
voluntary; only Internet users who want the security services of PEM
are expected to make use of it and, as you observed, it takes two to
tango.

	- Your description of PEM security services and mechanisms was
a bit short and not quite accurate.  PEM uses DES, not RSA, to encrypt
messages, but encryption is optional.  PEM uses computes a message
integrity check (MIC) on each message and encrypts it to provide
message integrity and authenticity.  The integrity and authentication
functions are not optional, i.e., they are always employed.  The
version of PEM that we expect to be widely used employs RSA keys both
to encrypt the MIC (for authenticity, integrity and a basis for
non-repudiation) and to encrypt the DES key in support of
confidentiality (secrecy).  A key management infrastructure, based on
the CCITT/ISO Directory authentication standards (X.509) is used by
PEM to support distribution of the RSA keys.

	- A sender of a PEM-protected message can ensure that the
message content is decipherable only by the intended recipients and
that each recipient can verify the message inetgrity and the sender
ID.  PEM does not address directly more subtle confidentiality issues,
e.g., traffic analysis, though "double-enveloping" can be employed to
mitigate this threat as well.

	I hope this clarifies the issue of "what PEM does."  As for
timing, those of use working on the PEM standards are behind schedule,
as noted.  Three RFCs were issued almost 2 years ago and we are now
trying to get revised standards out this summer.  Several independent
implementations of PEM are now undergoing testing on the Internet and
arrangements for the key management infrastructure are progressing.
The latter work includes a numer of activities, e.g., license
agreements with RSA to enable a PEM freeware implementation to be made
available and interoperable with product-level PEM implementations in
the Internet.  The bottom line on RSA licenses for PEM is that they
are expected to be quite cheap, as little $2.50 per-user (maybe even
less for students), if the keys are locally managed (by the school,
company, or whatever organization with which the user is affiliated).

	I recommed you review the existing RFCs (1113-1115), or the
Internet-Drafts which will replace them, for more info on PEM.

Steve Kent
Chair
Internet Privacy and Security Research Group

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 22:21:24 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   well-behaved firewalls

When a gateway is configured as a firewall, what is the polite thing
to do about those packets that aren't passed?  The packet itself
should be dropped on the floor, but should the originating system be
told anything about it?

Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is
blocked.  Should the gateway return a Host Unreachable in response to
a telnet request?  Or maybe only a Port Unreachable or Protocol
Unreachable, which would leave the originator wondering what other
ports might be reachable or which protocols might be passed?  RFC792
says that the destination host may send the Unreachable message back
to the source host, but implies that only a host may send a Port or
Protocol unreachable.  Should the firewall, since it's assuming the
filtering responsibility, also assume responsibility for the ICMP
returns?

RFC1009 doesn't seem to address this area except to suggest in 4.4
that address filters be supported, so I must rely on precedent for
protocol filter behavior.  What is polite?  What is common?

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 91 22:44:51 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

On 17 Jun 91 11:50:11 GMT, exspes@gdr.bath.ac.uk (P E Smee) said:

exspes> In article <PCG.91Jun14183028@aberdb.aber.ac.uk> pcg@aber.ac.uk
exspes> (Piercarlo Grandi) writes:

pcg> Also, the DARPA was funding a lot of efforts to produce networking
pcg> ARPAnet software for a large variety of machines, software that was,
pcg> thanks to US govmt. practice, freely available.

exspes> But not always outside the States -- owing to various 'technology
exspes> transfer' regulations, including CoCom. [ ... even staunch
expses> allies like the UK have to be wary of crazy USA export controls
expses> ... ]

Agreed. But this does not mean then that JNT had to choose something
completely different and incompatible and build everything from the
ground up.  It could have meant that JNT could have taken what was on
offer (a lot!) as to implementations and start from the publicly
available standards to duplicate what was not.

Frankly, to everybody but a PTT, the DARPA is a far more "open" body
than the CCITT. For example anbybody can submit cheaply and have a quick
"approval" for an RFC, if it is useful. No red tape, no colossal
expenses.

pcg> The JNT chose unproven, incomplete technology for which there was
pcg> no ready made software, against proven, well established technology
pcg> for which there was a large and growing mass of ready made
pcg> software.

exspes> Except, this 'large mass' of software has some serious deficiencies

I would object to 'serious', it is a classic english understatement; I
would say 'catastrophic'.

There are not that many major sw/hw components in widespread use today
which do not have *catastrophic* shortcomings.  SunOS, SysV3.2, MSDOS,
NFS, X11, ...  choose your favourite abomination (not to mention ASN.1,
X.400, the plethora of ridiculously incompatible TPs, ...).

TCP/IP and company, for all their failings (my favourite one is
watermark acknowledgement in TCP/IP) and limitations (no really good
internetwork gateway or routing protocols) is not one of the worst, and
it is lightweight and efficient, at least compared to ISO/OSI.

exspes> (as compared with notional IP specs -- particularly, in terms of
exspes> subnet masking.

The problem with subnet masking is that it is basically a hack; it could
well be a clean hack, but very few people actually understand
subnetting. Too bad.

exspes> It also contains many well-known security holes, [ ... ] Also,
exspes> the underlying structure of addresses makes address management a
exspes> royal pain.

Just flies in the ointment. The comparison the JNT had before themselves
was between a working viable fairly suboptimal system of specifications
and implementations and an incomplete paper design, which could have
been conceivably optimally designed and implemented (it wasn't...), but
nobody could have been sure.

*IF* ISO/OSI had been completely designed then, *IF* the design had been
problem free, *IF* implementations had been freely available, then maybe
it could have made sense for the UK to ignore a dozen years of ARPAnet
experience and easy connectivity with the largest (and at the time the
only one) research network in the world and live in splendid isolation.

But all those *IF*s were not true at the time, only very prejudiced
people could not see it, and are still not true now, and even if they
were, that is even *IF* ISO/OSI were distinctly better than ARPAnet as
to technical quality and availability, it would still make more sense to
have connectivity, and live with good enough.

exspes> And, in some places (e.g. here) we do not have available, for
exspes> cultural reasons, the large mass of student employees which a
exspes> typical US University used to handle all this drudgery.  (Mind
exspes> you, the ISO NSAP addresses seem to have gone overboard in the
exspes> other direction.

Here the culprit is not really TCP/IP, but UNIX. UNIX, which was
designed assumign that Thompson & Ritchie were the system managers.
TCP/IP is really a minor nuisance, and there are decent tools out there
to relieve a lot of the problems.

As I said we are stuck with abominable sw all around us; yet we still
muddle thru.

For a lot of this the UK academic environment is guilty of many sins of
omission; the quality of much UK sw research has been, especially in the
sixties and the seventies, much higher than that of now popular USA
equivalents, but the stubborn persistence with which the UK research has
been kept well "hidden" has been a disgrace. Just compare MUSS with
Unix...
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 00:35:28 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 931 "Not Recommended" (Re: Authenticated SMTP, anyone done one?)

In article <STJOHNS.91Jun16205511@umd5.umd.edu> stjohns@umd5.umd.edu (Mike St. Johns) writes:
> In article <6201.Jun1504.10.2091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>    it does make some sense that Party babies should get ahead... :-) )
> Speaking as both the author of RFC931 and a charter member of the
> IETF... AND as a member of the Security Area Advisory Group of the IETF...

Da, Comrade, I am suitably impressed vit your qualifikations. You zhould
be nominated for ze Central Kommittee tomorrow mornink.

(I was kidding, Mike...)

> The
> functionality of RFC931 was very limited and in any case has been
> subsumed by two other very good protocols - KERBEROS and SNMP.

I have nothing against Kerberos. I think it's a good start; I even wrote
some code for Kerberos v5. But the current implementation simply cannot
be used to authenticate, e.g., mail between nyu.edu and umd.edu, at
least not without a lot of work. Surely you want some authentication
outside your local network?

I just heard about SNMP's proposed security mechanism. I don't like it.
It's ridiculously vulnerable to known-plaintext, even chosen-plaintext
attacks, especially given the stylized format of SNMP output. And it
still won't help you outside your local network unless you've exchanged
a whole bunch of keys in advance.

I agree that RFC 931 doesn't do a whole lot. It just provides usernames.
But that's enough to stop what is by far the most common type of mail
forgery.

> Admittedly, SNMP does not have the MIB variables written to extract
> 931 data, but the mechanism is there.

But the implementation is not. Any knowledgeable BSD sysadmin can ftp
the RFC 931 server source from stealth.acf.nyu.edu in five minutes,
compile and install it in ten, and (if he already has sendmail source)
add sendmail authentication in five more. If it takes more than five
minutes to repeat the whole job on the next several machines, I'll eat
my hat. There's only one known incompatibility: Sun gratuitously changed
some things in SunOS 4.1.1, so you have to change NETSTATREMOTE to 53 in
my source under that system. That's it.

How long does it take you, right now, to achieve the same security
through SNMP or Kerberos? Hmmm?

> If you have a revision, submit it now as an internet draft - send it
> to Steve Crocker - Security Area Directory for the IETF
> (crocker@tis.com).

Okay, I'll continue this via e-mail.

>    > How seriously should people take the suggestion that experimental
>    > protocols should not be implemented without coordination with their
>    > developers?
>    Answer 1: You mean someone takes that seriously? Uh-oh.
> Please take this seriously - its given us great benefits in the past.

C'mon, where's your sense of humor? We're only discussing one
implementation anyway, and I did talk about it with you beforehand.

> Its gratifying to see that someone actually reads the old RFC's, and I
> appreciate all the work Dan has put into his implementation, but if I
> could put a stake through the heart of 931, I would do it - its just
> too limited.

It completely stops all username forgeries above the TCP level. To break
RFC 931 security means that you have to break TCP security. A typical
user, without a machine of his own and without physical network access,
has no means to do this. Sure, you can get more mileage out of Kerberos,
but where's the Kerberized version of sendmail that I can install later
tonight in my sleep?

Question to all university sysadmins reading this: How many of you have
never watched an undergraduate telnet to your SMTP server and forge a
message? How many of you just don't think this is a problem? How many of
you wouldn't stop these forgeries if a simple software solution were
available?

Well, a simple software solution is available: RFC 931. Sure, in two or
three years you'll have Kerberos, and in a couple more Kerberos might
even work across networks, but don't you want to fix the problem now? My
authd doesn't bite: it won't hurt any legitimate applications, and even
if you never use it it'll only waste the disk space for one small
executable. In the meantime it will raise the ante for mail forgers and
system crackers, help CERT track intruders, and give normal users a way
to write secure networked applications across diverse machines. Isn't
that worth a few minutes of your time?

---Dan

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 03:24:16 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

[I, of course, replied:]

Hi--

The "Open" in OSI was originally touted as being the antithesis of
Proprietary.  "Anybody can do it" sort of thing.  Thus, depending on
your view of the comprehensibility of ISO specs, TCP/IP is arguably
MORE "open" than OSI, and in no meaningful sense less so.  (The
lack of blessing by an international standards organization is both
circular reasoning and, to some, a further argument in TCP/IP's favor
[though rarely in its favour, apparently (just a little Panatlantic
orthographical humo{u}r, there)].)

Assuming you've figured out which side I'm on, I'll touch briefly on
why I'd claim the Colourisers SHOULD have known better: by the late
'70s TCP/IP implementations were running whilst the only thing the
ISORMites had running was their mouths.

(Plus, rudimentary awareness of the pace of the international standards
process should have indicated that it would take quite some time for
OSI to overcome TCP/IP's chronological lead.  Say, at least half-a-dozen
years as of the late '70s.  That it's a dozen and counting by now could not
necessarily have been anticipated, but was at least implicit in some
technoaesthetic critques of the early '80s.)

For more on "ISORMites", and what somebody once called the "electropolitics"
of it all in a review, see M. A. Padlipsky, _The Elements of Networking
Style_, Prentice-Hall, 1985, and--lest I be accused of advertizing--
Marshall Rose, _The Open Book_, Prentice-Hall, 1990.  Although the
conclusions do differ, both books do, in my view, adduce rather
similar evidence about the technoholy wars between what I call the
ARM (ARPANET Reference Model) and the ISORM (ISO Reference Model)
--or, more accurately, between the adherents of the ARM and the ISORM.

cheers, map
-------

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 03:33:13 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Is the Internet usable for wide-area interactive conversations?

Here's the ping data from nyu.edu to berkeley.edu over the last 10
minutes or so. They show a minute of communication, followed by 10
seconds of ``unreachable network'', four minutes of communication, half
a minute of ``unreachable network'', another three minutes of
communication, another half minute of ``unreachable network'', another
two and a half minutes of communication, nine seconds of ``unreachable
network'', and then just over a minute of communication. 

Keep in mind that an active TCP connection---e.g., a remote login---dies
the second that the network becomes unreachable. An objective observer
would have to conclude that, no matter how good the IP service was while
it was responding, the network was simply unusable for interactive work
during this period.

And how good was that IP service? The minimum round trip time was rather
impressive: one sixth of a second. But the maximum (not counting the
unreachable periods) was awful: over ten seconds. The average was over a
second, and the sample standard deviation was a whopping 1.8 seconds.
That means you'd expect one packet in every few hundred to have a delay
of seven seconds or more. Many studies have shown that people work best
with a consistent feedback delay---it's much more important that the
standard deviation be small than that the minimum be small.

Don't try to tell me that four gateways between NYU and Berkeley crashed
in quick succession, only to have our Super Duper Dynamic Routing
Protocols bravely intercede, restoring service within 30 seconds of each
crash in ways that mere mortals could never hope to understand. The
pattern of Berkeley being reachable, then unreachable a moment later,
has continued while I typed this article. I see this behavior all the
time, even on links as short as BNL to NYU.

I see only two possible explanations for these problems. Either the
routes are flapping wildly, losing packets every time a router decides
to ``optimize'' its choices, or sudden bursts of extra activity push the
``optimal'' route over the edge of its maximum load. Can anyone propose
another explanation? No matter what the reasons, the Internet is simply
not usable for interactive work coast-to-coast during times like this.

Both problems, by the way, are easy to fix. To solve the second, split
data among three or four usable routes, instead of loading it all onto
one which will crash at the first increase in load. To solve the first,
use semi-static routing---update routing tables every few days instead
of every few minutes, so that (as control theory experts will observe)
routing changes are too slow to hit a resonant frequency of any link.

---Dan

PING berkeley.edu (128.32.133.1): 56 data bytes
64 bytes from 128.32.133.1: icmp_seq=64. time=779. ms
64 bytes from 128.32.133.1: icmp_seq=65. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=66. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=67. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=68. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=69. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=70. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=72. time=4649. ms
64 bytes from 128.32.133.1: icmp_seq=73. time=4069. ms
64 bytes from 128.32.133.1: icmp_seq=74. time=3229. ms
64 bytes from 128.32.133.1: icmp_seq=75. time=3149. ms
64 bytes from 128.32.133.1: icmp_seq=76. time=3369. ms
64 bytes from 128.32.133.1: icmp_seq=77. time=2610. ms
64 bytes from 128.32.133.1: icmp_seq=78. time=1850. ms
64 bytes from 128.32.133.1: icmp_seq=79. time=1080. ms
64 bytes from 128.32.133.1: icmp_seq=80. time=719. ms
64 bytes from 128.32.133.1: icmp_seq=81. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=82. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=83. time=7079. ms
64 bytes from 128.32.133.1: icmp_seq=84. time=6079. ms
64 bytes from 128.32.133.1: icmp_seq=85. time=5109. ms
64 bytes from 128.32.133.1: icmp_seq=86. time=4239. ms
64 bytes from 128.32.133.1: icmp_seq=87. time=3299. ms
64 bytes from 128.32.133.1: icmp_seq=88. time=2299. ms
64 bytes from 128.32.133.1: icmp_seq=90. time=400. ms
64 bytes from 128.32.133.1: icmp_seq=91. time=2209. ms
64 bytes from 128.32.133.1: icmp_seq=92. time=2879. ms
64 bytes from 128.32.133.1: icmp_seq=93. time=1890. ms
64 bytes from 128.32.133.1: icmp_seq=94. time=1140. ms
64 bytes from 128.32.133.1: icmp_seq=95. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=96. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=97. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=98. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=99. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=100. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=101. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=102. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=103. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=104. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=105. time=330. ms
64 bytes from 128.32.133.1: icmp_seq=106. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=107. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=108. time=249. ms
64 bytes from 128.32.133.1: icmp_seq=109. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=110. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=111. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=112. time=299. ms
64 bytes from 128.32.133.1: icmp_seq=113. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=115. time=5469. ms
64 bytes from 128.32.133.1: icmp_seq=116. time=4479. ms
64 bytes from 128.32.133.1: icmp_seq=117. time=3599. ms
64 bytes from 128.32.133.1: icmp_seq=118. time=2609. ms
64 bytes from 128.32.133.1: icmp_seq=120. time=829. ms
64 bytes from 128.32.133.1: icmp_seq=121. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=122. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=123. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=124. time=209. ms
64 bytes from 128.32.133.1: icmp_seq=125. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=126. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=127. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=128. time=179. ms
64 bytes from 128.32.133.1: icmp_seq=129. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=130. time=230. ms
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
64 bytes from 128.32.133.1: icmp_seq=141. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=142. time=330. ms
64 bytes from 128.32.133.1: icmp_seq=143. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=144. time=159. ms
64 bytes from 128.32.133.1: icmp_seq=145. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=146. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=159. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=160. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=161. time=420. ms
64 bytes from 128.32.133.1: icmp_seq=162. time=500. ms
64 bytes from 128.32.133.1: icmp_seq=176. time=279. ms
64 bytes from 128.32.133.1: icmp_seq=175. time=1279. ms
64 bytes from 128.32.133.1: icmp_seq=177. time=460. ms
64 bytes from 128.32.133.1: icmp_seq=178. time=610. ms
64 bytes from 128.32.133.1: icmp_seq=179. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=180. time=179. ms
64 bytes from 128.32.133.1: icmp_seq=181. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=182. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=183. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=184. time=229. ms
64 bytes from 128.32.133.1: icmp_seq=185. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=186. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=187. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=188. time=419. ms
64 bytes from 128.32.133.1: icmp_seq=189. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=190. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=191. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=192. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=203. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=204. time=410. ms
64 bytes from 128.32.133.1: icmp_seq=205. time=710. ms
64 bytes from 128.32.133.1: icmp_seq=206. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=207. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=208. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=209. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=210. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=211. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=212. time=530. ms
64 bytes from 128.32.133.1: icmp_seq=213. time=500. ms
64 bytes from 128.32.133.1: icmp_seq=214. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=215. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=216. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=217. time=410. ms
64 bytes from 128.32.133.1: icmp_seq=218. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=219. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=220. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=221. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=222. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=255. time=8839. ms
64 bytes from 128.32.133.1: icmp_seq=259. time=4840. ms
64 bytes from 128.32.133.1: icmp_seq=260. time=4120. ms
64 bytes from 128.32.133.1: icmp_seq=264. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=256. time=8500. ms
64 bytes from 128.32.133.1: icmp_seq=261. time=3500. ms
64 bytes from 128.32.133.1: icmp_seq=262. time=2510. ms
64 bytes from 128.32.133.1: icmp_seq=257. time=7510. ms
64 bytes from 128.32.133.1: icmp_seq=258. time=6510. ms
64 bytes from 128.32.133.1: icmp_seq=263. time=1500. ms
64 bytes from 128.32.133.1: icmp_seq=265. time=8719. ms
64 bytes from 128.32.133.1: icmp_seq=266. time=7739. ms
64 bytes from 128.32.133.1: icmp_seq=268. time=5779. ms
64 bytes from 128.32.133.1: icmp_seq=270. time=3779. ms
64 bytes from 128.32.133.1: icmp_seq=271. time=2849. ms
64 bytes from 128.32.133.1: icmp_seq=272. time=1850. ms
64 bytes from 128.32.133.1: icmp_seq=273. time=1330. ms
64 bytes from 128.32.133.1: icmp_seq=274. time=510. ms
64 bytes from 128.32.133.1: icmp_seq=275. time=570. ms
64 bytes from 128.32.133.1: icmp_seq=276. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=277. time=580. ms
64 bytes from 128.32.133.1: icmp_seq=278. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=279. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=280. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=281. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=282. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=283. time=510. ms
64 bytes from 128.32.133.1: icmp_seq=284. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=285. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=286. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=287. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=288. time=440. ms
64 bytes from 128.32.133.1: icmp_seq=289. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=290. time=540. ms
64 bytes from 128.32.133.1: icmp_seq=291. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=292. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=293. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=294. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=295. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=296. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=297. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=298. time=2390. ms
64 bytes from 128.32.133.1: icmp_seq=301. time=8849. ms
64 bytes from 128.32.133.1: icmp_seq=307. time=5229. ms
64 bytes from 128.32.133.1: icmp_seq=308. time=6680. ms
64 bytes from 128.32.133.1: icmp_seq=309. time=5720. ms
64 bytes from 128.32.133.1: icmp_seq=310. time=4720. ms
64 bytes from 128.32.133.1: icmp_seq=312. time=4110. ms
64 bytes from 128.32.133.1: icmp_seq=314. time=2140. ms
64 bytes from 128.32.133.1: icmp_seq=315. time=1350. ms
64 bytes from 128.32.133.1: icmp_seq=316. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=320. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=321. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=327. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=328. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=329. time=1030. ms
64 bytes from 128.32.133.1: icmp_seq=330. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=331. time=440. ms
64 bytes from 128.32.133.1: icmp_seq=332. time=470. ms
64 bytes from 128.32.133.1: icmp_seq=333. time=910. ms
64 bytes from 128.32.133.1: icmp_seq=334. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=335. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=336. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=337. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=338. time=1010. ms
64 bytes from 128.32.133.1: icmp_seq=339. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=340. time=580. ms
64 bytes from 128.32.133.1: icmp_seq=351. time=320. ms
64 bytes from 128.32.133.1: icmp_seq=352. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=353. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=354. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=355. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=356. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=357. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=358. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=359. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=360. time=400. ms
64 bytes from 128.32.133.1: icmp_seq=361. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=362. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=363. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=364. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=365. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=366. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=367. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=368. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=369. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=370. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=371. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=372. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=373. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=374. time=450. ms
64 bytes from 128.32.133.1: icmp_seq=375. time=3580. ms
64 bytes from 128.32.133.1: icmp_seq=376. time=5750. ms
64 bytes from 128.32.133.1: icmp_seq=377. time=4770. ms
64 bytes from 128.32.133.1: icmp_seq=378. time=3770. ms
64 bytes from 128.32.133.1: icmp_seq=379. time=3460. ms
64 bytes from 128.32.133.1: icmp_seq=380. time=2460. ms
64 bytes from 128.32.133.1: icmp_seq=382. time=580. ms
64 bytes from 128.32.133.1: icmp_seq=383. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=384. time=1820. ms
64 bytes from 128.32.133.1: icmp_seq=385. time=990. ms
64 bytes from 128.32.133.1: icmp_seq=386. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=387. time=8060. ms
64 bytes from 128.32.133.1: icmp_seq=388. time=7470. ms
64 bytes from 128.32.133.1: icmp_seq=389. time=6480. ms
64 bytes from 128.32.133.1: icmp_seq=390. time=5860. ms
64 bytes from 128.32.133.1: icmp_seq=391. time=5020. ms
64 bytes from 128.32.133.1: icmp_seq=392. time=4020. ms
64 bytes from 128.32.133.1: icmp_seq=393. time=3020. ms
64 bytes from 128.32.133.1: icmp_seq=394. time=2140. ms
64 bytes from 128.32.133.1: icmp_seq=395. time=1150. ms
64 bytes from 128.32.133.1: icmp_seq=396. time=420. ms
64 bytes from 128.32.133.1: icmp_seq=397. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=398. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=399. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=400. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=401. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=402. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=403. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=404. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=405. time=870. ms
64 bytes from 128.32.133.1: icmp_seq=406. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=407. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=408. time=1310. ms
64 bytes from 128.32.133.1: icmp_seq=409. time=610. ms
64 bytes from 128.32.133.1: icmp_seq=410. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=411. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=412. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=413. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=414. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=415. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=416. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=417. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=418. time=1580. ms
64 bytes from 128.32.133.1: icmp_seq=419. time=780. ms
64 bytes from 128.32.133.1: icmp_seq=420. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=421. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=422. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=423. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=424. time=750. ms
64 bytes from 128.32.133.1: icmp_seq=425. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=426. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=427. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=428. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=429. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=430. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=431. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=432. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=433. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=434. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=435. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=436. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=437. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=438. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=439. time=6870. ms
64 bytes from 128.32.133.1: icmp_seq=440. time=6570. ms
64 bytes from 128.32.133.1: icmp_seq=441. time=5580. ms
64 bytes from 128.32.133.1: icmp_seq=442. time=4620. ms
64 bytes from 128.32.133.1: icmp_seq=447. time=970. ms
64 bytes from 128.32.133.1: icmp_seq=448. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=449. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=459. time=4250. ms
64 bytes from 128.32.133.1: icmp_seq=463. time=650. ms
64 bytes from 128.32.133.1: icmp_seq=464. time=4570. ms
64 bytes from 128.32.133.1: icmp_seq=467. time=2590. ms
64 bytes from 128.32.133.1: icmp_seq=470. time=2649. ms
64 bytes from 128.32.133.1: icmp_seq=471. time=3180. ms
64 bytes from 128.32.133.1: icmp_seq=474. time=2389. ms
64 bytes from 128.32.133.1: icmp_seq=477. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=478. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=479. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=481. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=482. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=483. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=487. time=1220. ms
64 bytes from 128.32.133.1: icmp_seq=489. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=490. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=491. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=492. time=330. ms
64 bytes from 128.32.133.1: icmp_seq=493. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=496. time=1410. ms
64 bytes from 128.32.133.1: icmp_seq=497. time=580. ms
64 bytes from 128.32.133.1: icmp_seq=498. time=1579. ms
64 bytes from 128.32.133.1: icmp_seq=499. time=750. ms
64 bytes from 128.32.133.1: icmp_seq=500. time=660. ms
64 bytes from 128.32.133.1: icmp_seq=501. time=640. ms
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
64 bytes from 128.32.133.1: icmp_seq=549. time=960. ms
64 bytes from 128.32.133.1: icmp_seq=555. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=556. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=557. time=720. ms
64 bytes from 128.32.133.1: icmp_seq=558. time=269. ms
64 bytes from 128.32.133.1: icmp_seq=559. time=550. ms
64 bytes from 128.32.133.1: icmp_seq=560. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=561. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=563. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=562. time=1399. ms
64 bytes from 128.32.133.1: icmp_seq=564. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=565. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=566. time=419. ms
64 bytes from 128.32.133.1: icmp_seq=567. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=568. time=610. ms
64 bytes from 128.32.133.1: icmp_seq=569. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=570. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=571. time=640. ms
64 bytes from 128.32.133.1: icmp_seq=572. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=576. time=5789. ms
64 bytes from 128.32.133.1: icmp_seq=582. time=1190. ms
64 bytes from 128.32.133.1: icmp_seq=584. time=660. ms
64 bytes from 128.32.133.1: icmp_seq=585. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=586. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=587. time=440. ms
64 bytes from 128.32.133.1: icmp_seq=588. time=490. ms
64 bytes from 128.32.133.1: icmp_seq=643. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=644. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=645. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=646. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=647. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=648. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=649. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=650. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=651. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=653. time=1869. ms
64 bytes from 128.32.133.1: icmp_seq=655. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=656. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=657. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=658. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=659. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=660. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=661. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=662. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=663. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=664. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=665. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=671. time=1480. ms
64 bytes from 128.32.133.1: icmp_seq=673. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=674. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=675. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=676. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=677. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=678. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=679. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=680. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=681. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=682. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=683. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=684. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=685. time=2229. ms
64 bytes from 128.32.133.1: icmp_seq=688. time=3779. ms
64 bytes from 128.32.133.1: icmp_seq=689. time=3319. ms
64 bytes from 128.32.133.1: icmp_seq=690. time=2480. ms
64 bytes from 128.32.133.1: icmp_seq=691. time=1570. ms
64 bytes from 128.32.133.1: icmp_seq=694. time=3319. ms
64 bytes from 128.32.133.1: icmp_seq=695. time=3009. ms
64 bytes from 128.32.133.1: icmp_seq=696. time=2289. ms
64 bytes from 128.32.133.1: icmp_seq=697. time=1569. ms
64 bytes from 128.32.133.1: icmp_seq=698. time=1000. ms
64 bytes from 128.32.133.1: icmp_seq=699. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=700. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=701. time=259. ms
64 bytes from 128.32.133.1: icmp_seq=702. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=703. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=704. time=6839. ms
64 bytes from 128.32.133.1: icmp_seq=708. time=3389. ms
64 bytes from 128.32.133.1: icmp_seq=709. time=2579. ms
64 bytes from 128.32.133.1: icmp_seq=710. time=1710. ms
64 bytes from 128.32.133.1: icmp_seq=711. time=910. ms
64 bytes from 128.32.133.1: icmp_seq=712. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=713. time=289. ms
64 bytes from 128.32.133.1: icmp_seq=714. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=715. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=716. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=717. time=219. ms
64 bytes from 128.32.133.1: icmp_seq=718. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=719. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=720. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=721. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=722. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=723. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=724. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=725. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=726. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=727. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=728. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=730. time=1340. ms
64 bytes from 128.32.133.1: icmp_seq=731. time=1090. ms
64 bytes from 128.32.133.1: icmp_seq=732. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=733. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=734. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=735. time=330. ms
64 bytes from 128.32.133.1: icmp_seq=736. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=737. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=738. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=739. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=740. time=310. ms
64 bytes from 128.32.133.1: icmp_seq=741. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=742. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=743. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=744. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=745. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=746. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=747. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=748. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=749. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=750. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=751. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=752. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=753. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=754. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=755. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=756. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=757. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=758. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=759. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=760. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=761. time=590. ms
64 bytes from 128.32.133.1: icmp_seq=762. time=4119. ms
64 bytes from 128.32.133.1: icmp_seq=765. time=3829. ms
64 bytes from 128.32.133.1: icmp_seq=766. time=2929. ms
64 bytes from 128.32.133.1: icmp_seq=767. time=1949. ms
64 bytes from 128.32.133.1: icmp_seq=769. time=780. ms
64 bytes from 128.32.133.1: icmp_seq=771. time=3989. ms
64 bytes from 128.32.133.1: icmp_seq=772. time=2989. ms
64 bytes from 128.32.133.1: icmp_seq=776. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=777. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=778. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=779. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=780. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=781. time=1540. ms
64 bytes from 128.32.133.1: icmp_seq=782. time=660. ms
64 bytes from 128.32.133.1: icmp_seq=783. time=460. ms
64 bytes from 128.32.133.1: icmp_seq=784. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=785. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=786. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=787. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=788. time=350. ms
64 bytes from 128.32.133.1: icmp_seq=789. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=790. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=791. time=380. ms
64 bytes from 128.32.133.1: icmp_seq=792. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=793. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=794. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=795. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=796. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=797. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=798. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=799. time=180. ms
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
64 bytes from 128.32.133.1: icmp_seq=830. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=831. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=832. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=833. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=834. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=835. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=836. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=837. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=838. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=844. time=209. ms
64 bytes from 128.32.133.1: icmp_seq=849. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=850. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=913. time=2770. ms
64 bytes from 128.32.133.1: icmp_seq=916. time=4139. ms
64 bytes from 128.32.133.1: icmp_seq=917. time=3159. ms
64 bytes from 128.32.133.1: icmp_seq=918. time=2249. ms
64 bytes from 128.32.133.1: icmp_seq=921. time=4209. ms
64 bytes from 128.32.133.1: icmp_seq=922. time=4179. ms
64 bytes from 128.32.133.1: icmp_seq=923. time=3329. ms
64 bytes from 128.32.133.1: icmp_seq=924. time=2469. ms
64 bytes from 128.32.133.1: icmp_seq=925. time=1490. ms
64 bytes from 128.32.133.1: icmp_seq=926. time=500. ms
64 bytes from 128.32.133.1: icmp_seq=927. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=928. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=929. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=930. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=931. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=932. time=249. ms
64 bytes from 128.32.133.1: icmp_seq=933. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=934. time=7019. ms
64 bytes from 128.32.133.1: icmp_seq=936. time=5209. ms
64 bytes from 128.32.133.1: icmp_seq=937. time=4489. ms
64 bytes from 128.32.133.1: icmp_seq=938. time=3639. ms
64 bytes from 128.32.133.1: icmp_seq=939. time=3069. ms
64 bytes from 128.32.133.1: icmp_seq=941. time=1660. ms
64 bytes from 128.32.133.1: icmp_seq=942. time=1000. ms
64 bytes from 128.32.133.1: icmp_seq=943. time=430. ms
64 bytes from 128.32.133.1: icmp_seq=944. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=945. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=946. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=947. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=948. time=189. ms
64 bytes from 128.32.133.1: icmp_seq=949. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=950. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=951. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=952. time=169. ms
64 bytes from 128.32.133.1: icmp_seq=953. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=954. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=955. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=956. time=209. ms
64 bytes from 128.32.133.1: icmp_seq=959. time=3259. ms
64 bytes from 128.32.133.1: icmp_seq=960. time=2530. ms
64 bytes from 128.32.133.1: icmp_seq=961. time=1670. ms
64 bytes from 128.32.133.1: icmp_seq=963. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=964. time=209. ms
64 bytes from 128.32.133.1: icmp_seq=965. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=967. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=968. time=209. ms
64 bytes from 128.32.133.1: icmp_seq=970. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=971. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=972. time=219. ms
64 bytes from 128.32.133.1: icmp_seq=973. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=974. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=975. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=976. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=977. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1068. time=10509. ms
64 bytes from 128.32.133.1: icmp_seq=1069. time=9569. ms
64 bytes from 128.32.133.1: icmp_seq=1071. time=7639. ms
64 bytes from 128.32.133.1: icmp_seq=1070. time=8709. ms
64 bytes from 128.32.133.1: icmp_seq=1097. time=360. ms
64 bytes from 128.32.133.1: icmp_seq=1098. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=1099. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1100. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=1101. time=320. ms
64 bytes from 128.32.133.1: icmp_seq=1102. time=390. ms
64 bytes from 128.32.133.1: icmp_seq=1103. time=390. ms
64 bytes from 128.32.133.1: icmp_seq=1104. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1105. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1106. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1107. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1113. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1119. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=1120. time=320. ms
64 bytes from 128.32.133.1: icmp_seq=1121. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=1122. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=1123. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1124. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1125. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1126. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1128. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1129. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1130. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1131. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1132. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1133. time=160. ms
64 bytes from 128.32.133.1: icmp_seq=1134. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1135. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1136. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=1137. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=1138. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=1139. time=359. ms
64 bytes from 128.32.133.1: icmp_seq=1140. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=1141. time=1940. ms
64 bytes from 128.32.133.1: icmp_seq=1142. time=3909. ms
64 bytes from 128.32.133.1: icmp_seq=1144. time=5119. ms
64 bytes from 128.32.133.1: icmp_seq=1147. time=2879. ms
64 bytes from 128.32.133.1: icmp_seq=1149. time=1330. ms
64 bytes from 128.32.133.1: icmp_seq=1150. time=660. ms
64 bytes from 128.32.133.1: icmp_seq=1151. time=329. ms
64 bytes from 128.32.133.1: icmp_seq=1152. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=1153. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1154. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1155. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=1158. time=4839. ms
64 bytes from 128.32.133.1: icmp_seq=1163. time=319. ms
64 bytes from 128.32.133.1: icmp_seq=1164. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1165. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1166. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1167. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1168. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1170. time=5809. ms
64 bytes from 128.32.133.1: icmp_seq=1169. time=6819. ms
64 bytes from 128.32.133.1: icmp_seq=1174. time=1809. ms
64 bytes from 128.32.133.1: icmp_seq=1176. time=360. ms
64 bytes from 128.32.133.1: icmp_seq=1177. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=1178. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=1179. time=339. ms
64 bytes from 128.32.133.1: icmp_seq=1180. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1181. time=420. ms
64 bytes from 128.32.133.1: icmp_seq=1182. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=1183. time=259. ms
64 bytes from 128.32.133.1: icmp_seq=1184. time=510. ms
64 bytes from 128.32.133.1: icmp_seq=1185. time=650. ms
64 bytes from 128.32.133.1: icmp_seq=1186. time=5919. ms
64 bytes from 128.32.133.1: icmp_seq=1187. time=6109. ms
64 bytes from 128.32.133.1: icmp_seq=1188. time=5119. ms
64 bytes from 128.32.133.1: icmp_seq=1192. time=3160. ms
64 bytes from 128.32.133.1: icmp_seq=1193. time=2200. ms
64 bytes from 128.32.133.1: icmp_seq=1195. time=839. ms
64 bytes from 128.32.133.1: icmp_seq=1201. time=2110. ms
64 bytes from 128.32.133.1: icmp_seq=1202. time=1140. ms
64 bytes from 128.32.133.1: icmp_seq=1203. time=2129. ms
64 bytes from 128.32.133.1: icmp_seq=1204. time=1170. ms
64 bytes from 128.32.133.1: icmp_seq=1205. time=230. ms
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
ping: wrote berkeley.edu 64 chars, ret=-1
64 bytes from 128.32.133.1: icmp_seq=1215. time=440. ms
64 bytes from 128.32.133.1: icmp_seq=1216. time=330. ms
64 bytes from 128.32.133.1: icmp_seq=1217. time=650. ms
64 bytes from 128.32.133.1: icmp_seq=1218. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1219. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1220. time=4989. ms
64 bytes from 128.32.133.1: icmp_seq=1225. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1226. time=380. ms
64 bytes from 128.32.133.1: icmp_seq=1227. time=660. ms
64 bytes from 128.32.133.1: icmp_seq=1228. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=1229. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=1230. time=400. ms
64 bytes from 128.32.133.1: icmp_seq=1231. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=1234. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=1239. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=1240. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1241. time=340. ms
64 bytes from 128.32.133.1: icmp_seq=1242. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=1243. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1244. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1245. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1246. time=390. ms
64 bytes from 128.32.133.1: icmp_seq=1247. time=400. ms
64 bytes from 128.32.133.1: icmp_seq=1248. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=1249. time=680. ms
64 bytes from 128.32.133.1: icmp_seq=1250. time=759. ms
64 bytes from 128.32.133.1: icmp_seq=1251. time=360. ms
64 bytes from 128.32.133.1: icmp_seq=1252. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1253. time=260. ms
64 bytes from 128.32.133.1: icmp_seq=1254. time=300. ms
64 bytes from 128.32.133.1: icmp_seq=1255. time=370. ms
64 bytes from 128.32.133.1: icmp_seq=1256. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1257. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=1258. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1269. time=6619. ms
64 bytes from 128.32.133.1: icmp_seq=1270. time=5619. ms
64 bytes from 128.32.133.1: icmp_seq=1271. time=4629. ms
64 bytes from 128.32.133.1: icmp_seq=1272. time=5399. ms
64 bytes from 128.32.133.1: icmp_seq=1273. time=4399. ms
64 bytes from 128.32.133.1: icmp_seq=1275. time=2400. ms
64 bytes from 128.32.133.1: icmp_seq=1276. time=1780. ms
64 bytes from 128.32.133.1: icmp_seq=1277. time=3729. ms
64 bytes from 128.32.133.1: icmp_seq=1278. time=4239. ms
64 bytes from 128.32.133.1: icmp_seq=1279. time=3240. ms
64 bytes from 128.32.133.1: icmp_seq=1280. time=2340. ms
64 bytes from 128.32.133.1: icmp_seq=1281. time=1340. ms
64 bytes from 128.32.133.1: icmp_seq=1282. time=709. ms
64 bytes from 128.32.133.1: icmp_seq=1283. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=1284. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1285. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1286. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1287. time=190. ms
64 bytes from 128.32.133.1: icmp_seq=1288. time=880. ms
64 bytes from 128.32.133.1: icmp_seq=1289. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1291. time=250. ms
64 bytes from 128.32.133.1: icmp_seq=1292. time=750. ms
64 bytes from 128.32.133.1: icmp_seq=1293. time=2039. ms
64 bytes from 128.32.133.1: icmp_seq=1294. time=1089. ms
64 bytes from 128.32.133.1: icmp_seq=1295. time=290. ms
64 bytes from 128.32.133.1: icmp_seq=1296. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1297. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1298. time=280. ms
64 bytes from 128.32.133.1: icmp_seq=1299. time=650. ms
64 bytes from 128.32.133.1: icmp_seq=1300. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1301. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1302. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1303. time=200. ms
64 bytes from 128.32.133.1: icmp_seq=1304. time=170. ms
64 bytes from 128.32.133.1: icmp_seq=1305. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=1306. time=359. ms
64 bytes from 128.32.133.1: icmp_seq=1307. time=270. ms
64 bytes from 128.32.133.1: icmp_seq=1308. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=1309. time=180. ms
64 bytes from 128.32.133.1: icmp_seq=1310. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=1311. time=240. ms
64 bytes from 128.32.133.1: icmp_seq=1312. time=220. ms
64 bytes from 128.32.133.1: icmp_seq=1313. time=230. ms
64 bytes from 128.32.133.1: icmp_seq=1314. time=210. ms
64 bytes from 128.32.133.1: icmp_seq=1315. time=190. ms

----berkeley.edu PING Statistics----
1316 packets transmitted, 681 packets received, 48% packet loss
round-trip (ms)  min/avg/max = 159/1106/10509

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 04:03:49 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

In article <9106171612.AA01441@mazatzal.merit.edu> clw@MERIT.EDU writes:

   The Directory Group at MERIT, Chris Weider and Mark Knopper, are starting
   to address some of these issues.  I do think that Directory Services are
   a good medium term answer, and we're starting to put everything which
   fits the X.500 philosophy into X.500....

All due respects, Chris, but X.500 doesn't address many of these
issues at all, and the ones it does sort of fit into can be more
easily addressed with other tools.  

X.500 Directory services assume a neat, structured, hierarchical name
space and a clear line of authority running from the root all the way
to the leaves.  Indeed, most X.500 services in place on the internet
today that work well enough to be useful run off of centrally
organized, centrally verified, and bureaucractically administered
information -- the campus phone book.  For what this is, it's great --
i'm happy that I can finger user@host.edu at any number of sites and
get something back.  But that is of little relevance to the archives
problem.

X.500 services are hard to run -- the technology is big, bulky,
osified.  So the people who are most interested in running it are the
"computer center" folks.  If you look for the innovative, interesting,
and desirable applications that you'd want to find on the net, you'll
see that many of them are being done out in the field in departmental
computing environments or increasingly in small focused private
commercial or non-commercial efforts.  There's not a terribly good
reason for these two groups to communicate, and so most X.500 projects
have much more structure than substance.

X.500 services are directory oriented.  The data in them is relatively
small, of known value, and highly structured.  Information about
archive sources is just about completely counter to these basic
principles.  The amount of information about any particular service
which you'd like to have on hand can be quite considerable; perhaps at
minimum access instructions, but more likely some text describing the
service, who its intended audience is, sample output, etc.  In
addition it would be valuable to keep information on user reactions to
the system close to the official provided directory notice; these
reviews (a la the michelin guide) are often more valuable than the
official propaganda put out by the designer.  To search this mass of
information, you'll want something much more expressive than the
relatively pitiful X.500 directory access tools -- full text
searching, at the very minimum, with a way to sensibly deal both with
structured data and with more fuzzy matches on "similar" items.

X.500 is a holy grail, there's a lot of money which seems to be being
thrown at it these days in the hope to make it useful.  Good luck, I
wish you well.  But please, don't try to cram all the world's data
into it, because it doesn't all fit.  It's a shame that equivalent
amounts of effort aren't being spent on developing other protocols
more suited to the task. I'm thinking in particular of the Z39.50
implementation in WAIS [*] which holds a lot of potential for
providing a reasonable structure for searching and sifting through
databases which have rich textual information.  Perhaps it's just as
well that federal subsidy hasn't intruded here and clouded people's
judgments on the applicability of a particular technology to a
certain task.

-- 
Edward Vielmetti, MSEN Inc. 	moderator, comp.archives 	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"


[*] think.com:/public/wais/,
    also quake.think.com:/pub/wais/

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 04:16:26 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?

kent@BBN.COM (Steve Kent) writes:

> ..... ....... ....... ....... ....... ......  Several independent
>implementations of PEM are now undergoing testing on the Internet and
>arrangements for the key management infrastructure are progressing.
>The latter work includes a numer of activities, e.g., license
>agreements with RSA to enable a PEM freeware implementation to be made
>available and interoperable with product-level PEM implementations in
>the Internet.  The bottom line on RSA licenses for PEM is that they
>are expected to be quite cheap, as little $2.50 per-user (maybe even
>less for students), if the keys are locally managed (by the school,
>company, or whatever organization with which the user is affiliated).

And what arrangements are being made to legalize and manage distribution
of keys in the "Internet-at-large" that lies outside the US, such as the
national and regional networks of Australasia, the Pacific rim, Scandanavia,
Europe, etc etc etc.

Who, if anybody is going to licence and distribute PEM keys to bodies outside
of the RSA patent area? Will PEM capable mailers be embedded into software
distributions such as SunOS and Ultrix and BSD4.4 for export, or will export
versions of the tapes be cut which lack this functionality? 

How does PEM behave when software DES is used? -As it stands, hardware DES
and some libraries for DES usage are not available outside of the US.


	-george

-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 07:47:51 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.dec,comp.sys.hp,comp.unix.xenix.sco
Subject:   8mm or DDS, which is better?


Does anyone know of what advantages 8mm has over DDS tape drives?
Or,  are DDS tape drives a better choice?   

Which has the better tranfer rates?

Which has better search algorithyms to locate files faster for extraction?

Which one is more of a standard?

Which has lower error rates?

etc, etc, etc, etc.

			Thanks,
				Stuart Szabo



-- 
Postal:    Co-Cam Computer Services              |  Stuart Szabo
	   18-22 Trenerry Cr                     |  sgs@rand.mel.cocam.oz.au 
           Abbotsford, VIC 3067                  |  +61 3 412-3411 (voice)      
	   Melbourne,  Australia                 |  +61 3 417-7857 (fax) 

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 08:40:31 GMT
From:      adam@castle.ed.ac.uk (Adam Hamilton)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

In article <PCG.91Jun17234451@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
: Agreed. But this does not mean then that JNT had to choose something
: completely different and incompatible and build everything from the
: ground up.  It could have meant that JNT could have taken what was on
: offer (a lot!) as to implementations and start from the publicly
: available standards to duplicate what was not.
: 
:  The JNT chose unproven, incomplete technology for which there was
:  no ready made software, against proven, well established technology
:  for which there was a large and growing mass of ready made
:  software.
: 
: Just flies in the ointment. The comparison the JNT had before themselves
: was between a working viable fairly suboptimal system of specifications
: and implementations and an incomplete paper design, which could have
: been conceivably optimally designed and implemented (it wasn't...), but
: nobody could have been sure.
: 
: *IF* ISO/OSI had been completely designed then, *IF* the design had been
: problem free, *IF* implementations had been freely available, then maybe
: it could have made sense for the UK to ignore a dozen years of ARPAnet
: experience and easy connectivity with the largest (and at the time the
: only one) research network in the world and live in splendid isolation.

	Most of this is simply wrong.  The choice made by the JNT
was NOT between OSI-on-paper and a basically-working-TCP-IP.  It was between
TCP-IP-on-paper and a basically-working-X25, the only standardised available
protocol of the time.  The decision to target on OSI when available is
hardly one to be criticised; after all, the Internet has stated it will
convert eventually.
	PCG seems to have the timescales all wrong.  As has been
explained to him several times, the Arpanet was NOT running well-proven
software at the time, it did NOT have a dozen years of experience and
it did NOT have a "working viable...system of specifications and
implementations".  The key point he misses is that what makes sense is to
run the same protocols locally as you will have to connect to if you want
to go further afield.  In Europe at that time that meant X25.
	Next message, he will start to tell us again about how the JNT chose
big-endian domain ordering when little-endian had already been chosen for
TCP/IP (and for viewers who have missed this endless discussion - they didn't.
They simply failed to change their minds some months later when the
opposite decision was made over the pond).

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 09:58:56 GMT
From:      fradin@irisa.fr (Marc Fradin)
To:        comp.protocols.tcp-ip
Subject:   IP source code


Can anyone give me a pointer to public domain IP, ARP, ICMP
source - preferably in 'C'? 

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 13:14:44 GMT
From:      droms@SOL.BUCKNELL.EDU (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

jqj@duff.uoregon.edu (JQ Johnson) writes:

   From my perspective, EMV's important point is that there is no equivalent
   of a AAA (or any other national Automobile Association) to provide travel
   information services, personalized maps, triptics, towing services, motel
   certifications, etc. for normal people (rather than hackers like us). 
   Perhaps what we need is a users' group that is tied to international
   networking rather than to a particular computer vendor or even to a
   particular internet or particular protocol stack.  "American Networking
   Association" anyone?

Might I also suggest a 'Consumers Reports' for the Internet, with
unbiased evaluations of protocol implementations, hardware components,
etc.?  There is a lot of experience and expertise pass around by
word-of-mouth; we could use a more formal delivery system for those
non-networking folks who don`t attend IETF meetings or subscribe to
TCP-IP.

How does all of this tie into the 'The Internet Society'?

- Ralph Droms                 Computer Science Department
  droms@bucknell.edu          323 Dana Engineering
                              Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 13:49:57 GMT
From:      worley@compass.com (Dale Worley)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

In article <EMV.91Jun18000345@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
   X.500 services are directory oriented.  The data in them is relatively
   small, of known value, and highly structured.  Information about
   archive sources is just about completely counter to these basic
   principles.

   X.500 is a holy grail, there's a lot of money which seems to be being
   thrown at it these days in the hope to make it useful.

What can be done to produce good catalogs?  As Ed notes, archive
information is likely to be bulky, chaotic, and of unknown (probably
small) value.  Given how much money is needed to get a directory
system for information without these problems running, it will
probably take much more to get a good system for archive information
working.

Perhaps the analogy to road maps can be a guide -- Roads have been
around for thousands of years, but road maps have only been available
for fifty(?) years.  What happened?  One thing is that it is now
possible to make a map and then sell thousands (hundreds of
thousands?) of copies, thus making each copy reasonably inexpensive.
Until the development of the automobile this was not possible, there
were too few potential users.  (Or even necessary, since a horse cart
is slow enough that stopping to ask directions in each town isn't a
burden.)

One possibility is to make a service that charges you for use.  A good
archive information system should see enough use that each query can
be quite inexpensive.  And the authorization and billing should be
easy enough to automate!

Dale Worley		Compass, Inc.			worley@compass.com
--
Perhaps this excerpt from the pamphlet, "So You've Decided to
Steal Cable" (as featured in a recent episode of _The_Simpsons_)
will help:
	Myth:  Cable piracy is wrong.
	Fact:  Cable companies are big faceless corporations,
		which makes it okay. 

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 14:10:03 GMT
From:      vanbaren@esseye.UUCP (Gerry VanBaren)
To:        comp.sources.wanted,alt.sources.wanted,comp.protocols.tcp-ip
Subject:   Wanted: info on loader-debugger protocol


I am looking for commercial and/or public domain routines for the Loader
Debugger Protocol (RFC 909).  Advice on its suitability and alternatives
are also welcome.

My application has a clone (486) as the host.  It will be programmed in
Microsoft C and we will probably be using FTP Software's link libraries for
TCP/IP support.  The link will be serial (RS-422) running at normal baud rates
but also capable of high baud rates (115200, 1.25Mbaud).  We will probably be
running a custom serial link protocol to minimize overhead in our target
system.  The target system is a 68040 programmed in Ada.

Thanks, Jerry

Mail addresses:
    vanbaren@esseye.si.com
    vanbaren@cpsin.msu.edu

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 14:29:36 GMT
From:      randall@Virginia.EDU (Randall Atkinson)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Authentication & Internet Protocol Suite

In article <STJOHNS.91Jun16205511@umd5.umd.edu>,
 Mike St. Johns  <stjohns@umd5.umd.edu> writes:

% The functionality of RFC931 was very limited and in any case has been
% subsumed by two other very good protocols - KERBEROS and SNMP.

In article <29102.Jun1800.35.2891@kramden.acf.nyu.edu>,
 Dan Bernstein <brnstnd@kramden.acf.nyu.edu> writes:

> I have nothing against Kerberos. I think it's a good start; I even wrote
> some code for Kerberos v5. But the current implementation simply cannot
> be used to authenticate, e.g., mail between nyu.edu and umd.edu, at
> least not without a lot of work. Surely you want some authentication
> outside your local network?
>
> I just heard about SNMP's proposed security mechanism. I don't like it.
> It's ridiculously vulnerable to known-plaintext, even chosen-plaintext
> attacks, especially given the stylized format of SNMP output. And it
> still won't help you outside your local network unless you've exchanged
> a whole bunch of keys in advance.
>
> I agree that RFC 931 doesn't do a whole lot. It just provides usernames.
> But that's enough to stop what is by far the most common type of mail
> forgery.

  I think that the Internet Protocol Suite does need to have viable
authentication mechanisms built in to the protocols (hopefully most
people agree that the current lack of authentication is a problem).  

  I haven't read the new SNMP draft yet, but I have read the Kerberos
documentation.  I think Kerberos does a good job, but I'd like to see
authentication supported by the basic protocols rather than relying
exclusively on Kerberos addons.  Also, key distribution continues to
rear its ugly head (barring the arrival of inexpensive & easily
obtained RSA licenses and keys).

  I've cross-posted this to alt.security because it is clearly of interest
there as well.

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 15:17:46 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

On 17 Jun 91 07:32:13 GMT, igb@fulcrum.bt.co.uk (Ian G Batten) said:

igb> In article <PCG.91Jun14183028@aberdb.aber.ac.uk> pcg@aber.ac.uk
igb> (Piercarlo Grandi) writes:

pcg> On 5 Jun 91 13:39:32 GMT, grahamt@syma.sussex.ac.uk (Graham S Thomas) said:

grahamt> When the Coloured Book software suite was conceived, it was
grahamt> (according to my best information - correct me if I'm wrong) by
grahamt> no means clear that TCP/IP would become as dominant as it has
grahamt> today.

pcg> On this I would disagree. At the time the CB were done, the *only*
pcg> large scale network, especially in the academic sector, was the
pcg> ARPAnet. There were *no* ISO style networks in widespread use, in
pcg> the academic sector.

igb> But were there TCP networks either?  My understanding is that at the
igb> time the CBen were being written, the majority of the ARPAnet was
igb> running NCP.  TCP was certainly not the proven technology that it is
igb> now.

Yes, buit I was really referring to 'ARPAnet technology', quite
explicitly, rather than 'Internet technology'. ARPAnet technology was
indeed working, was proven, and was obviously viable, and with an
obviousn growth path, and was the only technology for WANs at the time.

igb> Remember that TCP was first seriously available in 4.2bsd.  I don't
igb> have an easy feel for when ``most'' Universities would have had
igb> something running 4.2bsd, but I feel certain that the number of
igb> Computer Centres who would have traded their big iron for a 780
igb> running 4.2bsd was vanishingly small.  That may be right or wrong,
igb> but it is a fact.

I agree on the fact, but maybe you miss out that ARPAnet was a Big Iron
type of network. CS departments with BSD minis were a very late
addition, and one that DARPA had to foster by financing the development
of TCP/IP for BSD. But the ARPAnet did not start with VAXes and BSDs;
initially the ARPAnet was a WAN to which dozens of IBM, Honeywell, DEC
mainframes in corporate and Unviersity computer centres were connected.
Cost of connection was high enough that few departments could afford it.

igb> Additionally the PTTs, especially BT, were installing shed-loads of
igb> 8 bit X25.

IMNHO they were try to soft pedal introducing X.25 as much as they
could, and to install the minimal X.25 services thatthey could get away
with, while paying very political lip service to the concept. For an
European PTT x.25 networks were a stupid nuisance, a distraction, and an
opportunity for computer businesses to corner the lucrative services
market while the PTT eked out small money from just carrying the bits
around.

As of now, advanced X.25 technology in Europe gives you 2400 baud
connectivity, just as one example, and international X.25 links are a
few *times* slower and more expensive than a TrailBlazer link. Technical
problems? No, simple ill will. The IP network that has sprouted recently
in Europe puts the PTT run X.25 networks to shame as to bandwidth
supported, cost of traffic, and the velocity with which it has been set
up. And please note that it still has to run on the incredibly
overpriced leased lines that European PTTs deign to offer customers. In
Europe you don't get any cheap T1/T3 style links, nor you can set up
your own microwave network that easily, unless you are a very big
corporation or the military.

igb> IP over X25 was inefficient to put it mildly

Well, one could have taken ARPAnet technology and run their protocols
lock stock and barrel. What we have now *is* indeed IP over X.25, ten
years late, even it is not that inefficient, if done cleverly.

igb> and without a massive Military-Industrial complex (TM) there was no
igb> way that a datagram infrastructure was going to be installed. (**)

The UK does have a military industrial complex, and a relatively big one
(consider the money spent on military research), but one that is very
closed and inward looking. The USA have been luckier in this respect.
For example, whatever the nasty militaristic and corporatist overtones
of the USA military industrial complex, it funds 60-80% of research at
major USA Universities, for example MIT, and in a fairly open way.
Unheard of in the UK.

igb> (*) Did you know the post office still has a class A IP number from the
igb> early days of EPSS?

I did not, actually. Amusing little bit of news.

igb> (**) Unless you had voted SERC out and taken the MOD instead.  Remember
igb> who funded most of US Computer Science through that period?

This is what has happened, I understand. Reading between the lines it is
fairly clear that the military have been leaning quite heavily on the
folks at education and industry to get better connectivity to their
chummy colleagues across the Pond.

Let me guess that since the nice chaps with the Stars and Stripes have
very effective intelligence networks based on Internet technology, the
UK military have found it very useful (Falklands, Kuwait) to be albe to
connect into those.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 15:34:29 GMT
From:      WELDEN@JAGUAR.ESS.HARRIS.COM
To:        comp.protocols.tcp-ip
Subject:   Fwd Error Correct/Data Compress-TCP/IP

I am looking for sources of IP Router products or interface unit components which do Forward Error Correction and Data Compression for TCP/IP internodal trunks.

welden@jaguar.ess.harris.com

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 15:35:11 GMT
From:      liam@dcs.qmw.ac.uk (William Roberts;)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking experiences with FDDI interfaces for Sun's

In <9106041306.AA09116@msr.EPM.ORNL.GOV> dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 
576-2522) writes:

>What kind of experiences (reliability, installability, performance ...)
>have folks had with the FDDI interfaces for Sun.
>This would include Sun FDDI interface, CMC's, others?

The Sun FDDI card basically works. The main interesting things about it are:

1) It breaks the ring when the card is configured down (even if the Sun is 
still powered up). Use it single attached via a concentrator or with an 
optical bypass.

2) It didn't conform to RFC 1188 - puts out ARP requests with hardware type 
code 6 that give problems in a bridged environment. This can (now) be tweaked 
at kernel build time.

3) It gives *no measurable performance increase* for NFS - even with both 
client and server on FDDI and tests which don't involve server disk access 
there is no increase in performance over Ethernet connections.

We have a pair of the CMC cards but we haven't tested them yet. Mail me a 
reminder in a month's time if you don't get any alternative responses.
--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 15:39:48 GMT
From:      GSMILLER@MTUS5.BITNET
To:        comp.protocols.tcp-ip
Subject:   The SunOS version of Talk


 Does anyone have an explicit description of the BSD 'Talk' mechanism?
More specifically, does anyone either have a definition for it, or
can tell me whether the Sun version of Talk differs from the mainstream
BSD version?

 The reason I ask is that I'm attempting to implement a Sun-compatible
'talk'.  Before one can do this, a definition of the protocol is
necessary.  My first thought was to check to see if there was an RFC
covering it.  I checked, and was rather suprised to find that there
wasn't.  Next, I grabbed the BSD sources for 'talk' and 'talkd' from
somewhere (uunet?), and analyzed them.  There seemed to be easily enough
information there for me to work off of (reluctantly) - so I created a
little udp daemon to wait on the talk port - and report what kind of
packets it received.  To my suprise, the packets it received did -not-
match that defined in the BSD source.  (Specifically, I attempted a
talk session from a Sun to my machine - the Sun sent a request to
my machine, checking to see if an invitation awaited it.)  Apparently,
most (if not all) of the same data was there - but mostly in different
places.  Now, before I go trying to reverse-engineer the whole thing -
perhaps someone knows a little about the protocol that they can share?

 Thanks!

 - Greg

 GSMILLER@MTUS5.BITNET
 (gsmiller@mtu.edu)

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 15:45:35 GMT
From:      scottp@se-sd.SanDiego.NCR.COM (Scott Platenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT TCP/IP WIN/3B Help Needed !

In article <538@nysnet.nys.GOV> fyang@nysnet.nys.GOV (Frank Yang) writes:
stuff deleted...
<
<unknown host nysnet
<can't determine internet address/usr/etc/inetinit: config line #13: Failed to
< link netstart failed.
<   "nysnet" is our machine's official host name.
<    As I know, inetinit is started by anentry in the file S86win3b when the
<netstart program is executed. Inetinit looked for a configuration file
</usr/etc/inetinit.cf. 
<   Here is the content of inetinit.cf file :
<# Stream configuration file for win3b as used by inetinit.
<#
<# This is the standard stream configuration for a machine configured with a
<# single Ethernet interface (ni).
<#
<#ifname lowerdev        upperdev     hostname
<#
<en0     /dev/ni/clone0  /dev/arp0       0
<en0     /dev/arp        /dev/ip0        0
				      ^^^^^^^
 With NCR's implementation of WIN-TCP you need to have your host name in
the inetinit.cf file.  Although the ifnames are different between the
implementations, I believe you may want to put 'nysnet' in the hostname
field for the above two entries.  Hope this helps, and I tried mailing this
to you but it bounced.

<   Any suggestion will be appreciated.
<   Thanks !   
<                                                       Frank Yang.

	+-------------------------------------------------------+
	|	   Scott Platenberg, NCR NPD-San Diego		|
	|	   9900 Old Grove Road, San Diego, CA		|
	|	 Scott.Platenberg@se-sd.SanDiego.NCR.com	|
	|	VOICE: (619) 693-5714, VOICEplus: 442-5714	|
	|		    FAX: 619-693-5705			|
	+-------------------------------------------------------+

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 16:21:58 GMT
From:      kdenning@genesis.Naitc.Com (Karl Denninger)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In article <BOB.91Jun17182958@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>When a gateway is configured as a firewall, what is the polite thing
>to do about those packets that aren't passed?  The packet itself
>should be dropped on the floor, but should the originating system be
>told anything about it?
>
>Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is
>blocked.  Should the gateway return a Host Unreachable in response to
>a telnet request?  Or maybe only a Port Unreachable or Protocol
>Unreachable, which would leave the originator wondering what other
>ports might be reachable or which protocols might be passed?  RFC792
>says that the destination host may send the Unreachable message back
>to the source host, but implies that only a host may send a Port or
>Protocol unreachable.  Should the firewall, since it's assuming the
>filtering responsibility, also assume responsibility for the ICMP
>returns?

I return a "host unreachable" for any hosts behind our firewall.  On >all<
protocols and ports.

This is as (from my reading) it should be -- the host IS unreachable.  IF
you're doing SMTP mail, and don't recognize the MX records, you will end up
bouncing the mail.  Then again, if you're doing SMTP, you should know what
an MX record is ;-)

The choice of having all points beyond the firewall unreachable directly was
a policy one here at the company....

--
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.

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 16:45:49 GMT
From:      aris@tabbs.UUCP (Aris Stathakis)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:

>After repeated calls to SCO, which, by the way, has the LONGEST
>queing mechanism I've ever encountered, I have been able to find
>_NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find
>it hard to believe that I can get 16-bit drivers for a simple MS-DOS
>machine but *NOT* for our multi-gigabyte SCO hosts!!!!
 
>Does ANYBODY know of any 16-bit drivers for SCO Unix?
>(WD 8013 preferred)....

Try the Racal-Interlan NI6510.  The drivers are available from Interlan
themselves.  Apparently, some data-comms magazine rated the NI6510 as
the best performing 16bit ethernet card a while back (sorry, can't
quote the exact magazine or date).  I've used them quite a bit and
can safely say that they work pretty well :-)

Aris

-- 
 Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP
-                                                                          -
-    I'd rather have a bottle in front of me, than a frontal lobotomy.     -

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 17:25:11 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

The real solution is to fix telnet and its ilk so that it doesn't kill
the connectionn when it gets what could well be a temporary error like
network unreachable.  It's not at all unusual to get temporary errors
like that whilst rerouting is taking place.
	- Brian

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 17:32:19 GMT
From:      paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

>Keep in mind that an active TCP connection---e.g., a remote login---dies
>the second that the network becomes unreachable. An objective observer
>would have to conclude that, no matter how good the IP service was while
>it was responding, the network was simply unusable for interactive work
>during this period.

You must have an older TCP.  Berkeley TCP ignores net/host unreachables
once the connection is established.

600 lines of ping data is not that informative.  traceroute data before,
during, and after the glitches would help a lot more.  There were also
power outages affecting SURAnet yesterday that may have had an affect.

/pbp
--
Paul Pomes, Computing Services Office
University of Illinois - Urbana
Email to Paul-Pomes@uiuc.edu

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 17:35:11 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <2039.Jun1803.33.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Keep in mind that an active TCP connection---e.g., a remote login---dies
>the second that the network becomes unreachable.

The above statement is only true with certain broken versions of BSD
TCP software.  It is not true on other operating systems; nor is it
true on fixed versions of BSD (you can thank me for nagging NeXT to
fix it).

What happened is that long ago some cretin thought that it was
important to tell user programs about `network unreachable' errors
(which generally are transient) so he made the TCP I/O system calls
fail if it happened.  The problem is that 99.99% of TCP user software
considers a failure of a read() or write() system call to be a hard
failure that necessitates the termination of the program.

The fix is to change the `network unreachable' handling in the kernel
so that it will cause an open() system call to fail, but no-op it for
read() and write().  I believe the Host Requirements RFC mandates
this.  The idea is that `network unreachable' will stop you from
opening a connection in the first place, but won't affect an existing
connection.

A few stubborn individuals continue to insist that every user program
in the world should instead interpret the error code and figure out
from that whether or not it is a hard error, but fortunately they are
in a dwindling minority.

-- DoD#105

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 17:48:52 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?


> 10 minutes of ping data, showing awful results

there is unfortuantely no wide-area newsgroup where reports like this
are welcomed; the party line is that you're supposed to contact your
local network service provider to tell them that something's wrong,
and they are supposed to pass the question up and down the line to
pinpoint the problem.  

there was a recent article in ny.nysernet describing some outages in
nysernet which would have affected the nyu to berkeley connection;
here's a quote.

  We are experiencing intermittent connectivity problems in central
  NY this evening as a result of a combination of router and line
  problems.  The resultant routing fluctuations have made access
  to NSS10 (also in central NY) also intermittent at times.  We have
  dispatched technicians and expect the problems to be cleared by 1am
  (6/18/91).  (from levinn@nisc.psi.net)

as a point of order -- there's no good reason that a temporary
"network unreachable" error should cause a perfectly good TCP
connection to be torn down.  unfortunately i can't quote an RFC on
this point but I think it's in 1122/1123.

--Ed

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 17:59:59 GMT
From:      wex@cs.ULowell.EDU (Paul Wexelblat)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   CDMA

I am looking for pointers to an elementary description of how
CDMA works in practice;  I have seen simple example descriptions,
I have no idea, for example how many chips/bit occur in practice,
whate actual bandwidth is in the real world.

TNX,
	...Wex

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 18:20:34 GMT
From:      scs@iti.org (Steve Simmons)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

worley@compass.com (Dale Worley) writes:

>What can be done to produce good catalogs?  As Ed notes, archive
>information is likely to be bulky, chaotic, and of unknown (probably
>small) value.  Given how much money is needed to get a directory
>system for information without these problems running, it will
>probably take much more to get a good system for archive information
>working.

Arguing with an analogy is silly, but I'm gonna do it . . .  :-)

In the middle ages, maps were often critical trade secrets.  A chart
of waters was worth significantly more than its weight in gold, as
it revealed both what places existed and how to get there and back
safely.  The Portugese managed to keep the "safe route" to Japan
secret for an incredibly long time.

Trivially yours,

Steve
-- 
  "If we don't provide support to our users someone is bound to
   confuse us with Microsoft."
	-- Charles "Chip" Yamasaki

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 18:49:13 GMT
From:      sfb@NCoast.ORG (Stephen F. Bush)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   SNMP Packages/Appl. Mgt./CMOT questions

Hello,

I have some questions about SNMP packages:

(1) HP OpenView vs. Cabletron Spectrum - has anyone used either one and what
    are your opinions about them? Any problems with either product? 
    I'm trying to determine which package to buy.

(1a) Is there any product, such as the above, which handles application
     management?

(2) Does anyone know whether the following devices already do, or will 
    support SNMP?

    Stratacom IPX Switches 	(I believe they plan to)
    Telematics X.25 Nodes
    Octocom Modems
    PCI Pads and Protocol Converters
    Codex Modems
    Memotec Data Compressors
    rOUTAROUNDS
    AT&T WideBand Circuits
    MCI WideBand Circuits
    Telco Services

(3) What ever became of CMOT? Do any agents speak that protocol?


					Thanks,

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 20:10:44 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: Authentication & Internet Protocol Suite

In article <1991Jun18.142936.5962@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes:

>   I haven't read the new SNMP draft yet, but I have read the Kerberos
> documentation.  I think Kerberos does a good job, but I'd like to see
> authentication supported by the basic protocols rather than relying
> exclusively on Kerberos addons.  Also, key distribution continues to
> rear its ugly head (barring the arrival of inexpensive & easily
> obtained RSA licenses and keys).

First, Kerberos does not use RSA encryption. It is entirely based on DES. Since
it is free and keys are private, there is no problem.

The real problem is that Kerberos requires at least one trusted system to hold
ALL keys (the KDC). This means that this system, if breached, can destroy
everything. This system is normally not available from the net, so this is not
as serious as it sounds, as long as you have a "local" KDC.

The problem arises when you want to do Kerberos authentication across the
Internet. Unless you are willing to turn all of your secrets over to a third
party (and I'm not), you must build a table of trusted systems to exchange key
information. While this is not a security problem since you don't ever actually
exchange any of the secrets, it is a problem in that you must maintain a table
containing the access information for every other realm you plan on dealing
with. Also, the security between realms can only be trusted as much as you can
trust the security of the remote KDCs and the information you use to allow
their access to your realm.

I would also question the idea of having protocols do their own authentication.
A uniform system of authentication is one of the cornerstones on which Kerberos
was built. What is needed is attention to providing authentication checking
when protocols are designed. Things like NFS are NOT easy (possible?) to do
this with. The MIT "Kerberized" NFS only does authentication at mount time
since there is no practical way to do this for each access in such a stateless
engine.

The real answer is a public key based authentication system such as the Digital
Equipment "Sphinx" system and the forthcoming DSSA system. The problem of cheap
keys may be well on its way to resolution with the BB&N key meter, analogous
with a posstage meter, for issuing keys.

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.

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 20:46:00 GMT
From:      sl@wimsey.bc.ca (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   uucpd and sco uucico (was Is there such a thing as a uucp daemon?)

In article <1991Jun12.075244.26984@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes:
|> In article <1991Jun11.183342.23051@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes:
|> >In article <1991Jun10.154542.2992@chinacat.unicom.com> I wrote:
|> >>In article <1991Jun9.030935.27196@mp.cs.niu.edu>
|> >>	rickert@mp.cs.niu.edu (Neil Rickert) writes:
|> >>>You need a uucico which is built to first check if
|> >>>its stdin/stdout is a socket.
 
|> The problem now is that with SCO's uucico you can only use the "g" packet level
|> protocol. This is blessed with small packets (64 bytes data) and a small window size
|> (3, can be adb'd up to 7). The end result is truly amazing throughput :-) About 102
|> cps with windowsize of 3 and 170 with windowsize 7.

Some more throughput can be squeezed out of SCO's uucico by hacking the
packetsize up to 128 bytes. On my uucico:

	adb -w uucico
	pkopen+55?w80
	^D

Remember to do this at both ends.

I would have thought it would also work at larger sizes but there must be
some fixed sized buffers because it doesn't.

Ethernet throughput went from about 4000cps to 6000cps. 

My uucp news feed through the PPP went from about 170cps to 230cps.

-- 
Stuart Lynne	Computer Signal Corporation, Canada
		...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca 

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 20:47:08 GMT
From:      carroll@ssc-vax (Jeff Carroll)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

In article <9106171742.AA26647@phloem.uoregon.edu> jqj@DUFF.UOREGON.EDU writes:
>From my perspective, EMV's important point is that there is no equivalent
>of a AAA (or any other national Automobile Association) to provide travel
>information services, personalized maps, triptics, towing services, motel
>certifications, etc. for normal people (rather than hackers like us). 
>Perhaps what we need is a users' group that is tied to international
>networking rather than to a particular computer vendor or even to a
>particular internet or particular protocol stack.  "American Networking
>Association" anyone?

	Yup. Even with distributed file systems there's no way of knowing
_a_priori_ which volumes to mount, or to attempt to mount.

	There's something of a start being made toward this type of service
in the form of servers which provide information on other servers. An 
example which comes to mind is "archie", a server (running at a location
that I haven't yet committed to memory) which serves as a pointer to other
archive sites for various types of code and documentation.

	Before netland becomes tractable to the general public, it will
have to emulate the functionality of a fairly complete videotex system.

	Another problem which will eventually have to be addressed (once
the issue of commercial use of the Internet is put to bed) is protocols
for handling commercial transactions (how to pay your dues to the Network
Association, or make a contribution to FTPers Anonymous).




-- 
Jeff Carroll		carroll@ssc-vax.boeing.com

"...and of their daughters it is written, 'Cursed be he who lies with 
any manner of animal.'" - Talmud

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 21:16:41 GMT
From:      bcn@cs.washington.edu (Clifford Neuman)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: Authentication & Internet Protocol Suite


  From: oberman@ptavv.llnl.gov
  Subject: Re: Authentication & Internet Protocol Suite
  Date: 18 Jun 91 20:10:44 GMT

  The real problem is that Kerberos requires at least one trusted system
  to hold ALL keys (the KDC). 

The trusted system need only hold the keys for local clients and
servers (called a realm).  If the server is compromised, this isolates
the damage to the principals registered in that realm.

  The problem arises when you want to do Kerberos authentication across
  the Internet. [This] is a problem in that you must maintain a table 
  containing the access information for every other realm you plan
  on dealing with.

In version 5, realms can be organized hierarchically.  Thus, you can
often get by maintaining entries for only immediate ancestors and
descendants in the tree.

  Also, the security between realms can only be trusted as much as you
  can trust the security of the remote KDCs and the information you use
  to allow their access to your realm.

But this is true for any system, even public key based systems.  You
are trusting the certification authority for the remote realm to
accurately identify the principal you are communicating with.

  The real answer is a public key based authentication system such as
  the Digital Equipment "Sphinx" system and the forthcoming DSSA system.
  The problem of cheap keys may be well on its way to resolution with
  the BB&N key meter, analogous with a posstage meter, for issuing keys.

The problems that you cite for Kerberos also exist for public-key
based systems.  If the key of the certification authority is
compromised, an attacker can impersonate anyone in the "realm" of that
authority.  Some public key based systems take the certification authority
offline in an attempt to make it more secure.  Once taken offline,
however, the credentials issued by the certification authority have to
be very long lived.  This presents a problem for revocation.
Revocation is dealt with by maintaining revocation lists on online
authentication servers, but these servers then become vulnerable to
attack.

	~ Cliff

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 22:11:56 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

>Efforts by existing commercial internet providers have been mediocre
>at best.  None appear to be much interested in mapping out the network
>beyond the immediate needs of their customers.  If you consider that
>one of the roles of a commercial internet provider is to provide
>access to software archives, and then you take a look at the state of
>the software archives on uunet.uu.net and uu.psi.com,

Ah, but many people do *not* consider provision of software archives to be a
role for a commercial Internet provider.

If I want a reliable transport medium to get bits from *here* to *there*, I
pay a commercial Internet provider. If I want access to software archives, I
find someone in the business (paid or _gratis_) of providing such a service.

I believe it would be a mistake for the government to be expected to provide
anything in the area of software archives or the like, except for giving
away software they possess which was written at taxpayer expense and is
therefore in the public domain. If the keepers of NREN are given the task of
maintaining software archives, they're likely to start looking at what's in
the archives and choosing what they will and will not make available. Do you
really think the government would keep something like the Code Breaker's
Workbench in any archive it maintained? Would it even store references to
archives not under government control where such software might be
maintained?

NREN should be just that - a data highway. If you want the equivalent of a
AAA TripTik, go to the equivalent of AAA and buy it; likewise for
Rand-McNally maps and such.

A more-apt metaphor, by the way, would be something like a Guide to
Roadside America or some other sightseeing or travelling guide. Researching
raw data and deciding what to put in those guides is what you pay for when
you buy one, and those activities require (a) good judgement and (b) some
restraint from censorship, neither of which is a known strength of the US
Government.
--
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

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 22:43:50 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <2039.Jun1803.33.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>And how good was that IP service? The minimum round trip time was rather
>impressive: one sixth of a second. But the maximum (not counting the
>unreachable periods) was awful: over ten seconds. The average was over a
>second, and the sample standard deviation was a whopping 1.8 seconds.

Sounds like a problem at the NYU end.  I tried pinging Berkeley.EDU from
here for a few minutes, and my maximum time is closer to your your minimum.
My times were: minimum 90ms, maximum 370ms, average 120ms.  And we're 18
hops away (7 hops across NEARnet, 7 hops across the NSFnet T3 backbone, and
4 hops across BARRnet and Berkeley's internal network).

I sent one packet every five seconds for ten minutes, and had 5% packet
loss.  I'm now trying a similar test using UDP, to see if I can elicit any
ICMP errors (ping doesn't notice down routes, because we use a default
route for everything outside the TMC local network, and routers don't
generate ICMP errors for ICMP packets).  I ran it for about five minutes
(again, 1/5 hz) without a single error (the UDP implementation I'm using
performs automatic retransmission for query/response protocols, so it would
only signal an error for several lost packets in a row or ICMP errors).

>That means you'd expect one packet in every few hundred to have a delay
>of seven seconds or more. Many studies have shown that people work best
>with a consistent feedback delay---it's much more important that the
>standard deviation be small than that the minimum be small.

I haven't bothered computing the std.dev. of my times.  A casual glance at
them (since I only pinged every five seconds, my sample size is easy to
look at manually) shows that most are in the 100-120ms range.  I think
people can live with that.

>I see this behavior all the
>time, even on links as short as BNL to NYU.

More evidence that the problem is somewhere near NYU.  Other posters have
mentioned that Nysernet has been having problems lately.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 22:48:40 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <1991Jun18.173511.7510@milton.u.washington.edu> mrc@milton.u.washington.edu (Mark Crispin) writes:
>In article <2039.Jun1803.33.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>>Keep in mind that an active TCP connection---e.g., a remote login---dies
>>the second that the network becomes unreachable.
>The above statement is only true with certain broken versions of BSD
>TCP software.  It is not true on other operating systems; nor is it
>true on fixed versions of BSD (you can thank me for nagging NeXT to
>fix it).

Unfortunately, some of the most popular BSD derivatives still have this
bug.  I think it may still be in SunOS.

Also, BSD is not the only system with this bug.  Symbolics Genera also has
it.  And even though the Symbolics error signalling system makes it much
easier for an application to recognize and handle this error gracefully,
none of them seem to.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 91 23:11:29 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Miniumum hardware required to support SLIP connection?

In article <229@eclectic.COM> kovar@eclectic.com (David C. Kovar) writes:
>
>  If one wanted to add dialup SLIP capability to a network, what is
>the minimum set of hardware required? You definitely need a modem,
>Telebit TrailBlazer, for example, but after that ... what? A Cisco
>router will do the trick, but is there anything less expensive?
>Basically, I'd like to be able to attach a modem to the phone line,
>the modem to a piece of hardware, the hardware to the Ethernet, and,
>with a minimum of configuration, be able to dial into that modem and
>establish a SLIP connection. Any suggestions would be most appreciated.
>Thanks, in advance!
>

Well, I think that I'm about as cheap as one can get. I went out and got
dialupip version 2.0 and installed it on several machines (sony running news,
ibm rt running 4.3, and a sun 3 running 3.5). Then I got a Netblazer from
Telebit (prior to my present test-related contract) and two additional modems
(I'd already a rack of them for my vax, of these two were trailblazers).

Now I can a) slip into my office from my sun 3 at home,
	  b) slip from the telebit test lab over to my office,
	  c) assuming I'd scads of routes at home and at my office, rip with
	     the best of them.

Total cost, well let's say I got a very good price. Most of the "cost" was
debugging dialupip2.0. If I'd have had to actually pay for what I've gotten,
I would have, and that would be my host-independent slip|ppp link to the
rest of the world, e.g. a regional or commercial or cooperative carrier.
Oh, at least 9.6 over standard voice lines, 19.2 when PacBell is not under
too much stress. Sync cards at 56Kb would be in next Christmas' stocking.

Eric Brunner
consulting to, not employed by Telebit

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 00:14:11 GMT
From:      ajw@manta.mel.dit.CSIRO.AU (Andrew Waugh)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

In article <EMV.91Jun18000345@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
> X.500 Directory services assume a neat, structured, hierarchical name
> space and a clear line of authority running from the root all the way
> to the leaves.

While this is certainly true, it is important to understand why this is
so. X.500 is intended to support a distributed directory service. It
is assumed that there will be thousands, if not millions, of
repositories of data (DSAs). These will co-operate to provide the
illusion of a single large directory.

The problem with this model is how you return a negative answer in a
timely fashion. Say you ask your local DSA for a piece of information.
If the local DSA holds the information you want, it will return it.
But what if it doesn't hold the information? Well, the DSA could
ask another DSA, but what if this second DSA also doesn't hold the
information? How many DSAs do you contact before you return the
answer "No, that piece of information does not exist"? All of them?

X.500 solves this problem by structuring the stored data hierarchically
and using this heirarchy as the basis for distributing the data
amongst DSAs. Using a straightforward navigation algorithm, a query
for information can always progress towards the DSA which should hold
the information. If the information does not exist that DSA can
authoritatively answer "No such information exists." You don't have to
visit all - or even a large proportion - of the DSAs in the world.

It is important to realise that this is a generic problem with highly
distributed databases. The X.500 designers chose to solve it by
structuring the data. This means that X.500 is suitable for storing
data which can be represented hierarchically and is less suitable
for storing data which cannot. Exactly what data will be suitable for
storing in X.500 is currently an open question - there is simply not
sufficient experience.

The proposed archive database which started this thread will have
exactly the same problem. The solution chosen will, if different to
that X.500 uses, will have problems as well. There is no such thing as
a perfect networking solution!

>X.500 services are hard to run -- the technology is big, bulky,
>osified.  So the people who are most interested in running it are the
>"computer center" folks.  If you look for the innovative, interesting,
>and desirable applications that you'd want to find on the net, you'll
>see that many of them are being done out in the field in departmental
>computing environments or increasingly in small focused private
>commercial or non-commercial efforts.  There's not a terribly good
>reason for these two groups to communicate, and so most X.500 projects
>have much more structure than substance.
>
>X.500 services are directory oriented.  The data in them is relatively
>small, of known value, and highly structured.  Information about
>archive sources is just about completely counter to these basic
>principles.  The amount of information about any particular service
>which you'd like to have on hand can be quite considerable; perhaps at
>minimum access instructions, but more likely some text describing the
>service, who its intended audience is, sample output, etc.  In
>addition it would be valuable to keep information on user reactions to
>the system close to the official provided directory notice; these
>reviews (a la the michelin guide) are often more valuable than the
>official propaganda put out by the designer.  To search this mass of
>information, you'll want something much more expressive than the
>relatively pitiful X.500 directory access tools -- full text
>searching, at the very minimum, with a way to sensibly deal both with
>structured data and with more fuzzy matches on "similar" items.
>
>X.500 is a holy grail, there's a lot of money which seems to be being
>thrown at it these days in the hope to make it useful.  Good luck, I
>wish you well.  But please, don't try to cram all the world's data
>into it, because it doesn't all fit.  It's a shame that equivalent
>amounts of effort aren't being spent on developing other protocols
>more suited to the task. I'm thinking in particular of the Z39.50
>implementation in WAIS [*] which holds a lot of potential for
>providing a reasonable structure for searching and sifting through
>databases which have rich textual information.  Perhaps it's just as
>well that federal subsidy hasn't intruded here and clouded people's
>judgments on the applicability of a particular technology to a
>certain task.

As for the rest of the posting, all I can say is that it must be great
to know so much about the costs and benefits of using X.500.
From my perspective, it is obvious that X.500 will not solve all
the world's problems (nothing ever does :-) but it is way too early
to be so dogmatic.  When we have had
	1) The necessary expericence of implementing X.500, running
	X.500 databases and storing different types of data in such
	a database; and
	2) experience in alternative highly distributed databases.
	(X.500 might prove to be extremely poor for storing certain
	types of data - but the alternatives might be even worse.)
then we can be dogmatic.

andrew waugh

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 01:01:24 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Re: Request for experience with Telebit Netblazer

In article <2517@gold.gvg.tek.com> davew@viper.gvg.tek.com (David White) writes:
>In article <1991Jun13.134237.25324@newshub.ccs.yorku.ca>,
>davecb@nexus.yorku.ca (David Collier-Brown) writes:
>|>
>|>  Anyone have experiecne with the netblazer?  I'm looking at a
>|>possible slip service and/or the very pedestrian use of the terminals
>|>as a dilin gateway to our local network's machines.

See my previous posting to the tcp-ip list for a pedestrian demand dialup
slip connection between my sun at home and my rt's and vax at my office,
as well as to the rest of my clients' sites and the local carriers.

>I am also interested in the Netblazer.  I have seen several requests
>for experiences with this product, but no replies of note.  One of the
>things I am concerned about is the ability of the device to handle
>multiple 38.4 sessions, SLIP, PPP and Telnet and also be able to
>handle routing functions since it is using only a 386SX processor
>(correct me if this has changed).  I believe that you can assign
>a password for each user up to a maximum of X users.  Anyone know
>what the value of X is?

Thanks for the ideas, I'll add this to the multi-line tests. Just for
fun I asked the guys in tech support the value of X. They didn't know so I
took the 222 entries in Telebit's yp password and made up an add user
script... There are now a _lot_ of users listed in addition to the half
dozen that were on one of the units in the test lab. I'll add "find the
value of X" to several of the commands.

>Are there any plans to upgrade the product to support port rates
>of greater than 38.4?

I can't say.

>I would also be interested in any experience with using V.32bis
>modems with this product since Telebit doesn't have one.  What
>types of V.32bis modems have been used and how well do they work
>with the Netblazer?

I don't know. (I didn't know the answer to the previous question but
this way it looks as if I do.)

>If anyone has any other recommendations for a terminal server with full
>modem control on the ports that supports SLIP, PPP, FTP, Telnet, DNS, and
>SNMP, I would be interested in the configurations and performance.

I've always like Annex boxes, but I don't ask as much of them as you appear
to. Ask Chuck or any of the Rutgers guys for real numbers. 

>If anyone has received replies to previous requests for real life
>experiences with the Netblazer, I think it would be valuable if they
>could post a summary of the replies.  Thanks in advance,

OK, OK. I'll write something up over the weekend, whether it comes out as
an applications note or a riviting posting from Tule Network Services
(me inc), or both I seem to be obligated.

Eric
consulting to, not employed by Telebit, and no, I don't speak for them either.

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 02:38:22 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

adam@castle.ed.ac.uk (Adam Hamilton) writes:

>	Next message, he will start to tell us again about how the JNT chose
>big-endian domain ordering when little-endian had already been chosen for
>TCP/IP (and for viewers who have missed this endless discussion - they didn't.
>They simply failed to change their minds some months later when the
>opposite decision was made over the pond).

There are more versions of this story than I care to think about. I see
no reason to believe yours over anybody elses. I suggest somebody who
was present at the JNT sponsored meeting(s) of the time should comment.
Were you? I believe Jim Cragie, John Larmouth or Steve Kille are all
qualified to comment (I doubt if they will by choice, this opens old
and ugly wounds).

I'm not saying you're wrong, I'm just asking that you offer some proof
of correctness for your version.

	-george
-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 02:53:15 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

Instead of complaining about how inappropriate X.500 is for all but the
simplest problems, why don't we identify the problems we're really
trying to solve?

I think that the Internet People Problem---make a *usable* database of
people on the Internet---embodies most, if not all, of the technical and
political difficulties that an archive service has to overcome. You want
to find that vocrpt package? I want to find Don Shearson Jr. You want to
find a SLIP-over-the-phone package? I want to find a SLIP-over-the-phone
expert. You want to know where you got this collection of poems? I want
to know where I got this phone number. You want to see what everyone
thinks of vocrpt now that you've found it? DISCO wants to get references
for Shearson from anyone who's willing to admit he's worked with him.

One advantage of starting from the Internet People Problem is that it
has a lot more prior art than the archive problem, from telephone
directories on up. Once we've solved it we can see how well the same
mechanisms handle data retrieval.

---Dan

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 04:23:09 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <35911@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:
> The real solution is to fix telnet and its ilk so that it doesn't kill
> the connectionn when it gets what could well be a temporary error like
> network unreachable.  It's not at all unusual to get temporary errors
> like that whilst rerouting is taking place.

I agree, that would keep connections alive. Provided, that is, that you
convince Sun (among others) to change this behavior, and replace all the
old machines out there. But you missed my point.

Just because service isn't interrupted doesn't mean it's usable. Folks,
an average of 1 second round trip time, with 1.8 seconds standard
deviation, is just abominable on a route that could easily handle
several times more data with a round trip time under a quarter second.

Let me explain what's really happening on the NYU-Berkeley connection.
On the average there's not too much data on each link: some segments of
the ``optimal'' route are at a mere 50% or 90% capacity, with slightly
sub-``optimal'' routes nearby lying unused. So I see round trip times of
well under a second.

Suddenly a few too many people start ftp requests in the same second.
The ``optimal'' route is quickly overwhelmed, packets die like flies,
and my round trip time goes down the drain. The sub-``optimal'' routes
are still carrying almost no traffic. Our Super Duper Dynamic Routing
Protocols see the disaster and respond, bravely throwing packets to
those no longer suboptimal routes until a permanent lifeline has been
established. In the meantime there's been a service interruption or
delay of several seconds up to a few minutes.

Soon the same thing happens again. Again the route is flooded. Again
service disappears. Again the routers intercede and revert to their
original routing decisions. And so it goes, on and on through the night.

At higher loads, a funny thing happens. The load regularly bursts over
the top of what the current route can handle. Within seconds a router
changes its decisions---but the other end simultaneously comes to the
opposite conclusions. By the time each burst of packets has made its
round trip, the routers have changed their decisions again, feeding
their already obsolete data back into the loop. And so the routes
rapidly flap. Down goes the network.

In the meantime, any dolt can see that the network backbone is
multiply connected. While one route degenerates, several parallel routes
cruise along at 1% or 3% capacity. Sure, they didn't look ``optimal''
five minutes before, because they meant some extra T1 or even 56kb hops.
But if every router simply split its data between the three best routes,
the whole network would be able to handle a far higher load before
*anything* crashed.

A funny thing happens, by the way, when you start using split routes. It
no longer matters much whether you dynamically optimize or not. If your
optimal link goes down, who cares? You're already sending most of your
packets along the three or four slightly suboptimal links. Think of it
as a backup battery system. Not just a backup battery, but a constantly
online backup battery---an uninterruptible power supply, in fact a
supply with three or four big backup batteries that will keep you alive
just as well as the power company.

So there's no point in rushing to react to every little problem. That
way lies inefficiency, route flapping, and madness. You might as well
leave routes constant for a while---a day, say. Just keep track of how
well the routes worked, and the next day adjust the packet flow by a
little bit on each line, making sure never to overload one sensible
route or to ignore another.

I've left out of this story any notes on why NYU-Berkeley was so slow---
why the ``optimal'' routes were so close to capacity that they kept
getting pushed over the edge. Suffice it to say that the entire net,
rather than just isolated pockets, will be seeing similar loads within
two or three years, unless we act now to split packets across every
available line.

---Dan

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 04:30:36 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <1991Jun18.224350.21721@Think.COM> barmar@think.com writes:
> In article <2039.Jun1803.33.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >And how good was that IP service? The minimum round trip time was rather
> >impressive: one sixth of a second. But the maximum (not counting the
> >unreachable periods) was awful: over ten seconds. The average was over a
> >second, and the sample standard deviation was a whopping 1.8 seconds.
> Sounds like a problem at the NYU end.

If it were, I wouldn't be able to get reliable connections from (e.g.)
Princeton to NYU while BNL was getting a consistent ``network
unreachable''. It is within PSI's reach, but this is all beside the
point. Today, the network, with its current routing protocols, cannot
handle the user-generated load between two major sites. Don't you think
this is a problem?

---Dan

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 04:46:23 GMT
From:      oleary@sura.net (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?


Yes, Dan, there are lots of problems on the Internet as far as 
route flaps and gateway crashes and congestion, etc.  but I think
you may have seen a particularly bad instance.  A lot of the 
technology being used is less robust than it needs to be, but
hey, we operations types have to keep our jobs somehow....  :-)

Your message was dated at 3:30 GMT, which is 7:30 EST, right?

That is about when things started to look bad here in College
Park as power to the area was gone and one of the routers
died of heat stroke.  Although our going down shouldn't have affected
NYU to Berkeley much, and we were mostly still up then.  

Script started on Wed Jun 19 00:23:41 1991
% traceroute -g nyu.edu berkeley.edu
traceroute to berkeley.edu (128.32.133.1), 30 hops max, 40 byte packets
 1  sura6 (128.167.1.6)  20 ms  10 ms  0 ms
 2  nss (192.80.214.254)  10 ms  0 ms  10 ms
 3  Ithaca.NY.NSS.NSF.NET (129.140.74.9)  40 ms  30 ms  40 ms
 4  lan.cornell.site.psi.net (192.35.82.1)  50 ms  50 ms  50 ms
 5  cornell.syr.pop.psi.net (128.145.30.1)  90 ms  50 ms  40 ms
 6  albpop.syr.pop.psi.net (128.145.20.2)  60 ms syr.wp.pop.psi.net (128.145.91.1)  70 ms albpop.syr.pop.psi.net (128.145.20.2)  70 ms
 7  wp.nyc.pop.psi.net (128.145.84.1)  50 ms albpop.nyc2.pop.psi.net (128.145.80.1)  80 ms wp.nyc.pop.psi.net (128.145.84.1)  60 ms
 8  nyc_P1.lan.nyc2.pop.psi.net (128.145.218.2)  60 ms  70 ms  70 ms
 9  nyc2.nyu.site.psi.net (128.145.44.2)  90 ms  130 ms  80 ms
10  NYU.EDU (128.122.128.2)  80 ms  330 ms  90 ms
11  NYEGRESS.NYU.EDU (128.122.128.44)  70 ms  70 ms  70 ms
12  nyu.nyc2.pop.psi.net (128.145.44.1)  70 ms  80 ms  70 ms
13  nyc_C1.lan.nyc2.pop.psi.net (128.145.218.1)  150 ms  80 ms  90 ms
14  nyc2.albany.pop.psi.net (128.145.80.2)  90 ms  70 ms  90 ms
15  syrpop.albany.pop.psi.net (128.145.20.1)  120 ms  80 ms  80 ms
16  syr.cornell.site.psi.net (128.145.30.2)  70 ms  70 ms  70 ms
17  NSS.TN.CORNELL.EDU (192.35.82.100)  80 ms  80 ms  140 ms
18  Ann_Arbor.MI.NSS.NSF.NET (129.140.81.10)  240 ms  90 ms  100 ms
19  Salt_Lake_City.UT.NSS.NSF.NET (129.140.79.17)  170 ms  180 ms  400 ms
20  Palo_Alto.CA.NSS.NSF.NET (129.140.77.15)  260 ms  450 ms  240 ms
21  SU1.BARRNET.NET (131.119.254.5)  210 ms  250 ms  200 ms
22  UCB2.BARRNET.NET (131.119.2.4)  250 ms  300 ms  250 ms
23  inr-22-dmz.Berkeley.EDU (128.32.252.22)  240 ms  210 ms  190 ms
24  inr-35.Berkeley.EDU (128.32.168.35)  220 ms  190 ms  200 ms
25  ucbvax.Berkeley.EDU (128.32.133.1)  210 ms  230 ms  230 ms
% 
script done on Wed Jun 19 00:24:12 1991

Wow, this worked a lot better than I expected.  Relatively consistent
results, no packet loss, no route flaps (I am guessing that the albpop/
syr/wp stuff is cisco load balancing?).  Anyway, the NYU-Berkeley path
looks to be in pretty good shape now.

Have fun,

dave o'leary	SURAnet NOC Mgr. 
oleary@sura.net   (301)982-3214

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 04:59:22 GMT
From:      rwskubow@GRAND.WATERLOO.EDU ("Carlos ", the great)
To:        comp.protocols.tcp-ip
Subject:   Re:  IP source code

> From tcp-ip-RELAY@NIC.DDN.MIL Tue Jun 18 20:18:55 1991
> From: mcsun!corton!irisa!fradin@uunet.uu.net  (Marc Fradin)
> Organization: IRISA, Rennes (Fr)
> Subject: IP source code
> Sender: tcp-ip-relay@nic.ddn.mil
> To: tcp-ip@nic.ddn.mil
> 
> 
> Can anyone give me a pointer to public domain IP, ARP, ICMP
> source - preferably in 'C'? 
> 

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 05:22:27 GMT
From:      mo@gizmo.bellcore.com (Michael O'Dell)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: CDMA info

(chomp chomp)

a good start is...

Dixon, Spread Spectrum Communications, 2nd Edition.

good stuff.

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 06:01:10 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.archives.admin,comp.protocols.tcp-ip,comp.misc
Subject:   copyright status and future development of comp.archives


in the near future, postings to comp.archives are going to be tagged
with an explicit copyright notice. [*]  this is a step in the direction of
making this service fully self-supporting, with enough resources
readily available to the project so that I can afford to keep it
going.  as i posted in an article to comp.archives a few months ago,
unless my work on this starts to yield some results, i'm going to stop
distributing my efforts far and wide for free.  free distribution of
comp.archives is currently expected to continue to the end of the
year; if things haven't worked their way out to my satisfaction, i
expect to step down from moderating comp.archives some time not too
long after the winter Usenix meeting.  no specific dates set yet.

there are several very good reasons to stick a copyright notice of
some kind on the materials which i have collected and organized for on
the order of 18 months now.  first and foremost, comp.archives needs
some better publicity and name recognition.  it's somewhat
embarrassing to have people still asking how it's produced, that
there's some sense that it's magic or just automatic processing that's
going on.  explicit copyrights will start to clue people in on just
what it is they are looking at  -- a production not only of some
technology but also of considerable human creative input.  

explicit assertion of copyright will assist me in gaining cooperation
from resource providers who might be interested in producing services
which were derived from my efforts.  these might be on-line searchable
databases, services which offered direct hands-off delivery of
successful searches by anonymous ftp or uucp transfer, caches of
information dynamically updated from comp.archives postings, or paper
or cd-rom products that would incorporate materials derived from
comp.archives.  in addition, it will enable my work to be properly
credited by other researchers who are working on the "resource
discovery" problem; rather than them simply saying "we searched
through netnews for interesting stuff and found a lot of it, so our
search stuff must be pretty good", i would expect proper credit and
attribution and recognition of the substantial progress made thus far.

i expect that in the same timeframe that postings to comp.archives
will also be cross-posted to a new group, with the tentative name
"msen.internet.archives".  MSEN, Inc. will be the publisher of
materials in the msen.* hierarchy; I expect to be doing this for the
benefit of our operations and that of our customers and strategic
partners, and these groups will be fed in accordance with that policy.
I have developed a considerable amount of expertise in this area, and
expect to populate the msen.* hierarchy with interesting, insightful,
and consistently high quality information. 

Some people who really enjoy reading comp.archives right be cut off
from it for some amount of time.  I'm content for that to happen; for
my own needs, I can do all of the filtering and searching and sorting
on netnews and just hoard that knowlege all to myself.  It would be
much easier to do that rather than spend the extra time adding all of
the extra information, verifying that thigs are really there, editing
down really long posting etc.  That's where too much time is spent
right now, and where support from people using that information is
going to help me assess whether it's worthwhile continuing.

If you are currently building any services based on comp.archives
(other than strictly personal use), please contact me and let me know
what your plans are so that we can assure their continued viability on
into 1992.  if you considered building such services and rejected the
notion, let me know what the limitations of the current data stream
are and what you would like to see in the future.

MSEN Inc., if it ever gets sufficiently successful to actually pay any
of its current employees instead of draining their own personal bank
accounts :-(, will be looking for skilled people to fill a position of
Internet Archivist.  (Save your resumes, at the current rate of
progress it's a ways off.)  So far as I can tell, none of the
commercial internet providers as of yet have anyone filling this role;
Cerfnet and ANS has nothing along this line, UUNET's generic title is
"postmaster", and everyone at PSI is working on X.500.  It would make
me quite happy if when we finally got to the point of hiring for this
position, all of the good people had been snapped up; not too likely
as far as I can tell.  I would also be happy to pursue joint
development work with archivists to develop dictionaries or other
classifiction schema and to further the state of the art in searching
and text retrieval systems.

I ran across an estimate that it costs all told $200 to put together a
single complete Library of Congress card catalog entry.  If you look
at the sustained production of about a dozen entries daily in
comp.archives and value it at this at this rate, that's an estimate of
the potential value of this project at about $750,000 to $1M per year.
I believe that MSEN could deliver this service extremely well with
that sort of a budget, that it would be money well spent, and that it
would be best for everyone involved if the end product wasn't burdened
by any nasty copyright nonsense.  Unfortunately, the current "Interim
MSEN" plans don't have a large pile of money falling out of the sky,
and the realities of doing this much work for nothing are starting to
catch up on me.  I hope very much that things will work out well, and
if they don't, well it's been fun.

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

"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."  
							RFC 1216

[*] Pointers to materials available under the GNU Public License will
of course be freely redistributable; MSEN will not assert any
copyright or place any restrictions over their redistribution, and
I'll continue to try to track GNU project announcements even if I give
up free distribution of everything else.

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 08:51:23 GMT
From:      oleary@sura.net (dave o'leary)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <17719.Jun1904.23.0991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <35911@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes:
>> The real solution is to fix telnet and its ilk so that it doesn't kill
>> the connectionn when it gets what could well be a temporary error like
>> network unreachable.  It's not at all unusual to get temporary errors
>> like that whilst rerouting is taking place.
>
>I agree, that would keep connections alive. Provided, that is, that you
>convince Sun (among others) to change this behavior, and replace all the
>old machines out there. But you missed my point.
>
>Just because service isn't interrupted doesn't mean it's usable. Folks,
>an average of 1 second round trip time, with 1.8 seconds standard
>deviation, is just abominable on a route that could easily handle
>several times more data with a round trip time under a quarter second.
>

Do you have stats on the utilization of the lines, the memory on the 
gateways, etc.  I agree that 1000 msec average is pretty unreasonable 
but I'm not sure what the basis for your claim is - what kind of 
latencies do you anticipate through a loaded regional network gateway
for example?

>Let me explain what's really happening on the NYU-Berkeley connection.
>On the average there's not too much data on each link: some segments of
>the ``optimal'' route are at a mere 50% or 90% capacity, with slightly
>sub-``optimal'' routes nearby lying unused. So I see round trip times of
>well under a second.
>

50% utilization on a point to point line sampled less frequently than
every couple of seconds is starting to look like real congestion.  90%
is not pretty.  Queuing delay, retransmissions due to delayed acks,
dropped packets (large swings in buffer allocations) etc.  Life
becomes harsh very rapidly.  If you sample frequently enough, you
can see 100% utilization.  Without context these numbers don't mean
a lot.

>Suddenly a few too many people start ftp requests in the same second.
>The ``optimal'' route is quickly overwhelmed, packets die like flies,
>and my round trip time goes down the drain. The sub-``optimal'' routes
>are still carrying almost no traffic. Our Super Duper Dynamic Routing
>Protocols see the disaster and respond, bravely throwing packets to
>those no longer suboptimal routes until a permanent lifeline has been
>established. In the meantime there's been a service interruption or
>delay of several seconds up to a few minutes.
>

I can only think of one case where something like this would happen
but it would be pretty unusual.  Distance vector protocols don't 
decide whether a link is up or down - they receive that information
from a link level protocol.  The link level protocol doesn't care if
packets are getting thrown away because the router doesn't have any
more buffer space.  So the line stays up, routes remain installed 
in the router's tables, and the "optimal" link is still used.  The
case where this doesn't happen (brief consideration says that this
is applicable to both link state and distance vector protocols) is 
when the packets that are getting thrown away are the routing updates.
However, there are at least a couple of things that prevent this from
being too common - first, typically multiple routing updates have 
to be thrown away before routes time out.  Also, since routing info
flows in the opposite direction from user traffic, the link has to 
be congested in both directions for this to be a problem.  Another
reason, and probably the clincher, is that CPU's can generate routing
updates faster than the interfaces can put packets in the queue.
So if there is a lot of buffer space on an interface, the CPU can 
queue a routing update into that space rapidly, much faster than 
the interface can drain the queue, or another interface could fill
the queue (via the CPU).  Some of this changes with routers that
copy directly between interfaces using a local interface CPU and 
such but this only makes the proposed scenario less probable.

>Soon the same thing happens again. Again the route is flooded. Again
>service disappears. Again the routers intercede and revert to their
>original routing decisions. And so it goes, on and on through the night.
>
>At higher loads, a funny thing happens. The load regularly bursts over
>the top of what the current route can handle. Within seconds a router
>changes its decisions---but the other end simultaneously comes to the
>opposite conclusions. By the time each burst of packets has made its
>round trip, the routers have changed their decisions again, feeding
>their already obsolete data back into the loop. And so the routes
>rapidly flap. Down goes the network.
>
Actually this did happen, in the "old" NSFnet backbone, with the 
Fuzzballs, using Hello as the IGP and DDCMP as the link level 
protocol.  However, in this case, the link level protocol tried to 
be smart, and retransmit frames that were lost due to buffer problems
at the other end.  The fuzzballs didn't have a lot of free memory 
lying around (despite heroic efforts by a certain individual) and 
(I'm trying to remember, this was a while ago when I didn't understand 
this stuff very well :-) so anyway, buffer thrashing resulted and 
route flapping did occur kind of as you describe.  They were 56kb lines,
and trying to cram the load of a busy ethernet down 2 or 3 or these 
slow speed lines was not pretty.  Dave Mills can without doubt 
explain what was breaking much more clearly than I ever could.

>In the meantime, any dolt can see that the network backbone is
>multiply connected. While one route degenerates, several parallel routes 
>cruise along at 1% or 3% capacity. Sure, they didn't look ``optimal'' 
>five minutes before, because they meant some extra T1 or even 56kb hops.  
>But if every router simply split its data between the three best routes, 
>the whole network would be able to handle a far higher load before 
>*anything* crashed.  

How do you determine what is a "parallel route"?  When your routing
protocol works at the network layer (or the IP layer, anyway), your
routers keep routing tables of IP routes and forwarding decisions are
made using the destination IP address.  However, congestion occurs on
links between a pair of routers (I think this is called a subnet in
ISO-ese).  So the router can't really balance across the three best
links - what are the three "best"?  Since you are forwarding *packets*
through the network, rather than streams, you have to keep track of a
lot of stuff - and you can't anticipate what is coming next.  In 
a circuit switching network (i.e. telephone calls) lots of assumptions
are made about the calls that allow the network to do this kind of
"balancing".  

>A funny thing happens, by the way, when you start using split routes. It
>no longer matters much whether you dynamically optimize or not. If your
>optimal link goes down, who cares? You're already sending most of your
>packets along the three or four slightly suboptimal links. Think of it
>as a backup battery system. Not just a backup battery, but a constantly
>online backup battery---an uninterruptible power supply, in fact a
>supply with three or four big backup batteries that will keep you alive
>just as well as the power company.
>
>So there's no point in rushing to react to every little problem. That
>way lies inefficiency, route flapping, and madness. You might as well
>leave routes constant for a while---a day, say. Just keep track of how
>well the routes worked, and the next day adjust the packet flow by a
>little bit on each line, making sure never to overload one sensible
>route or to ignore another.
>

I think I'm missing something here. (of course it is getting a little
late :-( ).  I consider a reaction time on the order of hours to be
engineering decisions, not routing decisions.  This addresses the
problems I started to delineate above, but it isn't clear to me what
you are measuring.  How do you respond to outages?  How do you "keep
track of who well a route worked"?  What is a "sensible route"?  Maybe
you know one when you see one, but can you code that into a routing
protocol?  Congestion on a link occurs on a second by second basis (or
more often in some cases), so correcting things on the order of days
won't really solve the problem.  Although if you are proposing a kind
of dynamic bandwidth allocation...well, that's been thought of too.
Merit was going to do something like that with the IDNX's of the
original "new" NSFnet backbone, late 1988.  I'm not sure what really
came of that, other than instead of trying to reallocate bandwidth
they ended up just adding more everywhere.  

The packet flows are bursty second to second, so if you can handle
the load now, it doesn't mean that you can handle it a second from
now.  But you might be able to handle it all day tomorrow without
dropping anything.  How do you plan for that other than building in 
lots of extra capacity (which just solves the problem anyway)?

>I've left out of this story any notes on why NYU-Berkeley was so slow---
>why the ``optimal'' routes were so close to capacity that they kept
>getting pushed over the edge. Suffice it to say that the entire net,
>rather than just isolated pockets, will be seeing similar loads within
>two or three years, unless we act now to split packets across every
>available line.
>
>---Dan

We *are* splitting traffic across every available line.  Every line
isn't running at the same level of utilization, but when we are 
running RIP we don't really have much of a choice.  OSPF and IGRP
allow the costing of interfaces so that better balance can be 
achieved.  Okay, so we've started to address the problem within
one autonomous system.  Now it's time to cross over into the NSFnet
backbone.  Or maybe the ESnet backbone or Milnet.  Of course, they
are possibly using different IGP's, and we lose all the costing 
information anyway when we cross over from one AS to another.
Is BGP the answer here?  Maybe if we (the network service providers)
can agree on how to assign OSPF costs consistently across different
routing domains.  And on a system to translate between OSPF and 
IGRP metrics (it's starting to look messy....).  

The problems certainly aren't trivial.  And neither are the answers.
Yes, we had better get to work.

dave o'leary	SURAnet NOC Manager
oleary@sura.net       (301)982-3214

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 13:27:19 GMT
From:      garethh@sadss (Gareth Howell )
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting a very large population

garethh@sadss (Gareth Howell ) writes:

> Hi all,
> I wonder if someone can help me with a tricky problem I am trying to come to 
> grips with.
> 
> I have the (un)enviable taks of coming up with an Internet Addressing 
> Strategy for the UK Department of Social Security's internet (note small 
> 'i':-). This comprises (or soon will) 2500+ Ethernet LANs: each with 
> anything from 4-50 PCs, Unix application servers and gateways on them; all 
> interconnected using the Government Data Network (X.25 (1980)). Most of the 
> operational systems use OSI protocols, but there is a significant amount of 
> IP traffic, mainly for SNMP HUB and BRIDGE and host management on the LANs.
> 
I have had a couple of mail replies to this query (thanks guys), but 
unfortunately the advice has been contradictory. On the one hand I have been 
told that this will work if we use OSPF as the routing protocol (provided we 
have variable length subnet masks). On the other hand I have been told that 
this will not work as all subnets of a network must be physically connected. 

The latter was my view as well until I read Comer's book "Internetworking 
with TCPIP". In this (section 16.9) he deals with the situation where a host 
on a non-subnetted network needs to talk to one of two hosts, each of which 
is on a different, unconnected, subnet of a second network. This seems to be 
what I am trying to deal with as well.

So, the questions are, a) Is Comer section 16.9 correct? b) Must the 
individual subnets of a network be connected?
Gareth

 _____________________________________________________________________________
|                   |                                       |                 |
| EMAIL:            | ADDRESS:                              |                 |
| ukc!sadss!garethh | DSS, Moorlands Road, Lytham St Annes, | PHONE:          |
| ukc!cix!garethh   | Lancs, England.                       | +44 253 797205  |
|___________________|_______________________________________|_________________|

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 13:43:45 GMT
From:      mano@alantec.UUCP (Mano Murthy)
To:        comp.protocols.tcp-ip
Subject:   Internet addressing


All you great network administrators out there (including gpz!), I am
interested in finding out the various schemes that are used for assigning
host as well as internet addresses. In particular, I would like to know
the bits in the internet address that are most variant for your site
(for class A, B and C style addressing).

Thank you in advance for your help.

Mano

email to: mano@alantec.com

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 13:46:50 GMT
From:      cage@cbnewsd.att.com (charles.gerlach)
To:        comp.protocols.tcp-ip
Subject:   Re: ATT TCP/IP WIN/3B Help Needed !

Folks:

I really hate dragging the entire newsgroup through this, but all my attempts
to send email directly have been bounced.  Sorry.

					Chuck Gerlach

=========================================================================

Frank:

I don't know which version of WIN/3B you're running, but let me give you 
some understanding of the link between the /usr/etc/inetinit.cf file
and /etc/hosts.  You currently have a line in /usr/etc/inetinit.cf for 
the loopback driver that ends in "me".  Inetinit uses this name as a key 
into the /etc/hosts to determine the interface's internet address. 
The lines for the primary interface usually end in zero.  In that case,
inetinit uses the uname as the key. 

What inetinit is complaining about is he can not find an entry in
/etc/hosts for the uname of your current system.  You need one.  

Now this /etc/hosts entry is usually created during the package install
process.  I haven't looked lately, but I expect the admin package is
attempting to save you from yourself.  The admin scripts are nice and, 
apparently in this case, too helpful.  All WIN/3B administration can be 
done via vi once you figure out the interrelationships between the 
configuration/data files.

You also need some way to determine the internet addresses of the hosts 
you will be contacting.  You can either enter them into the /etc/hosts 
file or use the DNS system.

If this doesn't work or you have any questions, please send me email
directly and we can work it out.

			Chuck Gerlach
			AT&T - Bell Labs
			IW 1F313 (708)-979-7325
			...!att!iwlcs!cag
			cag@iwlcs.ATT.COM

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 13:55:22 GMT
From:      randall@Virginia.EDU (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps


  I for one would like to see any NREN proposal include the keeping of
a "archive library catalog" that contains pointers to software
archives kept at various sites across the Internet.  It needn't keep
pointers to all of the tiny anonymous ftp sites, but an index by item
that included information on whether it were located on one or more of
the major archive sites (Simtel20, UUNET, WUarchive, prep, ucbvax,
grape, ncsa, etc.).

  It would be *nice* if something like Simtel20 were made available
and kept orderly as part of the NREN, but it isn't essential because
there are enough kind sites already that the net could get by.  The
catalog pointing to where to look for things is already becoming a
problem.  When I was at GE, people generally used *me* or a couple of
other people as the catalog and that wasn't fun.  I know that the same
practice exists at a lot of sites -- someone who has been around a
little while becomes the catalog of "the usual places to look."

Just a few partly-baked thoughts...

Randall Atkinson
randall@Virginia.EDU

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 14:42:56 GMT
From:      blknowle@frodo.JDSSC.DCA.MIL (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 931 "Not Recommended"...

Mike, Dan, and any others who might be interested,

    Please do not interpret this as a flame, but somehow I get the
impression that you are on opposite sides of the fence on this issue (no
matter what kind of friends you may be), and I think it's about time we
let the issue drop.

    I am perfectly well interested in RFC implementations, no matter what
the status of the RFC, as well as the status of upcoming RFCs that may
well obsolete previous ones.  However, the argument of Kerberos/SNMP vs.
RFC 931 seems to be getting more emotional than rational.

    For my own part, I will ftp the source for the RFC 931 implementation,
if only to look at it.  I will also take a long look at any upcoming
network security RFCs or software (like Kerberos or the security features
of SNMP), because that is part of my job.  I think you agree on the goal,
but not how to get there (which is precisely the problem the Soviet Union
and the U.S. have had historically, as well as any other relatively large
country I know of).
 ________________________________________________________________________ 
| Brad Knowles                 | Internet: blknowle@frodo.jdssc.dca.mil  |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849  Fax: (703) 693-7329 |
| The Pentagon, Room BE685     |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
| Washington, D.C.  20301-7010 |  Speaking from, not for DISA (nee DCA)  |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 14:53:04 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   Is the Internet usable for wide-area interactive conversations?

You state:

   Keep in mind that an active TCP connection---e.g., a remote login---dies
   the second that the network becomes unreachable. An objective observer
   would have to conclude that, no matter how good the IP service was while
   it was responding, the network was simply unusable for interactive work
   during this period.

TCP connections are not lost when you get a network unreachable!!!
Please see RFC 1122.  That is a bug in the Berkeley (4.2bsd) TCP/IP
implementation, which unfortunately (for its bugginess) has been the
base for more TCP implementations that any other.  Its bugs must not
be taken as gospel.  Please complain to the vendor of your TCP/IP
implementation to fix this bug.

The MIT V6 UNIX TCP/IP written in 1980-81 did not drop TCP connections
on host/net unreachable, although the user telnet was nice enough to
tell you that it was happening.  The SMTP/TCP would just sit there and
keep trying.

Nonetheless, cross-country backbone routes should not be thrashing
like this.  I'm not trying to apologise for the network, but I think
the blame for the problem should be more properly shared between the
network and the host.

There may be some stablitiy problem in our bailing wire inter-AS
routing protocols (EGP & BGP) prompted by some link failure.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 15:03:26 GMT
From:      ianhogg@cs.umn.edu (Ian J. Hogg)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Re: SNMP Packages/Appl. Mgt./CMOT questions

In article <1991Jun18.184913.8206@NCoast.ORG> sfb@NCoast.ORG (Stephen F. Bush) writes:
>(1) HP OpenView vs. Cabletron Spectrum - has anyone used either one and what
>    are your opinions about them? Any problems with either product? 
>    I'm trying to determine which package to buy.

  I used OpenView extensively for 9 months last year (until I left my former 
  company).  I developed an management system for data acquisition systems that
  was demoed at last summers IEEE Summer Power Meeting.  I felt it is 
  an excellant product and pretty solid, even though I
  started with pre-release versions.  I know they have a least 1 newer version 
  that may make it easier to develop managers and applications.  It is very 
  powerful but big.  An analogy I use is that is comparable to Xlib what we need
  is an Xt layer with widgets on top of the current system.

  I was working on this by encapsulating OpenView inside of C++ classes.  My
  two main classes were ObjectManager and ManagedObject.  I was pretty close to
  getting it working before I left my old company.

  HP was considering building a code generator for the managed objects.  I hope
  that they still provide a simpler programatic interface for those of us who
  would rather roll our own.
  
>
>(1a) Is there any product, such as the above, which handles application
>     management?

  I don't know about products but that was the problem I was working on.
  I was designing a system to manage our applications and servers.  Most of
  our servers are NCS based so I defined an interface that all servers must
  support.  Then the server manager takes the OpenView requests and turns around
  and makes an NCS request to the appropriate server.  The server manager handle
  requests for starting servers, killing them, etc.

  I felt this approach was reasonable to avoid having to put OpenView support
  in our servers or NCS support in our management applications.

>
>(2) Does anyone know whether the following devices already do, or will 
>    support SNMP?

    I have no idea about this.

>(3) What ever became of CMOT? Do any agents speak that protocol?

   OpenView uses CMOT and SNMP through the same interface.  In some configuration
   file you define attributes for the managed objects, one of the attributes is
   whether it supports SNMP or CMOT. Hp's snmpd will connect to the OpenView
   server if one is running.

   I think supporting both protocols is a real benefit, I believe that it will
   allow smoother integration of managed objects whos agents speak SNMP, CMOT, 
   or CMIP (when it comes).

Although this should have been at the top of my message, I haven't used OpenView
since the end of january so I may have forgotten some things or unaware of 
recent upgrades.  I do feel that is an excellant product and should be seriously
considered.  


>
>
>					Thanks,


-- 
===============================================================================
Ian Hogg						ianhogg@cs.umn.edu
                                                        (612) 225-1401

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 15:28:49 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?


    .... Keep in mind that an active TCP connection---e.g., a remote login---
    dies the second that the network becomes unreachable. ...

Some implementations (many 4bsd based implementations) actually drop the
connection on an ICMP error, but others keep it in place and continue
retransmitting for quite a while (PC/TCP) or forever (KA9Q).  You get
lousy response time, but you don't lose your type-ahead.

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

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 15:29:15 GMT
From:      ng@neutron.mpr.ca (Steve Ng)
To:        comp.protocols.tcp-ip
Subject:   Re:  SNMP second try


In article <9106142304.AA25102@grand.waterloo.edu>, rwskubow@GRAND.WATERLOO.EDU
(Rog Skubowius) writes:
|> I think you'll find alot of pointers to SNMP-compliant applications ( some
|> free ) in RFC ( request for comment ) number 1147. It's a little old,
|> but gives quite a # of anonymous ftp sites for snmp source code and 
|> more. Check it out.
|> 
|> Rog.

RFC 1147 was dated April, 1990. In the last 14 months, there is (I believe) a
tremendous changes in the SNMP industy + market. Is anyone thinking of updating
RFC1147 to include more up-to-date information?


--------------------------------------------------------------------------
Steve Ng              INTERNET: ng@mprgate.mpr.ca  or  ng%mprgate@cs.ubc.ca
MPR Teltech Ltd.,     UUCP: ...!ubc-cs!mprgate!ng
8999 Nelson Way,      CSNET: ng%mprgate.mpr.ca@RELAY.CS.NET
Burnaby, B.C.,        PHONENET: (604) 293-5463
Canada. (V5A 4B5)     FAX: (604) 293-5787
--------------------------------------------------------------------------

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 15:29:41 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

"Son of 1009" aka the Router Requirements RFC (draft) says something
about this.  The proposal will be different from anything now done,
assuming the draft is agreed to (and that stage isn't far away now).
The idea is to make a new ICMP Unreachable subtype code for generic
"communication administratively prohibited".  There are existing codes
(documented in RFC 1122 only) for "communication with host administratively
prohibited" (code 10) and "communication with network administratively
prohibited" (code 9).  I think I would prefer that the new code be sent for
a protocol-specific firewall and probably for a host or network-wide
prohibition as well.  (Such was the intent of the proposal, which by
the way wasn't mine.  Apparently there is some fast algorithm for
filtering packets that works in such a way that you can decide that
something failed much quicker than you can decide why it failed.  Since
the router world is now benchmark-driven, the vendors want the code
structure to support this way of doing things.)

People with (intelligent) opinions on what routers ought to do about
anything related to IP ought to be feeding their inputs to the Router
Requirements Working Group.  Unless something surprising occurs, the
next meeting ought to be at the Atlanta IETF at end of July/beginning
of August.  A (hopefully fairly current) draft is available at the
usual Internet-Drafts repositories including nnsc.nsf.net, in directory
internet-drafts, filename draft-ietf-rreq-iprouters-01.txt.  The
beginning of the document has lots of info about how to contribute
to its development.  It would make sense for people to read the draft
before commenting on what it should say.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 16:48:50 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the Internet usable for wide-area interactive conversations?

In article <1991Jun19.044623.19628@sura.net>, oleary@sura.net (dave o'leary) writes:
|> traceroute to berkeley.edu (128.32.133.1), 30 hops max, 40 byte packets
|>  1  sura6 (128.167.1.6)  20 ms  10 ms  0 ms
|>  2  nss (192.80.214.254)  10 ms  0 ms  10 ms
|>  3  Ithaca.NY.NSS.NSF.NET (129.140.74.9)  40 ms  30 ms  40 ms
|>  4  lan.cornell.site.psi.net (192.35.82.1)  50 ms  50 ms  50 ms
|>  5  cornell.syr.pop.psi.net (128.145.30.1)  90 ms  50 ms  40 ms
|>  6  albpop.syr.pop.psi.net (128.145.20.2)  60 ms syr.wp.pop.psi.net (128.145.91.1)  70 ms albpop.syr.pop.psi.net (128.145.20.2)  70 ms
|>  7  wp.nyc.pop.psi.net (128.145.84.1)  50 ms albpop.nyc2.pop.psi.net (128.145.80.1)  80 ms wp.nyc.pop.psi.net (128.145.84.1)  60 ms
|>  8  nyc_P1.lan.nyc2.pop.psi.net (128.145.218.2)  60 ms  70 ms  70 ms
|>  9  nyc2.nyu.site.psi.net (128.145.44.2)  90 ms  130 ms  80 ms
|> 10  NYU.EDU (128.122.128.2)  80 ms  330 ms  90 ms
|> 11  NYEGRESS.NYU.EDU (128.122.128.44)  70 ms  70 ms  70 ms
|> 12  nyu.nyc2.pop.psi.net (128.145.44.1)  70 ms  80 ms  70 ms
...


Actually, PSI has been having some problems recently with a T-span into
cornell.   This is probably the cause of your problems.

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 17:06:35 GMT
From:      darnold@felix.UUCP (Dave Arnold)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In article <9106120113.AA16777@toaster.SFSU.EDU> eps@cs.SFSU.EDU writes:
>Will it interoperate with BSD uucpd?  Not out of the box.  For
>one, AT&T's code uses 'e' protocol rather than 't' protocol over
>TCP connections.
>
>					-=EPS=-

But, what's to stop me from running 'g' over TCP connections?

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 17:22:43 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Telnet Terminal Servers

I am looking for terminal servers which support the automatic establishment
of sessions upon seeing Data Terminal Ready going high.  It must be able to
establish a session with a specifically designated terminal server port at the
other end of the net.  Most terminal servers can handle automatic session
initiation - but going to a SPECIFIC port on a corresponding terminal server
seems to be a problem.

Unfortunately, the systems development folks like to write applications which
require specific user terminals attached to specific addresses...

Many thanks for any info.  Please e-mail me directly, to avoid wasting
bandwidth on the news-group...

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 18:26:29 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

On 18 Jun 91 08:40:31 GMT, adam@castle.ed.ac.uk (Adam Hamilton) said:

adam> In article <PCG.91Jun17234451@aberdb.aber.ac.uk> pcg@aber.ac.uk
adam> (Piercarlo Grandi) writes:

adam> The choice made by the JNT was NOT between OSI-on-paper and a
adam> basically-working-TCP-IP.  It was between TCP-IP-on-paper and a
adam> basically-working-X25, the only standardised available protocol of
adam> the time.

No, it was between working ARPAnet with many services and dozens of
nodes and X.25 yet to be used massively and little more than remote
login.

The choice between Internet and ISO/OSI is the one they are facing now,
or rather, the choice has already been made by somebody else, and the
JNT are trying to ride the wave.

adam> The decision to target on OSI when available is hardly one to be
adam> criticised; after all, the Internet has stated it will convert
adam> eventually.

Milnet, maybe will (in due time :->). NFSnet, quite improbably. The
Internet, surely not.

As to 'OSI when available' I would never bet the farm on a set of
standards yet to be approved, sight unseen. Apparently I am in good
company.

adam> the Arpanet was NOT running well-proven software at the time, it
adam> did NOT have a dozen years of experience and it did NOT have a
adam> "working viable...system of specifications and implementations".

Tell that to the guys that were running the ARPAnet at the time... :-)

Maybe I suffer from hallucinations, as somebody else has pointed out
before. I have obviously delusionary memories of using the ARPAnet in
the late seventies/early eighties with remote login, mail, file
transfer between dozens of otherwise incompatible mainframes.

I cannot remember any similarly complete ready made alternative from the
X.25/ISO/OSI camp.

Still I must admit that the only way I had to get onto ARPAnet from
Italy was to use TYMnet, which was X.25 based. But X.25 based networks
did not offer much more than remote login, and painfully as to that.

adam> The key point he misses is that what makes sense is to run the
adam> same protocols locally as you will have to connect to if you want
adam> to go further afield.  In Europe at that time that meant X25.

Mention *any* other largish X.25 based research network in Europe at the
time. Or even now.

Or maybe this was another JNT miscalculation. They may well have
believed that there would be a lot of traffic with other European
countries and with Australia and New Zealand, rather than with the USA.
Wishful thinking, if so. A dozen years ago I was using TYMnet to connect
to the ARPAnet, not to CYGALE or EIN. For good reasons...

adam> Next message, he will start to tell us again about how the JNT
adam> chose big-endian domain ordering when little-endian had already
adam> been chosen for TCP/IP (and for viewers who have missed this
adam> endless discussion - they didn't.  They simply failed to change
adam> their minds some months later when the opposite decision was made
adam> over the pond).

This is not what I wrote. I remember (and will eventually find the
article I saved) one of the guys who did attend the meetings reported
that JNT had chosen a completely different addressing format with big
endian domains, and then they changed their minds and decided to use the
USA adopted syntax but with their own original big endian domain
ordering. Hearsay, admittedly. Will try to retrieve that posting.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 18:30:25 GMT
From:      davidk@dsinet (David Karr)
To:        comp.protocols.tcp-ip
Subject:   TFTP code from Unix Network Programming

I am looking at the code for TFTP that is described in "Unix Network
Programming", by W. Richard Stevens.  Is that TFTP code available on-line
somewhere?  I could just type it in, but there is quite a bit of code there.
I don't have access to anon. FTP, except for possibly a mail server, but I
don't know of one that works for me, so sending it to me in mail form would
be more convenient.
-- 
Digital Systems International, Inc.	David Karr
7730 177th Pl NE			dsinet!davidk
Redmond, WA   98073-0903
(206) 881-7544 ext. 547

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 19:03:52 GMT
From:      lance@lances.aiss.uiuc.edu (C Lance Moxley)
To:        comp.protocols.tcp-ip
Subject:   APPC over TCP/IP

A question: Can APPC be run over TCP/IP? I know nothing about APPC
but the question came up in a meeting this morning and I thought 
someone here could shed some light on the subject.

Thanks.
-- 
C Lance Moxley                Internet: Lance-Moxley@uiuc.edu
AISS/Telecommunications         BITNET: UNETCLM at UICVMC
University of Illinois            UUCP: uunet!uiucuxc!uiuc.edu!Lance-Moxley

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 19:07:52 GMT
From:      satya@ssdc.honeywell.com (Satya Prabhakar)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa



Hi,

I am involved in developing the ISO/RDA protocol between CDC 920
and IBM 3090.  CDC 920 uses ASCII representation and the IBM
uses EBCDIC. I am looking for C routines that convert ASCII strings
into EBCDIC strings and vice-versa.  We need these DESPERATELY and
asap. If you have some information re: these, please let me know
asap. I would REALLY appreciate your help.

Very many thanks in advance.

Satya Prabhakar  (satya@ssdc.honeywell.com)
(Office Phone: 612-782-7134)

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 19:57:32 GMT
From:      howard@coh-uk.UUCP (Howard Wilkinson)
To:        comp.protocols.tcp-ip
Subject:   Request for sources of Public Domain TCP/IP implementations


I have been asked by a client to try and prove out the possibility
of running a TCP/IP protocol suite on his board.

The board is a standalone embedded microcontroller. It has no disc and
a funny memory mapping model (Z180 look-alike I think). I need to get
a cheap source of a TCP/IP implementation to demonstrate the feasibility
or not. So the obvious answer is PD software.

I have read this newsgroup for the last 2 weeks and seens requests for
information on PD software but no comments. Can anyone direct me at a source
or sources for such information.

I'm willing to use a lot of brain power to get this working as I think
the source will probably end up being a model rather than the actual
implementation.

Any help appreciated.

Howard.

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 20:10:09 GMT
From:      mmccorm@d.cs.okstate.edu (McCormick Martin)
To:        comp.protocols.tcp-ip
Subject:   Subnetting Class B Internet Number


We have a class B Internet number.      While our Ethernet
 isn't subnetted now, it may be some day.  What is the most
 efficient, (allowing the most IP numbers),  method for
 subnetting and what does each local host have to have in its
 configuration to work properly in such an environment.
     I have heard conflicting information from many
knowledgeable people and would like to hear pros and cons
from those who have actually done this.  I'll post a summary
of answers.
Thanks.

Martin McCormick
Amateur Radio WB5AGZ
Oklahoma State University
Computer Center
Data Communication sGroup
Stillwater, OK

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 20:49:21 GMT
From:      goldstein@delni.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK


In article <12694360385.18.PADLIPSKY@A.ISI.EDU>, PADLIPSKY@A.ISI.EDU 
(Michael Padlipsky) writes...

>Assuming you've figured out which side I'm on, I'll touch briefly on
>why I'd claim the Colourisers SHOULD have known better: by the late
>'70s TCP/IP implementations were running whilst the only thing the
>ISORMites had running was their mouths.

Now that you mention it, I've been looking for somebody who remembers 
the date.

While TCP/IP was being developed in the '70s and had some lab 
implementations, the ARPAnet itself was running NCP for quite a while, 
until they were ready to switch everything over.  I recall that one day 
(well, probably a long weekend) it happened, and NCP was No More.

Anybody remember the date?

I think that was the last time a protocol simply died, kaput, just like 
that, never to be heard from again.  Well, ANF-10 may have outlasted 
it...
---
Fred R. Goldstein              Digital Equipment Corp., Littleton MA
goldstein@delni.enet.dec.com   voice: +1 508 952 3274
 Do you think anyone else on the planet would share my opinions, let
 alone a multi-billion dollar corporation?

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 22:58:00 GMT
From:      systemdw@NTSC.NAVY.MIL ("SYSTEM MANAGER")
To:        comp.protocols.tcp-ip
Subject:   looking for transport layer software


Hi,

    I am a Graduate student working on an independent research project

    at a local University and I am trying to locate the following

    information:

    1)  Public domain source code, preferably C/Unix, for the Transport
        Control Protocol.  I would like a product that is compliant with
        mil std 1778 and was developed for a workstation, LAN/WAN environment.
        Also would be interested in obtaining tools that would aid in the
        evaluation/testing of this software.

    2)  Source code, preferably C/Unix, for layer 4, the Transport Layer,
        of the OSI stack, class X.

    3)  Locating a copy of standards ISO8072 and ISO8073

    Any leads/information will be appreciated,

    Please direct REPLIES to    systemdw@ntsc.navy.mil

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 91 23:05:25 GMT
From:      carroll@ssc-vax (Jeff Carroll)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: CDMA

In article <1991Jun18.175959.29344@ulowell.ulowell.edu> wex@cs.ulowell.edu writes:
>I am looking for pointers to an elementary description of how
>CDMA works in practice;  I have seen simple example descriptions,
>I have no idea, for example how many chips/bit occur in practice,
>whate actual bandwidth is in the real world.

	This will be difficult to find in the open press. A typical case
might be 500 chips/bit, and bandwidth between first nulls on the order of
10^8 Hz.

	You might want to check the latest issue of the IEEE Transactions
on Vehicular Technology, where Klein Gilhousen and other members of the
technical staff at Qualcomm, Inc. talk about their CDMA cellular system
(I haven't read my copy yet.)



-- 
Jeff Carroll		carroll@ssc-vax.boeing.com

"...and of their daughters it is written, 'Cursed be he who lies with 
any manner of animal.'" - Talmud

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 01:29:32 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a number of Class C Networks - How?

In article <1991Jun13.065802.9433@picasso.cssc-syd.tansu.oz.au>, rodney@picasso.cssc-syd.tansu.oz.au (Rodney Campbell) writes:
> We am having a number of problems attempting to set up a number of Class C

I tried to reply by mail, but metro.su.oz has problems and it bounced.
Other responders may be having problems too - you may not get m(any)
replies. So here it is posted.

>Now the problem is that SunOS defaults all of this to a Class B network

The definition of a "default" setting is "As shipped the equipment
will be set up exactly the way you don't want it" :-).

So you have to change it. On all machines. Don't miss any. Don't let
anyone connect new machines onto the network (with the "default"
config) or it may mess up your network.

The Sun Installation manuals probably tell you how to do all this
properly. I'd probably grep for "ifconfig" in /etc/rc*, and change
it there, but what do I know? Address and subnet mask and broadcast too...

>Also the broadcast address on Suns defaults to NET.0 is this right or
>should it be NET.255?

Either is right - as long as it is the same on all machines. Unless
you have something so old on your network that it can't be convinced
to use "NET.255" you should probably use "255".

>      2) Any machine on these nets can talk to any other machine on any
>      other net.

Now it gets interesting. If I read this right you want multiple
separate class c subnets on the same ethernet cable.

Fortunately IP allows this, All good and conforming IP implementations
SHOULD reject all packets not destined to the correct subnet. However,
this is where any "rogue" machines configured wrongly (i.e. configured
as default) may wrongly receive things that they shouldn't, or may ARP
for addresses on the subnet that it isn't on (in which case other
machines won't be able to return packets to it although it can send).

You need to configure an IP router to have multiple LOGICAL IP
interfaces, with different IP addresses, but all connected to the same
physical Ethernet interface. I think Cisco can do this.

>Also if anyone has an Idea about setting up the Webster Multiport Gateway
>to work with this setup?

Set it up as a "normal" IP host with the correct subnetmask and
broadcast address, and let the router connect everything together.

It might be easiest if the router is designated as the "default
router" on all machines - but note that it has a different IP
address on each subnet. You'll probably want all subnets in
/etc/networks, and proper entries in /etc/gateways - not necessary but
it does "document" the network somewhat.

========================
Tom Evans  tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") **
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179  A.C.N. 004 818 455

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 02:36:17 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP code from Unix Network Programming


> TFTP code from "Unix Network Programming"

Some pointers for you.

Code from MIT that implements TFTP (Copyright 1984 MIT, "permission to
use for any purpose granted provided that the copyright appear and
remain intact", which should make it suitable for use in commercial
products) is available for anonymous ftp from
	vax.ftp.com:/pub/pc800/tftpd.shr
It does both a simple client and a simple server.

Code from the 4.3 BSD Reno distribution (Copyright 1983 Regents of the
University of California, similar permissions to the above, suitable
for commercial use) can be had from 
	wuarchive.wustl.edu:/unix/4.3bsd-reno/usr.bin/tftp/
for the client code.

-- 
Edward Vielmetti, MSEN Inc. 	moderator, comp.archives 	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"

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 03:56:45 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Can Someone Give Details On Sun And Wollongong's X.400 MTA?

Can someone give details about how Sun and Wollongong have
implemented the X.400 Message Transfer Agent in UNIX?  Is 
the intent to gateway SMTP names to X.400 names, or in theory
could a single user agent simultaneously use SMTP and X.400
transfer agents to send mail to the respective domains?

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 05:03:37 GMT
From:      alanlb@csgrad.cs.vt.edu
To:        comp.protocols.tcp-ip
Subject:   Looking for TCP/IP source for Ultrix

Hi!  I'm looking for a port of Douglas Comer's TCP/IP implementation
that works on Ultrix.  Is there such an animal anywhere?  Actually,
any source code for TCP/IP, as long as it runs on Ultrix, will be
quite helpful.  I would appreciate any and all replies and will
summarize afterwards.

Thanks!

-alan l. batongbacal

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 05:20:20 GMT
From:      et@ajk.tele.fi (Eero Torri)
To:        comp.protocols.iso,comp.protocols.tcp-ip,sci.crypt,alt.security
Subject:   Arto Karila's study on Open Systems Security available


Hello all!

I'm posting this on behalf of Arto Karila

--------------------- Forwarded message -----------------------

I have written a study "Open Systems Security - an Architectural Framework"
which is now availabe in post script form through the Internet. 

Based on the Internet architecture I have analyzed the security requirements
of some real applications, found the security services needed with them,
placed these services into the layers of the OSI model, and found some existing
mechanisms that can be used to implement them.

Even though this work is based on the existing international standards it is
not limited to the OSI world but should be directly applicable to virtually any
layered telecommunications architecture such as the DoD Internet architecture.
It appears to be justifiable to place all security functions in the layers
4 and seven of the OSI model (corresponding to TCP and the "upper layer" in
the DoD Internet model).

We have also implemented a secure FTAM service (File Transfer, Access and
Management, corresponding approximately to FTP) running on Sun and based on
the ISODE software package and tested the ideas presented here in practise.
We have also built a rather similar system for a client based on TCP/IP.

Professor David Farber of the University of Pennsylvania had the patience to 
got through my dissertation which was the basis of this paper. He suggested
that I make it available through the Internet. So, here it is. Feel free to
distribute it for non-profit purposes. If you have any comments, please 
E-mail them to me at the address below.
 
The study is over a hundred pages long with the appendix included. It is 
available in both compressed and uncompressed form (about 750 and 250 kB,
respectively) but I suggest you transfer it in its compressed form. 
Here is a sample session of how it's done:

% ftp ajk.tele.fi
Connected to ajk.tele.fi.
220 ajk.tele.fi FTP server (SunOS 4.0) ready.
Name (ajk.tele.fi:atk): anonymous
331 Guest login ok, send ident as password.
Password: *** type your username here, e.g. atk@ajk.tele.fi ***
230 Guest login ok, access restrictions apply.
ftp> bin
200 Type set to I.
ftp> cd /PublicDocuments
250 CWD command successful.
ftp> get OpenSystems.Security.ps.Z
200 PORT command successful.
150 Binary data connection for OpenSystemsSecurity.ps.Z (130.233.192.2,3814) 
(246271 bytes).
226 Binary Transfer complete.
246271 bytes received in 8.2 seconds (29 Kbytes/s)
ftp> quit
221 Goodbye.
% uncompress OpenSystemsSecurity.ps




Host: ajk.tele.fi (131.177.5.20)
Username: anonymous
Password: your-user-id
Directory: /PublicDocuments
Files: OpenSystems.Security.ps = the normal post script file (ca. 750 kB)
       OpenSystems.Security.ps.Z = the same but compressed (ca. 250 kB)

Other info:
- The file was prepared with Macintosh and MS-Word
- The Macintosh LaserPrep file was appended to the beginning of the file
- The file should print on any post script laser with Times font
  (it has only been tested with Apple LaserWriter)
- If you are using a printer that has already been initialized with the
  LaserPrep file, turn it off and on again before printing (or remove the
  Laser Prep part of this file)
- The page is set for the European A4 size which is slightly taller than
  US letter size. With letter size you may loose the footers. With US legal
  paper size it should work fine.

If you have technical problems in getting the file contact our system
administrator Eero Torri (et@ajk.tele.fi).

--
Arto Karila              + INTERNET: atk@ajk.tele.fi
Telecom Finland          + TEL     : +358 0 704 2000
Business Systems R&D     + FAX     : +358 0 704 2712
P.O. Box 140
00511 HELSINKI

-----------------------------------------------------------------
-- 
Eero Torri               + INTERNET: et@ajk.tele.fi
TELE/Palvelukehitys      + TELEBOX : spp482
Elim{enkatu 8            + TEL     : +358 0 704 2973
00511 HELSINKI           + FAX     : +358 0 704 2712

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 07:05:16 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: building an interstate (data) highway with no roadmaps

In article <EMV.91Jun18000345@bronte.aa.ox.com>
   emv@msen.com (Ed Vielmetti) writes:
>   X.500 services are directory oriented.  The data in them is relatively
>   small, of known value, and highly structured.  Information about
>   archive sources is just about completely counter to these basic
>   principles.

In article <WORLEY.91Jun18094957@sn1987a.compass.com>
   WOrley@compass.com (Dale Worley) writes:
>What can be done to produce good catalogs?  As Ed notes, archive
>information is likely to be bulky, chaotic, and of unknown (probably
>small) value.  Given how much money is needed to get a directory
>system for information without these problems running, it will
>probably take much more to get a good system for archive information
>working.

Actually, we know quite well what it takes to raise the signal-to-noise
ratio. Administration and moderation.

One possible option would be for the Internet Society to sponsor an
archive registration facility. Maybe each of the IETF task forces can
identify valuable programs that  need to be archived, with mirrored
servers on each continent, available for NFS mounting as well as
anonymous FTP. It should be worth $50 for each site to have access to
good easily  accessible archives instead of having to keep disk space
for everything in our own space. (I know; not every "hobby site" can
afford $50, but there are many commercial sites, including my own, that
would be happy to help feed such a beaST; I'm sure many academic sites
would be able to help, too).
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 08:19:21 GMT
From:      edwin@cs.ruu.nl (Edwin Kremer)
To:        comp.protocols.tcp-ip
Subject:   Re: TFTP code from Unix Network Programming

In <656@elroy> davidk@dsinet (David Karr) writes:

   |DK> I am looking at the code for TFTP that is described in "Unix Network
   |DK> Programming", by W. Richard Stevens.  Is that TFTP code available
   |DK> on-line somewhere?
Yes, it is. I picked up all the  code  published  in  the  book  by  FTP
sometime  ago  (don't remember where), but it is in our archive. Details
on how to get it follow...


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  We, Computer Science department, Utrecht University,  are  running  an
anonymous  FTP  server  on  one  of  our systems. In addition to the FTP
service we're also running a mail  server,  for  those  of  you  without
direct Internet access.


--> How to get 'stevens-book-code' via anonymous FTP:

	Site:		archive.cs.ruu.nl  [131.211.80.5]
	Login:		"anonymous" or "ftp"
	Password:	your own email address (you@your_domain)
	File:		UNIX/stevens-book-code.tar.Z


--> How to get 'stevens-book-code' via e-mail from our mail-server:

    NOTE: In the following I have assumed that your mail address is
	  "fred_flintstone@stone.age.edu"; of course you must substitute
	  your own address for this.
	  ** PLEASE USE VALID DOMAIN ADDRESSES. DO NOT USE ADDRESSES **
	  ** WITH ! and @ MIXED !!!! BITNETTERS USE USER@HOST.BITNET **


    Send the following message to
		mail-server@cs.ruu.nl
    or the old-fashioned path alternative
		uunet!mcsun!hp4nl!ruuinf!mail-server


      begin
      path fred_flintstone@stone.age.edu (SUBSTITUTE *YOUR* ADDRESS)
      send UNIX/stevens-book-code.tar.Z
      end


The path command can be deleted if we receive a valid from address in your
message. If this is the first time you use our mail server, we suggest you
first issue the request:

      send HELP


  A complete "ls-lR" listing of the archive is  kept  in  the  top-level
directory, it will be updated every night. To get it, issue the command:

     send ls-lR.Z



  That's all for now. If you encounter problems using  the  FTP  service
and/or the mail-server, feel free to drop me a line (by e-mail, please).



						--[ Edwin ]--
--
Edwin Kremer, systems and network administrator.  [NIC-Whois handle: EHK3]
     Department of Computer Science,  Utrecht University,  The Netherlands
     Email: edwin@cs.ruu.nl  | UUCP to: ...!uunet!mcsun!hp4nl!ruuinf!edwin

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 09:02:07 GMT
From:      sonneveld@pttrnl.nl
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.modem
Subject:   ISDN and X-Windows

{
   Hello, all
   
   For one of my colleagues I'm posting this request for information. If
   you've  any  suggestion  or  answer,  please reply to him via his own
   address: pttrnl!duursma@hp4nl.nluug.nl. Thanks a lot in advance,
   
   Rolf E. Sonneveld
   -= PTT Research =-
   The Netherlands
}

Hello,

For one of our projects we try to get the following stack of hard/software 
working together for a MS-DOS PC:

X-windows
---------
TCP/IP
---------
ISDN (The German 1TR6-protocol)

Until now we could not find an ISDN-card for the MS DOS PC (386 or 486) 
on which we could use standard TCP/IP software in order to use X-windows.
We are looking for a complete stack from German ISDN up to X-windows 
commercially available. However, if you have a better stack, but 
including ISDN and X-windows, please let me know!

Thanks in advance,

Menco Duursma

=======================================================
Menco Duursma (pttrnl!duursma@hp4nl.nluug.nl)
PTT Research Tele-informatics
P.O. BOX 15000
9700 CD Groningen
The Netherlands
PHONE: +31 50 821169     FAX: +31 50 122415
===========================================================

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 11:56:13 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun19.190752.28034@ssdc.honeywell.com> satya@ssdc.honeywell.com (Satya Prabhakar) writes:
>uses EBCDIC. I am looking for C routines that convert ASCII strings
>into EBCDIC strings and vice-versa.  We need these DESPERATELY and

  I don't understand.  What is wrong with a simple loop replacing
c with EBCDIC[c] for each char c in the string of unsigned chars.
Something like:
	while(*p) { *p = EBCDIC[*p]; p++;}

 You do need to initialize your table.  Pick up the tables used on the
3090 and use those.  If you don't like that choice build your own in
the grand tradition of mutual inconsistency which currently exists in
the ASCII <-> EBCDIC translation world.


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 13:00:47 GMT
From:      mo@messy.bellcore.com (Michael O'Dell)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: ASCII/EBCDIC Isomorphism

munch munch

A long, long time ago, in a galaxy far, far away, I built a printer
spooler which could talk to an IBM mainframe to do output
on the printers attached thereto.  In the process, I created
an ASCII/EBCDIC translation table which was invertable and corresponded
essentially directly with the major print-trains (TN being most interesting).
I could go prospecting in the dusty bits if folks are interested...

	-Mike

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 14:45:47 GMT
From:      rafferty@dish.jpl.nasa.gov (mike rafferty)
To:        comp.protocols.tcp-ip
Subject:   looking for SysV LPD

We have several AEG Modular Computer Systems (Modcomp) 9735 machines
running a modified AT&T SysV UNIX called REAL/IX. Does anyone know of 
a ftp site for SysV LPD.

   Thanks in advance.

Mike Rafferty   Jet Propulsion Lab

email rafferty@dish.jpl.nasa.gov
phone (818) 354-8604

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 15:04:21 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

On 19 Jun 91 20:49:21 GMT, goldstein@delni.enet.dec.com (Fred R. Goldstein) said:


goldstein> While TCP/IP was being developed in the '70s and had some lab
goldstein> implementations, the ARPAnet itself was running NCP for quite
goldstein> a while, until they were ready to switch everything over.  I
goldstein> recall that one day (well, probably a long weekend) it
goldstein> happened, and NCP was No More.
goldstein> Anybody remember the date?

Not so suddendly. Comer says that TCP/IP introduced to ARPAnet around
1980, and that gradually sites started dropping NCP based services and
using TCP/IP, until in 1983 nearlly all sites had converted. I guess
that if you really wanted a cutoff date it would be hard to say;
probably one could say it was when more than say 80% (but any percentage
greater than 50% would probably do) of ARPAnet backbone traffic had
become IP based. Somebody should have such statistics around...

--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 15:12:56 GMT
From:      pcg@aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

On 18 Jun 91 03:24:16 GMT, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) said:

PADLIPSKY> the Colourisers SHOULD have known better: by the late '70s
PADLIPSKY> TCP/IP implementations were running whilst the only thing the
PADLIPSKY> ISORMites had running was their mouths.

Not necessarily so; they had viable if fiarly rudimentary X.25
technology to show. At the end of the seventies one could observe:

	1) a large scale production WAN, the ARPAnet
	2) experimental or otherwise small scale X.25 technology

	3) experimental or otherwise small scale Internet technology
	4) papers and intentions about ISO/OSI

The ISO people *did* have something going for them; there were X.25
operational networks after all.

Now comparisons 1 vs. 2 and 3 vs 4 point out that for *comparable*
(ARPAnet vs. "X.25", Internet vs. ISO/OSI) levels of technology you are
indeed right when you say that:

PADLIPSKY> (Plus, rudimentary awareness of the pace of the international
PADLIPSKY> standards process should have indicated that it would take
PADLIPSKY> quite some time for OSI to overcome TCP/IP's chronological
PADLIPSKY> lead. Say, at least half-a-dozen years as of the late '70s.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 15:15:42 GMT
From:      echan@CAD017.INTEL.COM (Eldon Chan ~)
To:        comp.protocols.tcp-ip
Subject:   Re:  SNMP Packages/Appl. Mgt./CMOT questions

We have a group actually evaluating both Spectrum and HP OpenView.  
I'll be very interested in how you come down to these two vendors. 

Other vendors we have tested are SunNet manager and  DECmcc MSU.

You may check the Datapro documents for a list of NMS and SNMP agents. 

Hope it helps.

Eldon
------------------------------------------------------------------------
Hello,

I have some questions about SNMP packages:

(1) HP OpenView vs. Cabletron Spectrum - has anyone used either one and what
    are your opinions about them? Any problems with either product? 
    I'm trying to determine which package to buy.

(1a) Is there any product, such as the above, which handles application
     management?

(2) Does anyone know whether the following devices already do, or will 
    support SNMP?

    Stratacom IPX Switches 	(I believe they plan to)
    Telematics X.25 Nodes
    Octocom Modems
    PCI Pads and Protocol Converters
    Codex Modems
    Memotec Data Compressors
    rOUTAROUNDS
    AT&T WideBand Circuits
    MCI WideBand Circuits
    Telco Services

(3) What ever became of CMOT? Do any agents speak that protocol?


					Thanks,

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 16:03:34 GMT
From:      exspes@gdr.bath.ac.uk (P E Smee)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun19.190752.28034@ssdc.honeywell.com> satya@ssdc.honeywell.com (Satya Prabhakar) writes:
>I am involved in developing the ISO/RDA protocol between CDC 920
>and IBM 3090.  CDC 920 uses ASCII representation and the IBM
>uses EBCDIC. I am looking for C routines that convert ASCII strings
>into EBCDIC strings and vice-versa.  We need these DESPERATELY and
>asap. If you have some information re: these, please let me know
>asap. I would REALLY appreciate your help.

There's a basic problem here, which is that there is (still) no such
thing as EBCDIC.  At present, for example (and I may have missed some
possibilities) the following codings might be used for 5 example
special chars:

    Char   ASCII    EBCDIC
    {      0x7b     0x43, 0x44, 0x51, 0x63, 0x9c, or 0xc0
    }      0x7d     0x47, 0x54, 0xd0, or 0xdc
    [      0x5b     0x4a, 0x90, 0x9e, 0xb1, 0xb5, 0xba
    ]      0x5d     0x51, 0x5a, 0x9f, 0xb5, 0xbb
    |      0x7c     0x4f, 0xbb

and, there are some characters in each set which don't exist in the
other.  Apropos those codes above, the problem is that original EBCDIC
did not define codes for a lot of the special chars, but they DID exist
on various IBM printer belts (in different places).  So, as a pragmatic
approach, various packages used, internally, the encodings which they
though most likely to work with the types of print belts that they
thought their type of users would use.

The UK's BlueBook file transfer protocol suggested using the following
mapping, which seems to work pretty well most of the time, which is as
good as you're gonna be able to do (has the advantage of being 1-1 and
reversible as long as the chars involved exist in the ASCII set):

    0x  1x  2x  3x  4x  5x  6x  7x  8x  9x  Ax  Bx  Cx  Dx  Ex  Fx
x0  00  10  40  F0  7C  D7  79  97
x1  01  11  5A  F1  C1  D8  81  98
x2  02  12  7F  F2  C2  D9  82  99
x3  03  13  7B  F3  C3  E2  83  A2
x4  37  3C  5B  F4  C4  E3  84  A3
x5  2D  3D  6C  F5  C5  E4  85  A4
x6  2E  32  50  F6  C6  E5  86  A5
x7  2F  26  7D  F7  C7  E6  87  A6
x8  16  18  4D  F8  C8  E7  88  A7
x9  05  19  5D  F9  C9  E8  89  A8
xA  25  3F  5C  7A  D1  E9  91  A9
xB  0B  27  4E  5E  D2  AD  92  C0
xC  0C  1C  6B  4C  D3  E0  93  4F
xD  0D  1D  60  7E  D4  BD  94  D0
xE  0E  1E  4B  6E  D5  71  95  5F
xF  0F  1F  61  6F  D6  6D  96  07

This is EBCDIC on the inside, ANSI (IA5) on the edges.  So, to turn
ASCII 0x21 into EBCDIC, you look in the column headed 2x on the row
labelled x1, and come up with EBCDIC 0x5a.  To find out what EBCDIC
0xD1 is, you find D1 in the table, in column 4x, row xA, so it is ASCII
0x4a.  (Note this assumes 0-parity ASCII, as well.)

Warning, EBCDIC is bigger than ASCII.  if you turn this into a set of
translation tables, you have to decide what you are going to do with
EBCDIC chars which do not appear in the table (with no corresponding
char in ASCII).  IBM's normal response is to just map them all to one
printing char (forgotten which, something like $ or &).

The above mapping seems to do the right sort of things with most IBM
applications -- e.g. ASCII C programs moved to an IBM and translated
this way will probably compile with the IBM C compiler.  Ditto other
language sources.

For a real real definitive answer, you'll have to get friendly with
someone in IBM.  I know THEY are trying to come up with a definitive
ASCII<->EBCDIC mapping as part of their SAA project; to dig themselves
out of the hole caused by the fact that IBM/PCs speak ASCII, while IBM
mainframes speak EBCDIC.  God only knows what mapping they'll end up
with.

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 17:45:06 GMT
From:      davy@wombat.erg.sri.com (David Curry)
To:        comp.protocols.iso,comp.protocols.tcp-ip,sci.crypt,alt.security
Subject:   Re: Arto Karila's study on Open Systems Security available

In article <1991Jun20.052020.15854@ajk.tele.fi>, et@ajk.tele.fi (Eero
Torri) writes:
|>
|>Hello all!
|>
|>I'm posting this on behalf of Arto Karila
|>
|>--------------------- Forwarded message -----------------------
|>
|>I have written a study "Open Systems Security - an Architectural Framework"
|>which is now availabe in post script form through the Internet. 
|>
|>Other info:
|>- The file was prepared with Macintosh and MS-Word
|>- The Macintosh LaserPrep file was appended to the beginning of the file
|>- The file should print on any post script laser with Times font
|>  (it has only been tested with Apple LaserWriter)
|>- If you are using a printer that has already been initialized with the
|>  LaserPrep file, turn it off and on again before printing (or remove the
|>  Laser Prep part of this file)
|>- The page is set for the European A4 size which is slightly taller than
|>  US letter size. With letter size you may loose the footers. With US legal
|>  paper size it should work fine.


Has anyone managed to get this thing to print on a non-LaserWriter?  I tried,
and ended up with mirror-images of the pages (and they were offset wrong too).
This is on an Imagen with UltraScript.

Deleting the LaserPrep stuff doesn't work, because then there's all
sorts of undefined functions and other nastiness.

Dave Curry
SRI International
                                                                        

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 17:57:07 GMT
From:      galvin@TIS.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   RFC 931, PEM, and SNMP Security

There have been a few message about RFC 931 and authenticated SMTP and I
would like to add a few words that have not been stated and correct a
few things that have been stated.  This is a long message, but it covers
RFC 931, Kerberos, PEM, and SNMP security, respectively.

First, RFC 931 is not a security panacea.  Let me say that again more
strongly.  RFC 931 does not, can not, and will not solve the security
problems of the Internet.  Mike St. Johns, the author of RFC 931 has
said this.  Let me quote from the RFC itself:

   Unfortunately, the trustworthiness of the various host systems that
   might implement an authentication server will vary quite a bit.  It
   is up to the various applications that will use the server to
   determine the amount of trust they will place in the returned
   information.  It may be appropriate in some cases to restrict the use
   of the server to within a locally controlled subnet.

The problem is you have no reason to believe anything a 931 server tells
you in the general case.  If I know nothing about the relative security
or insecurity of your host -- which has a high probability of being true
when receiving "arbitrary" ftp, smtp, and telnet connections -- why
should I "trust" anything you tell me about the source of your
connection request.

Dan Bernstein has said a 931 server "provides enough additional security
to stop those pesky undergraduates from forging mail (at least without a
network machine of their own)".  Insofar as he is speaking about an
environment which is "a locally controlled subnet", he is absolutely
right.  After all, if they are your machines you know how secure or
insecure they are and whether or not to believe anything they tell you.

However, the Internet does not have a secure architecture.  To suggest
that 931 supports TCP authentication in the absence of a secure
architecture is ludicrous.  I may choose to define my configuration as a
secure architecture, but I can not impose that on other autonomous
Internet subscribers.  The Internet is a collection of cooperating
autonomous domains, not a tightly-coupled collection of autonomous
domains, which I believe would be true if a secure architecture existed.

The bottom line is RFC 931 does not stop all username forgeries above
the TCP level in the general case.  And, to suggest that to break RFC
931 requires breaking TCP security makes no sense.  Last time I checked
TCP was as insecure as almost every other Internet protocol.

Kerberos is better than RFC 931, in the Internet today.  The reason is
because it supports a complete infrastructure, a secure architecture,
with which "secure" applications can be built.  With RFC 931, secure
applications must be built on it, as opposed to with it, i.e., the
access control policy must be rebuilt for each application (or at least
repeated for it).

PEM is also better than RFC 931, and contrary to recent press here there
will be an openly available implementation this year.  The
implementation is being provided by Trusted Information Systems (my
employer), BBN, and RSA Data Security, Incorporated.  We are currently
beta testing an operational system now.  Like Kerberos, it supports a
complete infrastructure.  By the way, it is provides end-to-end
security, so as long as your user agent is RFC 822 compliant, it is
independent of the transport used, e.g., SMTP or UUCP.  Thus, no patches
to Sendmail are necessary to support PEM.

PEM will work on BSD derived UNIX machines, which covers a good portion
of the Internet.  Unfortunately, every little compile/install step is
not automated, but then there is no comparison between its complexity
and that of any RFC 931 implementation.

Finally, as for SNMP security being ridiculously vulnerable to
known-plaintext, even chosen-plaintext attacks, I must disagree.

The SNMP security protocols may have limited vulnerability to
known-plaintext attacks.  If privacy is used, this assumes you know the
query that was sent.  If not, the response is meaningless.  While it is
true an attacker has a high probability of knowing certain bytes in a
query -- because ASN.1 encoding is used -- this is a small part of the
overall message and it is not obvious to me how this is helpful enough
to suggest the vulnerability is ridiculous.

I do not see how the protocols are subject to chosen-plaintext attacks.
This kind of attack assumes I can submit a plaintext message and receive
a ciphertext message in return.  This is not possible in the security
protocols as defined.  You only get what you send, so if you send
plaintext that is what you get back.  If you send ciphertext you get
back ciphertext.

I must also disagree with the comment that the SNMP security protocols
require the exchange of a whole bunch of keys in advance.  A careful
reading of the specifications will tell you that a management station
and an agent need only share 6 party identifiers initially, 3 for the
agent and 3 for the management station.  All further key exchanges and
creation of parties can be completely automatic and transparent to the
user.  Six is hardly "a whole bunch".

Jim

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 18:30:57 GMT
From:      galvin@TIS.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   Re: Authenticated SMTP, anyone done one?


	1) Does PEM address all of the security and authorization issues
	for sending mail on the Internet?

Depends on what you mean by all.  I believe that PEM addresses the
principal security issues, since it supports message integrity, message
origin authentication and message confidentiality.  Since public-key
technology is used, our implementation will also support
non-repudiation.  Of course, you must "trust" your local host as far as
protecting your private key is concerned, but this is an acceptable
risk.

	2) Is PEM the preferred approach for building security into
	private company Internets as well?

PEM may satisfy most, if not all, private company E-Mail security
requirements.  As for whether or not it is a preferred approach for
building security, recent developments with respect to the licensing of
the technology may make this true.  However, this discussion is best
held on "pem-dev@tis.com".  Send mail to "pem-dev-request@tis.com" if
you want to get added to the list.

Jim

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 19:13:29 GMT
From:      urlichs@smurf.sub.org (Matthias Urlichs)
To:        comp.protocols.tcp-ip
Subject:   Re: Is there such a thing as a uucp daemon?

In comp.protocols.tcp-ip, article <165451@felix.UUCP>,
  darnold@felix.UUCP (Dave Arnold) writes:
< In article <9106120113.AA16777@toaster.SFSU.EDU> eps@cs.SFSU.EDU writes:
< >Will it interoperate with BSD uucpd?  Not out of the box.  For
< >one, AT&T's code uses 'e' protocol rather than 't' protocol over
< >TCP connections.
< 
< But, what's to stop me from running 'g' over TCP connections?

Nobody, assuming that you run it through a pty.

Directly attaching stdin/out to uucico won't work because it wants to issue
several ioctls which are only defined for terminals. This holds for "e"
protocol if the vendor hasn't changed his copy; thererfore a direct
connection between AT&T-UUCP and BSD-UUCP can't work..

Don't forget, however, that almost any protocol is more efficient than g when
run over a TCP path, except possibly "x" which relies on empty packets and
therefore won't work at all.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 22:20:45 GMT
From:      siemion@milton.u.washington.edu (John Siemion)
To:        comp.protocols.tcp-ip
Subject:   Easycad/Prisma CAD media choices for LAN implementation?


Is anyone out there familiar with Easycad/Prisma CAD devices?

When connecting these devices over a LAN, what media should be used?
Is IBM STP Type-1 necessary or can it also be done over UTP (PDS phone-type
wiring) ?

Incidentally, if a Synoptics concentrator LAN is used, what module should 
be used to connect this?  Is it an OSI module?  (I was told that the 
protocol used for this particular CAD system is actually based on
the OSI standard.)

Thanks for the info.   Please reply by email.  :)

John Siemion		siemion@u.washington.edu

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 91 23:39:35 GMT
From:      glass@postgres.Berkeley.EDU (Adam Glass)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls


In article <BOB.91Jun17182958@volitans.MorningStar.Com> Bob Sutterfield writes:
   When a gateway is configured as a firewall, what is the polite thing
   to do about those packets that aren't passed?  The packet itself
   should be dropped on the floor, but should the originating system be
   told anything about it?

   Suppose 25/tcp (SMTP) is allowed through but 23/tcp (Telnet) is
   blocked.  Should the gateway return a Host Unreachable in response to
   a telnet request?  Or maybe only a Port Unreachable or Protocol
   Unreachable, which would leave the originator wondering what other
   ports might be reachable or which protocols might be passed?  RFC792
   says that the destination host may send the Unreachable message back
   to the source host, but implies that only a host may send a Port or
   Protocol unreachable.  Should the firewall, since it's assuming the
   filtering responsibility, also assume responsibility for the ICMP
   returns?

   RFC1009 doesn't seem to address this area except to suggest in 4.4
   that address filters be supported, so I must rely on precedent for
   protocol filter behavior.  What is polite?  What is common?

The Host Requirements RFCs (rfc1122 and the other one) define 6 new codes for use in the ICMP Destination Unreachable datagrams.  these are 
                    6 = destination network unknown
                    7 = destination host unknown
                    8 = source host isolated
                    9 = communication with destination network
                            administratively prohibited
                   10 = communication with destination host
                            administratively prohibited
                   11 = network unreachable for type of service
                   12 = host unreachable for type of service

Unfortunately, I don't think much software actually understands these
yet.  9, and 10 are much more explicit and truthful than 'host unreachable'.
What an older implementation might do with an unknown code is anybody's guess.

I've also seen 'network down' used by a cisco box somewhere.

BTW: are you doing a hacking a 4.X bsd tcp-ip implementation to do
     packet filtering?

later,
Adam Glass










--
Adam Glass                           |Internet: glass@postgres.Berkeley.EDU
various roles at Berkeley	     |Home    : glass@Chaos.org

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 00:13:56 GMT
From:      pcc@s1.gov (Philip C. Cox)
To:        comp.protocols.tcp-ip
Subject:   slip and suns

I have been given the task of getting slip to work for the dialup part
of our network. We currently have a netblazer and a few T2500 telebit
modems connected to it. I am trying to figure out the best way to
provide my clients with an "office" atmosphere (i.e. be able to run X
and display it on their sun/X terminal at home).

I am very new at this part of the communications game, and would
appreciate
any comments as to the best solution AND source of such,
Thank You,

-Phil-



-- 
Philip C. Cox
Lawrence Livermore National Laboratory
pcc@s1.gov

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 01:50:49 GMT
From:      warren@worlds.com (Warren Burstein)
To:        comp.protocols.tcp-ip
Subject:   can a Bridge do null padding

This is really a Bridge question.  Is there a Bridge group?

I'm trying to get a uucp link working.  I am dialing from SCO Unix,
thru a Telebit Trailblazer Plus, to a Microcom AX/2400 which talks to
a Bridge, from there to a Decstation.  The protocol is failing, and it
seems that the reason is that an octal 15 is getting a spurious NUL
afterwards.  I have already disabled FCF and FCT.  Could the bridge be
doing this padding?

/|/-\/-\       The entire world			Jerusalem
 |__/__/_/     is a very strange carrot
 |warren@      But the farmer
/ worlds.COM   is not worried at all.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 03:44:09 GMT
From:      laws@CCINT1.RSRE.MOD.UK ("John")
To:        comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

Ian,

I agree with your history. It does seem to agree with my memory of events.
For the last 12 years I have been responsible for funding and the use of
the UK MOD interconnection to the US Internet (nee Arpanet). During that
period and prior to it I have had involvement with the JNT. BTW for many
years I carried academic traffic at my cost; more recently we (I & JNT)
have agreed to joint funding of the link. I still have an early 80's
lapel button "I survived the TCP transition" and I can recall C-Book
discussions well before that date.

I also recall that I was using BT (then GPO) X.25 in the late 70's.

It is some regret, to me at least, that my Country no longer knows how
to judge the time and place to invest in a Grand Challenge (probably has
something to do with the accountants moving in - value for money). In the
late 60's and early 70's the UK was co-equal with the US in networking.
There was also an internetworking (EIN) programme in Europe throughout
the 70's (see early ICCC Proceedings).

The JNT is responsible through various academic boards to the Dept of
Education & Science. In the mid/late 70's it would be unlikely to have
a winning case to the Boards for networking based upon a still developing
concept that was largely funded by a Defense community; much better to
have a case based upon concepts being developed in the civil/vendor
community.

John

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 04:36:49 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

In article <PCG.91Jun20160421@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>Not so suddendly. Comer says that TCP/IP introduced to ARPAnet around
>1980, and that gradually sites started dropping NCP based services and
>using TCP/IP, until in 1983 nearlly all sites had converted. I guess
>that if you really wanted a cutoff date it would be hard to say;
>probably one could say it was when more than say 80% (but any percentage
>greater than 50% would probably do) of ARPAnet backbone traffic had
>become IP based. Somebody should have such statistics around...

How soon these young whippersnappers forget.  Perhaps sometime I
should dig out my "I SURVIVED THE TCP TRANSITION - JANUARY 1, 1983"
button.

I'll have to check my copy of Comer's book to see what he actually
said, but let me assure you that the transition from NCP to TCP was
done in a great rush, occupying virtually everybody's time 100% in the
year 1982.  *Nobody* was ready.

On January 1, DCA had the ARPANET IMP software modified so that they
would not pass NCP traffic.  There was a hue and cry, and thus for
several months afterwards a number of sites (both NCP-only and NCP/TCP
sites which needed to be able to talk to NCP-only sites) had "reclama"
to use NCP.

It was a major painful ordeal, and one that those who experienced it
are not eager to repeat.  You can tell who we are -- the old farts who
smirk knowingly when "ISO transition" gets mentioned.

IMHO, however, it is likely that if DCA didn't do this, that NCP would
still be the standard protocol.  Now that there is no single agency
(particularly a military agency used to using its teeth) that runs the
Internet, I doubt such a thing could be done again.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 08:53:26 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: can a Bridge do null padding

In article <9106202109.aa00454@vaccine.worlds.COM>, warren@worlds.com
 (Warren Burstein) wrote:
>I'm trying to get a uucp link working.  I am dialing from SCO Unix,
>thru a Telebit Trailblazer Plus, to a Microcom AX/2400 which talks to
>a Bridge, from there to a Decstation.  The protocol is failing, and it
>seems that the reason is that an octal 15 is getting a spurious NUL
>afterwards.  I have already disabled FCF and FCT.  Could the bridge be
>doing this padding?

It sounds like your "bridge" is really a terminal server (perhaps
made by a company named Bridge Communications).

The answer to your question is yes, it is very likely that your
terminal server is running as a Telnet client on that particular
serial port and is performing <CR> to <CR><NUL> mappings on the
inbound characters, assuming they are typed by a human user on
a terminal.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 09:03:20 GMT
From:      paul@tetrauk.UUCP (Paul Ashton)
To:        comp.protocols.tcp-ip
Subject:   IEN116

Can anybody tell me where I can get a copy of IEN116 by email (no ftp) please?
I tried reverse engineering it but there are a couple of magic numbers that
I can't figure out.

Cheers,
-- 
Paul

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 09:11:19 GMT
From:      lnds@sherlock.mmid.ualberta.ca (Mark Israel)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun20.160334.11278@gdr.bath.ac.uk>, P.Smee@bristol.ac.uk 
(Paul Smee) writes:

> There's a basic problem here, which is that there is (still) no such
> thing as EBCDIC....   For a real real definitive answer, you'll have to get
> friendly with someone in IBM.

   I extracted the following from local documentation.

				Mark Israel
I have heard the Wobble!	userisra@mts.ucs.ualberta.ca

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

   In February 1987, a new eight-bit ISO character set standard,
8859/1, was ratified.  Also in 1987, IBM published an EBCDIC 
standard called Code Page 37, based on the ISO 8859/1 standard. 
Both of these standards contain identical character graphics.  The
ISO 8859/1 character set contains such EBCDIC characters as the
logical-not sign and the cent sign, and the new EBCDIC character
set contains the ISO tilde and circumflex, among other ASCII
characters.  The ISO 8859/1 standard is supported by many large
computer manufacturers, including DEC and IBM.  

   As we deal more and more with other machines using ISO-based
rather than EBCDIC-based character coding schemes, it becomes
imperative that we be able to move data from one machine to
another and back again without loss of information.  The mapping 
that results from using the ISO 8859/1 standard and the IBM
Code Page 37 EBCDIC will allow us to move information back and
forth between ISO- and EBCDIC-based machines with none of the
problems we have had in the past. 

    EBCDIC     ASCII     GRAPHIC  DESCRIPTION 
--------------------------------------------------------------------- 
    X'00'      X'00'       NUL   null 
    X'01'      X'01'       SOH   start of heading           (Ctrl-A) 
    X'02'      X'02'       STX   start of text              (Ctrl-B) 
    X'03'      X'03'       ETX   end of text                (Ctrl-C) 
    X'04'      X'9C'     ?        ... 
    X'05'      X'09'     	  HT    horizontal tabulation      (Ctrl-I) 
    X'06'      X'86'     ?        ... 
    X'07'      X'7F'       DEL   delete (rubout, DEL control char) 
    X'08'      X'97'     ?        ... 
    X'09'      X'8D'     ?        ... 
    X'0A'      X'8E'     ?        ... 
    X'0B'      X'0B'       VT    vertical tabulation        (Ctrl-K) 
    X'0C'      X'0C'        FF    form feed                  (Ctrl-L) 
    X'0D'      X'0D'     
    X'0E'      X'0E'       SO    shift-out                  (Ctrl-N) 
    X'0F'      X'0F'       SI    shift-in                   (Ctrl-O) 
    X'10'      X'10'       DLE   data link escape           (Ctrl-P) 
    X'11'      X'11'       DC1   device control 1    (X-Off, Ctrl-Q) 
    X'12'      X'12'       DC2   device control 2           (Ctrl-R) 
    X'13'      X'13'       DC3   device control 3     (X-On, Ctrl-S) 
    X'14'      X'9D'     ?        ... 
    X'15'      X'85'     ?        ... 
    X'16'      X'08'        BS    backspace                  (Ctrl-H) 
    X'17'      X'87'     ?        ... 
    X'18'      X'18'       CAN   cancel                     (Ctrl-X) 
    X'19'      X'19'       EM    end of medium              (Ctrl-Y) 
    X'1A'      X'92'     ?        ... 
    X'1B'      X'8F'     ?        ... 
    X'1C'      X'1C'       FS    file separator 
    X'1D'      X'1D'       GS    group separator 
    X'1E'      X'1E'       RS    record separator 
    X'1F'      X'1F'       US    unit separator 
    X'20'      X'80'     ?        ... 
    X'21'      X'81'     ?        ... 
    X'22'      X'82'     ?        ... 
    X'23'      X'83'     ?        ... 
    X'24'      X'84'     ?        ... 
    X'25'      X'0A'     
  LF    line feed                  (Ctrl-J) 
    X'26'      X'17'       ETB   end of transmission block  (Ctrl-W) 
    X'27'      X'1B'       ESC   escape                     (Escape) 
    X'28'      X'88'     ?        ... 
    X'29'      X'89'     ?        ... 
    X'2A'      X'8A'     ?        ... 
    X'2B'      X'8B'     ?        ... 
    X'2C'      X'8C'     ?        ... 
    X'2D'      X'05'       ENQ   enquiry                    (Ctrl-E) 
    X'2E'      X'06'       ACK   acknowledge                (Ctrl-F) 
    X'2F'      X'07'       BEL   bell                       (Ctrl-G) 
    X'30'      X'90'     ?        ... 
    X'31'      X'91'     ?        ... 
    X'32'      X'16'       SYN   synchronous idle           (Ctrl-V) 
    X'33'      X'93'     ?        ... 
    X'34'      X'94'     ?        ... 
    X'35'      X'95'     ?        ... 
    X'36'      X'96'     ?        ... 
    X'37'      X'04'       EOT   end of transmission        (Ctrl-D) 
    X'38'      X'98'     ?        ... 
    X'39'      X'99'     ?        ... 
    X'3A'      X'9A'     ?        ... 
    X'3B'      X'9B'     ?        ... 
    X'3C'      X'14'       DC4   device control 4           (Ctrl-T) 
    X'3D'      X'15'       NAK   negative acknowledge       (Ctrl-U) 
    X'3E'      X'9E'     ?        ... 
    X'3F'      X'1A'       SUB   substitute character       (Ctrl-Z) 
    X'40'      X'20'              space (blank) 
    X'41'      X'A0'     ?        no-break space 
    X'42'      X'E2'     ?        small a with circumflex accent 
    X'43'      X'E4'     ?        small a with diaeresis 
    X'44'      X'E0'     ?        small a with grave accent 
    X'45'      X'E1'     ?        small a with acute accent 
    X'46'      X'E3'     ?        small a with tilde 
    X'47'      X'E5'     ?        small a with ring above 
    X'48'      X'E7'     ?        small c with cedilla 
    X'49'      X'F1'     ?        small n with tilde 
    X'4A'      X'A2'     ?        cent sign 
    X'4B'      X'2E'     .        period, full stop 
    X'4C'      X'3C'     <        less-than sign 
    X'4D'      X'28'     (        left parenthesis 
    X'4E'      X'2B'     +        plus sign 
    X'4F'      X'7C'     |        vertical line (bar, "or" sign) 
    X'50'      X'26'     &        ampersand (and sign) 
    X'51'      X'E9'     ?        small e with acute accent 
    X'52'      X'EA'     ?        small e with circumflex accent 
    X'53'      X'EB'     ?        small e with diaeresis 
    X'54'      X'E8'     ?        small e with grave accent 
    X'55'      X'ED'     ?        small i with acute accent 
    X'56'      X'EE'     ?        small i with circumflex accent 
    X'57'      X'EF'     ?        small i with diaeresis 
    X'58'      X'EC'     ?        small i with grave accent 
    X'59'      X'DF'     ?        small sharp s, German 
    X'5A'      X'21'     !        exclamation mark 
    X'5B'      X'24'     $        dollar sign 
    X'5C'      X'2A'     *        asterisk (star) 
    X'5D'      X'29'     )        right parenthesis 
    X'5E'      X'3B'     ;        semicolon 
    X'5F'      X'AC'     ?        not sign 
    X'60'      X'2D'     -        minus sign or hyphen 
    X'61'      X'2F'     /        solidus (slash) 
    X'62'      X'C2'     ?        capital A with circumflex accent 
    X'63'      X'C4'     ?        capital A with diaeresis 
    X'64'      X'C0'     ?        capital A with grave accent 
    X'65'      X'C1'     ?        capital A with acute accent 
    X'66'      X'C3'     ?        capital A with tilde 
    X'67'      X'C5'     ?        capital A with ring 
    X'68'      X'C7'     ?        capital C with cedilla 
    X'69'      X'D1'     ?        capital N with tilde 
    X'6A'      X'A6'     ?        broken bar 
    X'6B'      X'2C'     ,        comma 
    X'6C'      X'25'     %        percent sign 
    X'6D'      X'5F'     _        low line (underscore) 
    X'6E'      X'3E'     >        greater-than sign 
    X'6F'      X'3F'     ?        question mark 
    X'70'      X'F8'     ?        small o with slash 
    X'71'      X'C9'     ?        capital E with acute accent 
    X'72'      X'CA'     ?        capital E with circumflex accent 
    X'73'      X'CB'     ?        capital E with diaeresis 
    X'74'      X'C8'     ?        capital E with grave accent 
    X'75'      X'CD'     ?        capital I with acute accent 
    X'76'      X'CE'     ?        capital I with circumflex accent 
    X'77'      X'CF'     ?        capital I with diaeresis 
    X'78'      X'CC'     ?        capital I with grave accent 
    X'79'      X'60'     `        grave accent 
    X'7A'      X'3A'     :        colon 
    X'7B'      X'23'     #        number sign (hash mark, sharp sign) 
    X'7C'      X'40'     @        commercial at 
    X'7D'      X'27'     '        apostrophe (single quote) 
    X'7E'      X'3D'     =        equals sign 
    X'7F'      X'22'     "        quotation mark (double quote) 
    X'80'      X'D8'     ?        capital O with slash 
    X'81'      X'61'     a        small a 
    X'82'      X'62'     b        small b 
    X'83'      X'63'     c        small c 
    X'84'      X'64'     d        small d 
    X'85'      X'65'     e        small e 
    X'86'      X'66'     f        small f 
    X'87'      X'67'     g        small g 
    X'88'      X'68'     h        small h 
    X'89'      X'69'     i        small i 
    X'8A'      X'AB'     ?        angle quotation mark left (<< mark) 
    X'8B'      X'BB'     ?        angle quotation mark right (>> mark) 
    X'8C'      X'F0'     ?        small eth, Icelandic 
    X'8D'      X'FD'     ?        small y with acute accent 
    X'8E'      X'DE'     ?        small thorn, Icelandic 
    X'8F'      X'B1'     ?        plus or minus sign 
    X'90'      X'B0'     ?        degree sign 
    X'91'      X'6A'     j        small j 
    X'92'      X'6B'     k        small k 
    X'93'      X'6C'     l        small l 
    X'94'      X'6D'     m        small m 
    X'95'      X'6E'     n        small n 
    X'96'      X'6F'     o        small o 
    X'97'      X'70'     p        small p 
    X'98'      X'71'     q        small q 
    X'99'      X'72'     r        small r 
    X'9A'      X'AA'     ?        ordinal indicator feminine 
    X'9B'      X'BA'     ?        ordinal indicator, masculine 
    X'9C'      X'E6'     ?        small ae dipthong 
    X'9D'      X'B8'     ?        cedilla 
    X'9E'      X'C6'     ?        capital AE dipthong 
    X'9F'      X'A4'     ?        currency sign (lozenge) 
    X'A0'      X'B5'     ?        micro sign (small mu) 
    X'A1'      X'7E'     ~        tilde (wavy line) 
    X'A2'      X'73'     s        small s 
    X'A3'      X'74'     t        small t 
    X'A4'      X'75'     u        small u 
    X'A5'      X'76'     v        small v 
    X'A6'      X'77'     w        small w 
    X'A7'      X'78'     x        small x 
    X'A8'      X'79'     y        small y 
    X'A9'      X'7A'     z        small z 
    X'AA'      X'A1'     ?        inverted exclamation mark 
    X'AB'      X'BF'     ?        inverted question mark 
    X'AC'      X'D0'     ?        capital D with stroke, Icelandic eth 
    X'AD'      X'DD'     ?        capital Y with acute accent 
    X'AE'      X'FE'     ?        capital thorn, Icelandic 
    X'AF'      X'AE'     ?        registered sign (circled capital R) 
    X'B0'      X'5E'     ^        circumflex accent 
    X'B1'      X'A3'     ?        pound sign (Sterling currency) 
    X'B2'      X'A5'     ?        yen sign (Nipponese currency) 
    X'B3'      X'B7'     ?        middle dot (scalar product) 
    X'B4'      X'A9'     ?        copyright sign (circled capital C) 
    X'B5'      X'A7'     ?        section sign (S-half-above-S sign) 
    X'B6'      X'B6'     ?        pilcrow (paragraph, double-barred P) 
    X'B7'      X'BC'     ?        fraction one-quarter (1/4) 
    X'B8'      X'BD'     ?        fraction one-half (1/2) 
    X'B9'      X'BE'     ?        fraction three-quarters (3/4) 
    X'BA'      X'5B'     [        left square bracket 
    X'BB'      X'5D'     ]        right square bracket 
    X'BC'      X'AF'     ?        macron 
    X'BD'      X'A8'     ?        diaeresis or umlaut 
    X'BE'      X'B4'     ?        acute accent 
    X'BF'      X'D7'     ?        multiply sign (vector product) 
    X'C0'      X'7B'     {        left curly bracket (left brace) 
    X'C1'      X'41'     A        capital A 
    X'C2'      X'42'     B        capital B 
    X'C3'      X'43'     C        capital C 
    X'C4'      X'44'     D        capital D 
    X'C5'      X'45'     E        capital E 
    X'C6'      X'46'     F        capital F 
    X'C7'      X'47'     G        capital G 
    X'C8'      X'48'     H        capital H 
    X'C9'      X'49'     I        capital I 
    X'CA'      X'AD'     ?        soft hyphen 
    X'CB'      X'F4'     ?        small o with circumflex accent 
    X'CC'      X'F6'     ?        small o with diaeresis 
    X'CD'      X'F2'     ?        small o with grave accent 
    X'CE'      X'F3'     ?        small o with acute accent 
    X'CF'      X'F5'     ?        small o with tilde 
    X'D0'      X'7D'     }        right curly bracket (right brace) 
    X'D1'      X'4A'     J        capital J 
    X'D2'      X'4B'     K        capital K 
    X'D3'      X'4C'     L        capital L 
    X'D4'      X'4D'     M        capital M 
    X'D5'      X'4E'     N        capital N 
    X'D6'      X'4F'     O        capital O 
    X'D7'      X'50'     P        capital P 
    X'D8'      X'51'     Q        capital Q 
    X'D9'      X'52'     R        capital R 
    X'DA'      X'B9'     ?        superscript one 
    X'DB'      X'FB'     ?        small u with circumflex accent 
    X'DC'      X'FC'     ?        small u with diaeresis 
    X'DD'      X'F9'     ?        small u with grave accent 
    X'DE'      X'FA'     ?        small u with acute accent 
    X'DF'      X'FF'     ?        small y diaeresis 
    X'E0'      X'5C'     \        reverse solidus (backslash) 
    X'E1'      X'F7'     ?        divide sign (dot over line over dot) 
    X'E2'      X'53'     S        capital S 
    X'E3'      X'54'     T        capital T 
    X'E4'      X'55'     U        capital U 
    X'E5'      X'56'     V        capital V 
    X'E6'      X'57'     W        capital W 
    X'E7'      X'58'     X        capital X 
    X'E8'      X'59'     Y        capital Y 
    X'E9'      X'5A'     Z        capital Z 
    X'EA'      X'B2'     ?        superscript two (squared) 
    X'EB'      X'D4'     ?        capital O with circumflex accent 
    X'EC'      X'D6'     ?        capital O with diaeresis 
    X'ED'      X'D2'     ?        capital O with grave accent 
    X'EE'      X'D3'     ?        capital O with acute accent 
    X'EF'      X'D5'     ?        capital O with tilde 
    X'F0'      X'30'     0        digit zero 
    X'F1'      X'31'     1        digit one 
    X'F2'      X'32'     2        digit two 
    X'F3'      X'33'     3        digit three 
    X'F4'      X'34'     4        digit four 
    X'F5'      X'35'     5        digit five 
    X'F6'      X'36'     6        digit six 
    X'F7'      X'37'     7        digit seven 
    X'F8'      X'38'     8        digit eight 
    X'F9'      X'39'     9        digit nine 
    X'FA'      X'B3'     ?        superscript three (cubed) 
    X'FB'      X'DB'     ?        capital U with circumflex accent 
    X'FC'      X'DC'     ?        capital U with diaeresis 
    X'FD'      X'D9'     ?        capital U with grave accent 
    X'FE'      X'DA'     ?        capital U with acute accent 
    X'FF'      X'9F'     ?        ... 

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 09:48:54 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

I disagree with you argument, Jason, about the government not being
an organization that should provide archives.  Yes, they might select
what is in the archive, but I would hope that any commercial provider would
also "select" what they archive.  Different archivers would potentially
select different overlapping sets.  The Library of Congress is an archive,
along with the National Archives.  Both contain docuements which are
unique to the archive and which are duplicated by other libraries or 
archives.  Why should software be any different?

dennis

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 10:05:25 GMT
From:      liam@dcs.qmw.ac.uk (William Roberts;)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking experiences with FDDI interfaces for Sun's

In <3384@redstar.dcs.qmw.ac.uk> liam@dcs.qmw.ac.uk (William Roberts;) writes:

>In <9106041306.AA09116@msr.EPM.ORNL.GOV> dunigan@MSR.EPM.ORNL.GOV (Tom 
 Dunigan 
>576-2522) writes:
 
>3) It gives *no measurable performance increase* for NFS - even with both 
>client and server on FDDI and tests which don't involve server disk access 
>there is no increase in performance over Ethernet connections.

I had some mail saying:

|    I'd  be *fascinated* to read or hear more about your experiences
|with FDDI cards, especially Sun's and *especially* why Sun's doesn't
|get any speed inprovements with FDDI vs. Ethernet!

I'm quite prepared to believe that Sun4 machines (I was using a Sun 4/280 and 
a Sun 4/160) can drive the FDDI network at greater than Ethernet bandwidth: 
one of the planned experiments was to change the FDDI driver software so that 
it generated continuous "idle traffic" transmitting strips of a VME 
framebuffer, sending to another machine which writes such things direct into 
its display memory.

What my experiments showed was that there is no performance improvement for 
NFS operations benchmarked with the Legato "nhfsstone" benchmark: I've a paper 
on this in the UK Sun User Group conference in September (in fact an extention 
of a paper I gave at the European Unix User Group Autumn '90 conference) and 
that's probably the best way to look at what I've done. There should be a 
report on the overall FDDI Pilot project (it's being done for the JNT: the 
body which runs the UK academic network) but I don't know the timescale on 
that any more.

FDDI doesn't make any difference because present machines can't really compute 
at those speeds (well, Crays and the like perhaps, but nothing that Sun 
manufacture). The only applications which ship data around that fast and which 
might benefit from FDDI are ones where the machines at either end don't have 
to manipulate the data as it comes in - they just pump bursts of data for 
later use. Obvious examples are live video and very low-level data transfer 
between peripherals (FDDI started life as something for IBM channels, I 
believe): the only one which seems pertinent to workstations is swapping over 
FDDI.
--

% William Roberts                 Internet:  liam@dcs.qmw.ac.uk
% Queen Mary & Westfield College  UUCP:      liam@qmw-dcs.UUCP
% Mile End Road                   Telephone: +44 71 975 5234
% LONDON, E1 4NS, UK              Fax:       +44 81-980 6533

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 12:57:10 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun19.190752.28034@ssdc.honeywell.com> satya@ssdc.honeywell.com (Satya Prabhakar) writes:

>I am involved in developing the ISO/RDA protocol between CDC 920
>and IBM 3090.  CDC 920 uses ASCII representation and the IBM
>uses EBCDIC. I am looking for C routines that convert ASCII strings
>into EBCDIC strings and vice-versa.  We need these DESPERATELY and
>asap. If you have some information re: these, please let me know
>asap. I would REALLY appreciate your help.

Well, let's see--this is a hard one, seeing as how it's a C programming
problem, of course it's posted to comp.lang.c, isn't it?

>Newsgroups: comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions

Oops, guessed wrong on that one...

Try building a 256 by 2 char array, initializing [x,0] with the EBCDIC
code set and [x,1] with the ANSI (it hasn't been ASCII for many years) 
code set, so that you can use the character as the offset to find out
what it converts to.

Typing in the initialization strings are left as an exercise to the
programmer. (You could do this with pointers, but that's a little
more complicated, and you said you were in a hurry.)

>Very many thanks in advance.

Anytime.

-- 
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?".

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 14:11:59 GMT
From:      mickey@bigglescetia.dml (M J Dance Account)
To:        soc.culture.british,comp.protocols.tcp-ip
Subject:   Re: IP in the UK (was Re: Fingering the English)

Well, looks like I may well unsubscribe to this group as for
the past few weeks the only traffic I have seen is about Janet
and ARPA all of which has little to do with british culture
(well I suppose that Janet *WAS* set up by british people
but hardly a majority of them).

ANyway, it seems that people are haggling over time-scales so
I'll add my comments.

1) I do not known the exact time scales *BUT* I was doing
research in an English university in the period 1984-1987
and Janet was pretty new at that time (althoug it did exist).
ARPA net also existed as my research weas in large networks
and there were *NO* large british networks so most of the
papers I read were from the USA, an awful lot were from BBN
on the implementation of routing in the ARPA net.
2) At this time most published material (which of course lags
behind installed systems) was about IMPs connecting diverse
machines and the word UNIX was almost never seen.
3) The coloured book protocols (Janet) existed but I never
saw a working installation (my university was not a very large
one) although major (in size) universities were inter-connected.
4) Almost all local network research was based on Basic Block
Protocol on Cambridge rings (a sort of token-ring network) which
as far as I am aware never left England (well it reached Scotland:))
5) As a result of this all that I known about TCP/IP I have learnt
since (and this learning was more or less obligatory given that I
work for a computer constructor that sells work-stations).
6) Perhaps things have changed but all=most all that I learnt
about networking protocols (with the exception of routing protocols)
during my research has been of no use to me at all. IMHO this is
why England lags behind in networking (well that and British Telecoms
pricing strategy)

For those who are persistent enough to get this far, what are you
hoping to achieve. Thos who think Janet is wonderful are not going
to change their minds and vv those who think the opposite are
unlikely to change their minds. I doubt that those who decide
British university policy ever read this group (I even doubt that
most of them even use a network:).

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 15:10:34 GMT
From:      chrisv@cmc.com (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP Packages/Appl. Mgt./CMOT questions

To add my two cents worth (since I have used the product extensively since about
March of this year):
>In article <1991Jun18.184913.8206@NCoast.ORG> sfb@NCoast.ORG (Stephen F. Bush) writes:
>>(1) HP OpenView vs. Cabletron Spectrum - has anyone used either one and what
>>    are your opinions about them? Any problems with either product? 
>>    I'm trying to determine which package to buy.
>>
>>(1a) Is there any product, such as the above, which handles application
>>     management?
This is all dependant upon the information available in the agent MIB.
Some vendors, such as H/P, have put information such as % swap, CPU
utilization, amount of space left on each file system, etc. into their
MIBs that ship with their O/S. Since OPENVIEW lets you load in any mib,
and the application builder lets you decide how to collect and display
that information, the product is very capable of performing application
management. I've heard a rumor that SUN will be following with their
version of system management variables in the SVr4 version of SUNOS 
coming soon to a theater near you (:*).
>
>(2) Does anyone know whether the following devices already do, or will 
>    support SNMP?

I never saw your original post. 
One of the main reasons that I needed to use OPENVIEW was to manage our
FDDI agent on FDDI which employs the IETF working group FDDI MIB.
Since it was(and is) in the experimental branch, using the application
builder allowed me to create applications that used these parameters
and "tailor" the product to manage FDDI. It was flexible and easy. I'd
recommend it.

Chris VandenBerg
CMC -  A Rockwell Intl Co.   125 Cremona Dr.   Goleta, CA. 93117
Internet - chrisv@cmc.com          ma-bell - 805-562-3127 

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 16:48:36 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting a very large population


Gareth, if you run OSPF and the router implements variable length subnet
support properly, subnets of a subnetted network do not need to
be connected.  We do this at NASA.  It does work.  It should work with
any vendor who implements according to the spec.  We sort of stumbled into
this by accident when configuring some routers, but since then, we've found
it very useful.  It shouldn't be used as a way to kludge around a bad design,
but there are many cases where it's useful.

I suggest you ask the router vendors you are taking bids from for this
support.  I expect most of them will tell you they can now support
this configuration.

						Thanks,
						   Milo

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 17:32:57 GMT
From:      braudes@seas.gwu.edu (Bob Braudes)
To:        comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Looking for TCP, XTP, VMTP Sources

I am looking for the sources for various transport level protocols, such
as TCP, XTP, and VMTP.  Any pointers or suggestions would be appreciated.
Please feel free to respond via email.  Thanks.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 19:19:11 GMT
From:      dag@fciva.FRANKCAP.COM (Daniel A. Graifer)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun20.115613.13073@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <1991Jun19.190752.28034@ssdc.honeywell.com> satya@ssdc.honeywell.com (Satya Prabhakar) writes:
>>uses EBCDIC. I am looking for C routines that convert ASCII strings
>>into EBCDIC strings and vice-versa.  We need these DESPERATELY and
>
>  I don't understand.  What is wrong with a simple loop replacing
>c with EBCDIC[c] for each char c in the string of unsigned chars.
>Something like:
>	while(*p) { *p = EBCDIC[*p]; p++;}
>
> You do need to initialize your table.  Pick up the tables used on the
>3090 and use those.  If you don't like that choice build your own in
>the grand tradition of mutual inconsistency which currently exists in
>the ASCII <-> EBCDIC translation world.

I wrote a two line c program to output chars0-256, and
piped this through dd -ascii and od -c to create my
table. This way, the table is at least consistant with
what dd produces.  Note that the table produced this way
will not necessarily be invertable.  (But then neither
are the mainframe translate tables.  If I recall my
Burroughs B[67]000 days correctly (now Unisys A-Series),
the translation of ASCII "!" was not invertable.  And
you may have a real problem with the >100 EBCDIC chars
that aren't meaningful.

Dan
-- 
Daniel A. Graifer			Coastal Capital Funding Corp.
Sr. Vice President, Financial Systems	7900 Westpark Dr. Suite A-130
(703)821-3244				McLean, VA  22102
uunet!fciva!dag				fciva.FRANKCAP.COM!dag@uunet.uu.net

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 20:21:48 GMT
From:      jason@CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

The Library of Congress and the National Archives are very special
organizations. The LofC is not selective in what it keeps in its collection;
every publisher is required to submit two copies (if memory serves) to the
LofC to be issued a valid ISBN number, which is close to mandatory in the
publishing business.

Were a software archive to be founded under government auspices subject to a
charter which required it to keep a copy of everything submitted, I'd be
less leary; however, such a charter is unlikely and perhaps undesired.

Finally, I agree that other archivers would spring up providing those bits
the government refused to provide; those archives, however, would not have
the special financial (i.e. taxpayer or cross-subsidized from transport
fees) support that a government archive would have, and could not compete
with such an archive on a fair basis.

Jason

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 21:17:37 GMT
From:      tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  Subnetting Class B Internet Number

You should read RFC 1219 about this.  It doesn't discuss
all the pros and cons of every possible method, but does
give one method that is the best known (I think) but requires
variable-mask routing protocols like OSPF.

PT

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 22:27:10 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 931, PEM, and SNMP Security

In article <9106201757.AA15689@TIS.COM> James M Galvin <galvin@TIS.COM> writes:
> First, RFC 931 is not a security panacea.  Let me say that again more
> strongly.  RFC 931 does not, can not, and will not solve the security
> problems of the Internet.

Agreed. It just establishes a minimum standard for security above the
TCP level. Mail forgers, news forgers, and Internet system crackers all
rely heavily on the anonymity of a TCP connection from a mainframe with
many accounts. RFC 931 strips away that anonymity. Surely you agree that
this is a worthwhile minimum standard?

> The problem is you have no reason to believe anything a 931 server tells
> you in the general case.

I've never understood the logic in that argument. I think people are
forgetting that RFC 931 usernames must be interpreted *in the context of
the machine generating the usernames*. Let me explain.

With RFC 931, you get addresses like shmoe@tis.com instead of
<anonymous>@tis.com. It is patently obvious that you can trust ``shmoe''
only if you trust tis.com and the communications links between yourself
and tis.com. Similarly, if you get an address like
shmoe@mac37.opennet.tis.com, you can trust ``shmoe'' only if you trust
mac37.opennet.tis.com, tis.com's name server, and the communications
links. Trust, of course, is only as strong as its weakest link.

So what?

One important application of RFC 931 is to trace network attacks. If you
record an address like shmoe@tis.com, you can talk to TIS later, and if
they take responsibility for tis.com then shmoe@tis.com is in trouble.
If you record an address like shmoe@mac37.opennet.tis.com, and TIS tells
you later that mac37 is owned by Sally Smuthers, then Sally is going to
have some explaining to do.

In other words, you identify the first place where trust was violated,
and find out who was responsible for that place. It is *absolutely*,
*totally* irrelevant whether the information received *past* that place
is accurate or can be trusted. In this case, it is *absolutely*,
*totally* irrelevant whether you get shmoe@mac37 or sally@mac37 or
nobody@mac37.

Yes, James, Sally can forge any username she wants on mac37, because
it's her machine. But because she has responsibility for it, there is
absolutely no need to trace attacks further than the machine itself.

You say that it's a problem that usernames can't be trusted unless the
machine can. I don't believe you. Why is it a problem?

Let me guess at your answer. It is a problem if you trust a username
*independently* of the host reporting the username---if, for instance,
you say that any user named ``root'' on any machine on the Internet can
log in to yours, provided that RFC 931 reports root.

But that's a really stupid thing to do. RFC 931 presumes that usernames
are taken in the context of the system reporting the username.

So, James, why is RFC 931 a problem? It *does* increase security in the
case of a mainframe---shmoe@tis.com can no longer hide behind anonymous
TCP connections. This is a definite improvement, one that will help CERT
tremendously, and I don't see why you're so opposed to it.

> However, the Internet does not have a secure architecture.  To suggest
> that 931 supports TCP authentication in the absence of a secure
> architecture is ludicrous.

But it does stop all attacks above TCP. In fact, it makes some below-TCP
attacks much more difficult, because (in Steve Bellovin's words) it uses
a second TCP connection not under control of the attacker. I'd love to
see you try a source routing attack against an RFC 931-cognizant host.

> The bottom line is RFC 931 does not stop all username forgeries above
> the TCP level in the general case.  And, to suggest that to break RFC
> 931 requires breaking TCP security makes no sense.

Uh, wait a minute. I don't understand either of those statements.

RFC 931 *does* stop all username forgeries above the TCP level. That's
practically the definition of the protocol. What did you mean to say?

Breaking RFC 931 *does* require breaking TCP security---you cannot forge
a username unless you can forge TCP packets. (This is, of course,
vacuously true when you have complete control over the machine.)

Let me put this differently. If someone comes up with a secure version
of TCP---say, TCP with good encryption---and plugs in RFC 931, SMTP and
NNTP and TELNET and other user-level TCP protocols will be completely
secure. No ifs, ands, or buts.

> Kerberos is better than RFC 931, in the Internet today.

I agree that Kerberos is a far more secure protocol, since it addresses
security both above and below TCP, and only allows half a dozen major
attacks as outlined by Bellovin. If you can convince all vendors to
support Kerberos v5 in systems they release tomorrow, and if you can
make it work across wide-area nets without an n^2 exchange of passwords
at the top level, and if you can convince the U.S. government to export
it to Europe, and if you can get rid of all the bugs, then it will be
quite usable in practice.

Or have you forgotten that Europe is part of the Internet?

Same comments about PEM---though of course PEM is useless for tracing
Internet attackers. In fact, Kerberos is too, unless you throw out all
the old telnetds which people need for wide-area logins.

> With RFC 931, secure
> applications must be built on it, as opposed to with it, i.e., the
> access control policy must be rebuilt for each application (or at least
> repeated for it).

What do you mean by this?

> Finally, as for SNMP security being ridiculously vulnerable to
> known-plaintext, even chosen-plaintext attacks, I must disagree.

Okay, I should have explained this better. In practice, it's quite
obvious from the most basic traffic analysis exactly what information
machines are asking from each other. Let's assume you can only figure
out 1% of the SNMP queries; that's more than enough for cryptanalysis.
The responses are not only in an extremely structured format, but
contain essentially public information. If host A gives SNMP information
to hosts X and Y, and host X can intercept even a fraction of the
encrypted traffic to host Y, then it can ask for the same information
itself and have completely known plaintext for a whole bunch of packets.
That's what I was calling ridiculous. Even if host X can't get any of
the information, it can guess pretty well---SNMP-reported userids come
in order, each network connection is specified by 12 bytes carrying only
a few bytes worth of information, etc.

> I do not see how the protocols are subject to chosen-plaintext attacks.
> This kind of attack assumes I can submit a plaintext message and receive
> a ciphertext message in return.

Yep. In practice you can ask host Y something that will make it send a
known SNMP query to host A. (Simple example, derived from one of the
proposed uses of SNMP: Ask Y's mailer to verify an address at A.) There
are dozens of ways to do this.

> I must also disagree with the comment that the SNMP security protocols
> require the exchange of a whole bunch of keys in advance.  A careful
> reading of the specifications will tell you that a management station
> and an agent need only share

That's the problem, right there. If you have N trusted hosts that
exchange SNMP information, you need N^2 keys. That's unusable. Do you
still disagree?

---Dan

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 91 23:02:12 GMT
From:      li@cambridge.oracorp.com (Li Gong)
To:        comp.protocols.tcp-ip
Subject:   Re: Authentication & Internet Protocol Suite

In article <1991Jun18.211641.4075@beaver.cs.washington.edu> bcn@cs.washington.edu (Clifford Neuman) writes:
>The trusted system need only hold the keys for local clients and
>servers (called a realm).  If the server is compromised, this isolates
>the damage to the principals registered in that realm.
> ...
>In version 5, realms can be organized hierarchically.  Thus, you can
>often get by maintaining entries for only immediate ancestors and
>descendants in the tree.

When a user from a good realm trying to talk to a service in a broken
realm, what happens ?  Does the compromised KDC get to know the
secrets of the remote users ?  Other damages ?  If so, isn't it the
case that damages are *not* confined to the local (broken) realm ?

>be very long lived.  This presents a problem for revocation.

Very much agreed.  The public-key systems give a false impression that
they can save because of the reduced number of interactions with the
servers.  But this also reduces the chance for revocation.
-- 
Li GONG, PhD              | Email:  li@cambridge.oracorp.com
ORA Corporation           | Tel  :  (617) 354-8230
675 Massachusetts Avenue  | Fax  :  (617) 354-6593
Cambridge, MA 02139       | (li@oracorp.com, li@oravax.UUCP)

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 00:27:15 GMT
From:      siemion@milton.u.washington.edu (John Siemion)
To:        comp.protocols.tcp-ip
Subject:   ISICAD/Calcomp/Prisma CAD media choices for LANs?


Is anyone out there familiar with ISICAD/Calcomp/Prisma CAD devices?
 
When connecting these devices over a LAN, what media should be used?
Is IBM STP Type-1 necessary or can it also be done over UTP (PDS phone-type
wiring) ?

Incidentally, if a Synoptics concentrator LAN is used, what module should 
be used to connect this?  Is it an OSI module?  (I was told that the 
protocol used for this particular CAD system is actually based on
the OSI standard.)

Thanks for the info.   Please reply by email.  :)

John Siemion		siemion@u.washington.edu

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 01:25:18 GMT
From:      mcdonald@aries.scs.uiuc.edu (Doug McDonald)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK


In article <PCG.91Jun20161256@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 18 Jun 91 03:24:16 GMT, PADLIPSKY@A.ISI.EDU (Michael Padlipsky) said:
>
>PADLIPSKY> the Colourisers SHOULD have known better: by the late '70s
>PADLIPSKY> TCP/IP implementations were running whilst the only thing the
>PADLIPSKY> ISORMites had running was their mouths.
>
>Not necessarily so; they had viable if fiarly rudimentary X.25
>technology to show. At the end of the seventies one could observe:
>
>	1) a large scale production WAN, the ARPAnet
>	2) experimental or otherwise small scale X.25 technology
>
>	3) experimental or otherwise small scale Internet technology
>	4) papers and intentions about ISO/OSI
>

A more interesting date, to me, was in late 1973 (or was it early 1974).
I proved that the then-existing technology was not so robust by
crashing the entire Arpanet and about 30% of the computers on it
(all the IBM 360s).

Three times in one day. This resulted in a big guru fest in an attempt
to figure out how it happened.

Doug McDonald

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 01:28:38 GMT
From:      rsm@math.arizona.edu (Robert S. Maier)
To:        comp.protocols.tcp-ip,alt.security
Subject:   nosy finger daemons

Several machines in the nrl.navy.mil domain have an interesting
undocumented feature: if you finger them, they finger you right back! 
Examples are tiger.nrl.navy.mil and ccf.nrl.navy.mil.  Try it
yourself; if your finger daemon logs incoming requests you'll pick
it up at once.

If you finger either, it's always tiger.nrl.navy.mil that fingers you.
So the modifications to their finger daemons must be nontrivial.

Apparently the folks at nrl.navy.mil (Navy Research Laboratory) didn't
want to erect a full-fledged firewall, so they compromised on this.
It doesn't seem a very effective protection against the outside world
though.  In fact it's rather amusing.  Has anyone ever seen anything
else like this?

I haven't checked to see whether their other daemons (e.g. rusersd)
are nosy too, but I wouldn't be surprised.  Apparently `Caller ID' has
come to the Internet.

-- 
Robert S. Maier   | Internet: rsm@math.arizona.edu, rsm@cs.arizona.edu
Dept. of Math.    | UUCP: uunet!arizona!amethyst!rsm
Univ. of Arizona  | Bitnet: maier@arizrvax
Tucson, AZ  85721 | FAX: +1 602 621 8322
U.S.A.            | Voice(POTS): +1 602 621 6893  /  +1 602 621 2617

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 08:08:38 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: seeking experiences with FDDI interfaces for Sun's

In article <3393@redstar.dcs.qmw.ac.uk> liam@dcs.qmw.ac.uk (William Roberts;) writes:
>I'm quite prepared to believe that Sun4 machines (I was using a Sun 4/280 and 
>a Sun 4/160) can drive the FDDI network at greater than Ethernet bandwidth: 
>one of the planned experiments was to change the FDDI driver software so that 
>it generated continuous "idle traffic" transmitting strips of a VME 
>framebuffer, sending to another machine which writes such things direct into 
>its display memory.

Someone here did some tests with a program that just sends UDP or TCP data,
not NFS, 4/3xx and 4/4xx machines, over FDDI.  For certain datagram sizes
he was able to get much better than Ethernet bandwidth.  But at other
sizes, it wasn't much better than Ethernet; I suspected that this was due
to kernel buffering strategies optimized for Ethernet's smaller MTU.

>FDDI doesn't make any difference because present machines can't really compute 
>at those speeds (well, Crays and the like perhaps, but nothing that Sun 
>manufacture).

Be aware that the machines you said you tried are not "present machines."
The 4/280 and 4/160 have been around for almost four years.  The current
top-of-the-line Sun-4's are about an order of magnitude faster.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 09:29:37 GMT
From:      perry@MCL.UNISYS.COM (Dennis Perry)
To:        comp.protocols.tcp-ip
Subject:   Re: building an interstate (data) highway with no roadmaps

Jason, although I agree the Library of Congress and National Archives are
very special organizations, having used them extensively in the 6 years
I have been in Washington, they are selective in what they keep, even if
parts must be submitted to receive a number.  For example, the LoC does not
keep old catalogs (no number?) in general, but they do keep old Sears 
catalogues (historical interest?)  Another government archive that comes
to mind is DTIC.  The government has tried to privatize DTIC, but industry
showed no interest because of the cost of maintaining a lot of information
that was not commercially of interest.  I think the government has the
same problem with Landsat pictures.

I suspect that what this illustrates is that commercial archives will select
material based on the probabiliy of making money, not on the intrensic value
of the material.  Thus we get the issue of maintaining historical archives
(old RFCs) vs current or standard RFC only.  Or in the case of software,
that which sells will be available and that which doesn't won't be.  This
is good from a commercial point of view, but may be bad from other points
of view, for what sells today, may not sell tomorrow and will be purged
from the archive.

I think there is room for both commercial and government archives.  In fact,
there exist today commercial ventures which sell that which is freely available
from the government.  Why do people pay for what is free?  Probably because
of the value added featrues such as accessability, packaging, convenience,
advertizing (i.e. knowing it is available), etc.

dennis

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 16:00:26 GMT
From:      alo@hiisi.hut.fi (Antti Louko)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

In article <RSM.91Jun21182838@coral.math.arizona.edu> rsm@math.arizona.edu (Robert S. Maier) writes:
>Several machines in the nrl.navy.mil domain have an interesting
>undocumented feature: if you finger them, they finger you right back! 
>Examples are tiger.nrl.navy.mil and ccf.nrl.navy.mil.  Try it
>yourself; if your finger daemon logs incoming requests you'll pick
>it up at once.
 
>though.  In fact it's rather amusing.  Has anyone ever seen anything
>else like this?

I haven't seen it before, but I have thought about it. I decided not
to implement it. Why? Think about it. What if my fingerd and theirs
both implement this "feature"? How long they will keep fingering each
other?

Or if I find another internet site who implements this, say
rixrax.foo.com and give command

finger @tiger.nrl.navy.mil@rixrax.foo.com

and let them finger each other forever.

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 18:58:41 GMT
From:      jrb@jove.cs.pdx.edu (James Binkley)
To:        comp.protocols.tcp-ip
Subject:   SNMP experiences?




In the process of trying to learn something about SNMP
and looking at RFC1157, I started wondering about whether
or not one would expect one vendor's client to work with
another vendor's server. There is probably no reason to
expect that there would be problems, but I was wondering
what the experiences of those who have actually used SNMP
in the real world are like (in contrast to my just reading
about it...)? Does one expect different vendor's software
to work together and if so, are there any problems observed?
I guess more broadly, can anyone say something about whether
or not SNMP is really solving problems and proving to be useful.
Features provided that aren't useful? Features needed that
aren't provided? ... that sort of thing.

				Just curious,

				Jim Binkley
				jrb@jove.cs.pdx.edu

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 19:09:05 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Encapsulation of IBM SNA Traffic by Routers

Of late, there have been several manufacturers that have announced Systems
Network Architecture transport over internet backbones - Cisco and Wellfleet
come to mind.

Is anyone aware of any other manufacturers providing this capability?  I am
particularly interested in the performance aspects of this capability.  I am
writing a paper comparing the various options.

Many thanks for any help.

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 20:03:07 GMT
From:      welch@soda.berkeley.edu (Sean N. Welch)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

In article <RSM.91Jun21182838@coral.math.arizona.edu> rsm@math.arizona.edu (Robert S. Maier) writes:
>Several machines in the nrl.navy.mil domain have an interesting
>undocumented feature: if you finger them, they finger you right back! 
>Examples are tiger.nrl.navy.mil and ccf.nrl.navy.mil.  Try it
>yourself; if your finger daemon logs incoming requests you'll pick
>it up at once.

Interesting, but only to a point.  Many sites let you bounce fingers such
that you can chain them from your site to somewhere that your machine
doesn't know about by going through a machine that does know where you
want to finger.  Some companies operate with only a single gateway on
the internet, so you can't finger at foo.big.com, but you can finger 
@foo@big.com since the foo gets evaluated at big.com which knows about
foo and can get to it.  The effect this has on finger-you-back finger
daemons is that they look for you at the most recent link in the chain.

What if you do something really silly like:

	finger @ccf.nrl.navy.mil@tiger.nrl.navy.mil

(Yes, I tried it.  Unfortunately you can't chain forever on these two
machines since if you try and finger @somehere@ccf.nrl.navy.mil, you 
get finger@ccf3.nrl.navy.mil: argument list not permitted)

Sean Welch
welch@Berkeley.EDU

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 91 23:35:46 GMT
From:      srp@babar.mmwb.ucsf.edu (Scott R. Presnell%Cohen)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

rsm@math.arizona.edu (Robert S. Maier) writes:

>Apparently `Caller ID' has come to the Internet.

Ever since getpeername() and gethostbyaddr()!

(Remember, Caller ID doesn't get you exactly *who* is on the other end,
just the "address" of the device, be it phone or computer.)

	- Scott
--
Scott Presnell				        +1 (415) 476-9890
Pharm. Chem., S-926				Internet: srp@cgl.ucsf.edu
University of California			UUCP: ...ucbvax!ucsfcgl!srp
San Francisco, CA. 94143-0446			Bitnet: srp@ucsfcgl.bitnet

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 00:51:14 GMT
From:      cgw@vaxb.acs.unt.edu
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

In article <RSM.91Jun21182838@coral.math.arizona.edu>, rsm@math.arizona.edu (Robert S. Maier) writes:
[discussion of nrl.navy.mil's 'feature' of fingering the fingerer (ie: 'you')
when you finger them]
> Apparently the folks at nrl.navy.mil (Navy Research Laboratory) didn't
> want to erect a full-fledged firewall, so they compromised on this.
> It doesn't seem a very effective protection against the outside world
> though.  In fact it's rather amusing.  Has anyone ever seen anything
> else like this?

yes! well, sortof.. read on:

> I haven't checked to see whether their other daemons (e.g. rusersd)
> are nosy too, but I wouldn't be surprised.  Apparently `Caller ID' has
> come to the Internet.

and has been for at least a while.. in march or so of 91, on comp.unix.*,
there was talk of a program that would wake up and do something when
your account is fingered. generally, what happens is this: you make
your .plan a FIFO queue that runs a program you specify whenever it
becomes active. (at least, that's my understanding. i could be wrong.)
anyway, i've written a companion to the program that does this (which 
is the purpose of the first program (to run another program when your
.plan is opened). you can see this program in action if you finger
cgw@ponder.csci.unt.edu. i don't login there much anymore, so i can't 
vouch for the availableness of this, but it should work. because of 
final exams in may, i didn't get a chance to make it use DNS to translate 
the IP addr to a hostname, but it's still an interesting thing. 
currently, the algorithm is this: do a ps and grep for 'finger'. then 
i can get the username and special-case that user. if it doesn't 
find anyone running finger, do a netstat and see what host has an 
open connection to port 79. it's admittedly in the stages of an 
advanced hack, and not exetremely useful in it's current state, but
ideas i have for it are: a personalized message sender. say you're 
out of the office/room for a few minutes, and want to let someone
know you're out. just add a line to a file, and the program will
send it to users specified (somewhere). there are many more things
you can do with this, but i'll refrain from going into them here.

i got the program from someone off the net. since i've forgotten
who it was, but still have the original mail, i'll entertain 
requests for it by email, if there's any interest. email _only_;
if you post to the net, i'll ignore it. 

oh, i almost forgot the reason i'm posting.. my program currently
logs usernames (if they're local) and host IPs if they're not. 
see? tcp/ip CallerId :)

-cgw-

>S. Maier   | Internet: rsm@math.arizona.edu, rsm@cs.arizona.edu
> Dept. of Math.    | UUCP: uunet!arizona!amethyst!rsm
> Univ. of Arizona  | Bitnet: maier@arizrvax
> Tucson, AZ  85721 | FAX: +1 602 621 8322
> U.S.A.            | Voice(POTS): +1 602 621 6893  /  +1 602 621 2617

-------------------------------------------------------------------------------
christopher williams, `gilligan', `dude', cgw@vaxb.acs.unt.edu, +1 817 565 4161
lead programmer/operator, the university of north texas, home of the _VaxCave_!
`help stamp out and abolish redundancy!'           my other .sig is boring too.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 02:47:50 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.protocols.iso,comp.dcom.modem
Subject:   Re: ISDN and X-Windows

In article <1991Jun20.100207.65096@pttrnl.nl> sonneveld@pttrnl.nl writes:

   For one of our projects we try to get the following stack of hard/software 
   working together for a MS-DOS PC:

   X-windows
   ---------
   TCP/IP
   ---------
   ISDN (The German 1TR6-protocol)


Well, the Clarkson collection of packet drivers has a Mitel Express ISDN
packet driver.  It acts like a SLIP driver.  The newest PC/TCP kernel from
FTP Software supports SLIP packet drivers.  That, and an X server that
uses the PC/TCP kernel (I'm pretty sure that one of them does, but I
don't know which one) should get you what you want.

That is, assuming the Mitel Express card can do 1TR6.

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
I am leaving the employ of Clarkson as of June 30.  Hopefully this email
address will remain.  If it doesn't, use nelson@gnu.ai.mit.edu.

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 06:51:25 GMT
From:      pwb@newt.phys.unsw.OZ.AU (Paul W. Brooks)
To:        comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   pointer to CHARON?

Dear Networkers,
	A while ago a flurry or messages passed by about CHARON,  a
PD/Shareware bi-directional print spooler between UN*X and Novell Netware. Now
I have a need for it, and can't find it or a reference to it anywhere. Could
some kind soul point me to a FTP site somewhere I might pick it up?
	Thanks in anticipation...
	
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 14:19:21 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Network maps

I am looking to create a list of where everyone stores their network map.
Please send me the following information:

1) anonymous ftp name and number
2) cd __________
3) get ___________.ps
4) what is included in your map?
5) how often is it updated?

Thanks,
Hank

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 17:32:10 GMT
From:      dlynch@ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

The magic cutover date was 1/1/83.  No more NCP.  Just TCP/IP.  Some 
bureaucrat chose the date.  Dozens of us system managers found ourselves
on a New Year's Eve trying to pull off this massive cutover.  We had been
working on it for over a year.  There were hundreds of programs at hundreds
of sites that had to be developed and debugged.  

Never again in history will there be such a clean cutover.  The transition
from TCP/IP to anything new will be done very slowly.  I think that is
a good idea.  

Dan

PS.  I'm the one who had the "I survived the TCP Transition" buttons
made up.  Made 500 of them and passed them out to the pioneers all over
the globe.  Save those buttons, gang!

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 91 17:48:28 GMT
From:      coates@uc780.umd.edu
To:        comp.protocols.tcp-ip
Subject:   Getting Internet Address : How?

How would a non-profit group get an Internet address?
Thanks-

**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 01:12:36 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   NDIS driver repository

FTP Software now has a repository of NDIS drivers available via anonymous
ftp.  They can be found on vax.ftp.com in the ndis subdirectory.
Drivers are stored in either .zip or .arc format.

These drivers are furnished under the auspices of Microsoft.  We encourage
driver vendors to submit addtional drivers to this site.





					Larry Backman
					backman@ftp.com

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 05:43:54 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: SOS: C Routines for ASCII to EBCDIC Conversion and Vice-versa


[ Disclaimer: Views and opinions, expressed or implied my own ]

I agree with that which you state below. There is no questions it's best to
go with a 'network-neutral' code set between disparate systems ( such
as those in question ). There are a couple of points of note , however:

() The mechanics of the operation are straight-forward.

   Declare a static array of 255 ( size of EBCDIC code set ) bytes.
   Then use the current character as an offset to this array to obtain
   the translated value. This is simple, quick, and widely used technique.

   The same table can be used in both direction as long as array initialization
   is consistent across your compute environment, i.e. all nodes used the
   same ( agreed on) 'network data' character sets. 


() There is the problem, however, ( and not just with 8859/1 ), when character
   defaults, "?", are used for non-display or print characters. If the original
   data is retrieved from the target system it is no longer intact. At      
   least for presentation purposes. One way I have gotten around this problem
   in the past was to encode these characters as transparent entries in 
   any table used. In other words the entries for these characters match
   the array index.

There are no doubt more clever and eloquent methods, but this proved very
flexible. 

BTW:

What happened to SCS data ( codes '00'-'3f', the SNA character string for
the old LU type 1 ) with this..is that what Code Page 37 addresses ?

 George Williams


    Date:    21 Jun 91 09:11:19 GMT
    From:    Mark Israel <aunro!alberta!sherlock.mmid.ualberta.ca!lnds@lll-wink
	      en.llnl.gov>
    Subject: Re: SOS: C Routines for ASCII to EBCDIC Conversion and Vice-versa

    In article <1991Jun20.160334.11278@gdr.bath.ac.uk>, P.Smee@bristol.ac.uk 
    (Paul Smee) writes:

    > There's a basic problem here, which is that there is (still) no such
    > thing as EBCDIC....   For a real real definitive answer, you'll have to g
 et
    > friendly with someone in IBM.

       I extracted the following from local documentation.

    				Mark Israel
    I have heard the Wobble!	userisra@mts.ucs.ualberta.ca

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

       In February 1987, a new eight-bit ISO character set standard,
    8859/1, was ratified.  Also in 1987, IBM published an EBCDIC 
    standard called Code Page 37, based on the ISO 8859/1 standard. 
    Both of these standards contain identical character graphics.  The
    ISO 8859/1 character set contains such EBCDIC characters as the
    logical-not sign and the cent sign, and the new EBCDIC character
    set contains the ISO tilde and circumflex, among other ASCII
    characters.  The ISO 8859/1 standard is supported by many large
    computer manufacturers, including DEC and IBM.  

       As we deal more and more with other machines using ISO-based
    rather than EBCDIC-based character coding schemes, it becomes
    imperative that we be able to move data from one machine to
    another and back again without loss of information.  The mapping 
    that results from using the ISO 8859/1 standard and the IBM
    Code Page 37 EBCDIC will allow us to move information back and
    forth between ISO- and EBCDIC-based machines with none of the
    problems we have had in the past. 

        EBCDIC     ASCII     GRAPHIC  DESCRIPTION 
    --------------------------------------------------------------------- 
        X'00'      X'00'       NUL   null 
        X'01'      X'01'       SOH   start of heading           (Ctrl-A) 
        X'02'      X'02'       STX   start of text              (Ctrl-B) 
        X'03'      X'03'       ETX   end of text                (Ctrl-C) 
        X'04'      X'9C'     ?        ... 
        X'05'      X'09'     	  HT    horizontal tabulation      (Ctrl-I) 
        X'06'      X'86'     ?        ... 
        X'07'      X'7F'       DEL   delete (rubout, DEL control char) 
        X'08'      X'97'     ?        ... 
        X'09'      X'8D'     ?        ... 
        X'0A'      X'8E'     ?        ... 
        X'0B'      X'0B'       VT    vertical tabulation        (Ctrl-K) 
        X'0C'      X'0C'        FF    form feed                  (Ctrl-L) 
        X'0D'      X'0D'     
        X'0E'      X'0E'       SO    shift-out                  (Ctrl-N) 
        X'0F'      X'0F'       SI    shift-in                   (Ctrl-O) 
        X'10'      X'10'       DLE   data link escape           (Ctrl-P) 
        X'11'      X'11'       DC1   device control 1    (X-Off, Ctrl-Q) 
        X'12'      X'12'       DC2   device control 2           (Ctrl-R) 
        X'13'      X'13'       DC3   device control 3     (X-On, Ctrl-S) 
        X'14'      X'9D'     ?        ... 
        X'15'      X'85'     ?        ... 
        X'16'      X'08'        BS    backspace                  (Ctrl-H) 
        X'17'      X'87'     ?        ... 
        X'18'      X'18'       CAN   cancel                     (Ctrl-X) 
        X'19'      X'19'       EM    end of medium              (Ctrl-Y) 
        X'1A'      X'92'     ?        ... 
        X'1B'      X'8F'     ?        ... 
        X'1C'      X'1C'       FS    file separator 
        X'1D'      X'1D'       GS    group separator 
        X'1E'      X'1E'       RS    record separator 
        X'1F'      X'1F'       US    unit separator 
        X'20'      X'80'     ?        ... 
        X'21'      X'81'     ?        ... 
        X'22'      X'82'     ?        ... 
        X'23'      X'83'     ?        ... 
        X'24'      X'84'     ?        ... 
        X'25'      X'0A'     
      LF    line feed                  (Ctrl-J) 
        X'26'      X'17'       ETB   end of transmission block  (Ctrl-W) 
        X'27'      X'1B'       ESC   escape                     (Escape) 
        X'28'      X'88'     ?        ... 
        X'29'      X'89'     ?        ... 
        X'2A'      X'8A'     ?        ... 
        X'2B'      X'8B'     ?        ... 
        X'2C'      X'8C'     ?        ... 
        X'2D'      X'05'       ENQ   enquiry                    (Ctrl-E) 
        X'2E'      X'06'       ACK   acknowledge                (Ctrl-F) 
        X'2F'      X'07'       BEL   bell                       (Ctrl-G) 
        X'30'      X'90'     ?        ... 
        X'31'      X'91'     ?        ... 
        X'32'      X'16'       SYN   synchronous idle           (Ctrl-V) 
        X'33'      X'93'     ?        ... 
        X'34'      X'94'     ?        ... 
        X'35'      X'95'     ?        ... 
        X'36'      X'96'     ?        ... 
        X'37'      X'04'       EOT   end of transmission        (Ctrl-D) 
        X'38'      X'98'     ?        ... 
        X'39'      X'99'     ?        ... 
        X'3A'      X'9A'     ?        ... 
        X'3B'      X'9B'     ?        ... 
        X'3C'      X'14'       DC4   device control 4           (Ctrl-T) 
        X'3D'      X'15'       NAK   negative acknowledge       (Ctrl-U) 
        X'3E'      X'9E'     ?        ... 
        X'3F'      X'1A'       SUB   substitute character       (Ctrl-Z) 
        X'40'      X'20'              space (blank) 
        X'41'      X'A0'     ?        no-break space 
        X'42'      X'E2'     ?        small a with circumflex accent 
        X'43'      X'E4'     ?        small a with diaeresis 
        X'44'      X'E0'     ?        small a with grave accent 
        X'45'      X'E1'     ?        small a with acute accent 
        X'46'      X'E3'     ?        small a with tilde 
        X'47'      X'E5'     ?        small a with ring above 
        X'48'      X'E7'     ?        small c with cedilla 
        X'49'      X'F1'     ?        small n with tilde 
        X'4A'      X'A2'     ?        cent sign 
        X'4B'      X'2E'     .        period, full stop 
        X'4C'      X'3C'     <        less-than sign 
        X'4D'      X'28'     (        left parenthesis 
        X'4E'      X'2B'     +        plus sign 
        X'4F'      X'7C'     |        vertical line (bar, "or" sign) 
        X'50'      X'26'     &        ampersand (and sign) 
        X'51'      X'E9'     ?        small e with acute accent 
        X'52'      X'EA'     ?        small e with circumflex accent 
        X'53'      X'EB'     ?        small e with diaeresis 
        X'54'      X'E8'     ?        small e with grave accent 
        X'55'      X'ED'     ?        small i with acute accent 
        X'56'      X'EE'     ?        small i with circumflex accent 
        X'57'      X'EF'     ?        small i with diaeresis 
        X'58'      X'EC'     ?        small i with grave accent 
        X'59'      X'DF'     ?        small sharp s, German 
        X'5A'      X'21'     !        exclamation mark 
        X'5B'      X'24'     $        dollar sign 
        X'5C'      X'2A'     *        asterisk (star) 
        X'5D'      X'29'     )        right parenthesis 
        X'5E'      X'3B'     ;        semicolon 
        X'5F'      X'AC'     ?        not sign 
        X'60'      X'2D'     -        minus sign or hyphen 
        X'61'      X'2F'     /        solidus (slash) 
        X'62'      X'C2'     ?        capital A with circumflex accent 
        X'63'      X'C4'     ?        capital A with diaeresis 
        X'64'      X'C0'     ?        capital A with grave accent 
        X'65'      X'C1'     ?        capital A with acute accent 
        X'66'      X'C3'     ?        capital A with tilde 
        X'67'      X'C5'     ?        capital A with ring 
        X'68'      X'C7'     ?        capital C with cedilla 
        X'69'      X'D1'     ?        capital N with tilde 
        X'6A'      X'A6'     ?        broken bar 
        X'6B'      X'2C'     ,        comma 
        X'6C'      X'25'     %        percent sign 
        X'6D'      X'5F'     _        low line (underscore) 
        X'6E'      X'3E'     >        greater-than sign 
        X'6F'      X'3F'     ?        question mark 
        X'70'      X'F8'     ?        small o with slash 
        X'71'      X'C9'     ?        capital E with acute accent 
        X'72'      X'CA'     ?        capital E with circumflex accent 
        X'73'      X'CB'     ?        capital E with diaeresis 
        X'74'      X'C8'     ?        capital E with grave accent 
        X'75'      X'CD'     ?        capital I with acute accent 
        X'76'      X'CE'     ?        capital I with circumflex accent 
        X'77'      X'CF'     ?        capital I with diaeresis 
        X'78'      X'CC'     ?        capital I with grave accent 
        X'79'      X'60'     `        grave accent 
        X'7A'      X'3A'     :        colon 
        X'7B'      X'23'     #        number sign (hash mark, sharp sign) 
        X'7C'      X'40'     @        commercial at 
        X'7D'      X'27'     '        apostrophe (single quote) 
        X'7E'      X'3D'     =        equals sign 
        X'7F'      X'22'     "        quotation mark (double quote) 
        X'80'      X'D8'     ?        capital O with slash 
        X'81'      X'61'     a        small a 
        X'82'      X'62'     b        small b 
        X'83'      X'63'     c        small c 
        X'84'      X'64'     d        small d 
        X'85'      X'65'     e        small e 
        X'86'      X'66'     f        small f 
        X'87'      X'67'     g        small g 
        X'88'      X'68'     h        small h 
        X'89'      X'69'     i        small i 
        X'8A'      X'AB'     ?        angle quotation mark left (<< mark) 
        X'8B'      X'BB'     ?        angle quotation mark right (>> mark) 
        X'8C'      X'F0'     ?        small eth, Icelandic 
        X'8D'      X'FD'     ?        small y with acute accent 
        X'8E'      X'DE'     ?        small thorn, Icelandic 
        X'8F'      X'B1'     ?        plus or minus sign 
        X'90'      X'B0'     ?        degree sign 
        X'91'      X'6A'     j        small j 
        X'92'      X'6B'     k        small k 
        X'93'      X'6C'     l        small l 
        X'94'      X'6D'     m        small m 
        X'95'      X'6E'     n        small n 
        X'96'      X'6F'     o        small o 
        X'97'      X'70'     p        small p 
        X'98'      X'71'     q        small q 
        X'99'      X'72'     r        small r 
        X'9A'      X'AA'     ?        ordinal indicator feminine 
        X'9B'      X'BA'     ?        ordinal indicator, masculine 
        X'9C'      X'E6'     ?        small ae dipthong 
        X'9D'      X'B8'     ?        cedilla 
        X'9E'      X'C6'     ?        capital AE dipthong 
        X'9F'      X'A4'     ?        currency sign (lozenge) 
        X'A0'      X'B5'     ?        micro sign (small mu) 
        X'A1'      X'7E'     ~        tilde (wavy line) 
        X'A2'      X'73'     s        small s 
        X'A3'      X'74'     t        small t 
        X'A4'      X'75'     u        small u 
        X'A5'      X'76'     v        small v 
        X'A6'      X'77'     w        small w 
        X'A7'      X'78'     x        small x 
        X'A8'      X'79'     y        small y 
        X'A9'      X'7A'     z        small z 
        X'AA'      X'A1'     ?        inverted exclamation mark 
        X'AB'      X'BF'     ?        inverted question mark 
        X'AC'      X'D0'     ?        capital D with stroke, Icelandic eth 
        X'AD'      X'DD'     ?        capital Y with acute accent 
        X'AE'      X'FE'     ?        capital thorn, Icelandic 
        X'AF'      X'AE'     ?        registered sign (circled capital R) 
        X'B0'      X'5E'     ^        circumflex accent 
        X'B1'      X'A3'     ?        pound sign (Sterling currency) 
        X'B2'      X'A5'     ?        yen sign (Nipponese currency) 
        X'B3'      X'B7'     ?        middle dot (scalar product) 
        X'B4'      X'A9'     ?        copyright sign (circled capital C) 
        X'B5'      X'A7'     ?        section sign (S-half-above-S sign) 
        X'B6'      X'B6'     ?        pilcrow (paragraph, double-barred P) 
        X'B7'      X'BC'     ?        fraction one-quarter (1/4) 
        X'B8'      X'BD'     ?        fraction one-half (1/2) 
        X'B9'      X'BE'     ?        fraction three-quarters (3/4) 
        X'BA'      X'5B'     [        left square bracket 
        X'BB'      X'5D'     ]        right square bracket 
        X'BC'      X'AF'     ?        macron 
        X'BD'      X'A8'     ?        diaeresis or umlaut 
        X'BE'      X'B4'     ?        acute accent 
        X'BF'      X'D7'     ?        multiply sign (vector product) 
        X'C0'      X'7B'     {        left curly bracket (left brace) 
        X'C1'      X'41'     A        capital A 
        X'C2'      X'42'     B        capital B 
        X'C3'      X'43'     C        capital C 
        X'C4'      X'44'     D        capital D 
        X'C5'      X'45'     E        capital E 
        X'C6'      X'46'     F        capital F 
        X'C7'      X'47'     G        capital G 
        X'C8'      X'48'     H        capital H 
        X'C9'      X'49'     I        capital I 
        X'CA'      X'AD'     ?        soft hyphen 
        X'CB'      X'F4'     ?        small o with circumflex accent 
        X'CC'      X'F6'     ?        small o with diaeresis 
        X'CD'      X'F2'     ?        small o with grave accent 
        X'CE'      X'F3'     ?        small o with acute accent 
        X'CF'      X'F5'     ?        small o with tilde 
        X'D0'      X'7D'     }        right curly bracket (right brace) 
        X'D1'      X'4A'     J        capital J 
        X'D2'      X'4B'     K        capital K 
        X'D3'      X'4C'     L        capital L 
        X'D4'      X'4D'     M        capital M 
        X'D5'      X'4E'     N        capital N 
        X'D6'      X'4F'     O        capital O 
        X'D7'      X'50'     P        capital P 
        X'D8'      X'51'     Q        capital Q 
        X'D9'      X'52'     R        capital R 
        X'DA'      X'B9'     ?        superscript one 
        X'DB'      X'FB'     ?        small u with circumflex accent 
        X'DC'      X'FC'     ?        small u with diaeresis 
        X'DD'      X'F9'     ?        small u with grave accent 
        X'DE'      X'FA'     ?        small u with acute accent 
        X'DF'      X'FF'     ?        small y diaeresis 
        X'E0'      X'5C'     \        reverse solidus (backslash) 
        X'E1'      X'F7'     ?        divide sign (dot over line over dot) 
        X'E2'      X'53'     S        capital S 
        X'E3'      X'54'     T        capital T 
        X'E4'      X'55'     U        capital U 
        X'E5'      X'56'     V        capital V 
        X'E6'      X'57'     W        capital W 
        X'E7'      X'58'     X        capital X 
        X'E8'      X'59'     Y        capital Y 
        X'E9'      X'5A'     Z        capital Z 
        X'EA'      X'B2'     ?        superscript two (squared) 
        X'EB'      X'D4'     ?        capital O with circumflex accent 
        X'EC'      X'D6'     ?        capital O with diaeresis 
        X'ED'      X'D2'     ?        capital O with grave accent 
        X'EE'      X'D3'     ?        capital O with acute accent 
        X'EF'      X'D5'     ?        capital O with tilde 
        X'F0'      X'30'     0        digit zero 
        X'F1'      X'31'     1        digit one 
        X'F2'      X'32'     2        digit two 
        X'F3'      X'33'     3        digit three 
        X'F4'      X'34'     4        digit four 
        X'F5'      X'35'     5        digit five 
        X'F6'      X'36'     6        digit six 
        X'F7'      X'37'     7        digit seven 
        X'F8'      X'38'     8        digit eight 
        X'F9'      X'39'     9        digit nine 
        X'FA'      X'B3'     ?        superscript three (cubed) 
        X'FB'      X'DB'     ?        capital U with circumflex accent 
        X'FC'      X'DC'     ?        capital U with diaeresis 
        X'FD'      X'D9'     ?        capital U with grave accent 
        X'FE'      X'DA'     ?        capital U with acute accent 
        X'FF'      X'9F'     ?        ... 

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 09:29:04 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: IP in the World (was UK) (was Fingering the English)


In terms of real interconnecting networks, we (UCL-CS) had Internet 
(read ARPANET) access via SATNET from 1976, and UK x.25 access around 
the same time

they have been very similar in terms of functionality/performance
ever since ...

(Performance: e.g. JANET-II is 2Mbps about same time as T1 NSFNET, we
arte going to 34 Mbps aropund this year, while NSFnet goes to T3...in
fact reliability of JANET is markedly better than most the
Internnet...
Functionality: the Internet (wide area) does FTP/SMTP/TELNET, we have
NIFTP, Grey Book/X.400, PAD/XXX).

now if you want fancy stuff like NFS/AFS, X/NeWS, Video, you dont
really get that much yet wide area...see paper by Paxson, or me at
INET'91 or some folks from USC at SIGCOMM '91 for traffic stats...

in terms of research, i started at UCL in '81 working on
interconnected *cambridge* rings running universe datagrams, and byte
strem protocol, with satellite hops to europe - pretty similar to the
US research going on at the time...

we now are loooking at 60Mbps ATM networks, and packet voice & video
in UK & UK-Europe - again pretty similar to what is happening in the
US

the arguments over what packet format carries the bits over the wire
are rather long in the tooth - what is relevant is: what *algorithms*
go in the end systems and routers/switches to give the QoS the users
want (e.g. reliablilty/throughput/delay versus cost)...

the socialogocal/political arguments should be left to
sociologists/politicians and people who have to argue with European
Telecom companies who operate a very disruptive cartel similar 
to that which airline companies have this side of the pond...
and what ...

jon

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 13:39:40 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK


Mark Crispin and Dan Lynch have already stated the official NCP to
TCP/IP transition date.  They have correctly stated the mad rush at the
end of 1982 to make the cutover.  For the historically curious, here are
a few more facts.

The first TCP implementation I am aware of was for the PDP-10 running
the TENEX operating system; it was reported to be running at BBN in
February 1975.  By November 1975 this implementation had been involved
in experiments with a Stanford University implementation for the PDP-11.
The experiments disclosed protocol design deficiencies which resulted in
a revision of the TCP spec.

The first TCP implementation for UNIX was written at BBN; it reached
operational status by November 1977.

A TCP/IP gateway written by BBN for the PDP-11/40 was in use
interconnecting the ARPANET and the Packet Radio Network (a DARPA
project) by May 1978.

The RFC announcing that the official cutover from NCP to IP would be
1/1/83 was published in November 1981, allowing more than a year for
host organizations do do planning and implementation.  There were TCP/IP
implementations for most ARPANET hosts already running (in at least
prototype form) by November 1981.

About 1/3 of the 285 general-purpose ARPANET hosts accepted TCP
connections in early December 1982, about 1/2 in early January 1983, and
about 2/3 by the end of February 1983. The IMP (packet switch) code
which would disable transmission of NCP protocol traffic was actually
never activated, although it had been written, tested, and installed.

Cheers,
Alex McKenzie
BBN Laboratories
 

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Mon, 24 Jun 91 15:32:53 GMT
From:      dc@sparc.micronics.com (Darren Croke)
To:        comp.protocols.tcp-ip
Subject:   email addr for CMU VAX TCP/IP

Can anyone tell me the email address I should contact to order the 
CMU TCP/IP for VAX. I had seen a posting in this group that suggested
tcpip+@andrew.cmu.edu but I have mailed to this address twice now with
no response.

Thanks in advance,
Darren Croke.

-- 
 Darren Croke         Micronics Computers
 dc@micronics.com     X Terminal Division
                          (415) 651-2300

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 16:22:46 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

> ... let me assure you that the transition from NCP to TCP was
> done in a great rush, occupying virtually everybody's time 100% in the
> year 1982.  *Nobody* was ready.

To the contrary - we (the enforcers) were! :-)

> On January 1, DCA had the ARPANET IMP software modified so that they
> would not pass NCP traffic.  

I wrote the IMP code to make this happen.  We had a configuration
bit for each host, to allow or disallow NCP on a host-by-host
basis, plus a master switch for each IMP.  To enforce the
cutover, we preset all the configuration bits ahead of time, and
then just flipped the master switches at cutover time.

> There was a hue and cry, and thus for several months afterwards
> a number of sites (both NCP-only and NCP/TCP sites which needed
> to be able to talk to NCP-only sites) had "reclama" to use NCP.

We had a long list of hosts that were granted permission, for one
reason or another, to continue to use NCP.  As I recall, we had a
good number of hosts on the list from day 1, and it grew quite a
bit before it started to shrink.

Eventually, the list grew shorter and shorter, until (probably
eight months or so after the cutover) the last hosts had their
NCP permission turned off.  That particular code is now long gone
from the PSN.  However, upon reflection, it was probably the
first protocol-based filtering ever built into a packet switch.
It used the 1822 "link number" protocol identifier to determine
which messages were carrying NCP.

> It was a major painful ordeal, and one that those who experienced it
> are not eager to repeat.  You can tell who we are -- the old farts who
> smirk knowingly when "ISO transition" gets mentioned.

I'm looking forward to it already.

Andy

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 16:23:50 GMT
From:      Y.Murayama@CS.UCL.AC.UK (Yuko Murayama, +44-71-387-7050 ext.3721)
To:        comp.protocols.tcp-ip
Subject:   a question on FDDI and Token Ring


I have the following question both on FDDI and on Token Ring.

Is it possible to misconfigure a subnet interface with a broadcast or 
multicast address?  Is there any detection mechanism when it is installed?

Yuko Murayama
Dept of Computer Science
University College London

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 16:52:05 GMT
From:      cmo@pogo.WV.TEK.COM (Christine Olsen)
To:        comp.protocols.tcp-ip
Subject:   Setting IP Options

Does anyone have an example of setting IP options (IPPROTO_IP)
with the setsockopt system call?  I'm interested in the
Record Route, Timestamp, and Strict Source Route options.

Please send replies via E-mail: cmo@pogo.wv.tek.com 

Thank you very much for any help,

Christine

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 16:58:17 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

rsm@math.arizona.edu:
   Several machines in the nrl.navy.mil domain have an interesting
   undocumented feature: if you finger them, they finger you right back! 
   Examples are tiger.nrl.navy.mil and ccf.nrl.navy.mil.

Now let me get this straight: I take a copy of Tiger's fingerd and I
install it on foo.bar.bletch.edu.  Logged into Foo, I finger
joe@tiger.nrl.navy.mil.  Watching my syslog in another window, I
observe an incoming finger request from Tiger.  This induces my
fingerd (being a copy of Tiger's) to perform "finger
@tiger.nrl.navy.mil" after which I observe another finger request
coming back from Tiger, to which my fingerd responds with "finger..."

--karl

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 17:59:28 GMT
From:      drt@cysog.UUCP (David R. Trinidad)
To:        comp.protocols.tcp-ip
Subject:   Re: Miniumum hardware required to support SLIP connection?

jcurran@SH.CS.NET (John Curran) writes:

>From: "David C. Kovar" 

[Text removed]

>You've just describe the exact specifications of an existing product 
>available from Telebit known as a "NetBlazer".  It consists of a 
>Trailblazer modem and a mid-power router in a single box with an ethernet
>interface. Once configured it will handle dialing in and establishing 
>a SLIP or PPP connection. My interest in it stems from its ability to
>automatically bring up line when a IP datagam is received, and subsequently
>take down the line when idle. (just like the "dialupip" SLIP s/w available)

How hard is the configuration on the Netblazer and how reliable
is it ???


>I'm not aware of any other routers which will initiate phone connections
>automatically, but that doesn't mean that they're not working on it..
 
>/John

************************************************************************
Organization: 	Cycare Systems 
Internet : 	drt%cysog@hbiso.ma02.bull.com
UUNET:		uunet!hbiso!cysog!drt
Phone:		(602) 224 0555	| FAX: (602) 224 0872
System:		B.O.S. UNIX     |
	 UNIX isn't just an OS  | It's a way of life !!!!!
***********************************************************************

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 21:18:28 GMT
From:      suitti@ima.isc.com (Stephen Uitti)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

In article <1991Jun22.160026.8876@nntp.hut.fi> alo@hiisi.hut.fi (Antti Louko) writes:
>In article <RSM.91Jun21182838@coral.math.arizona.edu> rsm@math.arizona.edu (Robert S. Maier) writes:
>>Several machines in the nrl.navy.mil domain have an interesting
>>undocumented feature: if you finger them, they finger you right back! 
>>Examples are tiger.nrl.navy.mil and ccf.nrl.navy.mil.  Try it
>>yourself; if your finger daemon logs incoming requests you'll pick
>>it up at once.
 
>>though.  In fact it's rather amusing.  Has anyone ever seen anything
>>else like this?
>
>I haven't seen it before, but I have thought about it. I decided not
>to implement it. Why? Think about it. What if my fingerd and theirs
>both implement this "feature"? How long they will keep fingering each
>other?
>
>Or if I find another internet site who implements this, say
>rixrax.foo.com and give command
>
>finger @tiger.nrl.navy.mil@rixrax.foo.com
>
>and let them finger each other forever.

If it were my fingerd, and I wanted it to keep a log of people
who had fingered my people, I'd only finger people I hadn't
fingered recently.  Recently means today, since last boot, or if
the info isn't still in my fixed maximum sized LRU table, or
whatever.

The "I'm on vacation" automatic reply mailers are a harder problem.

Stephen.
suitti@ima.isc.com
"We Americans want peace, and it is now evident that we must be
prepared to demand it.  For other peoples have wanted peace, and
the peace they received was the peace of death." - the Most Rev.
Francis J. Spellman, Archbishop of New York.  22 September, 1940

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 91 23:11:28 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Where Can I Get The IMAP Specification?

Does anyone know where I can get the specification for IMAP?
IMAP is a mail server, basically an enhanced POP.

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 00:02:09 GMT
From:      ching@brahms.amd.com (Mike Ching)
To:        comp.protocols.tcp-ip
Subject:   ka9q documentation


I recently decided to update my ka9q stuff to a more recent version and
find that hosts.net is no longer used. A quick look through files.c and
domain.c has not shed any light on how names are resolved. Is there a
new documentation file (mine is from 1987)? Or is there a quick and easy
answer for the 11/90 version of net? Thanks in advance.

Mike Ching

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 00:14:12 GMT
From:      erc@Apple.COM (Ed Carp)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: Authentication & Internet Protocol Suite


It seems that the whole issue revolves around the insupportability of secure
channels for the exchange of keys.  Typical problem: A wants to send B a
secure message, and he wants to make sure that only B can read it.  You have
to have a secure channel to exchange secrets so that you can agree on keys for
encryption.  No such secure channel exists.

Phil Karn's work with insecure login via packet radio has merit (time-slice),
but I'd rather see something akin to public key crypto.  I'd sure like a
piece of that software...:)
-- 
Ed Carp  N7EKG/6	erc@khijol.UUCP		...uunet!khijol!erc
Packet:  N7EKG @ N6IIU.#NOCAL.CA.US
UUWEST Consulting	Alameda, CA		415/814-0550

Computers HAVE caused a revolution in how much information we
can safely ignore!    --robs@ux1.cso.uiuc.edu (Rob Schaeffer)

-- Absolutely unabashed Gates McFadden groupie! --

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 00:36:09 GMT
From:      mogul@pa.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In article <BOB.91Jun17182958@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
>When a gateway is configured as a firewall, what is the polite thing
>to do about those packets that aren't passed?  The packet itself
>should be dropped on the floor, but should the originating system be
>told anything about it?

The system I implemented (see my paper in Proc. 1989 Summer USENIX
Conf.) currently sends "Host Unreachable" packets, but only in
those cases specified in the filtering rules.  E.g., the manager
of the gateway can say:

	from any to any tcp port telnet reject notify;
	from any to any tcp port finger reject;

This means that telnet users will get notification via ICMP, and finger users
will see their connections time out.  (This is a contrived example; in
real life, we tend to send notifications except in cases where nobody
is likely to be listening and the traffic rate could be high.)

In my implementation, the choice of ICMP type+code is wired into the kernel.
Given that I allow fine-grained choice of when to send an ICMP, it might
also be reasonable to add fine-grained choice of which ICMP code to send.
However, we've been running this way for more than 2 years without any
problems. [This code is now shipping with Ultrix (release 4.2) so if I
made the wrong choice, I guess I'll hear about it.]

-Jeff

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 05:32:01 GMT
From:      turbo@cse.uta.edu (Chris Turbeville)
To:        comp.protocols.tcp-ip
Subject:   SLIP TCP/IP and Comunication Servers

I am interested in connecting to our network through a slip connection.
We run a fairly standard net of UNIX machines (tcp/ip ethernet) and
terminal servers (Bridge).  Now the modems connect up through a set of
term servers.  In order to preform slip I have looked at modifying
existing slip kernal additions so they will cue of a new port
connection.  In other words if I connect to 129.107.2.10 at port 26 (In
use I am sure but a demonstration) from the terminal server instead of a 
a standard comm serv serial telnet connection the slip driver would kick in
just as the telnetd does for a UNIX-UNIX connection.  This would
require merging a telnetd with a slip driver and setting up kernal
mods so they work off of a non-specific device.  Not at all easy.  
I have seen discussion of terminal servers which run a
ppp.  Does anyone know if there exist terminal servers (or software for
them) which recognize a slip connection and handle it while also excepting
standard modem connections.  This sort of connection is needed by many
people I would think since this arrangement of serial term servers and
tcp/ip machines is quite common.  There are many problems though since routing
and many other things would arrise.  Such as an arp of a slip connection
through a term server.  Any help, advice, etc. would be apprceiated.
-Chris

turbo@cse.uta.edu and many others but they all forward so why worry?
 ___   /======
  |urb| |
 ======/
[1C[1C[1C[1C[1C[1C[1C[1A[1A|[1D/[1D-[1D|[1D\[1D|

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 10:32:17 GMT
From:      qoffice@nixeid.UUCP (Qofiice Software)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.questions,unix-pc.general
Subject:   Network backups

Posting the following for a colleague.......




To:	Anyone out there


	I am currently looking for a TCP/IP based software package that
	performs unattended, command line or batch mode file transfer.
	It is to be UNIX based (SCO pref.), but can be used with MS-DOS
	FTP. PC TCP/IP. Of course, thats the ideal, but I'd be willing to
	know of anything that even remotely comes near this. The option of
	stitching together an ftp based solution is too awful to 
	contemplate, so any answers would be greatly appreciated. Something
	akin to Legato Networker (no plugs please) would be nice.

	If no such product exists, then why not, and will it ever, and if
	it does, then I'll take it.

	Thanks in advance,

					Gary Smyth,
					Siemens Nixdorf Ireland 

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 11:14:26 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <43626@cup.portal.com>, Will@cup.portal.com (Will E Estes) wrote:
>Does anyone know where I can get the specification for IMAP?

IMAP3 is documented in RFC 1203, and IMAP2 is documented in RFC 1176.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 11:59:23 GMT
From:      tommyp@ida.liu.se (Tommy Pedersen)
To:        comp.protocols.tcp-ip
Subject:   C code for NDIS driver

Hi folks,

Can any of you nice guys out there tell me where I can find some source code
for an NDIS driver. Well, I actually don't need a whole driver since I'm just
going to build a layer to put on top of a real NDIS driver in order to mani-
pulate a little with the protocols involved (e.g. IP).

/TommyP

--
/Tommy Pedersen
 ________________________________________________________________
|E-mail: tommyp@isy.liu.se        /\                            |
|S-mail: Tommy Pedersen          / /  Telephone: +46 13 282369  |
|        Dept. of EE             | |        FAX: +46 13 289282  |
|        Linkoping University    |.>                            |
|        S-581 83 Linkoping      |/                             |
|_______ SWEDEN ________________________________________________|

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 13:37:15 GMT
From:      bygg@sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

In article <1991Jun22.160026.8876@nntp.hut.fi> alo@hiisi.hut.fi (Antti Louko) writes:

# I haven't seen it before, but I have thought about it. I decided not
# to implement it. Why? Think about it. What if my fingerd and theirs
# both implement this "feature"? How long they will keep fingering each
# other?
# 
# Or if I find another internet site who implements this, say
# rixrax.foo.com and give command
# 
# finger @tiger.nrl.navy.mil@rixrax.foo.com
# 
# and let them finger each other forever.

Why not:

finger @tiger.nrl.navy.mil@tiger.nrl.navy.mil

???

--Johnny

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 14:52:32 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP and Coloured Book Software in the UK

Alex,

I would like to disagree with you on one point:

> The IMP (packet switch) code which would disable transmission
> of NCP protocol traffic was actually never activated, although
> it had been written, tested, and installed.

We actually did pull the trigger, as it were.  We came in on New
Years Day and turned on the filtering in the IMPs.  It wasn't
until the 2nd that most of the complaints started coming in.
Before the cutover, we had run statistics on which hosts still
had NCP packets coming in and out, and we also knew which hosts
were officially allowed to run NCP following the cutover, so we
had a good idea where the complaints would be coming from.

Andy

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 15:09:50 GMT
From:      ckk+@andrew.cmu.edu (Chris Koenigsberg)
To:        comp.protocols.tcp-ip
Subject:   Re: email addr for CMU VAX TCP/IP

Darren, (& anyone else reading the newsgroup)

To contact the CMU-TEK TCP/IP (VMS) maintainer, you write to
cmu-tek-tcp-request@andrew.cmu.edu. I forwarded your note to them.

Chris Koenigsberg <ckk+@andrew.cmu.edu>
Andrew Message System Administration
Distributed Workstation Services, Carnegie Mellon University

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 18:10:48 GMT
From:      dandrews@bilver.uucp (Dave Andrews)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS:  C Routines for ASCII to EBCDIC Conversion and Vice-versa

In article <1991Jun20.160334.11278@gdr.bath.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes:
>For a real real definitive answer, you'll have to get friendly with
>someone in IBM.  I know THEY are trying to come up with a definitive
>ASCII<->EBCDIC mapping as part of their SAA project; to dig themselves
>out of the hole caused by the fact that IBM/PCs speak ASCII, while IBM
>mainframes speak EBCDIC.  God only knows what mapping they'll end up
>with.

I believe the IBM effort is leading toward Unicode, a double-byte set.   
As I recall, a recent SHARE-wide survey indicated that SHARE members
were not happy with the Unicode idea (which will STILL be unusable in
parts of the world).

I don't think the ASCII/EBCDIC dichotomy will ever be resolved.

- Dave

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 21:01:55 GMT
From:      lizhen@silver.ucs.indiana.edu (Zhen Li)
To:        comp.protocols.tcp-ip
Subject:   question on slip


   I am trying to run slip on two sparc stations and having some
problems.  I am wondering if someone who has success on this could
give me some help. 

   First let me describe my configuration.  I am trying to
run slip on a sparc1+ and a sparc2, both running SunOS4.1.1.
The calling machine is named eureka  which does not have ethernet
connection  and the called machine is named stone which is on the
network with an IP address of 129.79.13.1.   I assign 
129.79.17.1 to stone's slip interface and 129.79.17.2 to
eureka's slip interface.  Currently there is no subnet17 on
our campus network, so I chose 17.  Our gateway operator have
configured gateways to forward all packets of subnet17 to stone.
So basiclly the picture is like:

	ethernet
    <-----------------+
                      |
                 129.79.13.1
                 +----------+                   +----------+
                 |  stone   |                   |  eureka  |
                 +----------+                   +----------+
		 129.79.17.1                     129.79.17.2
                      |          serial link          |
		      +-------------------------------+


   I created a slip login account in stone which has sliplogin in 
its login shell. Then I tip from eureka, (I used the tip/with slip).
I could get the connection setup and login. (The tip showed 
[SLIP running]) But after that I tried "netstat -rn" on both
machines and the following are the result:

eureka> netstat -rn
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      917        lo0
129.79.17.1          129.79.17.2          UG       0      245        slip0
default              129.79.17.2          UG       0      245        slip0

stone>netstat -rn
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      917        lo0
default              129.79.13.254        UG       0      245        le0
129.79.13.0          129.79.13.1          U        2      8655       le0

* 129.79.13.254 is the gateway in subnet 13.

And "ifconfig -a" showed the slip0 on eureka is up, on stone is down. 
At this moment I tried ping/telnet 129.79.17.1, no success.

Questions:

1.  The manpage of sliplogin says "Only the super-user may attach a 
    network interface".  Does this mean on stone the root has to setup 
    the slip connection before any ordinary slip user login? 

2.  I tried to start sliplogin before tipping from eureka, then on stone 
    I got:

stone> netstat -rn
Destination          Gateway              Flags    Refcnt Use        Interface
129.79.17.2          129.79.17.1          UGDH     0      3          slip0
127.0.0.1            127.0.0.1            UH       0      917        lo0
default              129.79.13.254        UG       0      245        le0
129.79.13.0          129.79.13.1          U        2      8655       le0

    But after that the slip user won't be able to login. The tip showed 
[connected] but login failed. Actually after I started sliplogin on stone
even the ordinary user (dialed through sunos tip) won't be able to login.
Do I missed something in the configuration? 

    Any comments and suggestions are appreciated.

Zhen Li



    

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 21:22:41 GMT
From:      grossman@Sunburn.Stanford.EDU (Stu Grossman)
To:        comp.protocols.tcp-ip
Subject:   SLIP for SGI

Is there a slip implementation for SGI (Personal Iris's or Power Servers)?  If
so, where can I get it from?

On a related topic, what brand of UART is used in the aforementioned systems?

	Stu Grossman

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 22:15:58 GMT
From:      billy@vaxb.acs.unt.edu
To:        comp.misc,comp.protocols.tcp-ip
Subject:   New Release of Internet/THENET Library Guide AGAIN

Hi,

Another release of the "UNT's Accessing On-line Bibliographic Databases"
handout is now complete.  I know it was only about a month ago that I had
my last release.  That much has changed lately.

The real credit for this release should go to Joe St. Sauver (numerous
corrections and new entries), John Sadler (for his list of Canadian libraries),
and Peter Scott (for numerous reasons and morale support).

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@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. [this file is
               out of date on the library side right now].

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  [only if you need binary
                                                     mode]
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.  


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).

Also, you must have 8" by 11" paper to print it.  If you use A4 or some other
paper size, you will be to get the WordPrefect version and change the paper
size.


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

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 22:38:37 GMT
From:      jeff@henson.cc.wwu.edu (Jeff Wandling)
To:        comp.protocols.tcp-ip
Subject:   Optical Fiber 50mic vs 62.5 at 1300nm


The trend I hear is that 62.5mic is the standard emerging. I've read that
you can use LED transmitters and receivers and it can handle both data, 
video, etc..

Are there any other good things about 62.5 that I have not mentioned?

-- 
Jeff Wandling (206) 676-2868
Western Washington University Computer Center
516 High Street, Bellingham, WA 98225
<jeff@henson.cc.wwu.edu> <uunet!uw-beaver!henson.cc.wwu.edu!jeff>

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 91 23:20:39 GMT
From:      dalyb@gtephx.UUCP (Brian Daly)
To:        rec.radio.amateur.packet,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: CDMA

In article <1991Jun18.175959.29344@ulowell.ulowell.edu>, wex@cs.ULowell.EDU (Paul Wexelblat) writes:
> I am looking for pointers to an elementary description of how
> CDMA works in practice;  I have seen simple example descriptions,

Two references presented at Globecom 90:

  W.C. Y. Lee, "Overview of Cellular CDMA"; also in May 1991 IEEE Transactions
  on Vehicular Technology.

  Gilhousen, Jacobs, Padovani, Viterbi, Weaver, Wheatley: "The Capacity of a Cellular
  CDMA System", also in May 1991 IEEE Trans. on Vehicular Tech. (and Globecom 90).

You may also want to check Lee's book "Mobile Cellular Telecommunications Systems".
I'm not sure if he covers CDMA.

-- 
Brian K. Daly WB7OML @ AG Communication Systems, Phoenix, Arizona
UUCP: {...!ames!ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!dalyb
Phone: (602) 582-7644    FAX: (602) 582-7111
~

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 00:26:16 GMT
From:      joaquin@NISC.SRI.COM (Jose Garcia-Luna)
To:        comp.protocols.tcp-ip
Subject:   MULTIMEDIA '92, CALL FOR PAPERS




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

	   		     C A L L    F O R   
		P R E S E N T A T I O N S / P A P E R S


			      MULTIMEDIA '92
		  4th IEEE COMSOC INTERNATIONAL WORKSHOP 
		     ON MULTIMEDIA COMMUNICATIONS


		MONTEREY, CALIFORNIA, USA - APRIL 1-4, 1992

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


MULTIMEDIA '92 is the 4th international workshop dealing with
multimedia communication systems and services as well as the creation,
processing, storage, transmission and human utilization of multimedia
imformation that gives a strong impact on realizing a future
"Information Society."

MULTIMEDIA is a forum for telecommunciation networks, terminals and
applications specialists to meet, discuss and understand each other's
objectives, requirements and constraints.  MULTIMEDIA '92 will be more
specifically devoted to applications in the area of computer and
human communication.

Authors are invited to submit an extended abstract of 1500 words in
English, clearly indicating a contribution in the areas of multimedia
communications shown below.  Any other topics or related subjects are
welcome.

The workshop will be held at the Hyatt Regency in Monterey,
California.  The participants will be limited to 150.


MULITMEDIA '92 PROGRAM:

	Network Architecture and Implementation
	Node Architecture and Implementation
	Protocol Design, Analysis and Engineering
	Human Interface
	Multimedia Terminals & Databases
	Standardization Activity & Experience
	Relevant Application
	Network-Supported Collaboration


DATES:  

	Abstract Submission 		- October 1, 1991
	Notification of Acceptance  	- December 1, 1991

Authors should submit three sets of abstract with their complete
address (including fax & e-mail) to:  

	J. Joaquin Garcia-Luna
	Technical Program Chair, Multimedia '92
	SRI International
	333 Ravenswood Avenue
	Menlo Park, CA 94025
	Phone:  415-859-5647
	FAX:  415-859-6028
	INTERNET:  garcia@sri.com


International Steering Committee:

Chair:			H. Terada (Osaka University)
Vice Chair:  		K. Aihara (NTT America)
Data Comm. Rep:  	K.D Joseph (Bell Canada)
Trans. Comm. Rep: 	M.R. Kincaid (MSK & Associates)
Computer Comm. Rep:  	J.J Garcia-Luna (SRI International)
Multimedia Comm. Rep:  	E.J. Addeo (Bellcore)
Switching Comm. Rep:  	I.E. Hilt (Deutschen Bundespost)
N. American Reps:  	N.D Georganas (University of Ottawa)
		   	S.B Weinstein (Bellcore)
European Reps:  	J.P. Coudresuse (CNET)
			D. Shepherd (University of Lancaster)
Asian & Pacific Rep:  	K. Murakami (Fujitsu Laboratories)

Workshop Committee:

General Chair:  	  K. Aihara (NTT America)
Technical Program Chair:  J.J. Garcia-Luna (SRI International)
Local Arrangements:  	  G.M. Lundy (Naval Post-Grad. School)


Sponsored by:  IEEE Communications Society

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 01:55:31 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   What the Heck Is SLIP? : -)

Would someone explain to someone who has taken data communications 
courses what SLIP is ?
Thanks-

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 04:06:42 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <43626@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Does anyone know where I can get the specification for IMAP?
>IMAP is a mail server, basically an enhanced POP.

The specification for IMAP is RFC-1176.  There will be a follow-up RFC
to define the extensions for the new Internet Message Bodies standard.

The April '91 IMAP distribution is on FTPHOST.CAC.WASHINGTON.EDU (IP
address 128.95.112.1) as imap/imap.tar.Z via anonymous FTP.

A major new revision is in the works and will be released later this
summer.

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 04:08:06 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <1991Jun25.111426.16743@wimsey.bc.ca> skl@wimsey.bc.ca (Samuel Lam) writes:
>IMAP3 is documented in RFC 1203, and IMAP2 is documented in RFC 1176.

IMAP3 is vapor.  All the existing (and future contemplated) software
is RFC-1176 based.

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 04:19:42 GMT
From:      russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u)
To:        comp.protocols.tcp-ip
Subject:   Wanted - LPR to a telnet terminal server.

What we want to do is drive printers attached to terminal servers (TRW 
telnet servers) from our SGI 4D Unix box. In particular I was wondering
if anybody has patched PLP to do this.

I am aware that the LPR protocol handles spooling by passing whole files
at a time. THis means that the host driving the printer *must* have
space to store the file. i.e. it rules out programming the terminal
servers to understand LPR. (this was our first hope :-()

What we are now looking at is having the lpd open a telnet session to
the server instead of spitting the file out a serial port. 

Thanks, Russell.

-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@aukuni.ac.nz>

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 05:22:41 GMT
From:      gmc@PREMISES1.QUOTRON.COM (Greg Christy)
To:        comp.protocols.tcp-ip
Subject:   What the Heck Is SLIP? : -)


SLIP stands for Serial Line IP.  It is a method for framing IP
datagrams for transmission over a serial line.  This is quite often
used to connect one IP host or gateway to another over dial-up modems.
There are a number of implementations available for UNIX systems, IBM
PCs, and terminal servers.   See RFC-1055 for details on the protocol.

While SLIP is widely available, it is considered a "non-standard"
internet protocol.  The "standard" protocol for doing this is the
Point-to-Point Protocol or PPP (RFC-1171 and RFC-1172).  While PPP is
the up-and-coming method for establishing serial network links, it has
taken more time to find its way into the commercial mainstream.  This
is probably due to a variety of reasons, least of which is the greater
complexity of implemention of PPP as compared to SLIP.

I have found that the most important feature for a dial-up IP link,
whether it is SLIP or PPP, is the availability of Van Jacobson's TCP
header compression (RFC-1144).  This makes an incredible difference in
the effective throughput. 

Greg

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 07:13:46 GMT
From:      olson@anchor.esd.sgi.com (Dave Olson)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for SGI

In <1991Jun25.212241.10954@neon.Stanford.EDU> grossman@Sunburn.Stanford.EDU (Stu Grossman) writes:

| Is there a slip implementation for SGI (Personal Iris's or Power Servers)?  If
| so, where can I get it from?

You can get it from SGI; contact your sales person.

| On a related topic, what brand of UART is used in the aforementioned systems?
signetics SCN2681 (motorola SCN68681)

The newer systems (4D/35 and 4D/30) have have 8530 duarts (actually
a variant with a larger silo).

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 12:51:42 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM flights


Hi folks:

    ACM asked me to remind folks in North America that the last day for
the airfare deal for SIGCOMM '91 is June 30th (last business day before
the 30th is *this* Friday).

Craig

========================================================================

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


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

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.

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 13:56:01 GMT
From:      dale@interlan.Interlan.COM (Dale B)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.questions,unix-pc.general
Subject:   Re: Network backups

In article <83@nixeid.UUCP> qoffice@nixeid.UUCP (Qofiice Software) writes:
>Posting the following for a colleague.......
>
>
>
>
>To:	Anyone out there
>
>
>	I am currently looking for a TCP/IP based software package that
>	performs unattended, command line or batch mode file transfer.
>	It is to be UNIX based (SCO pref.), but can be used with MS-DOS
>	FTP. PC TCP/IP. Of course, thats the ideal, but I'd be willing to
>	know of anything that even remotely comes near this. The option of
>	stitching together an ftp based solution is too awful to 
>	contemplate, so any answers would be greatly appreciated. Something
>	akin to Legato Networker (no plugs please) would be nice.
>
>	If no such product exists, then why not, and will it ever, and if
>	it does, then I'll take it.
>
>	Thanks in advance,
>
>					Gary Smyth,
>					Siemens Nixdorf Ireland 

Sorry for having to post a reply, but I have yet to figure out how to email to
UUCP domains, tried everything I could think of and the message just kept 
bouncing back, I don't even think it left the machine.

Anyway...
For software that's 'in the works' check with Workstation Solutions in Nashua,
New Hampshire (USA).  Sorry, I don't have their address but their phone number
is (603)880-0080.  A fellow by the name of Jim Ward heads the company.  Also,
could you drop me an email giving a quick sumary of what you find, after you
think you have everything in?  I'm interested in what's out there also.

Dale - dale@interlan.interlan.com

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 19:43:22 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

<IMAP3 is vapor.  All the existing (and future contemplated) software
<is RFC-1176 based.

Well, the conclusion that IMAP3 will not succeed as an eventual
standard does not follow from the premise that IMAP3 has no
reference implementation.  That aside, after briefly scanning the
IMAP3 RFC it's clear that the IMAP3 and IMAP2 groups have some
bad blood between them and serious differences on how to implement
a mail server.

Can someone out there clarify the politics of this situation and
give some solid reasons why one standard is likely to succeed
over the other?

Thanks,
Will Estes        Internet: Will@cup.portal.com
                  UUCP: apple!cup.portal.com!Will

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 19:48:28 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: copyright status and future development of comp.archives


Ed,
 
You write....
> So far as I can tell, none of the
> commercial internet providers as of yet have anyone filling this role;
> Cerfnet and ANS has nothing along this line, UUNET's generic title is
> "postmaster", and everyone at PSI is working on X.500.

Actually PSI is working on X.500, Z39.50v2, SNMP, and several research
protocols...

In your initial posting you took a shot at X.500, and in some sense
it is implicit in this message also.  While there are a number of
negative aspects vis a vis X.500 it IS intended and IS being used to
register all kinds of information today.  Your obviously familiar with
the WhitePages work that many people have worked on over the last three
years.  As with any new network protocol there is the chicken and egg
problem, now that we have Mac applications that are available via anonymous
FTP and soon MSDOS applications I'd like to believe that we're going to
break out of our shell!

What you may not be aware of is that X.500 is bound to information retreival
(and of course information registration).  Under DARPA R&D sponsorship
PSI, along with a few other organizations, (Jon Postel can speak to
"FOX") we have been exploring this.  We have a tool which integrates
X.500 and Anonmous FTP so that you can (today) explore the RFC hierarchy
by author, title, etc, and then grab the document from various sites
which hold the RFC's.  The tool is called x5ftp and will be released
no later then the end of the project (31dec91).

And we're extending the model to deal with other things than RFC's....

But again X.500 is not the perfect protocol for information retreival,
neither is Z39.50, and we won't even talk about MARC records!  Recently
due to a discussion in the FOX group we decided to issue the equivalent
of a position paper which is titled "Towards Networked Information
Retrieval", available via anonymous FTP from uu.psi.com in

	wp/nir.ms (troff, ms macros)
	wp/ps/nir.ms (Postscript)

Take a look.

I think your efforts are appreciated by many, I hope they are fruitful,
others are working hard too, and believe that they are on a fruitful
path too.  A decade from now we MAY know who was right.

Marty

PS:  There is some X.500/WhitePages information on-line which can be
	retreived by sending email to wp-info@psi.com, a NULL message
	will suffice, as it does an "auto-reply".

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 21:51:03 GMT
From:      tr@samadams.princeton.edu (Tom Reingold)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

mogul@pa.dec.com (Jeffrey Mogul) writes:

$ The system I implemented (see my paper in Proc. 1989 Summer USENIX
$ Conf.) currently sends "Host Unreachable" packets, but only in
$ those cases specified in the filtering rules.  E.g., the manager
$ of the gateway can say:

$ 	from any to any tcp port telnet reject notify;
$ 	from any to any tcp port finger reject;

$ This means that telnet users will get notification via ICMP, and finger users
$ will see their connections time out.  (This is a contrived example; in
$ real life, we tend to send notifications except in cases where nobody
$ is likely to be listening and the traffic rate could be high.)

$ In my implementation, the choice of ICMP type+code is wired into the kernel.
$ Given that I allow fine-grained choice of when to send an ICMP, it might
$ also be reasonable to add fine-grained choice of which ICMP code to send.
$ However, we've been running this way for more than 2 years without any
$ problems. [This code is now shipping with Ultrix (release 4.2) so if I
$ made the wrong choice, I guess I'll hear about it.]

Forgive me if I am mentioning something that has been discussed here
before...

Is this sort of approach a "good idea"?  It has become common, with
different methods of implementation.  Would it not make more sense to
take the burden of security away from networks and put it on hosts?  To
me, it seems that firewalls like these are analogous to roadblocks on
highways that are placed there because a criminal MIGHT be using the
road to commit a crime.  I prefer to be presumed innocent and I like
having a road that is free for both me and the criminals.  I prefer
banks putting up heavy locks to prevent robberies over roadblocks on
roads.

What do network experts feel about this?
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 91 22:05:24 GMT
From:      davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   Re: SCO Unix 16-bit cards

In <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:

| After repeated calls to SCO, which, by the way, has the LONGEST
| queing mechanism I've ever encountered, I have been able to find
| _NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find
| it hard to believe that I can get 16-bit drivers for a simple MS-DOS
| machine but *NOT* for our multi-gigabyte SCO hosts!!!!
 
| Does ANYBODY know of any 16-bit drivers for SCO Unix?
| (WD 8013 preferred)....

  But... we run them with Xenix! The latest version of ODT is supposed
to have the current TCP. We haven't done the upgrade on any of the
machines with 8013s yet, but we sure assume that they will work.

  If they don't we won't upgrade the Xenix machines, and SCO will get
about a dozen copies of ODT back with some rude restocking suggestions.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
  GE Corp R&D Center, Information Systems Operation, tech support group
  Moderator comp.binaries.ibm.pc and 386-users digest.

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 00:30:15 GMT
From:      ejm@riscit.NOC.Vitalink.COM (Erik J. Murrey)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In article <tr.677973063@samadams>, tr@samadams.princeton.edu (Tom Reingold) writes:
|> Forgive me if I am mentioning something that has been discussed here
|> before...
|> 
|> Is this sort of approach a "good idea"?  It has become common, with
|> different methods of implementation.  Would it not make more sense to
|> take the burden of security away from networks and put it on hosts?  To
|> me, it seems that firewalls like these are analogous to roadblocks on
|> highways that are placed there because a criminal MIGHT be using the
|> road to commit a crime.  I prefer to be presumed innocent and I like
|> having a road that is free for both me and the criminals.  I prefer
|> banks putting up heavy locks to prevent robberies over roadblocks on
|> roads.
|> 


I wish the world were perfect enough to do this.  Why configure all 10,000+
hosts with stiffer security options when you have small handful of gateways
connecting them to the outside world?  You also better hope that all 10,000+
hosts are running new enough software to prevent the network attacks
that a firewall can stop.

And please tell me what happens when an Engineer connects his
brand-spanking-new workstation to the network with no passwords on his
accounts.  Do you have a security patrol that checks?

---
Erik J. Murrey
Vitalink Communications NOC
ejm@NOC.Vitalink.COM	...!uunet!NOC.Vitalink.COM!ejm

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 01:16:52 GMT
From:      moghe@husc8.harvard.edu
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   telnet BLUES ~~~; need fix.


Gentlemen:

I used to be able to run the folowing like script but
it does not work on the SUN OS4.1.1. Any suggestion
on doing a telent session via a script file would be
greatly appreciated.

Many thanks,

moghe@husc.harvard.edu

-------------------- e.g. script ---------------------
telnet <remotehost> <<eof
<username>
<password>
date
<other commands>
eof
--------------------- end -----------------------------

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 02:01:34 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <43708@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Can someone out there clarify the politics of this situation and
>give some solid reasons why one standard is likely to succeed
>over the other?

Sigh.  I've avoided discussing this because there has already been too
much airing of dirty laundry in public on this matter.  I hope I can
answer this question once and forget about it.  I would prefer to
ignore `IMAP3' and go about my work in building IMAP2 environments.

The story is that the author of the `IMAP3' specification wanted to
make several fundamental changes in the protocol to make his Lisp
machine implementation simpler.  He also felt that the IMAP2 model was
wrong; this is a religious argument more than anything.

Simply put, the religious difference goes like this: IMAP2 uses a
state-update model, in which clients access a local state that is
updated from a remote state as necessary.  IMAP2 also tries to work
well on networks where RTT's and/or throughput is bad.  Those of us
who use 2400 baud SLIP lines or Milnet know what I'm talking about.

IMAP3 is premised on always retrieving data from the network with no
local caching of state.  IMAP3 assumes RTT's are insignificant (that
is, you're on a high-speed LAN); it has operations (albeit not
specified well enough to implement) to fetch a single piece of a
message (e.g. to-list) at a micro-level.  The equivalents in IMAP2 are
at a higher-level; e.g. a single operation to fetch a structured
representation of all of the message envelope information in a single
transaction instead of separately fetching date, from, subject, to,
cc, etc. etc. in separate RTT's.

I wrote RFC-1176 as a replacement to my original RFC-1064, with the
sole intention of codifying reality and correcting bugs in RFC-1064.
I was not, at this stage, interested in making fundamental changes
that would break the entire installed base of IMAP users.  Everything
that is in RFC-1176 reflects IMAP software as it is actually
implemented, including at the site where the author of RFC-1203 works.

Because I had reservations about giving in to all of his demands, he
decided to get back at me by writing his RFC-1203 on `IMAP3'.  It
never should have been published; it accidentally slipped through the
cracks in the RFC review process.  When it was proposed that the
dispute be solved through the IETF, he asked "what's the IETF?"  I
don't think he or anyone else at that organization tracks what goes on
with Internet e-mail standards development; they have a lot of N.I.H.

The `IMAP3' protocol described in RFC-1203 has a number of operational
bugs which become apparent if anybody tries to implement it.  It does
not offer any greater asynchronity than IMAP2 (claims to the contrary
notwithstanding) and has a lot of poorly-thought-out ideas (for
example, the mechanism for binary mail).  Large chunks of `IMAP3' are
not specified at all (e.g. data base keys) other than as a concept.

I had written up a large document describing all the bugs in RFC-1203
that make it unimplementable without major changes.  After about 30K
of text I realized I was shooting fish in a barrel and put it aside.

The last I heard, the entire organization in which the author of
RFC-1203 works is going through some serious funding difficulties and
has had major staff cuts.  I don't know if any work has taken place at
all on RFC-1203; if it had I'm sure I would have heard something.  I
doubt it will ever see the light of day.

I am working on extensions in IMAP2 for the Borenstein/Freed Internet
Message Bodies extensions (the so-called `RFC-XXXX') and will be
releasing a major new release of IMAP2 which supports it.  As there
are no implementation of `IMAP3', and as IMAP2 is evolving to support
the new standards for typed/multipart e-mail, I don't believe that
`IMAP3' will do anything in the long-term other than to damage the
credibility of a lot of people who've worked on IMAP2.

Mark Crispin

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 03:18:22 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: What the Heck Is SLIP? : -)

In article <1991Jun26.015531.241@socrates.umd.edu>, coates@UC780.UMD.EDU writes:
>Would someone explain to someone who has taken data communications 
>courses what SLIP is ?
>Thanks-

I have received reponses to this question and really do appreciate them.
I will forward or summarize answers for anyone interested.
Again Thanks!

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 04:06:34 GMT
From:      mills@ccu.umanitoba.ca (Gary Mills)
To:        comp.protocols.tcp-ip
Subject:   Copies and E-mail with lpr/lpd

I'm looking for solutions to a couple of annoyances with lpr/lpd.  The machine
is a Sun-4/280 under SunOS 4.1.1.  

1) I have an ``if'' filter that diverts output through UREP to some IBM
mainframe printers.  It works fine, but if you specify multiple copies to
lpr, each copy is handled separately.  The number of copies is not made known
to the filter.  Is there perhaps a replacement that is more intelligent
about this, or another way to do it?

2) Lpd sometimes mails error reports to the person who submitted the print
job.  However, if the job comes from another machine, it mails to user@host,
rather than the fully-qualified domain name.  If the host is in another
domain, the mail fails.  Mail to PCs running NCSA Telnet also bounces.  Can
this be made more intelligent?

-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 04:43:09 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In article <tr.677973063@samadams> tr@samadams.princeton.edu
(Tom Reingold) writes:
+---------------
| Is this sort of approach a "good idea"?  It has become common, with
| different methods of implementation.  Would it not make more sense to
| take the burden of security away from networks and put it on hosts?  To
| me, it seems that firewalls like these are analogous to roadblocks on
| highways that are placed there because a criminal MIGHT be using the
| road to commit a crime.  I prefer to be presumed innocent and I like
| having a road that is free for both me and the criminals.  I prefer
| banks putting up heavy locks to prevent robberies over roadblocks on roads.
+---------------

Well, to me the analogy is less to roads and more to my house. I have several
rooms in my house, and some have private files that I need to protect very
well and some have nothing of very much importance at all. But I'd rather
put a lock on the front door (the firewall) and enjoy the convenience of
being able to walk freely from room to room, picking up a novel here and
a confidential file there, as opposed to leaving the front door wide open
and then having to use a key to get from the bedroom to the bathroom, a key
to get from the bathroom to the kitchen, and a key to get from the kitchen
to the study.

Organizations which prefer, for whatever reasons, to have a more "homey"
atmosphere within their "walls" (internal internet) tend to prefer the firewall
approach. It allows the conveniece of, say, open guest accounts on internal
systems without worrying about uninvited outside "guests". Yet a "well-behaved"
firewall -- together with a few specially-secured servers -- still allows a
controlled degree of sharing and communication. (E.g., my house allows the
postal deliveryperson to drop mail through the slot, allows the gas meter
to be read, and allows garbage to be carted away -- all without my being
there to approve it.)

I guess it just depends on your situation and perspective.


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 05:17:34 GMT
From:      mikes@iuvax.cs.indiana.edu (Michael Squires)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO Unix 16-bit cards

In article <3486@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>In <1991Jun12.200105.5024@group1.UUCP> johnw@group1.uucp (John Wheeler) writes:
>
>| After repeated calls to SCO, which, by the way, has the LONGEST
>| queing mechanism I've ever encountered, I have been able to find
>| _NO_ 16-bit cards supported by SCO Unix. CAN THIS BE TRUE? I find

ODT 1.0 (SCO UNIX 3.2.1) is running on the box from which I am posting
this note (via a login to iuvax) with a WD8013E card and seems to
happily coexist with a Sun 4/110FCE using NFS, telnet, and ftp.

The card is one of the older ones that has jumper-selected IRQ and I/O addresses.
For reasons that I don't pretend to understnd only IRQ 2 works.  Two WD8003EPR
cards failed in the same machine, one caused a failure during UNIX boot and
the other crashed the system irregularly (these are newer 8003E cards).
Both work fine under DOS, incidentally, as does the 8013E.

Older WD cards are available from surplus houses, such as LAN Recyclers and
Computer Recyclers.

-- 

Mike Squires (mikes@iuvax.cs.indiana.edu)     812 855 3974 (w) 812 333 6564 (h)
mikes@iuvax.cs.indiana.edu          546 N Park Ridge Rd., Bloomington, IN 47408
Under construction: mikes@sir-alan.cica.indiana.edu

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 05:46:11 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Info on directory servers requested

I'm toying with the idea of implementing a small local (campus) directory
server on a little Unix machine (an A/UX SE/30, maybe?). It's more of an
experiment, or showing someone that it *can be done*, rather than a *real*
service.

I imagine a Unix daemon, which would respond to requests on one of the
unused ports, and search a text file database for matches. I'm interested
only in queries like <last name> {<first name>}, possibly with wildcards.
The idea is to get e-mail address(es) of the matching person(s) in return,
nothing else; the response would be handled by some simple PC front-end.

I read the RFC on DAP, and it sort of scared me by the complexity of the
protocol. It does mention a program called "dish" - hence my first
question: where can I get it? what does it do?

Second question: has anyone implemented this obvious simple scheme I
described above? Or maybe it isn't as simple as it seems to me? I'd be
grateful for all comments and hints.
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 06:13:30 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Info on directory servers requested

I'm toying with the idea of implementing a small local (campus) directory
server on a little Unix machine (an A/UX SE/30, maybe?). It's more of an
experiment, or showing someone that it *can be done*, rather than a *real*
service.

I imagine a Unix daemon, which would respond to requests on one of the
unused ports, and search a text file database for matches. I'm interested
only in queries like <last name> {<first name>}, possibly with wildcards.
The idea is to get e-mail address(es) of the matching person(s) in return,
nothing else; the response would be handled by some simple PC front-end.

I read the RFC on DAP, and it sort of scared me by the complexity of the
protocol. It does mention a program called "dish" - hence my first
question: where can I get it? what does it do?

Second question: has anyone implemented this obvious simple scheme I
described above? Or maybe it isn't as simple as it seems to me? I'd be
grateful for all comments and hints.

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

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 09:21:00 GMT
From:      thomas@nexus.se
To:        comp.protocols.tcp-ip
Subject:   STREAMS flow control in SunOS 4.1.1

I've converted an application using a TCP socket to talk to a remote process
to use STREAMS instead. The communication is half duplex, the connection is
established and a lot of data is sent to the remote end and a reply is
expected after the remote end has consumed the data.

When I've set up the connection I I_PUSH tirdwr (after I_POPing timod)
to be able to use the ordinary read / write system calls. 
If I'm using sockets there wont be more than a few K bytes on the way
before write blocks. Using STREAMS I find that write will 
never block, I can cram 150K down the stream without blocking. The problem is
that I seem to lose the last part of the data. Also data flowing from the 
remote end is lost. Using a lanwatcher I can see that the last part of the
data written is not transmitted and that the remote end actually sends data 
that is never delivered to the process.

I would like the behaviour of the stream to match that of a socket. 
What am I missing? Is there an option that can be used on the stream that
would limit the amount of data that is on the way before blocking 
or is it a bug in SunOS?


--
Real life:      Thomas Tornblom             Email:  t_tornblom@nexus.se
Snail mail:     Communicator Nexus          Phone:  +46 18 171814
                Box 857                     Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 09:24:40 GMT
From:      tjc@ecs.soton.ac.uk (Tim Chown)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In <113425@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:

>Organizations which prefer, for whatever reasons, to have a more "homey"
>atmosphere within their "walls" (internal internet) tend to prefer the firewall
>approach. It allows the conveniece of, say, open guest accounts on internal
>systems without worrying about uninvited outside "guests". Yet a "well-behaved"
>firewall -- together with a few specially-secured servers -- still allows a
>controlled degree of sharing and communication. (E.g., my house allows the
>postal deliveryperson to drop mail through the slot, allows the gas meter
>to be read, and allows garbage to be carted away -- all without my being
>there to approve it.)
 
The problem comes with remembering to shut all the windows ... ;-)

Tim
-- 

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 10:19:07 GMT
From:      keith@ca.excelan.com (Keith Brown)
To:        bit.listserv.ibm-nets,bit.listserv.ibmcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Telnet from DOS - UNIX box via serial port &

The News Manager)
Nntp-Posting-Host: ca
Reply-To: keith@ca.excelan.com (Keith Brown)
Organization: Novell, Inc. San Jose, California
References: <1991Jun01.012032.3364@actrix.gen.nz>
Date: Wed, 26 Jun 1991 21:15:09 GMT

In article <1991Jun01.012032.3364@actrix.gen.nz> john@actrix.gen.nz (John Vorstermans) writes:
>
>I am looking for software that will allow a user dialing in via modem
>to a DOS box to login to a UNIX box via a small local ethernet.
>

This is exactly what some of us are in the habit of doing here. How?
Well, about a year ago I had an idea (not had one since but I am working
on it :-)). We (Novell) have a product called the Access Server. To cut
an entire slide presentation down to one sentance, the Access Server is
basically 16 PCs in a single 80386 PC, each virtual PC being able to
be dialled into over serial lines from a variety of devices including
terminals and remote PCs and each virtual PC is NetWare enabled (ie. you
can dial into an Access Server, become a virtual PC, switch to a network
drive and login to a NetWare server). Terrific....

We also have a product called the LAN WorkPlace for DOS. This is our TCP/IP
offering for DOS PCs that contains a fully re-entrant TCP/IP stack that
hangs together splendidly under both Windows 3.0 and, more importantly in
this case, Desqview. The way the Access Server does it's multiple virtual
PC on one 386 processor trick (and its memory management) is via a
"specialish" version of Desqview. Given that the LAN WorkPlace works with
Desqview, it doesn't take a giant leap of the imagination to conclude that the
LAN WorkPlace and the Access Server can be used in conjunction with each
other. This is basically what I did and it worked like a charm. You can dial
into an Access Server and telnet and FTP your way out onto the LAN.

The trick...... Before the AS fires up, load up and configure the LAN
WorkPlace TCP/IP transport TSR (and its underlying ODI driver, of course).
You also need to load our Int 14h redirector (TELAPI) if you wish to use
telnet from inside the DOS boxes, which I imagine everyone will? Then,
edit the various batch files that initialise the Access Servers RAM disk
to copy the various LAN WorkPlace utilities into the appropriate directories
so they will be available to the virtual PCs.  This is actually optional
as you could just keep the LAN WorkPlace utilities on a server somewhere
and get at them that way after logging in to said server. Finally, execute
the batch files that start up the Access Server and Bob is, as they say,
your uncle.

Now for the bad news. You need two LAN adaptors.  Yes, yes, I know! :-( :-(
The reason is that LAN WorkPlace uses the ODI and the Access Server doesn't.
Please don't flame me, it's not my fault. Still, if you do have an extra
LAN adaptor handy.......

Keith
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 12:29:18 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <1991Jun26.040642.8535@milton.u.washington.edu>, 
mrc@milton.u.washington.edu (Mark Crispin) writes:
> A major new revision is in the works and will be released later this
> summer.

Who is working on this?


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 13:35:19 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: well-behaved firewalls

In article <tr.677973063@samadams> tr@samadams.princeton.edu (Tom Reingold) writes:
>mogul@pa.dec.com (Jeffrey Mogul) writes:
 
>$ [ how he does a firewall ]
 
>Forgive me if I am mentioning something that has been discussed here
>before...

Many things are discussed repeatedly, in search of a better conclusion
that the last time. No forgiveness needed...

>Is this sort of approach a "good idea"?

Yes. After all, it's a network admins' job to keep the network secure
as well as up-and-running.

>                                         It has become common, with
>different methods of implementation.  Would it not make more sense to
>take the burden of security away from networks and put it on hosts?  To
>me, it seems that firewalls like these are analogous to roadblocks on
>highways that are placed there because a criminal MIGHT be using the
>road to commit a crime.  I prefer to be presumed innocent and I like
>having a road that is free for both me and the criminals.  I prefer
>banks putting up heavy locks to prevent robberies over roadblocks on
>roads.

Not quite a good analogy. Domains are more like private housing areas,
or apartment complexes, which don't have public roads thru them. You
can drive anywhere on the public roads (use the InterNet) you want,
and shouldn't be hindered by roadblocks (firewalls) without some act
on your part (note that this is contrary to MADDs' attitude), but you
have no business driving around in my parking lot (accessing my
domain). Rules for use of public property differ from those for private
property. The property owner (network admin) is perfectly within their
rights to refuse access (respond Host Unreachable) to anyone that isn't
paying rent or a member of the private community (users).

I want to see wide access for everyone, myself. My first responsibility
is to the users and our employer, though.

>What do network experts feel about this?

I'll want to see that as well. I'm certainly no expert, yet.

-- 
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?".

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 14:42:46 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   TCP Throughput over E-net

I have a question regarding TCP throughput on Ethernet, and what affects
it on a local network. I have 3 systems, two Sparc2s and an RS6000. I'll
call them A, B, and C :

	A - Newly installed Sparc, SunOs 4.1.1
	B - 6 month old Production Sparc 4.1.1
	C - Newly installed RS/6000 AIX 3.1.5

When I transfer a 1.7 MB binary file between systems, the results are
inconsistent between systems when I change the direction of the data flow.
There is also an inconsistency from machine to machine. The throughputs are:

	A -> B     850 KB
	A -> C     550 KB
	B -> A     270 KB
	B -> C     500 KB
	C -> A     200 KB
	C -> B     270 KB

All machines are idle and I was the only user during the tests. I used
rlogin to get from machine to machine, and used ftp binary transfers.

Could the flow direction impact the throughput this greatly? I would 
normally attribute this to hardware and/or TCP implementation differences,
but two of the machines are identical, and they all transfer 500 KB or
greater to at least one other machine in at least one direction.

Of course, I'd like them all to transfer at 850 KB to all machines in all
directions :-). Is there something I've missed or something I should look
at in my set-up here ?

Thanks for any insight...
-- 
Dewey Paciaffi           ...!uunet!edi386!eddjp

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 15:17:29 GMT
From:      blknowle@FRODO.JDSSC.DCA.MIL (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: SOS: C Routines to convert ASCII to EBCDIC

Folks,

    I just checked my man pages, and found a utility called ``dd'' that
purports to convert ASCII to EBCDIC (even does IBM-specific EBCDIC, for
further compatibility with certain print trains), and back.  I looked on
my SunOS 4.0.2 386i, and it is there, and is present under under SunOS
4.0.3 (checked on a Sun 4/280) and SunOS 4.1.1b (on my SS2).  From this, I
assume (perhaps wrongly) that dd is available under all machines running
SunOS 4.0.2 or later.

    I believe dd is part of the standard SVR3/BSD 4.2 and later versions
of those Operating Systems, although not all versions may do ASCII-EBCDIC
conversion.

    I haven't tried dd to convert ASCII to EBCDIC and/or back, but I'm
sure I'll get the opportunity -- I'll let you know if I have any
problems.

    So, in addition to everything else I've seen said here, how about
``RTFM''?

Please respond via e-mail -- I have a hard time keeping up with this list!
 ________________________________________________________________________ 
| Brad Knowles                 | Internet: blknowle@frodo.jdssc.dca.mil  |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849  Fax: (703) 693-7329 |
| The Pentagon, Room BE685     |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
| Washington, D.C.  20301-7010 | Speaking from, *not* for DISA (nee DCA) |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 15:59:52 GMT
From:      johnc@uh.msc.edu (John D. Cavanaugh)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   XTP

Does anyone know where I can find a description of the XTP protocol?
Email or FTP is preferred, but I'd be happy to find a reference to
a paper.

Thanks.

John Cavanaugh                              EMail: johnc@msc.edu
Minnesota Supercomputer Center, Inc.        Phone: (612) 626-0277
1200 Washington Ave. S                      FAX:   (612) 624-6550
Minneapolis, MN  55415

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 16:26:00 GMT
From:      puglia@cunixa.cc.columbia.edu (Paul Puglia)
To:        bit.listserv.ibm-nets,bit.listserv.ibmcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Telnet from DOS - UNIX box via serial port &

In article <1991Jun26.211509.8113@novell.com> keith@ca.excelan.com (Keith Brown) writes:
>The News Manager)
>Nntp-Posting-Host: ca
>Reply-To: keith@ca.excelan.com (Keith Brown)
>Organization: Novell, Inc. San Jose, California
>References: <1991Jun01.012032.3364@actrix.gen.nz>
>Date: Wed, 26 Jun 1991 21:15:09 GMT
>
>In article <1991Jun01.012032.3364@actrix.gen.nz> john@actrix.gen.nz (John Vorstermans) writes:
>>
>
>We also have a product called the LAN WorkPlace for DOS. This is our TCP/IP
>offering for DOS PCs that contains a fully re-entrant TCP/IP stack that
>hangs together splendidly under both Windows 3.0 and, more importantly in
>this case, Desqview. The way the Access Server does it's multiple virtual
>PC on one 386 processor trick (and its memory management) is via a
>"specialish" version of Desqview. Given that the LAN WorkPlace works with
>Desqview, it doesn't take a giant leap of the imagination to conclude that the

Speaking of Desqview, or more specifically, Desqview/X. I have heard
there has been some hint that Desqview/X will only work with FTPs
stuff. For those of us folks who are going to run LAN WorkPlace,
and would like to use Desqview to turn our pcs into X terminals.
this is a minus.  Does anyone know if Desqview/X is going to support
Lan WorkPlace for DOS? 

Paul Puglia
Dept of Civil Engineering
Columbia Univserity

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 18:57:59 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: copyright status and future development of comp.archives

In article <9106261948.AA20843@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:

   We have a tool which integrates
   X.500 and Anonmous FTP so that you can (today) explore the RFC hierarchy
   by author, title, etc, and then grab the document from various sites
   which hold the RFC's.  The tool is called x5ftp and will be released
   no later then the end of the project (31dec91).

   And we're extending the model to deal with other things than RFC's....

Well, I'd have to say that dealing with RFC's is about as easy as they
come, and you'd better have a damn fine project when you're done or
I'll be quite disappointed.  The texts are regular and structured,
there's a lot of boilerplate text which could be extracted out and
conclusions drawn from it, and there's a substantial amount of
"superstructure" in that RFCs reference other documents and there's a
strong sense of "this supersedes that, this modifies that, etc.".
It's a consistent, high quality, verified data stream, you should be
able to do a lot more with it than just browse author and title.

There is no "RFC Hierarchy"; the collection of RFCs is a complex,
tangled web of references, updates, improvements, discussions, and
ephemera.  Attempts to impose a strict hierarchical structure on it
will fail to capture the richness of information in it.  

Does your tool provide any way to search through the various sections
of the RFCs?  For instance, modern RFCs all have a "security
considerations" section; can you browse through those looking for RFCs
which have extensive discussion?  That would be valuable.

Does your tool provide any kind of similarity metrics or groupings
between the RFCs, so that (e.g.) RFC's 1064, 1176, and 1203 are
presented together (IMAP), with RFC 1223 not too far away (POP3) ?  A
tool with proper browsing support would facilitate this kind of exchange.

Several RFCs reference materials which are available for anonymous FTP
from other sites; does your browser have direct support for (e.g.) the
NOCTOOLS catalog?  A good system would let you point and click and get
the goods delivered back to your local machine.

A proper browser or filtering agent would have the ability to store
queries for later replay.  If I find an RFC that I like, can I store
the query that found so that the next time an RFC (or internet draft)
is issued that's similar to it I will be notified?

An RFC tool would be a useful thing, but I don't have high hopes for
x5ftp, to the extent that X.500 is a gubbishy protocol for these kind
of searches and that you're constrained to use that technology.

   ... we decided to issue the equivalent
   of a position paper which is titled "Towards Networked Information
   Retrieval"...

Full citation below.  A reasonably good paper, albeit wordy,
illustrating the defects in both X.500 and Z39.50 for information
retrieval; neither process seems adequate to handle the problem at
hand, though you could argue that any work in this area is progress
and should be supported.  Notably missing from the paper is a mention
of Brewster Kahle's WAIS project (see below), which is an
implementation of Z39.50 that addresses some of the defects mentioned.

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"

-- MSEN Archive Service file verification
uu.psi.com
-r--r--r--  1 dsadmin  staff       50666 Jun 25 18:27 /wp/nir.ms
-r--r--r--  1 dsadmin  staff       56973 Jun 27 11:16 /wp/nir.txt
-r--r--r--  1 dsadmin  guest      117611 Jun 25 18:27 /wp/ps/nir.ps
found psi-networked-information-retrieval ok
uu.psi.com:/wp/{nir*,ps/nir*}

-- MSEN Archive Service file verification
quake.think.com
total 5561
drwxrwxrwx  2 14           1024 Jun 25 00:07 wais-discussion
-rw-rw-rw-  1 1637       635857 Jun 21 21:50 WAIStation-Canned-Demo.sit.hqx
-r--r--r--  1 14         463981 Jun 13 20:44 wais-8-b1.tar.Z
-rw-rw-r--  1 1556       475161 May 21 18:43 wais-8-a12-3.tar.Z
-rw-rw-rw-  1 1637       635225 May 16 03:01 WAIStation-0-62.sit.hqx
-rw-rw-rw-  1 999        321268 May 13 20:48 wais-ir12.ZU
-rw-rw-rw-  1 14         409388 Apr  5 00:44 wais-8-a11.tar.Z
-rw-rw-rw-  1 1637      1094536 Mar 28 00:37 WAIStation-0-62-Sources.sit.hqx
-rw-rw-rw-  1 14        1070714 Mar 23 01:24 WAIStation-0-61.sit.hqx
-rw-rw-rw-  1 14         475815 Mar 23 01:19 wais-8-a10.tar.Z
found wais ok
quake.think.com:/pub/wais/

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 19:55:22 GMT
From:      coates@uc780.umd.edu
To:        comp.protocols.tcp-ip
Subject:   What the Heck is SLIP ?  : -)

The message posted in this group mentions all the facts contained in all of the messages I received.
The message posted in this group mentions all the facts contained in all of the messages I received.

**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 19:56:55 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Anon-ftp setup under ISC 1.0.6 using Micom-Interlan 322/622 code

Well, I've dug thru TFM and applied some extra steps from past postings
on the subject. However, I'm having a problem getting some of the ftp
commands to work when using the anon-ftp login. All the commands work
fine under a regular user login.

Symptoms:

ftp> ls
200 PORT command successful.
150 Opening data connection for /bin/ls (143.116.12.3,1080) (0 bytes).
226 Transfer complete.

ftp> dir
200 PORT command successful.
150 Opening data connection for /bin/ls -l (143.116.12.3,1081) (0 bytes).
226 Transfer complete.

ftp> pwd
451 Permission denied.

.... and so on. Strangely, I can get/put, and cd works--I just can't
find out where I am, or what files are there.

My /ftp directory looks like this (totals/blank lines deleted):

> ls -alR
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 .
drwxr-xr-x  21 root     sys          656 Jun 27 13:34 ..
dr-xr-xr-x   2 root     sys           64 Jun 27 13:50 bin
dr-xr-xr-x   2 root     sys           80 Jun 27 14:23 dev
dr-xr-xr-x   2 root     sys          112 Jun 27 14:06 etc
drwxrwxrwx   2 ftp      sys           48 Jun 27 13:52 pub
dr-xr-xr-x   2 root     sys           80 Jun 27 14:23 shlib
./bin:
dr-xr-xr-x   2 root     sys           64 Jun 27 13:50 .
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 ..
---x--x--x   1 root     sys        22540 Jun 27 13:36 ls
---x--x--x   1 root     sys        15448 Jun 27 13:50 pwd
./dev:
dr-xr-xr-x   2 root     sys           80 Jun 27 14:23 .
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 ..
crw-rw-rw-   4 root     root       9, 22 Mar 26 18:15 is
crw-rw-rw-   4 root     root       9, 24 Mar 26 18:15 it
crw-rw-rw-   2 bin      bin        3,  2 Jun 27 12:40 null
./etc:
dr-xr-xr-x   2 root     sys          112 Jun 27 14:06 .
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 ..
-rw-r--r--   1 root     sys          274 Jun 27 13:37 group
-rw-r--r--   1 root     sys          956 Jun 27 14:33 passwd
-rw-r--r--   1 root     root          36 Jun 27 14:27 utmp
-rw-r--r--   1 root     root          36 Jun 27 14:27 wtmp
./pub:
drwxrwxrwx   2 ftp      sys           48 Jun 27 13:52 .
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 ..
-rw-rw-rw-   1 root     sys         3468 Jun 27 13:52 profile
./shlib:
dr-xr-xr-x   2 root     sys           80 Jun 27 14:23 .
dr-xr-xr-x   7 ftp      sys          112 Jun 27 14:21 ..
-r-xr-xr-x   1 root     sys        50808 Jun 27 13:47 libc_s
-r-xr-xr-x   1 root     sys        39419 Jun 27 13:47 libnsl_s

I've gone thru the setup at least three times, now. Without 
hints that stu@mav.com posted back in February, I wouldn't
have gotten this far (TFM doesn't mention the dev and shlib
requirements.

No, I can't install 2.x or higher--it's not available for
MultiBus systems.

I'm open to any suggestions, and will greatly appreciate it.

Thanks,
Gary
-- 
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?".

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 20:40:24 GMT
From:      holley@eng.microcom.com (Bryan Holley)
To:        comp.protocols.tcp-ip
Subject:   OSPF Sources


Looking for a source to ftp the latest implementation of the OSPF application.  
Please respond via Email.

Bryan Holley
Director, Product Marketing

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 20:57:25 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: C code for NDIS driver


    ... tell me where I can find some source code for an NDIS driver.

I don't know of any.  The closest I know of is the NDIS-to-Packet-Driver
adapter module we put out as freeware last fall (look on vax.ftp.com in
pub/packet.driver/pubdom/ndis for the original ASM source).  Joe Doupnik
has improved it, his version is on 

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

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 91 23:17:07 GMT
From:      pwb@newt.phys.unsw.OZ.AU (Paul W. Brooks)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   charon is here...

Just a short note to say "thank you" to all the people who kindly told
me where to go (:-) to find the CHARON package. Most people pointed me
to omnigate.clarkson.edu, where both versions (3.1 and 2.0a) are
available by ftp.
Thanks to:	cintra4@u.washington.edu (Dave Lange)
		stubbs@uwslh.slh.wisc.edu 
		hughes@logos.ucs.indiana.edu (Larry Hughes)
		bkc@omnigate.clarkson.edu (Brad Clements)
			(and he should know!)

A special mention must go to blknowle@frodo.jdssc.dca.mil (Brad Knowles)
who shamed me by doing what I should have done in the first place, by
contacting his nearest archie server and sending me the output detailing
approx. 10 places where charon could be found. Now that archie server
sites are available there may be no excuse to wast net bandwidth with
"can someone tell me where is ....." messages again (except maybe
"where/what is the nearest archie server! ") :-)
	Cheers.
	
Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 00:08:15 GMT
From:      robert@netsoft.wimsey.bc.ca (Robert B. Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: STREAMS flow control in SunOS 4.1.1

In <THOMAS.91Jun27102100@mozart.nexus.se> thomas@nexus.se writes:

>When I've set up the connection I I_PUSH tirdwr (after I_POPing timod)
>to be able to use the ordinary read / write system calls. 

The problem is I_POPing timod, don't do it!  "tirdwr" translates the calls
between the stream head and "timod", if you pop "timod" then the streams driver
or mux which is next in the stream gets "timod" messages that it doesn't know
how to deal with.

>If I'm using sockets there wont be more than a few K bytes on the way
>before write blocks. Using STREAMS I find that write will 
>never block, I can cram 150K down the stream without blocking. The problem is
>that I seem to lose the last part of the data. Also data flowing from the 
>remote end is lost. Using a lanwatcher I can see that the last part of the
>data written is not transmitted and that the remote end actually sends data 
>that is never delivered to the process.

Flow control is handled within "timod" which you've removed.

>I would like the behaviour of the stream to match that of a socket. 
>What am I missing? Is there an option that can be used on the stream that
>would limit the amount of data that is on the way before blocking 
>or is it a bug in SunOS?


>--
>Real life:      Thomas Tornblom             Email:  t_tornblom@nexus.se
>Snail mail:     Communicator Nexus          Phone:  +46 18 171814
>                Box 857                     Fax:    +46 18 696516
>                S - 751 08 Uppsala, Sweden
-- 
Robert B. Nelson                               NetSoft Systems Inc
Phone: (604) 261-3652                          1102 West 48th Avenue
INTERNET: robert@netsoft.wimsey.bc.ca          Vancouver, BC, CANADA, V6M 2N5

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 02:05:30 GMT
From:      rpw3@rigden.wpd.sgi.com (Rob Warnock)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Re: XTP

In article <4369@uc.msc.umn.edu> johnc@uh.msc.edu (John D. Cavanaugh) writes:
+---------------
| Does anyone know where I can find a description of the XTP protocol?
| Email or FTP is preferred, but I'd be happy to find a reference to a paper.
+---------------

For a free copy of the XTP spec, send your surface-mail address to
"xtp-request@pei.com".


-Rob

-----
Rob Warnock, MS-1L/515		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 02:40:11 GMT
From:      mrc@milton.u.washington.edu (Mark Crispin)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

In article <2869DA1E.614E@intercon.com> kdb@intercon.com (Kurt Baumann) writes:
>In article <1991Jun26.040642.8535@milton.u.washington.edu>, 
>mrc@milton.u.washington.edu (Mark Crispin) writes:
>> A major new revision is in the works and will be released later this
>> summer.
>Who is working on this?

I am.  It's a major update from our April 1991 release (which is still
available on FTPHOST.CAC.WASHINGTON.EDU as imap/imap.tar.Z) and will
incorporate full support for the Borenstein/Freed internet message
bodies Internet Draft (the work of the IETF-822 group).  I've been
part of the development of the draft since its inception to be sure
that the corresponding functions can be incorporated into IMAP.

Once some of the dust settles there will also be an RFC describing the
extensions to IMAP2 to support Borenstein/Freed message bodies.

This new release will also include an IMAP-capable version of Pine,
our local (and very popular!)  Unix-based mail UA for novice users
written by one of my colleagues.  We've done some work in-house, but
none of us are PC experts and it's been slow going.  Various people
and organizations have expressed interest in assisting to port Pine to
the IBM PC, including at least one commercial organization.  There's
always room for more implementations though; to date I'm not aware of
any finished version.

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 05:56:55 GMT
From:      ELESKG@NUSVM.BITNET (Winston)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP FOR IBM MVS/XA MAINFRAME

We are trying to link a cluster of SUN workstations to an IBM MVS/XA
mainframe which contains the database required by the SUNs. All the
workstations and the IBM are connected via Ethernet, using TCP/IP.
Are there any good TCP/IP packages available for the IBM MVS/XA type
of environment? I would appreciate recommendations, suggestions, opinions,
pointers to info sources, etc, and will post a summary if there are
sufficient useful responses. Thank you very much.

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 06:15:42 GMT
From:      idj@mo.adl.dwr.csiro.au (Ian Jolly)
To:        comp.protocols.tcp-ip,comp.windows.x,aus.comms
Subject:   Source or executable code for tftpd

Does anyone know where I can find the source code for the Trivial File Transfer
Daemom (tftpd).  I wish to purchase an Xterminal for my HP9000/360 (running HPUX 6.5) and most seem to require tftpd for downloading of the server and/or fonts to the Xterminal.  Ideally, has anyone got an executable version running on HP9000/300 series computers?  Thanks for your help.


Ian Jolly
CSIRO Division of Water Resources
Adelaide, South Australia

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 06:22:06 GMT
From:      keith@ca.excelan.com (Keith Brown)
To:        bit.listserv.ibm-nets,bit.listserv.ibmcp-l,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans
Subject:   Re: Telnet from DOS - UNIX box via serial port &

The News Manager)
Nntp-Posting-Host: ca
Reply-To: keith@ca.excelan.com (Keith Brown)
Organization: Novell, Inc. San Jose, California
References: <1991Jun26.211509.8113@novell.com> <1991Jun27.162600.11139@cunixf.cc.columbia.edu>
Date: Thu, 27 Jun 1991 21:09:19 GMT

In article <1991Jun27.162600.11139@cunixf.cc.columbia.edu> puglia@cunixa.cc.columbia.edu (Paul Puglia) writes:
>
>Speaking of Desqview, or more specifically, Desqview/X. I have heard
>there has been some hint that Desqview/X will only work with FTPs
>stuff.

Absolute rot! I do wish I could get my hands on the people who put out these
lavatorial messages. It is in the interests of all application developers
who tie into any protocols stack, TCP/IP or otherwise, to try and support
as much of the installed base as possible. Even though we are the giant
of the network operating system business, most apps vendors choose to support
Banyan and LAN Manager aswell because they have no interest in doing our
marketing for us! We don't mind (much :-)). We do our own marketing.

The same now goes for the TCP/IP stack that's in the LAN WorkPlace for DOS.
The big red machine has it's weight well and truly behind LAN WorkPlace
and our installed base is huge and growing. We hold a developers conference
annually attended by over 1500 developers and this year the sessions on
socket and TLI programming using LAN WorkPlace and NetWare 3.11 were about
the best attended of any (with the possible exception of the NetWare vs LANman
session).

To answer your question though (stop ranting Brown :-)), Quarterdeck are
one of our developers and Desqview/X looks great. I had a demo of it
at NetWorld this year. I plan to run it on some of the LAN WorkPlace
machines that I use.

Keith


-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 09:04:18 GMT
From:      hwajin@sgi.com (Hwa-jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: STREAMS flow control in SunOS 4.1.1

>>>>> On 27 Jun 91 09:21:00 GMT, thomas@nexus.se said:

thomas> When I've set up the connection I I_PUSH tirdwr (after
thomas> I_POPing timod) to be able to use the ordinary read / write
thomas> system calls.  If I'm using sockets there wont be more than a
thomas> few K bytes on the way before write blocks.

it's not clear what's meant by "blocking" here but if you're refering
to a case where the call to write() blocks when socket level buffer
is full you can get around the problem by setsockopt()'ing with
larger number for socket level buffers.  the size available depend on the
upper limit for the amount of mbuf your kernel allowed for
such allocation. some systems have limit set to 64K even though the
default size of socket level buffer for a given protocol is set to
much smaller "a few" K bytes.

thomas> Using STREAMS I find that write will never block, I can cram
thomas> 150K down the stream without blocking. The problem is that I
thomas> seem to lose the last part of the data. Also data flowing from
thomas> the remote end is lost. Using a lanwatcher I can see that the
thomas> last part of the data written is not transmitted and that the
thomas> remote end actually sends data that is never delivered to the
thomas> process.

since the tirdwr simply calls tpi multiplexor in most implementations,
and hands over STREAMS msg to put routine of the tpimux, and tpimux
has its own write-put-service  routine, data loss at the STREAMS
msg queue between modules is probably unlikely.  sounds like a
protocol implementation strangeness... a few things to check:
1) how many bytes are not delivered, 2) anything still queued
at the socket on the sending side? (use netstat), 3) does write()
return successfully, 4) check tcp window sizes (sender might be
zero win probing) using your analyzer, 5) check # of bytes
not received on the receive side and the contents, 6) look at the
contents of last 20 or so tcp segments snooped via the net analyzer.

*hwajin
--
protocol engines, inc.

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 11:27:17 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Open Systems Security document

There was a posting about a week ago concerning an Open Systems Security
document available from an author in Finland.  To conserve bandwidth on
NORDUnet, I requested UUNET to retrieve this file and store it on this side
of the pond.  It is on ftp.uu.net as filename /doc/OpenSystemsSecurity.ps.Z .

----------------------------------------------------------------------
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	
----------------------------------------------------------------------

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 14:30:02 GMT
From:      gaw@SATURN.ACC.COM (Glen Warholic)
To:        comp.protocols.tcp-ip
Subject:   IP and IPX


In the beginning of the year a trade magazine carried an article 
about how to set up a PC to use the same network adapter to talk
IP and IPX.   It mentioned getting some files from BYU and a modified
IPX.COM file.  

I somehow lost the article and would like to get the information that 
it covered.  Would anyone have a copy of the article or know the
magazine and date when this article was published?  

If someone knows of this please send me a mailgram.  Any help is greatly
appreciated.

Thank you.

Glen Warholic
gaw@mercury.acc.com
ACC Systems
8320 Guilford Rd.
Columbia, MD. 21046

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 15:26:50 GMT
From:      dvaughan@DONIRM.NCTSW.NAVY.MIL (David Vaughan)
To:        comp.protocols.tcp-ip
Subject:   Conformant vs. compliant


In the world of protocol standards are these terms equivalent.  Or are they
different in the sense of conformance testing vs. functional testing.  Thanks
in advance.
				David Vaughan
				Dept of Navy

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 16:00:52 GMT
From:      ys11+@andrew.cmu.edu (Yael Shavit)
To:        comp.protocols.tcp-ip
Subject:   FDDI-TR bridge

Hi,

Have anyone  heard about the new FDDI products that DEC had announced
(Brouter, dual attached bridge, TR-FDDI bridge ...) ?

I am interesting in their Token-Ring to FDDI bridge. Do they preserve
source-routing, how do they relate to IBM token ring architecture ? etc.

I would appreciate any information.

Please response directly to my E-mail.

Thanks,
          Yael Zehavi-Shavit
          Information Networking Institute
          Carnegie Mellon University

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 17:03:13 GMT
From:      richardson@remacp.enet.dec.com ("John C. Richardson / Digital Equip. Corp / 508467-8720")
To:        comp.protocols.tcp-ip
Subject:   Questions around WELLFLEET Routers


	Hello All,

	I'm trying to size up some equipement and iron out some issues:

	Can anyone tell me if the Wellfleet Multi-Protocal Routers have
	any diagnostics (floppy or tftp) other than the ROM based power
	-up diags?  The machines in review are the LN-2000 (Link Node)
	and CN-3000 (Concentrator Node).  They (Wellfleet) offer hardware
	& maintenance support via Prime Computer, and neither will ellaborate..

	-Mean time between failures of either type (including the FN-1000,
	 Feeder Node).

	-The CN-3000 can have a secondary power supply installed as backup,
	 How reliable is it?

	-What do you _like_ , _dislike_ about the units?

	-Any "Un-documented Features" that pop up ?


		Public forum or personal Email accepted


	Thank you,

	John C. Richardson		Digital Equipement Corporation
	IN-DEC Customer Services	67 Forest Street  / IND-3
	Wide Area Network Services	Marlboro, Mass.  01752
					(508) 467-8720
					Richardson@REMACP.enet.dec.com
	

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 18:31:18 GMT
From:      mir@opera.chorus.fr (Adam Mirowski)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   DLPI definition

Could someone please tell me where I could find the definition of
the Data Link Provider Interface (DLPI)? It is the interface System
V uses between the network drivers and the rest of the protocol
stack, and it is based on LLC, 802.2, etc. but I am unable to
find any "official" definition of it, whereas I need it.

Many thanks!
-- 
Adam Mirowski,  mir@chorus.fr (FRANCE),  tel. +33 (1) 30-64-82-00 or 74
Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 18:48:46 GMT
From:      ktk@nas.nasa.gov (Katy T. Kislitzin)
To:        comp.protocols.tcp-ip
Subject:   Is source code for Comer vol II ftpable?

Hello.  I have not seen this question come across in the last few months, so
I will bravely pose it:

Does anyone know if the source code presented in "Internetworking
with TCP/IP, volume II", by Comer and Stevens, is available via ftp?  On page
xvi of the Preface, the authors state:

	To help, the publisher has agreed to make machine readable
	copies of all the code available so readers can use
	computer tools to examine, modify and test it.  We are
	interested in learning of imporvements, and will start an
	electronic mail list or newsgroup if appropriate.

If such a newsgroup has been started, mention of the name and address would
also be of interest.

Thanks,

--kt

--
Katy Kislitzin, ktk@nas.nasa.gov, ...!{ames, uunet}!nas.nasa.gov!ktk

[NASA/Ames is in Mt. View California.  I live in the Santa Cruz
Mountains with my cats Sid, Zippy, Nickel and Copper.]

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 19:23:37 GMT
From:      NIC@NIC.DDN.MIL (DDN Reference)
To:        comp.protocols.tcp-ip
Subject:   root server changes

The following is a list of current root servers, followed by a file
suitable for use as a "root.cache" file for BIND users.  Changes since the
last announcement are the temporary deletion of GUNTER-ADAM.AF.MIL, and the
addition of the first non-US server in Sweden, NIC.NORDU.NET.  NORDUnet
is the backbone network for the Nordic countries, connecting their academic
networks with the US Internet and the european IP networks.

   NS.NIC.DDN.MIL.	192.67.67.53
   NS.NASA.GOV.		128.102.16.10, 192.52.195.10
   A.ISI.EDU.		128.9.0.107,   26.3.0.103
   AOS.BRL.MIL.		192.5.25.82
   C.NYSER.NET.		192.33.4.12
   TERP.UMD.EDU.	128.8.10.90
   NIC.NORDU.NET.	192.36.148.17

--------------
;
;	@(#)root.cache	1.12	(Berkeley)	87/11/19
;
; Initial cache data for root domain servers.
;
.			99999999	IN	NS	NS.NIC.DDN.MIL.
			99999999	IN	NS	NS.NASA.GOV.
			99999999	IN	NS	TERP.UMD.EDU.
			99999999	IN	NS	A.ISI.EDU.
			99999999	IN	NS	AOS.BRL.MIL.
			99999999	IN	NS	C.NYSER.NET.
			99999999	IN	NS	NIC.NORDU.NET.
;
;  Prep the cache (hotwire the addresses).  Order does not matter.
;
NS.NIC.DDN.MIL.		99999999	IN	A	192.67.67.53
NS.NASA.GOV.		99999999	IN	A	128.102.16.10
NS.NASA.GOV.		99999999	IN	A	192.52.195.10
A.ISI.EDU.		99999999	IN	A	128.9.0.107
A.ISI.EDU.		99999999	IN	A	26.3.0.103
AOS.BRL.MIL.		99999999	IN	A	192.5.25.82
C.NYSER.NET.		99999999	IN	A	192.33.4.12
TERP.UMD.EDU.		99999999	IN	A	128.8.10.90
NIC.NORDU.NET.		99999999	IN	A	192.36.148.17
-------

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 19:34:05 GMT
From:      hwajin@sgi.com (Hwa-jin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: STREAMS flow control in SunOS 4.1.1

>>>>> On 28 Jun 91 00:08:15 GMT, robert@netsoft.wimsey.bc.ca (Robert B. Nelson) said:

Robert> The problem is I_POPing timod, don't do it!  "tirdwr"
Robert> translates the calls between the stream head and "timod", if
Robert> you pop "timod" then the streams driver or mux which is next
Robert> in the stream gets "timod" messages that it doesn't know how
Robert> to deal with.

on output side "tirdwr" simply hands over data to downstream (do putnext()),
unless the size is 0 (as documented in the manual), in which case it
discards it, while filtering out M_PROTO and M_PCPROTO msg's.

on input side "tirdwr" does various things with M_PROTO/M_PCPROTO msg's,
handling data, expedited data indication, orderly release, and disconnect
indication in the way described in the manaul.

there's really isn't any translation being done inside "tirdwr".
"timod" and "tirdwr" provide distinct services by handling disjoint
set of messages.  if you're not doing any further protocol
specific stuff and simply doing write()/read() on the end point,
it's shouldn't matter whether you have "timod" below tirdwr or not,
although i haven't personally tried to do it this way.  most people
just push "tirdwr" on a descriptor returned by t_open() directly,
which means on top of "timod".

Robert> Flow control is handled within "timod" which you've removed.

"timod" doesn't really do any flow control.  the place flow control
happens (in most implementations) is below or at tpimux level.  usually
by the protocols themselves if they're capable.




just my $.02.




*hwajin
--
protocol engines, inc.

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 19:47:52 GMT
From:      hwajin@sgi.com (Hwa-jin Bae)
To:        comp.protocols.tcp-ip
Subject:   STREAMS problem restatement


in my previous msg, i uttered the word "disjoint", which is not entirely
accurate.  more correctly, "timod" and "tirdwr" handle a common
set of msg types slightly differently, while handling other disjoint
set of msg types very differently.  in any case, sorry to add any
confusion to the questions.

*hwajin

--
protocol engines, inc.

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 19:56:28 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: Is source code for Comer vol II ftpable?


	There's a card in the back of the book that will allow you to order
the sources at a cost of $79.95 from Prentice Hall. You can also order directly
from Purdue (at higher cost) that, and various other versions of Xinu software.
Below are instructions for that.
	The software is not public domain, however, and at this time, there
are no plans for making it available via anonymous FTP.

Books and listed software are available from Prentice Hall, College Marketing 
Department, Englewood Cliffs, NJ  07632 .   Phone Mail Order Dept.
(201) 767-5937

                  Xinu Types and Price List
		----------------------------

Target  Xinu      Host Compiler  Media        Price   Make Check
Machine Version   Operating                          Payable to 
                   System
- -------------------------------------------------------------------
 LSI (@) 6 (Book I)Cross Compiler 1600 BPI    $100    Douglas Comer
                   Included       9-Track UNIX
                   4.3BSD UNIX    Tar Tape  
	
 LSI (@) 7(Book II)Cross Compiler 1600 BPI    $200   Douglas Comer
                   Included       9-Track UNIX
                   4.3BSD UNIX    Tar Tape
_____________________________________________________________________

 8086 (%)6 (Book I) Cross Compiler 1600 BPI    $100   Douglas Comer
            Derived Included       9-Track UNIX
            from    4.3BSD UNIX    Tar Tape
            LSI-11
______________________________________________________________________

 Sun3 (%)6 (Book I) Sun Micro-     1600 BPI     $100  Shawn Ostermann
                    Systems C      9-Track UNIX
                    Sun OS         Tar Tape

 Sun3 (%)7 (Book II)Sun Micro-     1600 BPI      $200 Shawn Ostermann
                    Systems C      9-Track UNIX
                    Sun OS         Tar Tape
______________________________________________________________________
 Sun3 (%)8.0 VM Xinu Sun Micro-     1600 BPI      $200 Jim Griffioen
                    Systems C      9-Track UNIX
                    Sun OS         Tar Tape, or
                                   1/4 inch cartridge
________________________________________________________________________

 Sun3 (@%)7.9-TCP  Xinu Sun Micro- 1600 BPI      $200  David L Stevens
                    Systems C    9-Track UNIX
                    Sun OS       Tar Tape, or
                                 1/4 inch cartridge
__________________________________________________________________________
 IBM-PC  6 PC-Xinu  Microsoft C    5 1/4 floppy ~ $80 Contact Prentice 
           (Book I)  MS/DOS                                  Hall
                                                  ISBN #0-13-638271-1

 IBM-PC (%)6 (Book I) Aztec C      5 1/4 floppy   $100 Andy Thomas


 IBM-PC	7 (Book II)  Microsoft C   5 1/4 floppy(5)$150 Contact T. Fossum
	              MS/DOS	


For ordering information on version 7 software for the PC, Please contact:
Prof. Timothy Fossum
Department of Applied Computer Science
University of Wisconsin-Parkside
Kenosha, WI  53141
(414) 553-2314
(414) 553-2297 office
FAX:  414-553-2630
fossum@vacs.uwp.wisc.edu

______________________________________________________________________

 Macint (%)6 (Book I) Aztec C   two 3 1/2 floppy  $200 Douglas Comer 
 tosh         &       Macintosh  &
 512K      7 (Book II)          1600BPI
                                9-Track UNIX
                                Tar Tape

 Macint (%)6 (Book I) Aztec C   two 3 1/2 floppy ~ $80 Contact Prentice 
 tosh                 Macintosh                             Hall                   
 512K                                              ISBN #0-13-638545-1

_________________________________________________________________________

 VAX         6 (Book I ) VAX UNIX C   1600 BPI     $200 Douglas Comer
                &        Compiler     9-Track UNIX
             7 (Book II) 4.3BSD UNIX  Tar Tape        
_________________________________________________________________________

 VAX (*%)     ConcurrenC VAX UNIX    1600 BPI       $50  Ken Rodemann
                        Compiler    9-Track UNIX
                        4.3BSD UNIX Tar Tape 
_________________________________________________________________________



     (@) Less expensive if purchased from Prentice-Hall.
     For Prentice Hall, contact Rob Dewey,  (201)  592-2862;
     or Mail Order dept.  (201) 767-5937.

     (%) Prepared by students.  These versions are "as is".

     (*) Requires UNIX source license.  Send a mailing  tape.
     4.2 BSD UNIX available.


     If you have a UNIX source license, please send  a  copy
     of the signature page; otherwise, we will send you dis-
     tributions without UNIX source.

     Send your order and check to: Professor Douglas  Comer,
     Department  of  Computer  Sciences,  Purdue University,
     West Lafayette, IN  47907.

Information about Xinu is exchanged through  electronic  mail.   To
have  your  name  added  to  the  mailing list, send to  
xinu-info- request@purdue.edu. To send mail to the Xinu list,  
address it to xinu-info@purdue.edu.

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 20:42:50 GMT
From:      zdmb05@hou.amoco.com (David M. Burns)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   Satellite FTP Problems


I have a question about possible TCP/IP throughput rates that can be
expected through a satellite link.  This problem has plagued us for
awhile and we currently think we are running up against a possible
protocol limitation.

The problem: slow FTP transfer rates between two ethernet LANs connected
via a T1 satellite link.  "Slow" means on the order of 30-35 Kbytes/sec
(though rates as high as 100 KB/s are observed when the connection
first starts.)  These are "large" datasets, 100Mbytes or better.

The serial connection for the satellite has ciscos at each end.  Much
effort has been expended verifying cisco settings, satellite tuning,
etc.  The hosts involved are primarily SS-2s, though we have also tested
tp other systems.  People have tried adjusting buffer, window sizes
and implementing the algorithms proposed in RFCs 1072 and 1185.  Nothing
seems to work.

Tests have also been done using the ttcp program (to eliminate the
INETD overhead, etc.)  Even with ttcp, response across the link is
abysmal.

My particular group has been on the periphery of this, so some of the
above is hearsay. (I can vouch for the intensive effort lots of people
have given it, though...but we are still relatively new to tcp/ip and
this one seems to have us stumped.)

I can understand that when going ethernet -> T1, the router will probably
become flooded and have to toss packets.  Does anyone have a suggestion
for minimizing this ?  Where should we double-check, to be sure we
haven't overlooked anything ?  We don't expect 160 KB/s, but would sure
like to improve our current situation.

Any and all suggestions are welcome. Please reply via email, and I'll
post a summary if warranted.

Thanks in advance,

David Burns
dmburns@hou.amoco.com
-- 
David Burns	 reply to: dmburns@hou.amoco.com
Amoco Corp. ISD  SSS/Mini-Micro Systems
Houston, Tx.     713/556-7013

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 22:07:40 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip
Subject:   Traceroute done differently?

Is there a traceroute like utility written for unix that uses the
record route option and or the strict source route option? When I got
traceroute today I was suprised to find that it doesn't use these ip
options.

	-John Kalucki
	johnk@gordian.com

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 22:47:03 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Where Can I Get The IMAP Specification?

Wis IMAP? Please post.
Thanks-

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 91 23:28:32 GMT
From:      ejb