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 April 1991 (422 messages, 243620 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/04.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 Apr 91 08:42:30 GMT
From:      tom@wcc.oz.au (Tom Evans)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Subnetted TCP addresses and Webster MultiGates

In article <1991Mar26.192901.1670@cns.umist.ac.uk>, jf@ap.co.umist.ac.uk (John Forrest) writes:
> We have ordered a Webster Multiport Gateway and are about to
> put in a Localtalk network for our Macs. In preperation we have
> put up CAP (to ensure it compiled on our Apollo's) and a few
> other things. We've got hold of atalkad, and have compiled that
> too. I am a bit concerned, though, about the issue of TCP
> subnets in the configuration. The program obviously supports
> them, but only refers to the use of whole number subnets.

CAP maps "whole number" Class C subnets to IPTalk (AppleTalk) networks.
Thus all CAP hosts that are on a Class C Subnet are deemed to be on
the same AppleTalk network. Whether or not you are subnetted as you
describe (subnetmask ffffffe0).

It should work OK, as long as the routers handle the "full subnet"
broadcast IP address properly (192.84.82.255). If this doesn't work
properly you may need to run atalkrd. Possibly not though. If the
MultiGate and the CAP host are on the same subnet it should be simple.

> Essentially we plan to use two of the Multigates four Localtalk
> ports for standard use (one is to be dedicated to a laser, and
> the other kept spare for the moment). I was hoping to use two
> of the subnets for these

Completely separate subject. Setting up MacIP (protocol that supports
MacTCP and NCSA Telnet etc.) is a completely separate issue to CAP.
They aren't really related. I'll send you mail on this.

> As far
> as I can tell, MacTCP is happy with subnets - it definitely
> allows you to set them up.

But what it actually does with subnets is a mystery. It probably only
uses this information when it is directly on Ethernet. Going through
MacIP is another matter - the "routing decisions" are different.

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

wcc@cup.portal.com
2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA
1-408-954-8054  FAX 1-408-954-1832

wcc-uk@cup.portal.com
Unit 7, Weltech Centre Ridgeway, Welwyn Garden City Hertfordshire AL7 2AA
LONDON UK. Ph  44-707-336969  Mobile 44-836-725849  FAX 44-707-373378

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 16:13:27 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over Frame Relay Network

> I am not really sure where to ask this question but here goes...
> Is anyone working on or has thoughts concerning running IP over a
> Frame Relay network?  What I had hoped to see (but didn't) was an RFC
> to the tune of "Standard for the transmission of IP datagrams over
> Frame Relay networks".

Carl,

This is actively in progress in the "IP over Large Public Data
Networks" working group of the IETF.  A new (hopefully close to
final) draft of the specification will soon be released, based
upon discussion at the St. Louis working group meeting.  To join
the discussion, send a subscription request to
iplpdn-request@nri.reston.va.us .

Regards,
Andy

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 18:38:54 GMT
From:      bill@polygen.uucp (Bill Poitras)
To:        news.software.nntp,comp.binaries.ibm.pc.d,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   NNTP news readers for MS-DOS (QUERY)

I have seen a lot of talk about news readers for MS-DOS.  Could someone
send me what they know about the various news readers.  Things I want to
know are:
	- What communications does it need? (pc-nfs,packet tcpip,none)
	- How good is it?  How much like RN does it work like?
	- How configurable is it?

If I get enough responce, I will post a summary to 
comp.protocols.tcp-ip.ibmpc.  Mail is preferable.  Thanks in advance.

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 | FAX (617)890-8694         | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 19:07:14 GMT
From:      carlson@mrx.webo.dg.com (James Carlson)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Reliability between processes on same host

Sure ... they can end up out of order -- UDP doesn't guarantee delivery, and packets
may arrive out of order or duplicated.  (Of course, this shouldn't happen on the *same*
host, but .... !)

May I ask why you're not just using IPCs, since that's what it sounds like you need?
UDP is usually used for self-contained data (like in XDMCP) and as the basis for a
more complex protocol (like TFTP).
-- 
Disclaimer:  My company neither knows nor cares what I say.
.//.

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 19:15:39 GMT
From:      rick@wucs1.wustl.edu (Rick Bubenik)
To:        comp.protocols.tcp-ip
Subject:   Public domain, user level TCP/IP

Does anyone know of a public domain implementation of TCP/IP that runs
as user level code under Unix (ideally implemented in C or C++)?  I'm
going to be porting TCP/IP to run over a new network and want to do some
experimentation outside of the kernel.

	rick

  ++++++

	Rick Bubenik	 		rick@cs.wustl.edu
	Research Associate
	Department of Computer Science
	Washington University
	Campus Box 1045
	One Brookings Drive
	St. Louis, Missouri 63130-4899
	(314) 726-7530

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 20:30:07 GMT
From:      enag@ifi.uio.no (Erik Naggum)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Reliability between processes on same host

In article <1991Mar28.220615.5501@newbridge.com> todds@newbridge.com (Todd Sandor) writes:

   Please don't flame me, I know UDP is unreliable, but I have a
   question concerning using UDP between processes on the same host.

My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).

The problem with assuming that you talk to the same host is that one
day, you don't.  The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host.  Sure,
it's more code, and you need to check that you got the right packet
and so on.  As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case".  It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.

       - socket overflows or
       - bad data length fields or
       - bad checksums

I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating.  Your code
should work, regardless.

   but could we experience out of order packets or duplicate packets.

You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do.  For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence.  Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called.  (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)

I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback.  Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.

Hope this helps.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 20:30:24 GMT
From:      enag@IFI.UIO.NO (Erik Naggum, the Internet Purist)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Reliability between processes on same host

In message <1991Mar28.220615.5501@newbridge.com>, Todd Sandor writes:

   ... I have a question concerning using UDP between processes on the
   same host.

My experience is that UDP is reliable on the same host, and especially
so if you use the loopback (127.0.0.1 on some systems).

The problem with assuming that you talk to the same host is that one
day, you don't.  The extra cost of sequence numbers, timeouts and
retransmits (which need only be trivial -- otherwise I would suggest
TCP), won't be incurred as long as you talk to your own host.  Sure,
it's more code, and you need to check that you got the right packet
and so on.  As message sequence integrity is one of your concerns, I
suggest that you use sequence numbers "just in case".  It _could_ be
that the network code implementation on your system uses a LIFO type
buffer for outstanding packets, and that you will find out only under
heavy load, as you allude to.

       - socket overflows or
       - bad data length fields or
       - bad checksums

I have a hard time thinking up conditions under which you'd get more
than the first problem on a local host, but as I said, you could
suddenly find yourself having two hosts communicating.  Your code
should work, regardless.

   but could we experience out of order packets or duplicate packets.

You should make sufficient safety nets to allow for these conditions.
Sequence numbers will do.  For instance, you could provide a minimal
layer which, when expecting n packets, read packets and requested
retransmits until it got all of them, then delivered them back to the
caller in sequence.  Or you could make this layer buffer up packets
arriving out of sequence and deliver the "next" (expected) packet when
called.  (This will require negotiation of initial packet numbers
between the communicating processes, and dynamic memory handling, both
of which may become costly.)

I can't speak on the relative speed of using (one of) the address(es)
of the host or using the loopback.  Intuitively, one would expect a
slightly higher throughput with the loopback, using your reasoning.
All I can say is I'm pretty certain that no implementation is slower
for the loopback than one of its other addresses.

Hope this helps.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Apr 91 22:55:11 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Reliability between processes on same host


    ...but could we experience out of order packets or duplicate packets?

Taking an unsophisticated view, one wouldn't expect out of order or duplicate
packets unless IP routers and long-haul paths were involved.  However,
consider what happens if a packet is lost due to hardware error on your
local cable (this WILL happen - believe me):  You have to have some sort of
mechanism for detecting that it was lost and retransmitting it.  If the
product of the probability of packet loss times the number of packets
outstanding (unacknowleged) at any given time gets high enough, your receiver
will see both out of order and duplication.  Better to use TCP, IMHO.

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

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 16:28:22 GMT
From:      frankh@durin.laguna.sparta.com (Frank Halsema)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   10BaseT installation

I have read a lot about 10BaseT and I am considering using it in a new
facility. Everything I see has the twisted pair connector as a RJ45 but
inplications are that twited pair uses two pair or four wires. My
question is how many pair do I need and if it is two pair why does
10BaseT use an RJ45 connector. 


Frank Halsema                           UUCP: durin!frankh             
SPARTA, Inc.                   		Internet: frankh@laguna.sparta.com
23041 de la Carlota, Suite 400
Laguna Hills Ca, 92653     (714) 768-8161 EXT 339  (714)583-9114 FAX

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Apr 91 17:22:23 GMT
From:      yjy@stlucia.uucp (Joe Yung)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Datakit Interface Through TCP/IP

NOTE: Followup to comp.sys.att

I have a SPARC station 2 and a Datakit with a bunch of TTY modules.
I am trying to have the SPARC connected to the Datakit so I can use
my SPARC to access various TTY line off the Datakit.
Does anybody know how ?

I heard that AT&T Datakit has a connection to TCP/IP directly.
We have a bunch of SPARCs on the Ethernet.  It will be a
a versatile way to open up the Datakit available to all the SPARCs.
Does anybody know anything about this connectivity.



Joe Yung
yjy@stlucia.bellcore.com
(908)699-5344

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 19:07:49 GMT
From:      ramsey@NPIRS.Purdue.EDU (Ed Ramsey)
To:        comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Has anyone updated pcnfsd to use passwd.adjunct?

Has anyone upgraded the pcnfsd program to work with sunos 4.1.1 C2
passwd.adjunct files? If so, could I have a copy?

Thanks!

-Ed

-- 
Ed Ramsey ramsey@npirs.purdue.edu 317/494-6616 FAX/494-0535
currently: "User Services Manager" soon to be: "Network Services Manager"

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Apr 91 19:10:23 GMT
From:      hughes@bronze.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,vmsnet.mail
Subject:   VMS POP3 server

IUPOP3, a VMS POP3 (Post Office Protocol Version 3) server, is now
available via anonymous ftp from mythos.ucs.indiana.edu (129.79.16.210)
in the /pub/iupop3 directory.  It was developed here at Indiana 
University in recent months.

IUPOP3 is a static, multithreaded server that can process up to 31
simulataneous POP3 client connections.  This does not mean that it
can serve only 31 clients; here at IU it serves dozens.

It was developed on VMS 5.3 and 5.4 systems, and currently requires
the Wollongong WIN/TCP for VMS product.  (It uses their $QIO
interface extensively).   We have not yet attempted to port the code 
to other TCP/IP products for VMS, although we will likely do so for 
UCX in the future.

We've tested IUPOP3 thoroughly with two POP3 clients:  Eudora for
the Macintosh, and FTP Software's POP3 for DOS.  It will probably
work well with others.

 //=========================================================================\\
||       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...    ||
 \\==========================================================================//

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 20:45:26 GMT
From:      van@EE.LBL.GOV (Van Jacobson)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET slow through bridge.

> One difficult tradeoff when deciding which packet to drop is
> which end of the TCP window to start from.  Most VJ TCPs seem to
> react badly when you drop the more recent packets first, so
> since v2.04 we drop the older ones.

James,

Could you elaborate on this a bit?  If something's broken, I'd
like to fix it.

 - Van

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 21:19:31 GMT
From:      vances@xenitec.on.ca (Vance Shipley)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital phones for SLIP circuits

In article <8204@suned1.Nswses.Navy.MIL> efb@suned1.Nswses.Navy.MIL (Everett F Batey II) writes:
>Confronted with an urgent need to run SLIP between two Sun3s (OS 4.1 and
>4.1.1) and some easy to comeby telephone assets AND NO money for modems,
>we are trying to pick the most trustworthy and easy to accomplish SLIP
>link.  Sites are within 3 miles, wire, 1/2 mile crow flight.
>
>- We have Meridian phones for which we can get 9600 baud RS-232 interfaces.
>DOES ANYBODY know if with handshaking and async over digitized phone line,
>these data phone options WORK SUCCESSFULLY for this purpose ?

I have Northern Telecom Meridian 1 telephones also.  I also have the data 
units equipped in EVERY telephone!  They work quite well.  We use them for
modem pooling, we have two T1000's and a pair of UDS 9600 baud modems that 
every one in house has access to.  I plan to use these for slip soon when I
get TCP/IP for DOS that supports slip.  I do use them for UUCP through the 
modem pools.  These beasts actually run up to 19.2K asynch.  Units that run
up to 64K sysnchronous are available.  If you have digital TIE lines between
your sites you should have no problem doing this up to 56K.

Vance Shipley
vances@ltg
..uunet!watmath!xenitec!ltg!vances

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 22:12:25 GMT
From:      rwolski@lll-crg.llnl.gov (Richard Wolski)
To:        comp.protocols.tcp-ip
Subject:   Bootp questions (a possible reposting)

Profuse apologies to those of you who have seen this before.  I am 
posting this request for a friend with a somewhat unreliable news feed.

Thanks for your patience,

Rich

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

Sorry if you have seen this before, but my news feed
has been flakey lately and I haven't seen it
posted.


Hi.

I have some questions about bootp that someone out
there might be able to answer.

Is the bootp 2.1 (cmu) the must current version?
What other versions are there out there
(and where can I get them)?

Is bootp the most widely used protocol
to boot up network devices? Are there others?

Has anyone run up against the 64 byte limitation
of vendor specific data? If so, what did you
do you about it?

What is the method for specifying a vendor
magic cookie (do you have to modify
the boop server source?).

Thanks any information will be appreciated!
If I get responses, I will post the replies.

Emily Hipp
ehipp@wrs.com
 

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Apr 91 22:27:23 GMT
From:      CCMARKM@UMCVMB.MISSOURI.EDU (Mark Moody)
To:        comp.protocols.tcp-ip
Subject:   Weird Iron

Greetings,

I work in the NOC for MOREnet a new network and some of our members are
bringing up TCP/IP implementations on ... some less common systems.
I am looking for people who have worked with TCP/IP on systems like these
and who would be willing to anwser some questions as they (will) arise down
the road here.  The systems in question are: an IBM AS/400 Model B55,
a HP 3000 Series 58 running MPE-V operating system, and a Unisys mainframe
(once a Burroughs) 'A' series A6KX.  I personnaly don't have any experience
with these but I would like to find *some* help for them.  If you can offer
any assistance, please let me know.  Many thanks,

Mark Moody
MOREnet - MissOuri Research and Educational network
University of Missouri - Columbia
CCMARKM@umcvmb.missouri.edu  (preffered)
mark@noc.missouri.edu        (alternate)

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 01:13:01 GMT
From:      rc@mit-caf.MIT.EDU (Ran-Chi Huang)
To:        comp.protocols.tcp-ip
Subject:   Determination of Statistics on a Subnet

I have an application that needs to determine the following :

	Average Utilization
	Average Packet Rates
	Peak Packet Rates

Can any netters give me some ideas as to how I can approach the
problem. I already have an application that processes packets
on a per-packet basis.

The aim is to put all this in a C program which will generate
the results I need.

Please mail responses to me at "rc@caf.mit.edu" because I do
not read this list often.

Thanks for any pointers.

rc@caf.mit.edu

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 02:43:42 GMT
From:      tridge@anu.oz.au (Andrew Tridgell)
To:        comp.windows.ms,comp.protocols.tcp-ip
Subject:   Re: WinQVT/Net and 3C503 DMA support

If the reason you want non-shared memory support is to run in
conjunction with SUN's PC-NFS then I suggest you use the pktd.sys driver
to make PC-NFS work in shared memory mode. I have done this and have
successfull combined PC-NFS, windows and NCSA Telnet, all using packet
drivers and shared memory.

You can get the "compatibility kit" from falstaff.cwru.edu in
/pub/compat.kit it is called compat.zip and includes source. If you have
troubles setting it up you can send me mail

---
Andrew Tridgell
tridge@aerodec.anu.edu.au

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 04:05:00 GMT
From:      HARISH@ITIVAX.BITNET
To:        comp.protocols.tcp-ip
Subject:   Question on FTP's MAC/NDIS driver + WinQVTNet

Folks,

I have machines that run 3Com's 3+Open (LAN Manager) and have been trying
without too much success to use FTP Software's MAC/NDIS to Packet Driver
translator to provide a PktDrvr interface to the MS Windows app WinQVT/Net.

WinQVT/Net works just fine when I load up the normal packet drivers and
the PKTINT (provided by WinQVT/Net).  However, I am then not able to get
to my servers.  Any suggestions?

Please respond by e-mail.  I'll summarize.  Thanks.

--
Harish Pillay                              harish@itivax.bitnet
Senior Software Engineer                   harish@ece.orst.edu
CSA Research Pte Ltd                       harish%temasek.uucp@cs.orst.edu
12 Science Park Dr #03-01
Singapore 0511
+65-772-0393 (w), +65-278-4191 (h)

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 12:15:21 MST
From:      haas%basset.utah.edu@cs.utah.edu (Walt Haas)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

In article <1991Apr3.153750.19033@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes:
>
>If anyone is interested, I can write a longer posting on the ins and outs
>of 10baseT, and the experiences I and my co-workers have had with it.

I'd be interested.  We have started to do 10BASE-T for offices where there
is little chance that a second computer will be added.  Thinnet still wins
for student bullpens and labs with lots of machines in one room.  The cost
to us is about $300 + wiring per computer for 10BASE-T.  Thinnet cost is
a little more than half that.  The big win with 10BASE-T is the situation
where a computer locked in somebody's office goes nuts and starts to hose
the network, or where somebody unplugs their cable.  With 10BASE-T we don't
have to check every office, we just check the hub, and wiring faults are
dealt with automatically.

In engineering offices where there are likely to be additional computers we
still like the hub idea, but set up a multiport thinnet repeater and assign
a port to an office.  This gives us the same automatic recovery from wiring
faults, at a slightly greater cost per office than 10BASE-T, with the
chance to inexpensively add up to 14 more computers per office.

-- Walt Haas     haas@ski.utah.edu


-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 08:11:08 GMT
From:      woody@ucscb.UCSC.EDU (Bill Woodcock)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation


         > I have read a lot about 10BaseT and I am
         > considering using it in a new facility.
         > Everything I see has the twisted pair connector
         > as a RJ45 but inplications are that twisted pair
         > uses two pair or four wires. My question is how
         > many pair do I need and if it is two pair why
         > does 10BaseT use an RJ45 connector.
     
     10BASE-T does indeed use four conductors.  On an RJ-45  modular  jack,
     pin  1  is Rx+, pin 2 is Rx-, pin 3 is Tx+, and pin 6 is Tx-. When you
     go to your wiring closet, they are normally punched down in that order
     as  well, pin 1 to row 1, pin 2 to row 2, pin 3 to row 3, and pin 6 to
     row 4.
     
     As to why 10BASE-T uses an RJ-45, I know of a couple of reasons, but I
     don't know that any of them are "official."  First and most important,
     it's to keep people from plugging their phones into  data  jacks,  and
     vice  versa. Secondly, it's to allow for people in the future plugging
     their phones into data jacks, but making it work.   You'll  find  that
     ISDN normally uses pins 4, 5, 7, and 8.
                              
                             -Bill Woodcock
                              BMUG NetAdmin

_______________________________________________________________________________
     
0000 : 0600 0800 7700 FE00 FF 0 FF8  7F 0 3 00 48              bill.woodcock.iv
0010 : CC00 7C00 0C00 1000 2800 440  8200  40 
0020 : C000 4000 8000 C000 C 00  800  80  48 0 9           woody@ucscb.ucsc.edu
0030 : FF00 F000 7F80 CC00 CC 0 7 80 7 80 CC    6
0040 : CC00 7F80 9800 7800 CC00 CC0  CC 0 C 00                 2355.virginia.st
0050 : CC00 CC00 FC00 CC00 CC 0 2000 10 0 7 00 C 0
0060 : CC00 CC00 CCC0 4800 2 00 1 00 2 00 48 0 9            berkeley.california
0070 : 4800 2400 1200 1000 2800 4 00 8 00  E0 
0080 : 3000 6000 F000 6000  000 60 0 600  C0 0 01C                   94709.1315
     
_______________________________________________________________________________

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 12:29:16 GMT
From:      kevin@exocet.mentec.ie
To:        comp.protocols.tcp-ip
Subject:   Honeywell Bull DPS700 ---> Ethernet (TCP/IP) ???

Hi Netlanders,

A sister company has a Honeywell BULL DPS7000 system which needs a connection 
to an Ethernet lan. Does anyone know if there is a TCP/IP package available
for a such a beast. As far as I can gather the  system is running an operating
system known as GCOS7. Also, any pointers on ethernet cards for the same would
be very helpful. I realise that being an  old system such hardware/software
may not be available.

Any help/comments greatly appreciated.

thanks,
Kevin.

-------------------------------------------------------------------------------
Kevin O'Farrell          | Internet/EUnet:    Kevin@mentec.ie
Technical Services Group.|                    Kevin@mentec.uucp
Mentec Computer Systems. | PSI-Mail:          PSI%272436059082::Kevin
Pottery Road,Dun Laoire, | MCI-Mail:          KOFARRELL / 390-4994
Co Dublin. Ireland       | Voice:             +353-1-858444
-------------------------------------------------------------------------------

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 14:37:37 GMT
From:      teb@SATURN.ACC.COM (Tom Benkart)
To:        comp.protocols.tcp-ip
Subject:   Message compression

In applications involving file transfers (FTP) over low speed lines,
has anyone investigated any type of data compression on a message
by message basis?  I'm familiar with the header compression
algorithms, but don't know of any data compression algorithms.
The pay-off might not be very high, but any compression could
be useful.

Tom Benkart
ACC

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 15:37:50 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

In article <5438@durin.sparta.COM> frankh@durin.laguna.sparta.com (Frank Halsema) writes:
>I have read a lot about 10BaseT and I am considering using it in a new
>facility. Everything I see has the twisted pair connector as a RJ45 but
>inplications are that twited pair uses two pair or four wires. My
>question is how many pair do I need and if it is two pair why does
>10BaseT use an RJ45 connector. 
>
>
>Frank Halsema                           UUCP: durin!frankh             
>SPARTA, Inc.                   		Internet: frankh@laguna.sparta.com
>23041 de la Carlota, Suite 400
>Laguna Hills Ca, 92653     (714) 768-8161 EXT 339  (714)583-9114 FAX

10baseT tends to be used in the same "wiring closets" (IDF's) as telephone
equipment, as well as the same wall plates, so I would guess the use of
RJ45 is an attempt to make use of existing telephone wiring, without
getting it confused with RJ11.

RJ11 won't work with 10baseT jacks or transceivers, since the pairs are
1-2, and 3-6, with the lines as T+, T-, R+, and R-, respectively. Six wire
RJ45 doesn't work, since you need pin 1 on the 8 wire RJ45. Pin 1 on the
six conductor version connects to pin 2 of the 8 wire outlet. You have to
use an 8 conductor RJ45 to plug into the 10baseT outlets and transceivers.
Which plugs, punchdowns, wires, and connections you use in between the ends
is your business, as long as the connections are fairly secure from EMI
ingress, and the wire has at least 3 twists per foot, preferably more. You
must maintain the pairs, and the polarity, obviously. Some transceivers
will detect backward polarity, and reverse themselves to compensate.
Regular "silver ribbon" telephone wire that they use to make desk-to-wall
cords will cause collisions on a 10baseT connection.

If anyone is interested, I can write a longer posting on the ins and outs
of 10baseT, and the experiences I and my co-workers have had with it.
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.	
Minneapolis, MN 55416-1528	So much System,
(612) 525-0000			so little CPU time...

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 15:37:55 GMT
From:      lan_csse@netrix.nac.dec.com (CSSE LAN Test Account)
To:        comp.protocols.tcp-ip,news.admin,comp.mail.misc
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

In article <1991Feb25.185436.11447@watserv1.waterloo.edu> broehl@watserv1.waterloo.edu (Bernie Roehl) writes:
>In article <39557@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>>Can someone please explain the difference between X.400 and Internet-style
>>names of the form: USER@SITE.DOMAIN?  I had thought that X.400 names
>>were of the form /THIS=,/THAT=,/ANDWHATEVER=.
>
>They are.  The standard syntax "user@site.domain" is used throughout the
>Internet (and beyond!).  The "/this=,that=" is unique to X.400, which is
>part of the OSI spec.

In any case, part of the confusion is the assumption that a standard's
address format must be what is presented to the user.  This isn't true.
It's quite legal for a single system to have, say, an X.400 mailer, an
SMTP (internet) mailer, and a UUCP mailer installed.  The usual result
would be that the poor users have to figure out for themselves which of
the mailers talks to a given machine, and use the correct syntax for that
mailer.  Sendmail typically comes configured to require this.  But this
is extremely user-hostile, and there is no real excuse for it.

It is quite legal, and not hard to program, to have the user interface
accept addresses in multiple formats, parse them, figure out which of
the mailers can handle a job, and convert the address to that mailer's
format.  This is, for example, what the smail package does.  Sendmail
also has the capability (if you can figure out how to change sendmail.cf
to do it right ;-), and some vendors even supply sendmail configured to
do this.

Forcing the user to figure out bizarre mail syntaxes is inexcusable in
these days of mass email confusion.  That's what we have computers for.
If your mail interface can't do the translation, you should harass your 
vendor until they get it right.

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Apr 91 20:15:25 GMT
From:      albers@ka3ovk (Jon Albers)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Anyone gotta netblazer


We just got 2 Netblazers (2 serial, 2 ethernet cards, 1 T2500) to evaluate
here.  We have 2 networks to link via the T2500 and phone line:

The ssi network consists of:

100.30.0.1	ssi	<-- The netblazer at ssi.
100.30.0.5	irs5	<-- Unix mini
100.30.0.6	irs6	<-- Unix mini
100.30.0.8	irs8	<-- Unix mini
100.30.0.10	ka3ovk	<-- SCO Unix micro
100.30.0.11	w3wox	<-- SCO Unix micro

The bxr network consists of:

89.0.0.1	sys95	<-- Unix mini
89.0.0.2	sys85	<-- Unix mini
89.0.0.3	bxr	<-- The netblazer at bxr.

Now, the netblazers at both networks are set up and working as terminal
servers.  I can log in and telnet from the netblazer to any other host
on the LOCAL network, and any other host on the LOCAL network can telnet
to the LOCAL netblazer.  Convincing the netblazer to connect the 2
networks together has been difficlut.  I think we have followed the
directions in the manual OK, but any attempt to cannect to a host on the
89.x.x.x net from the ssi netblazer still causes it to look out the 
LOCAL ethernet and vice versa.  When I log into the netblazer, and do
a 'session dial bxr', it complains that 'no dialout lines are available',
although the dialup is defined properly as far as Ican tell.  

Has anyone set up a netblazer yet!?! 

I have several calls into our local Telebit office, but I have not gotten a
call back in 2 days of trying..

							Jon


-- 
| Jon Albers, IRS, Information Systems Management, Support and Installation.  |
| Office Symbols: ISM:S:S:SI   voice: (202/FTS)535-3729  Packet: KA3OVK@N4QQ  |
| UUCP:(media|teemc|tcsc3b2|ki4pv)!ka3ovk!albers ARPA: JALBERS@SIMTEL20       |

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Apr 91 21:34:18 GMT
From:      chlebosc@nadia.stgt.sub.org (Claudius Chlebosch)
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Problems with IBMs TCP/IP V1.1 for OS/2

I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i
hope to get some help on this way.

I have to write a program, which transfers data using stream sockets in portions
of 32 kByte. The sender should send this portions with one call to the send()
function and the receiver should get this portions with one call to the recv()
function.
This works very well, if the size of the transmitted segments does not exceed about
6000 bytes and only one segment is transferred using the same socket. In the
other case the receiving program has to call the function recv() several times
to get the complete segment. Normally the recv() function should block the process,
until the whole segment is reveived.
For example: the client calls send() with the msgLen set to 20000. The server
calls the recv() function, which blocks the process, until the whole 20000 bytes
are received. The client calls send() once again with the msgLen set to 20000.
The server calls the recv() function, which returns with 4360 bytes received.
The client has to call the recv() function once again to get the remaining 15640
bytes of the segment. In my opinion this behaviour is not correct.

second problem:
If the server an the client reside in the same machine, no fragmentation is
detected, if the size of the transmitted segments is less than the 
receivebuffersize (which is 23360 bytes as reported by the function getsockopt()
). This beviaour does not change, even if the receivebuffersize of the
receiving socket and the sendbuffersize of the sending socket are increased via
the setsockopt() call. The border at which fragmentation begins remains at
23360 bytes.

My configuration is:
two IBM PS/2 (mod 80 and mod 50Z) both with an Token-Ring adaptercard 16/4 A
and OS/2 1.2 EE CSD:4098 and TCP/IP V1.1 for OS/2 (Program number: 5798-RXW
Part Number : 66F5612).
The mtu parameter of the TCP/IP is set to 4400 as it is recommended in the
documentation.

I hope somebody can give me a hint how i can solve this problem.
Thanx for reading this message.
Klaudius Chlebosch
-- 
Klaudius Chlebosch      | usenet: ..chlebosc@nadia.stgt.sub.org   
Eschenweg 1             | Mailbox: *49 711 484464   24 h  1200/2400  Baud
D-7045 Nufringen        |          *49 711 461592   24 h  1200/2400  Baud
Tel.: *49 7032 82023    | 

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 00:26:58 GMT
From:      ted@blia.sharebase.com (Ted Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with TCP, read(), and write()


The problem is that TCP is a pure stream protocol that does not preserve
record boundries. Thus, if something delays the processing on some of the
bytes from one of your write()s, your read can easily complete with only the
beginning of what we written.

Since you know that all "records" are 32 bytes, there is a real easy solution:
if your read() completes with less than 32 bytes, add that count to your
buffer pointer, subtract the count from your buffer size, and repeat the read.
Continue this loop until your buffer is full. For example:

	ptr = &buffer[0];
	cnt = sizeof buffer;
	do
	{
		i = read(d, ptr, cnt);
		if (i <= 0)
			<error-processing>
		ptr += i;
		cnt -= i;
	} while (cnt > 0);
 
-- 
Ted Marshall                                       ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 01:42:30 GMT
From:      lee@locus.com (Lee Slaughter)
To:        comp.protocols.tcp-ip
Subject:   tn connect closed

On a foreign site, over which we have no control, people
need to telnet in from here. An irritating problem
that sometimes occurs is "Connection closed by foreign host"
right after the login screen (on foreign site) appears.
Frequent retries then usually succeed.
(debug output shows nothing except some terminal negotiation)

I know there are many things (on the foreign site) that can cause this but 
what can we suggest to the administrator of that foreign site
in the way of configuration things to check there. I
don't know of any way we can tell from here.

Please e-mail me as I can't usually keep up with this group.

thanks.............

lee@locus.com

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 03:15:06 GMT
From:      caserta@athena.mit.edu (Francesco Caserta)
To:        comp.protocols.tcp-ip
Subject:   finger weather

The Department of Atmospheric Sciences, University of Washington
provides the following service, and also unusual application of finger.
Do you know of any other unusual application of finger?
(RFC742, RFC1194 and RFC1196)

finger [...]@stormy.atmos.washington.edu


[stormy.atmos.washington.edu]
Format: finger weather[-station[-type[-day]]e.g.:   finger weather-SEA-zone
where: station = station for required area or hiway (default=SEA)
       type = disc, zone, warn, extend (default=zone)
       day = day of month forecast was issued (default=today)

Washington                      SEA          Seattle
Oregon                          PDX          Portland
Northern and central California SFO          San Francisco
Southern California             LAX          Los Angeles
Hawaii                          HNL          Honolulu
Nevada                          RNO          Reno
Idaho                           BOI          Boise
Montana                         GTF          Great Falls
Wyoming                         CYS          Cheyenne
Utah                            SLC          Salt Lake City
Arizona                         PHX          Phoenix
Colorado                        DEN          Denver
New Mexico                      ABQ          Albuquerque
North Dakota                    BIS          Bismark
South Dakota                    FSD          Sioux Falls
Nebraska                        OMA          Omaha
Kansas                          TOP          Topeka
Oklahoma                        OKC          Oklahoma City
Western Texas                   LBB          Lubbock
Northern Texas                  FTW          Fort Worth
Southern Texas                  SAT          San Antonio
Minnesota                       MSP          Minneapolis
Iowa                            DSM          Des Moines
Missouri                        STL          St. Louis
Arkansas                        LIT          Little Rock
Louisiana                       NEW          New Orleans
Mississippi                     JAN          Jackson
Wisconsin                       MKE          Milwaukee
Michigan                        ARB          Ann Arbor
Illinois                        CHI          Chicago
Indiana                         IND          Indianapolis
Ohio                            CLE          Cleveland
Kentucky                        SDF          Louisville
Tennessee                       MEM          Memphis
Alabama and northwest Florida   BHM          Birmingham
Georgia                         ATL          Atlanta
Florida (except northwest)      MIA          Miami
South Carolina                  CAE          Columbia
North Carolina                  RDU          Raleigh
Virginia                        RIC          (issued by WBC)
West Virginia                   CRW          Charleston
DC and vicinity                 WBC          Washington
Western Pennsyvania             PIT          Pittsburgh
Eastern Pennsyvania             PHL          Philadelphia
Western New York                BUF          Buffalo
Interior eastern New York       ALB          Albany
S.E. New York and N. New Jersey NYC          New York City
Southern New England states     BOS          Boston
Vermont                         BTV          (issued by ALB)
New Hampshire                   CON          (issued by PWM)
Maine                           PWM          Portland


Francesco Caserta

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 05:23:06 GMT
From:      faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269)
To:        comp.protocols.tcp-ip
Subject:   10BaseT installation


We use 10BaseT here, on RJ-11's.  We use mass termination on the
10BaseT hubs, to 66 blocks, and cross connect to the 2nd and third
pairs of the RJ-11's.  We use a custom cable to connect the RJ11 to
the MAU, which we have made up for, I think, $8.00.
We don't do it, but you could run a telephone connection on the first
pair, and 10BaseT on the other two pairs simultaneously.  I have a
couple of adapters somewhere around that will do that out of one RJ11.

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 11:41:20 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression

In article <9104031437.AA14650@saturn.acc.com> teb@SATURN.ACC.COM (Tom Benkart) writes:
   In applications involving file transfers (FTP) over low speed lines,
   has anyone investigated any type of data compression on a message
   by message basis?  I'm familiar with the header compression
   algorithms, but don't know of any data compression algorithms.
   The pay-off might not be very high, but any compression could
   be useful.

One of the problems with a number of data compression algorithms
(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command)
is that they need to be able to look at the entire data stream before
being able to compress any part of it.  In this case, it would be about
the same as running compress yourself and then FTPing the resulting file.

Another approach would be to use something like an adaptive Huffman code
(the details of which I know nothing about).  The '/usr/old/compact' command
on Sun's Release 4.1 takes this approach by encoding the data as it is being
read in and sending it out immediately.  The man page lists the following
reference (and also indicates that the command will NOT be distributed or
supported in future releases):
	Gallager, Robert G., Variations on a Theme of Huffman,
	IEEE Transactions on Information Theory, vol.IT-24, no. 6,
	Novermber 1978, pp. 668-674.

I believe that the Applications Area of the Internet Engineering Task Force
is planning to look into improvements to FTP such as this at some point in
the near future, but I'm afraid I don't know what the time frames or immediate
plans are.


--
				-- Frank Solensky / Clearpoint Research Corp.
Red Sox magic number: 163

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 14:37:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: Problems with TCP, read(), and write()

>I am having problems with TCP, write(), and read(). I want to send and
>receive 32 byte structures....
>My problem is that if I do no put a sizeable delay in the
>send or receive loop, I end up receiving only part of a 32 byte chunk
>after a number of chunks have been received.

Shawn,

As you have discovered, TCP does not preserve record boundaries.  One
work-around makes use the value returned by read(), which is the number of the
bytes read.  Keep reading until you get your entire 32 bytes.  I.e.,

  int bf_ln,  /* number of bytes requested */
      bc,     /* byte count returned by read() */
      s;      /* socket */

  struct shawns_struct { /* whatever, 32 bytes worth */} in_rec;

  char *bptr;

  /* get the connection. Then, to load a structure... */

  bf_ln = sizeof(struct shawns_struct);
  bptr  = (char *) in_rec;
  while (bf_ln)
  {
      bc = read(s,bptr,bf_ln);
      if (bc < 1)
         exit(-1);
      bf_ln -= bc;
      bptr  += bc;
   }

Note that I exit if read() returns a value of zero.  In BSD, select() will
indicate that a closed socket is ready to read, but read() will return zero
bytes.  Hence, if the above loop didn't exit when read() returned a zero, then
a closed socket would keep it busy for quite some time... :-)

Regards,

Bob Stine
bstine@MCIMail.com

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 15:23:45 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

From the response, both here and in EMail, this sounds like a really hot
subject. I will put together as much as I can, and post it soon.
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.	
Minneapolis, MN 55416-1528	So much System,
(612) 525-0000			so little CPU time...

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 16:10:19 GMT
From:      oleg@watson.ibm.com
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Problems with IBMs TCP/IP V1.1 for OS/2

In  <ZSNPX4T@nadia.stgt.sub.org>  chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes:
> I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i
> hope to get some help on this way.
>
> I have to write a program, which transfers data using stream sockets in portions
> of 32 kByte. The sender should send this portions with one call to the send()
> function and the receiver should get this portions with one call to the recv()
> function.
> This works very well, if the size of the transmitted segments does not exceed ab
> 6000 bytes and only one segment is transferred using the same socket. In the
> other case the receiving program has to call the function recv() several times
> to get the complete segment. Normally the recv() function should block the proce
> until the whole segment is reveived.

No, it is not how recv()/send() work. You can't make any assumptions on size
of segments that you get with recv(). Also, there is 8K per call limit on
send/recv in OS/2 TCP/IP implementation.
[TEXT DELETED]

> second problem:
> If the server an the client reside in the same machine, no fragmentation is
> detected, if the size of the transmitted segments is less than the
> receivebuffersize (which is 23360 bytes as reported by the function getsockopt()
> ). This beviaour does not change, even if the receivebuffersize of the
> receiving socket and the sendbuffersize of the sending socket are increased via
> the setsockopt() call. The border at which fragmentation begins remains at
> 23360 bytes.

What do you mean by fragmentation, and what is the problem here ?

[TEXT DELETED]
> Klaudius Chlebosch      | usenet: ..chlebosc@nadia.stgt.sub.org

Oleg Vishnepolsky

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Apr 1991 18:02:39 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression

In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>One of the problems with a number of data compression algorithms
>(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command)
>is that they need to be able to look at the entire data stream before
>being able to compress any part of it...

Telebit would be very surprised to hear this; all their modems do
Lempel-Ziv compression on the fly.  No, LZ does *not* need to look at
the entire data stream before being able to compress any part of it.
-- 
"The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 are all true."  -D. Harrison|  henry@zoo.toronto.edu  utzoo!henry

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 18:05:41 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression

In article <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
   Telebit would be very surprised to hear this; all their modems do
   Lempel-Ziv compression on the fly.  No, LZ does *not* need to look at
   the entire data stream before being able to compress any part of it.

Faux pas, mea culpa, *sigh*!  Looking at the man page again, I see that
the "compress" command does indeed use an _adaptive_ LZ coding..  The main
point I wanted to make was that the IETF is, at least, aware of the desire
for compression within FTP.

--
				-- Frank Solensky / Clearpoint Research Corp.
Red Sox magic number: 163

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 18:21:15 GMT
From:      metzger@watson.ibm.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather

In article <1991Apr4.031506.6778@athena.mit.edu> caserta@athena.mit.edu (Francesco Caserta) writes:
>The Department of Atmospheric Sciences, University of Washington
>provides the following service, and also unusual application of finger.
>Do you know of any other unusual application of finger?

The RFC for finger specifies fingers behavior when applied to coke
machines. It is my understanding that CMU used to have a coke machine
on the internet that followed the stated behavior, although this may
be an urban legend.

Perry Metzger

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 20:35:15 GMT
From:      dshardin@zoot.avgrp.cr.rok.com (David Hardin)
To:        comp.protocols.tcp-ip
Subject:   XTIS info?

I am looking for information on XTIS, the X/Open Transport Interface
Specification (at least, I think that's what it stands for).  Is there
any info available via anonymous ftp, or do I have to contact X/Open?

Thanks in advance,

David Hardin

-- 
 David S. Hardin                                Collins Commercial Avionics
                                                Rockwell International 
                                                M/S 124-211, 400 Collins Rd. NE
 INTERNET: dshardin@zoot.avgrp.cr.rok.com       Cedar Rapids, IA  52498

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 20:46:14 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp questions (a possible reposting)


Emily,


> Hi.
 
> I have some questions about bootp that someone out
> there might be able to answer.
 
> Is the bootp 2.1 (cmu) the must current version?
> What other versions are there out there
> (and where can I get them)?

Bootpd 2.1 is the most recent release of bootpd from CMU.  I have not
had time to work on it in quite a while, but I will again eventually. 
The IETF Dynamic Host Configuration Working Group is working on a new
Dynamic Host Configuration Protocol (DHCP) based on BOOTP.  I will
eventually be writing and releasing a DHCP server which will work with
DHCP clients and old BOOTP clients.

A number of people have suggested improvements to CMU's bootpd.  Several
have added their own local extensions or ported it to other operating
systems (Unix System V, MS-DOS, VMS).  Unfortunately, there hasn't been
much effort to coordinate these versions or gather them together in a
single place (largely my fault for being unable to devote the time).  As
such, I don't really know where to find these other versions.

I know of no independently-developed BOOTP servers; all seem to be
derivations of the Stanford/CMU bootpd for BSD Unix.  (Someone please
correct me if I am wrong!)

The CMU distribution of bootpd is available via anonymous FTP from
LANCASTER.ANDREW.CMU.EDU (128.2.13.21) in the file pub/bootp.2.1.tar. 
This is actually a slightly newer version which calls itself 2.1a.  It
includes just a few minor bug fixes which were often reported to me.

> Is bootp the most widely used protocol
> to boot up network devices? Are there others?

RARP provides another alternative for assigning IP addresses to booting
hosts.  It only deals with the IP address assignment issue (unlike BOOTP
which can also pass information such as the subnet mask, default
router(s), etc.).  RARP is a link-layer protocol, so it cannot work
across routers like BOOTP can.

There are other protocols which deal with various aspects of the network
boot problem.  The DHC "Problem Statement" Internet Draft touches on
some of them.  This was available via anonymous FTP from NNSC.NSF.NET in
the internet-drafts/ directory, but seems to have disappeared (it
probably expired).

> Has anyone run up against the 64 byte limitation
> of vendor specific data? If so, what did you
> do you about it?

Yes, CMU certainly has and I know others have.  The DHCWG is trying to
address this problem as well.  One suggestion has been to modify both
BOOTP clients and servers to simply send larger packets.  In many
instances, the network manager knows the minimum MTU (Maximum
Transmission Unit) between the BOOTP server and a given client.  The
BOOTP server could be configured with this information and could then
send a packet up to that size.

I must stress that, so far, this is only a suggestion and is not
guaranteed to work in all environments, etc., etc.

Another suggestion is to use the vendor field to communicate a file name
containing configuration information and then use TFTP or something to
transfer that file.

> What is the method for specifying a vendor
> magic cookie (do you have to modify
> the boop server source?).

Yes; this is really the only way if you don't want to use the CMU or
RFC1084/RFC1048 formats.  Bootpd does contain some code to let you
specify an arbitrary vendor magic cookie, but there is no way to then
specify what actual information should go in the remaining 60 octets. 
This is one of those features that was sort-of half-implemented and then
forgotten/abandoned.

Note that you can stick with RFC1084/RFC1048 format and define your own
custom tags with the generic tag ":Tn=xxxx:" bootptab construct.  From
RFC1084:

         Reserved Fields (Tag: 128-254, Data: N bytes of undefined
         content)

            Specifies additional site-specific information, to be
            interpreted on an implementation-specific basis.  This
            should follow all data with the preceding generic tags 0-
            127).

> Thanks any information will be appreciated!
> If I get responses, I will post the replies.

There is also a mailing list devoted to open discussion about BOOTP and
questions such as yours.  The submission address is:

	bootp@andrew.cmu.edu

In the Internet tradition, please send requests to be added to or
removed from the mailing list to:

	bootp-request@andrew.cmu.edu



> Emily Hipp
> ehipp@wrs.com
 

Walt Wimer
Network Development
Carnegie Mellon University

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 23:34:08 GMT
From:      parr@wglen.ab.ca (Bob Parr)
To:        comp.protocols.tcp-ip
Subject:   (none)

To Whom It May Concern ...

This is probably a question that has been asked and answered many times in
the last six months but we've been unplugged from the USENET for the past
year so I'm operating out of a news blackout. In the INTEROP 1991 brochure
that advertises Doug Comer's TCP/IP Internals and Implementation tutorial
mention is made of his book "Internetworking with TCP/IP: Design,
Implementation, and Internals, Vol 2". On a recent business trip to the
Bay Area I stopped in at the Stanford Bookstore to see if this book was
available and found that it had ( as of the end of January at least ) not
yet been published. If you could respond with any information as to the
current or future availability of this book I would be greatly appreciative.

Thanks in advance,

Bob Parr
SCADACOM Product Manager
Willowglen Systems Ltd.
Calgary, Alberta, Canada
Tel: (403)-272-1800
Fax: (403)-272-2114
parr@wglen.ab.ca

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Apr 91 23:50:41 GMT
From:      rsk@hazel.circ.upenn.edu (Rick Kulawiec)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather

In article <1991Apr4.182115.3531@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes:
>The RFC for finger specifies fingers behavior when applied to coke
>machines. It is my understanding that CMU used to have a coke machine
>on the internet that followed the stated behavior, although this may
>be an urban legend.

I think it was for real...the three notes below cover the story,
and are probably worth reposting here since it's been a while since
they first appeared.

---Rsk

Originally-From: tgl@zog.cs.cmu.edu (Tom Lane)
Original-Newsgroups: alt.folklore.computers
Original-Subject: The only Coke machine on the Internet
Original-Date: 11 Dec 89 15:45:34 GMT

This story is old news to ex-CMU folk, but may be amusing to others.

Since time immemorial (well, maybe 1970) the Carnegie-Mellon CS department
has maintained a departmental Coke machine, which sells bottles of Coke
for a dime or so less than other vending machines around campus.  As no
Real Programmer can function without caffeine, the machine is very popular.
(I recall hearing that it had the highest sales volume of any Coke machine
in the Pittsburgh area.)  The machine is loaded on a rather erratic
schedule by grad student volunteers.

In the mid-seventies expansion of the department caused people's offices
to be located ever further away from the main terminal room where the Coke
machine stood.  It got rather annoying to traipse down to the third floor
only to find the machine empty; or worse, to shell out hard-earned cash to
receive a recently loaded, still warm Coke.  One day a couple of people got
together to devise a solution.

They installed microswitches in the Coke machine to sense how many bottles
were present in each of its six columns of bottles.  The switches were
hooked up to CMUA, the PDP-10 that was then the main departmental
computer.  A server program was written to keep tabs on the Coke machine's
state, including how long each bottle had been in the machine.  When you
ran the companion status inquiry program, you'd get a display that might
look like this:

		EMPTY	EMPTY	1h 3m
		COLD	COLD	1h 4m

This let you know that cold Coke could be had by pressing the lower-left
or lower-center button, while the bottom bottles in the two right-hand
columns had been loaded an hour or so beforehand, so were still warm.
(I think the display changed to just "COLD" after the bottle had been
there 3 hours.)

The final piece of the puzzle was needed to let people check Coke status
when they were logged in on some other machine than CMUA.  CMUA's Finger
server was modified to run the Coke status program whenever someone
fingered the nonexistent user "coke".  (For the uninitiated, Finger
normally reports whether a specified user is logged in, and if so where.)
Since Finger requests are part of standard ARPANET (now Internet)
protocols, people could check the Coke machine from any CMU computer by
saying "finger coke@cmua".  In fact, you could discover the Coke machine's
status from any machine anywhere on the Internet!  Not that it would do
you much good if you were a few thousand miles away...

As far as I know nothing similar has been done elsewhere, so CMU can
legitimately boast of having the only Coke machine on the Internet.

The Coke machine programs were used for over a decade, and were even
rewritten for Unix Vaxen when CMUA was retired in the early eighties.
The end came just a couple years ago, when the local Coke bottler
discontinued the returnable, coke-bottle-shaped bottles.  The old machine
couldn't handle the nonreturnable, totally-uninspired-shape bottles, so it
was replaced by a new vending machine.  This was not long after the New
Coke fiasco (undoubtedly the century's greatest example of fixing what
wasn't broken).  The combination of these events left CMU Coke lovers
sufficiently disgruntled that no one has bothered to wire up the new
machine.

I'm a little fuzzy about the dates, but I believe all the other details
are accurate.  The man page for the second-generation (Unix) Coke programs
credits the hardware work to John Zsarnay, the software to David Nichols
and Ivor Durham.  I don't recall who did the original PDP-10 programs.

				tom lane

==========
Orginally-From: sgw@cad.cs.cmu.edu (Stephen Wadlow)
Orginal-Newsgroups: alt.folklore.computers
Orginal-Subject: Re: The only Coke machine on the Internet
Orginal-Date: 11 Dec 89 20:26:30 GMT

In article <7295@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes:
>This story is old news to ex-CMU folk, but may be amusing to others.
[story of the CMU coke machine]

At the annual Jimmy Tsang's dinner expedition  last saturday, I 
was talking with a member of the CS Facilities staff [Hi Steve :-)]
who is currently working on the new hardware for the coke server.
In addition to monitoring the status of the coke machine, the new
server will re-implement the JF (junk food) protocol, telling you
the status of the CS M&M dispenser and other CS-affiliated junk
food dispensers.  It's hoped that this will all be finished and installed
by early next year, such that any internet site will be able to 
finger coke@cs.cmu.edu once again.  

An addendum to the coke story is that for quite sometime there was a
Perq sitting behind a large glass window in front of the elevators
on the third floor of science hall that frequently ran a variation
of the coke program that would display bar graphs indicating the 
amount of time since the machine had been filled.  You now didn't
even have to be logged in to find out if the coke was cold, rather
you could just be riding by on the elevator and decide on the fly
if you wanted to grab a cold coke.

You used to (and still may) be able to finger weather@hermes.ai.mit.edu
to find out what the weather was like on the 9th floor of tech square
(the ai labs).

			steve

==========
Originally-From: colbath@cs.rochester.edu (Sean Colbath)
Original-Newsgroups: alt.folklore.computers
Original-Subject: Re: The only Coke machine on the Internet
Original-Date: 11 Dec 89 19:01:21 GMT

I don't think the students at RIT (Rochester Institute of Technology) get
this newsgroup, so I'll relate this (true) story.  At UR, there is an
organization known as the Computer Interest Floor, an area of campus housing
where computer oriented people can get together.  RIT has a similar
organization, known as CSH (Computer Science House, or...).  Many of their
members are quite hardware oriented.  Well, apparently they found an old
slightly malfunctioning coke machine that was being thrown out (can-style).
They decided to install this on their hall, but were informed by the powers
that be that the university had granted a monopoly on vending machines to a
city vending machine service, and they couldn't set it up.  So, they decided
to come up with a way to get around this rule:  they changed the coke
machine from a vending machine to a peripheral!

The vending machine has a serial line running from it to one of the unix
systems.  It looks much like a regular machine, except it has a red
calculator-like display that says "Coke" on it.  If you press a button,
it'll tell you how many sodas are in that particular bin, or "Empty".  Next
to it is a terminal with the time of day displayed, and a coke logo.  To buy
a coke, all you have to do is to "log on" to your coke machine account at
the terminal, look at the status report, and "buy" your coke by selecting
from a menu.  Each user had a bank account that was added to by giving the
machine maintainers more money.

Now, this isn't all -- you could buy your coke from any terminal in their
housing section (every room had one, and they had two semi-public terminal
areas.  If you wanted to, you could program in a delay before the machine
dropped your coke, so you wouldn't get down the hall to find someone had
snarfed your coke.  Apparently they wanted coke to come do a commercial
showing someone hacking on a terminal, pausing with a thirsty look on their
face, type "coke", race down the hallway, and arrive just in time to have
the machine plop a soda in their hand...!

Sean Colbath
colbath@cs.rochester.edu			...uunet!rochester!colbath

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 01:27:07 GMT
From:      mikem@ibmpa.awdpa.ibm.com
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Problems with IBMs TCP/IP V1.1 for OS/2

In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes:
>I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i
>hope to get some help on this way.
>
>I have to write a program, which transfers data using stream sockets in portions
>of 32 kByte. The sender should send this portions with one call to the send()
>function and the receiver should get this portions with one call to the recv()
>function.

No. You can *not* code your client program to expect that a block of
bytes sent by your server will arrive in a single receive. It doesn't matter
what TCP/IP implementation you use. To do so is to cripple your client.

What you need to do is place some sort of signature byte so that your
client knows when the data block is complete and can process that
block at that time.


Michael R. MacFaden    IBM Palo Alto     Marketing Systems
mikem@ibmpa.awdpa.ibm.com, macfaden@paloic1.vnet.ibm.com 
disclaimer:  what I write above is not necessarily my employer's opinion 

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 04:50:55 GMT
From:      ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression


> Excerpts from internet.tcp-ip: 4-Apr-91 Re: Message compression Frank T.
> Solensky@ucsd.e (1666)
 
> One of the problems with a number of data compression algorithms
> (eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command)
> is that they need to be able to look at the entire data stream before
> being able to compress any part of it.  In this case, it would be about
> the same as running compress yourself and then FTPing the resulting file.


From empirical evidence, I don't believe this is true.  The 'compress'
program can read from a pipe.  I've used this feature to create a
compressed tar file of a directory tree in a single step:

	tar -cf - somedirectory | compress -c > somedirectory.tar.Z

Granted, it could be buffering quite a bit of data in virtual memory,
but I doubt it was buffering the 90 megabytes worth of data from one
particular tar I remember.  (My system only has 64 megs of swap space. .
. .)

Recently, there was also an excellent posting to the comp.sources.unix
newsgroup concerning compression techniques.  It included a draft of a
paper on the workings of various compression algorithms, including a
newly-invented variant of Lempel-Ziv which the author seems to claim is
free of patent (he calls it "Y-coding").  While I know and understand
very little about compression techniques, a brief reading of the paper
seems to suggest that these compression techniques work quite well even
applied to (relatively small) finite-sized chunks of data.  An
implementation of the new algorithm is included in the posting.


Walt Wimer
Network Development
Carnegie Mellon University

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 07:55:01 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   finger weather


   Date: 4 Apr 91 18:21:15 GMT
   From: decwrl!uunet.uu.net!bywater!arnor!halley!metzger  (Perry E. Metzger)

   The RFC for finger specifies fingers behavior when applied to coke
   machines. It is my understanding that CMU used to have a coke machine
   on the internet that followed the stated behavior, although this may
   be an urban legend.

No, it's true. CMU did have a coke machine on the Internet.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 08:03:32 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Bootp questions (a possible reposting)

In article <Ibyt2Ki00WCp44dZAH@andrew.cmu.edu> ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes:
>RARP provides another alternative for assigning IP addresses to booting
>hosts.  It only deals with the IP address assignment issue (unlike BOOTP
>which can also pass information such as the subnet mask, default
>router(s), etc.).  RARP is a link-layer protocol, so it cannot work
>across routers like BOOTP can.

Why couldn't an RARP server rebroadcast the RARP request on another subnet,
and then forward the response back to the original host?  BOOTP's "routing"
is done at the application layer, because IP-layer routing requires the
client to know most of the information it is trying to find out from the
BOOTP server.  Since BOOTP does its routing at the application layer, so
could RARP.

--
Barry Margolin, Thinking Machines Corp.

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

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 08:12:03 GMT
From:      francis@zaphod.uchicago.edu
To:        comp.protocols.tcp-ip
Subject:   FTP site for RFCs?


Is there an FTP site with RFCs? I'm kinda interested in seeing the
protocol specs for the stuff I'm using, but I'm just a student (not
even a CS student at that :-), so I don't have any clue about who
handles this stuff.


--
/============================================================================\
| Francis Stracke	       | My opinions are my own.  I don't steal them.|
| Department of Mathematics    |=============================================|
| University of Chicago	       | Earth: Love it or leave it.	     	     |
| francis@zaphod.uchicago.edu  |  					     |
 \============================================================================/

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 11:59:00 GMT
From:      CSP1DWD@MVS.OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: finger weather

Alas, the weather finger service at <stormy.atmos.washington.edu>
is not more, it's been replaced by an equivalent RPC-based service.
The RPC-client source code can be obtained by fingering "weather"
at the above host.

-- Denis

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Apr 1991 14:20:41 GMT
From:      dcarr@hobbit.gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression

In <1991Apr4.180239.12442@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>In article <SOLENSKY.91Apr4114120@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>>One of the problems with a number of data compression algorithms
>>(eg: Lempel-Ziv encoding, the one used by the Unix 'compress' command)
>>is that they need to be able to look at the entire data stream before
>>being able to compress any part of it...
 
>Telebit would be very surprised to hear this; all their modems do
>Lempel-Ziv compression on the fly.  No, LZ does *not* need to look at
>the entire data stream before being able to compress any part of it.
>-- 
I agree with Henry.  LZW type algorithms can me made to adapt very quickly
by adjusting the number of characters learned after each match.  For example,
V.42 bis data compression has the number of characters learned as a settable
parameter (N8 I believe).

As for speed, LZW can be made very fast.  After all, it was designed with 
disk controller applications. 

The main problem with LZW is expanding uncompressable (or precompressed) data.
Again, this is addressed with V.42 bis (but not with standard LZW).

If the compressor can handle the uncompressable cases without expansion (or
minimize the expansion), then TCPIP compression is a winning solution.

Couple this with Van Jacobson's header compression, (or better the one which we 
will soon debut) and you can get substantial compression.  I won't quote 
compression rates and spoil the marketting peoples fun.

BTW Henry, does Telebit use LZW, LZSS, or LZH ?
 


-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 15:06:54 GMT
From:      smith@newsserver.sfu.ca (Richard Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather


Here is what fingering "coke" will get you now:

[cs.cmu.edu]

[ Forwarding coke as "gripe@vega.fac.cs.cmu.edu" ]

[VEGA.FAC.CS.CMU.EDU]
Login name: gripe                       In real life: Gripe
Directory: /usr1/gripe                  Shell: /usr/cs/bin/csh
Last login Tue Mar  5 10:22 on ttyP7 from GLN.FAC.CS.CMU.EDU
Mail came on Fri Apr  5 09:57, last read on Fri Apr  5 09:01
Plan:
CS/RI User Services

Software and hardware requests, bug reports and fixes, general questions
about the facility -- all of these can be sent to "gripe".

Gripe mail is *NOT* constantly monitored.  If you have a problem which
requires immediate attention, please call the CS Operator (x2607).

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 15:53:17 GMT
From:      ypinn@gpu.utcs.utoronto.ca
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   TCP/IP tunnelled in IBM/SNA

As hideous as this may sound, is there a UNIX TCP/IP implementation that has
this capability?  In order for this to work, the UNIX box would need to support
SDLC based links, SNA services, and TCP/IP tunnelled through SNA using an
APPC.

Your probably asking yourself, why does this madman want to do this?
I work for a large multi-national accounting firm.  Our firm uses a public
mail system in Canada as the basis of their enterprise-wide mail system.
My group is trying to develop a proposal to bring our mail system in house.
The system would use a combination of Macintosh computers - 3000 dispersed
over 60 offices - and UNIX servers.  The UNIX boxes would provide the message
routing between offices.
Our network design for this system is based on a hub and spoke topology.  The
remote offices would use dial-up connections running UUCP to communicate
with one of eight hubs.
Now for the SNA component...
We currently have SNA lines running to the eight hub locations.  This newtork
is well entrenched.  We have suggested replacing it with multi-protocol routers
which would forward SNA as well as TCP.  However, the idea was flatly rejected
for two reasons:  its cost and the predominance of the technology blind IBM
group.  Hence the idea of tunnelling TCP/IP in SNA.  Of course, the fallback
plan would be to exchange mail between the hubs using UUCP, but, I would prefer to have a connected network in place.

Does anyone have any suggestions, or comments on this issue?  Your assistance
would be greatly appreciated.

Thanks
bruce pinn
Manager, NITG
Peat Marwick Thorne

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 15:58:36 GMT
From:      mqh@theory.tn.cornell.edu (Mike Hojnowski)
To:        comp.protocols.tcp-ip
Subject:   Old TCP announces MSS of 65496.  Fix available?

I'm running AIX/370 with it's built-in ancient BSD 4.3 networking code.
Occasionally, it will announce an MSS of around 65496 to sites it connects
to on non-local networks.  Some of those sites are also running ancient
networking code (Ultrix and VaxStations, notably).  Those sites tend to
panic when we connect to them.

We'd like to be better neighbors than that, though I realize that this bug
is due to problems on both ends.  Is there a reasonably short source patch 
I can put in our networking code to keep it from announcing an MSS > 32K?  I 
imagine the remote sites are having a problem 'cause they think the MSS is 
signed and are indexing into hyperspace or something.

Just to add to the confusion, we run "gated" on our site.  I don't know if
this makes a difference or not.

Please respond via Email here (this is not an AIX site, so it won't crash 
you :-)).  I don't read this newsgroup regularly.

Mike Hojnowski
AIX Grunt 
Cornell University

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 16:01:05 GMT
From:      ypinn@gpu.utcs.utoronto.ca
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   TCP tunnelled in IBM/SNA (more)

Apologies, but there appears to be a bug in our Pnews command so that
the From: address for my previous message - and probably this one - is
marked as ypinn@gpu.utcs.utoronto.ca.  It should read either
craystn@gpu.utcs.utoronto.ca  {which is the machine the note was sent from},
or you can reach me at ypinn@gauss.clsc.utoronto.ca

Thanks
bruce pinn

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 16:38:51 GMT
From:      hathawa@rdsunx.crd.ge.com (Barry Hathaway)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: TCP/IP tunnelled in IBM/SNA

IBM's TCP/IP software supports TCP/IP tunnelled through SNA.
In order to do this in your situation you would have to attach each
IBM system to you TCP/IP network.  This could be expensive, but it
would offer additional capabilities.

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 16:43:46 GMT
From:      yjy@stlucia.uucp (Joe Yung)
To:        comp.sys.att,comp.sys.tcp-ip
Subject:   Re: Datakit Interface Through TCP/IP

>from: yjy@stlucia.bellcore.com (Joe Young)

Previously, I posted the following questions:

>I have a SPARC station 2 and a Datakit with a bunch of TTY modules.
>I am trying to have the SPARC connected to the Datakit so I can use
>my SPARC to access various TTY line off the Datakit.
>Does anybody know how ?
>
>I heard that AT&T Datakit has a connection to TCP/IP directly.
>We have a bunch of SPARCs on the Ethernet.  It will be a
>a versatile way to open up the Datakit available to all the SPARCs.
>Does anybody know anything about this connectivity.

I have got many helps from the net.
The following is my conclusion.

There are two possible configurations.
The first configuration is the following:

   --------------   Fiber Link     ---------
   |Sparc server| -----------------|Datakit|-------async terminals
   --------------                  ---------

A CPM/HS module is required on the Datakit end and a fiber interface
plus some software (DKHOST ?) is requried on the Sparc server.
Based on my experience on the 3B2-to-Datakit fiber link,
I believe this configuration will allow me to use all the fiber link features
including the datakit library.

However this configuration does not apply to the Sparcstations
because the fiber interface requires VME bus architecture which is
on the Sparcserver only.
The Sparcstations use SBUS architecture !

Another configuration is the following:

  --------------
  |Sparcstation|
  --------------
         |
         |   TCP/IP                          TCP/IP
  ==========================            ================
                           |   |   |    |
                          ------------------------
                          |Datakit Interface(NIK)|
                          ------------------------
                                | Fiber
                                | Link
                    Async    ---------  Async
     Serial Printer----------|Datakit|--------async terminals
                             ---------

The Datakit Interface(NIK) is a "telnet" service box which convert the TCP/IP
to URP protocol.
The user login from the async terminals as shown has to select
the "telnet" service on the datakit destination prompt.
This will take the connection to the NIK.
From there, a host address will be entered to connect to the sparcstation.
This configuration is only limited to telnet service.
From the Sparcstation end, type in telnet and open the NIK host connection.
The NIK host can connect to the async lines via the fiber link.

I think the sparcstation is not awared of the NIK as a gateway to the Datakit. 
Here are some features provided by NIK(Thanks to Bill Hill):

*Local Routing on NIK 
*Routing between LAN and remote LAN through Datakit (DK)
*Up to 4 LANs/NIK
*NIK fiber connected to DK
*Local Mngt of NIK or through StarKeeper NMS
*Capability to act as Terminal Server; a terminal or host directly
connected to DK can log onto any Ethernet LAN host connected to DK
via NIK
*Reverse terminal service; PC on LAN to Access DK hosts or Terms



Joe Yung
 -----------------------------------------------------------------
Joe Yung
yjy@stlucia.bellcore.com
(908)699-5344

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 17:02:34 GMT
From:      smith@newsserver.sfu.ca (Richard Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather


"weather" is now a RPC which will produce similar results (i.e. the
weather for your locality - if you live in the U.S :->). I downloaded it
and tried it - it works.

...r

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 18:12:11 GMT
From:      amallic@swtec1.intel.com (Asit Mallick ~)
To:        comp.protocols.tcp-ip
Subject:   MIT/CMU implementatin of SNMP


	I am looking for source of a public domain implementation 
	of SNMP. I was told that a CMU and MIT version exist. Can 
	anyone send me information about these.

	Thanks in advance.

	email addr: amallic@swtec1.intel.com

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 18:35:03 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Two machine ethernet?


Out of curiosity, I have a question regarding 10BASET wiring:

Can two PC's with 10BASET cards be wired back to back using a single
twisted pair wire (RJ45s) with the transmit and receive pairs swapped
via a crossover block -- effectively producing a two machine ethernet?

======================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
======================================================================

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 19:28:23 GMT
From:      hollings@poona.cs.wisc.edu (Jeff Hollingsworth)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather (really Coke machines)

|> 
|> As far as I know nothing similar has been done elsewhere, so CMU can
|> legitimately boast of having the only Coke machine on the Internet.
|> 

Here at the University of Wisconsin we were *FORCED* to computerize our Coke
machine a year ago (or they would take it away).  The University had
given an exclusive vending contract to a local vending company.  That company
didn't like the fact we were under cutting their prices.  But they did permit
"coffee clubs" to continue.  The idea was people would pay into a club and
then only people who payed in could take coffee from the pot.  We decided to
do the same thing with our Coke machine.  A small bit of hardware was built to
activiate the Coke machine via a computer, and a program was written to track
coke accounts and keep their balances.  The coke machine was also modified so
that it would NOT take money and could only be activated from the computer.
So I guess Wisconsin can claim the only Coke machine that can be controlled
via the Internet.

-------------------------------------------------------------------------------
Jeff Hollingsworth					Work: (608) 262-6617
Internet: hollings@cs.wisc.edu				Home: (608) 256-4839
X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 20:02:46 GMT
From:      hollings@poona.cs.wisc.edu (Jeff Hollingsworth)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather (really Coke machines)

!>
!> As far as I know nothing similar has been done elsewhere, so CMU can
!> legitimately boast of having the only Coke machine on the Internet.

Here at the University of Wisconsin we were *FORCED* to computerize our Coke
machine a year ago (or they would take it away).  The universion had
given an exclusive vending contract to a local vending company.  But they
did prmit "coffee clubs" to continue.  The idea is that people pay into a
club and then only people in the club get to drink from the coffee.  We decided
to do the same thing with our Coke machine.  A small bit of hardware was built
to activate the Coke machine via a computer, and a program was written to track
coke accounts and keep their balances.  The coke machine was also modified so
that it would NOT take money and could only be activated from the computer.
So I guess Wisconsin can claim the only Coke machine that can be controlled
via the Internet.

-- 
-------------------------------------------------------------------------------
Jeff Hollingsworth					Work: (608) 262-6617
Internet: hollings@cs.wisc.edu				Home: (608) 256-4839
X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 23:31:40 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Token Ring ARPs

The research community has been pushing for all MAC addresses carried
as data in communication protocols to always be in cannonical format.
This is at odds with older implementations for the Token Ring which
were based on RFC1042 (use of SNAP).

I'm curious as to if and when this might have an effect on products in
the marketplace.  I believe there is a large installed base that uses
the RFC1042 style ARPs where the MAC addresses are in wire order.

Are there any products out there that use cannonical order?
Are there any coming?  Does anyone have any other information?

Art

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      5 Apr 91 23:50:16 GMT
From:      yates@UNIX1.CS.UMASS.EDU (David Yates)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP mailing list

I am interested in adding my name to the TCP/IP mailing list.
Is this the right e-mail stop?

Thanks in advance,
David

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 00:21:06 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather


John,

You know your stuff.

CMU still has a coke machine on the network. Alas because of software
upgrades being constant that little trick has been divorced from the
finger software.

Under finger we had coke machine status and "tingle" status...

At the current time we have network service for the coke machine and
for our M&M machine. We have this under the "junk food" service.

-Rudy

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 01:11:39 GMT
From:      cmilono@netcom.COM (Carlo Milono)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation




First, as was stated in an earlier post or RE:, it is *not* true that
AT&T uses more than the 4 wires for 10BASE-T - four is IT for the standard
and their product is standard.  Secondly, it is a misnomer to use the RJ45
name for an 8-pin jack - the correct terminology is the ISO 8877 jack.  The
RJ stands for Registered Jack and refers to those blocks that terminate a
TelCo circuit as a demarcation point to a public service. You may note that
if you have a DSU or Modem with a private line, that the connector looks a
bit different, possibly with a switch-selectable resistor and it will have
a notch on the jack as a key for the data-set plug.

Lastly, you can run your 10BASE-T on household 'quad' wire and get an
appropriate cord (twisted preferably) to splay the four wires into the
10BASE-T standard spacing within the ISO jack.  I have several locations
where the only wire available was a six-conductor wire split between two
four-wire jacks - the first being a true RJ11.  Works fine.

I agree with a previous poster in that:
	1) the physical arrangement allows for near foolproof use of a
	   phone on the SAME jack (with a splitter)
	2) the ISO jack has proven to be sufficient to support 3270, LAN,
	   ISDN, Async, Sync, twin-axial (5251 - yuck!), as well as other
	   less-used transmission schemes (Oh, LADC-II as well!)  8 pins
	   will do most everything in a neat and clean manner, a la AT&T's
	   PDS (as opposed to IBM's multi-gauge, shielded poop).

-- 
+--------------------------------------------------------------------------+
|  Carlo Milono:  cmilono@netcom.apple.com   or   apple!netcom!cmilono     |
|"When a true genius appears in the world, you may know him by this sign,  |
|that the dunces are all in confederacy against him."   - Jonathan Swift   |
+--------------------------------------------------------------------------+

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 02:15:56 GMT
From:      pchin@midautumn.wpd.sgi.com (Phil Chin)
To:        comp.protocols.tcp-ip
Subject:   How to put tcp/ip over LocalTalk?

Any information or pointers to that information will be very much
appreciated.

Thanks.

Philip

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 03:44:40 GMT
From:      bruce@camb.com (Barton F. Bruce)
To:        comp.protocols.tcp-ip,comp.sys.dec
Subject:   Re: LANTRONIX terminal server comments?

In article <1991Mar26.181532.27542@banana.fedex.com>, bill@banana.fedex.com (bill daniels) writes:
> I am interested in comments about Lantronix tcp/ip-LAT terminal servers.  We
> a looking for some small (physically & # ports) terminal servers and the
> good price of lantronix is attractive.  I would especially like to hear about

Never tried them, but the features you seek are available in DEC's new
DS90 that might have been announced by now. I have NOT seen one,
but apparently many customers have seen at least non-disclosure units.

They target BEATING everyone's price! DEC listening to customers? 

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 06:49:46 GMT
From:      faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269)
To:        comp.protocols.tcp-ip
Subject:   Two machine ethernet?

Yes. It's speced that way. It works.

   Date:         Fri, 05 Apr 91 13:35:03 EST
   From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu


   Out of curiosity, I have a question regarding 10BASET wiring:

   Can two PC's with 10BASET cards be wired back to back using a single
   twisted pair wire (RJ45s) with the transmit and receive pairs swapped
   via a crossover block -- effectively producing a two machine ethernet?

   ======================================================================
   Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
   Systems Programmer                                 (919) 757 - 6401
   East Carolina University                          Greenville, NC 27858
   ======================================================================

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 09:19:26 GMT
From:      colin@la.excelan.com (Colin Goldstein)
To:        comp.os.os2.programmer,comp.protocols.tcp-ip
Subject:   Re: Problems with IBMs TCP/IP V1.1 for OS/2

The News Manager)
Nntp-Posting-Host: la
Reply-To: colin@la.novell.com (Colin Goldstein)
Organization: Novell, Inc., San Jose, Ca
References: <ZSNPX4T@nadia.stgt.sub.org>
Date: Thu, 4 Apr 1991 16:17:06 GMT

In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes:
>The server calls the recv() function, which returns with 4360 bytes
>received. The client has to call the recv() function once again to
>get the remaining 15640 >bytes of the segment. In my opinion this
>behaviour is not correct.
>

I don't have the IBM TCP/IP package, but the TCP/IP toolkit from Novell
works the same way. Although stream sockets give reliable delivery, there
is no way to be sure that all the data will arrive at the same time. It
is therefore the applications responsibility to recv() until all the data
is read. Keep a count of bytes read or use select() to determine if more
data is available.

Colin
--
/-------------------------------------------------------------------\
|  The views expressed here are my own.  | Norm, what are you       |
|  They do not necessarily represent     | up too???                |
|  the views expressed by my employer.   |                          |
|                         ---------------| My ideal weight if I     |
|  colin@novell.com       | Novell Inc., | were 11 feet tall.       |
|  uunet!novell!colin     | San Jose     |                 - Cheers |
\-------------------------------------------------------------------/

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 12:37:30 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   Multi-protocol Routers with Compression

We are currently operating a multi-protocol (IP, XNS, IPX, SNA...) internet
using Wellfleet bridge/routers with 672 kbps links.  While this configuration
works quite nicely, it is a bit expensive to implement in smaller offices.

Is anyone aware of a multi-protocol bridge/router which incorporates data
compression techniques for operation on low-speed (56-384 kbps) lines?
It is difficult to justify T-1 circuits to an office with 10-15 office
workers, but a DDS or fractional T-1 circuit might be feasible.  A straight-
forward bridge/router without compression would give unacceptable performance
(IMHO) when retrieving mapping data from our NFS servers.

Many thanks for any ideas!

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714-6066	
-------------------------------
                        
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 16:12:24 GMT
From:      smithfd@weiss.cs.unc.edu (Don Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   TriComm'91 Final Call for Registration

FINAL CALL FOR REGISTRATION

[Note: If you plan to attend TriComm'91, please send the registration
information (below) immediately by express mail, FAX or email.  Payment 
can be made when you pick up your registration material at the conference.  
Registrations made after Monday, April 15, 1991, cannot be guaranteed lunch
and dinner tickets.]

TriComm'91
IEEE CONFERENCE ON COMMUNICATIONS SOFTWARE:
COMMUNICATIONS FOR DISTRIBUTED APPLICATIONS AND SYSTEMS

Chapel Hill, NC  April 18-19, 1991  (Registration & Reception April 17, 6 pm)

An International Conference Sponsored by the IEEE Communication Society, 
the University of North Carolina at Chapel Hill, and MCNC

The decade of the 1980s was a period of rapid advances in communications
technology (both hardware and software) and of pioneering deployment of 
distributed systems and applications. At the beginning of the 1990's, 
new communications technologies and new distributed applications are 
emerging that will have far-reaching impact on communications software. 
Very high-speed networks (e.g., from FDDI to Gigabit technologies), multi- 
and continuous-media communications, interconnection of workstations and 
supercomputers, visualization and image applications, and computer-supported 
cooperative work (CSCW) are just a few examples. Participation in the 
conference by both developers of advanced distributed applications or 
systems and researchers interested in communications software will 
provide a mutually beneficial dialogue.  

                         FEATURED SPEAKERS

Ken Birman, Cornell University, "Group Communication in Operating System 
                                 Microkernals"
Roger Bushnell, Bell Northern Research, "Subscriber Service Evolution"

J. L. Felton, IBM, "Directions in Information Systems in the 1990s" 

John Morris, Open Software Foundation, "Distributed Systems:  Meeting the 
                                        Needs of the 90s"
Dave Sincoskie, Bellcore, "Gigabit Testbed Activities at Bellcore"

                                SESSIONS

COMMUNICATIONS FOR MULTIMEDIA

"Multimedia TeleConferencing over International Packet Switched Networks,"
J. Crowcroft, University College-London
					
"On the Synchronization and Display of Multiple Full-Motion Video Streams," 
Howard Katseff, AT & T Bell Laboratories

"Delay Jitter Control for Real-Time Communication in a Packet Switching 
Network," 
Dinesh C. Verma, University of CA-Berkeley & International Computer Science 
Institute

"New Virtual Time CSMA/CD Protocols for Real-Time Communication," 
Jaideep Srivastava, University of Minnesota

APPLICATIONS AND  ARCHITECTURES	

"The Design and Implementation of the MONTAGE Multimedia Mail System," 
Keith Edwards, Georgia Institute of Technology

"A Proposed Extension of the ODA Document Model for the Processing of 
Multimedia Documents," 
Hannes P. Lubich, ETH-Zurich

"The Andrew File System on OS/2 and SNA," 
Neil Sullivan, IBM-RTP
					
"Vector Processor Services for Local Area Networks," 
Scott Midkiff, Virginia Polytechnic Institute and State University

COMPUTER CONFERENCING

"Evaluating Alternative Display Sharing System Architectures," 
Nina Rosson, Southwest Research Institute

"XTV: A Framework for Sharing X Window Clients in Remote Synchronous 	
Collaboration," 
Hussein Abdel-Wahab, Old Dominion University

"Control Issues in Multimedia Conferencing," 
S. R. Ahuja, AT & T Bell Laboratories

"System Design for Workstation-Based Conferencing with Digital Audio 
and Video." 
Kevin Jeffay, University of North Carolina-Chapel Hill
 
NETWORK PROTOCOLS AND IMPLEMENTATIONS

"A Communication Protocol for a Multi-level Secure Network," 
Andrew Mazeikis, Queen's University-Ontario

"Heirarchial Network Routing," 
Alan Fekete, University of Sydney

"A Parallel Implementation of the ISO 8802-2.2 Protocol," 
Matthias Kaiserswerth, IBM Research-Zurich

"A Layered Communication System Generator," 
Gen-Huey Chen, National Taiwan University

PERFORMANCE AND	MEASUREMENT					

"The Effects of Long Delay and Transmission Errors on the Performance of TP-4 
Implementation," 
Randy C. Mitchell, The MITRE Corp.

"HiPPI Link Data Analysis System," 
Dan Winkelstein, MCNC

"Tingle: Suite for Monitoring Networks," 
J. Dean Brock, University of North Carolina-Asheville

"Capability Analysis of Distributed Switching Systems in Interprocessor 
Communications," 
Serap Savari, MIT


CONFERENCE COMMITTEE
Alan Blatecky, General Chairman	     Jurg Nievergelt, International Chairman
    MCNC, USA			         ETH, Switzerland
Peter Calingaert		     Andre Fournier			
    UNC-Chapel Hill, USA		 BNR, USA
David May                            Joe Rusnak                      
    BNR, USA			         IBM, USA                        
Dan Stevenson
    MCNC, USA

PROGRAM COMMITTEE
F. Donelson Smith   Chairman         Yutaka Matsushita 
    IBM & UNC-Chapel Hill, USA	         Keio University, Japan 
Steven Bellovin			     Najah Naffah                          
    AT & T Bell Laboratories, USA        Bull, France                      
Rich Chilausky          	     Erich Neuhold                         
    BNR, USA                             GMD-IPSI, Germany                 
Brian Coan   			     Bernhard Plattner                         
    Bellcore, USA		         ETH, Switzerland                      
Flaviu Cristian                      Tom Rodeheffer                            
    IBM Research-Almaden, USA            DEC System Research Center, USA       
Carla Ellis     		     Beverly Sanders                           
    Duke University 		         ETH, Switzerland                      
Rong-Chin Fang			     M. Satyanarayanan                         
    Northern Telecom, USA	         Carnegie Mellon U., USA               
Domenico Ferrari		     H.T. Smith                            
    U. of CA-Berkeley, USA	         Nottingham University, UK         
James P. Gray   		     Jorgen Stanstrup                          
    IBM-RTP, USA    		         Technical University, Denmark         
Fukuya Ishino    		     Liba Svobodova                            
    NTT, Japan       		         IBM Res.-Zurich, Switzerland          
Kevin Jeffay			     Mladen Vouk                           
    UNC-Chapel Hill, USA	         NC State U., USA                  
Rivka Laden             	     Hussein Abdel-Wahab                       
    DEC CRL. USA            	         Old Dominion University, USA          
Simon Lam                            William Weihl                         
    U. of Texas-Austin, USA             MIT, USA                           
Geovane Magalhaes            	     Jennifer Welch                            
    CPqD/TELEBRAS, Brazil                UNC-Chapel Hill, USA              
				         
LOCATION

TriComm '91 will take place in Chapel Hill, North Carolina, at the University 
of North Carolina. The University of North Carolina is located at one corner 
of North Carolina's Research Triangle (Raleigh, Durham, Chapel Hill) in the 
center of which is the Research Triangle Park and the Raleigh-Durham Airport. 
MCNC, a national resource in microelectronics, is located in the Research 
Triangle Park. MCNC is a non-profit corporation established to support and 
develop the education and research technology infrastructure in North 
Carolina. It has three divisions: microelectronics, supercomputing, and 
communications.

All conference sessions and meals will be held at the Carolina Inn, a 
charming Chapel Hill landmark, located on the campus of the University of 
North Carolina just across the street from Sitterson Hall, the 
state-of-the-art building which houses UNC's Computer Science Department. 
On Wednesday night, April 17, pre-registration and the conference reception 
will take place in Sitterson Hall.

Chapel Hill is a small community of about 40,000. In April the weather will 
generally be very pleasant with daytime temperatures in the upper 60's and 
nighttime temperatures in the 50's; however, you should be prepared for a 
shower. Many spring-flowering plants and shrubs should be in bloom at this 
time.


TRANSPORTATION

The local airport is Raleigh-Durham International.  American Airlines is 
the official carrier of TriComm '91, offering special fares to North 
American conferees:  5% saving off published excursion fare within the 
US, or 40% (Canada 35%) off the full coach fare with a 7-day advance purchase 
valid from April 15-April 21, 1991. Call 1-800-433-1790 and refer to STAR 
FILE S0241GC to obtain the discount.

Taxis, which you can take to the Carolina Inn or any other location in 
Chapel Hill for about $25.00, are generally waiting outside the airport 
terminals. Or you can arrange to be picked up by LTD Services. LTD operates 
by reservation. In order to be picked up, call LTD (1-800-787-4474 or 
919-840-1829) at least one day in advance and give the time, flight number
and airline you will arrive on.  You may call after you arrive but you may 
have a substantial wait. The cost is $15.00 per person. Because all 
conference events will take place either at the Carolina Inn or Sitterson 
Hall just across the street, there is no need to rent a car.

For those commuting, we have arranged for a shuttle bus to run from the 
southwest corner of the University Mall parking lot (near First Union Bank) 
beginning at 7:00 am on April 18 and 19. The Mall is located at the 
intersection of Estes Drive and US 15-501. Parking is not available on the 
UNC campus between 8:00 am and 5:00 pm. The Carolina Inn provides free 
parking for registered guests only.

-------------------------------------cut here---------------------------------

ADVANCE REGISTRATION FORM (Clip and mail to address below)

Please make checks or money orders payable (in U.S. currency) to TriComm '91. 
We cannot accept credit cards. Mail with 
completed registration form to:	Mary Ducker
				TriComm '91
				CB #3175, Sitterson Hall
				University of North Carolina
				Chapel Hill, NC  27599-3175	USA	
				919-962-1869	FAX 919-962-1799	
                                ducker@cs.unc.edu

Conference registration includes a copy of the proceedings, coffee breaks, 
Wednesday evening reception, lunches Thursday and Friday, and the Thursday 
evening conference dinner. The basic student fee includes the technical 
sessions, proceedings, and coffee breaks.  Students who register in 
advance may also purchase lunches.  No refunds can be given after April 10. 
Please indicate the appropriate fee.
				
IEEE member			$225.00
Non-member			$275.00
Full time student (basic)	$35.00
Full-time student 
   (including lunches)		$55.00
Please print the following information.

Name (for name badge) __________________________________________________

Affiliation (for name badge) ___________________________________________

Address ________________________________________________________________
       
        ________________________________________________________________

Phone ______________________________Email_______________________________

IEEE membership number __________________________________
 
I will attend the reception on Wed., April 17____yes ____no

NOTE:  Individuals whose registrations are received after Monday, April 15, 
cannot be guaranteed lunch and dinner tickets. If you have any special 
dietary needs, please let us know. We will make every effort to work with 
our caterers to honor those needs.

------------------------------------cut here-------------------------------

HOTEL RESERVATIONS (Clip and mail to address below or phone for reservation)

CAROLINA INN
PO Box 1110
Chapel Hill, NC  27514
919-933-2001		1-800-962-8519

Please make reservations directly with the Carolina Inn and refer to 
TriComm '91 (Group #1960*1). Please complete all information and circle 
desired accommodation. 
TriComm '91 rates (not including tax):	single  $42-65	double  $52-80

Guest name___________________________________________________________ 

Phone_______________

Address______________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Arrival date _________________________Departure date_________________

Number in party__________ Share with ________________________________

_________________________________________________

Reservations will be held until 6:00 p.m. on the arrival date unless a 
one night deposit is received or is guaranteed with American Express, Visa, 
or Mastercard.

Card name ____________________Expiration date ___________

Card number __________________________

Name on card (please print clearly) ___________________________________

Signature ____________________________________________________________
				         

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 17:05:49 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Token Ring ARPs

There are apparently a number of vendors in the field with token ring
products that comply with RFC 1042. Many router vendors and PC
vendors, for instance. Interop has a respectable number of hosts on
token ring at the show every year, also. I think you're asking for a
lot of trouble if you try to change this now.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 17:08:52 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather (really Coke machines)

In article <1991Apr5.192823.400@spool.cs.wisc.edu> hollings@poona.cs.wisc.edu (Jeff Hollingsworth) writes:
>So I guess Wisconsin can claim the only Coke machine that can be controlled
>via the Internet.

Sorry, but Thinking Machines has had its Coke machine on the Internet for
at least five years.  If you telnet to Coke5.Think.COM, each character you
type is as if a nickel were dropped into the slot.

The subnet Coke5 is on a subnet to which we don't allow telnet from the
outside world, so you won't have much luck trying this.  But it works
in-house.  There's a terminal sitting next to the machine, and users can
type their name, get their drink, and then the price is deducted from their
paycheck (we also use the payroll deduction system for lunch and the
postage meter).
--
Barry Margolin, Thinking Machines Corp.

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

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 19:03:00 GMT
From:      amc@cup.portal.com (Alan Michael Crawley)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   10baseT Installation costs

Alot of people are talking about the costs of 10baseT vs. cheapnet.

My company engineers and INSTALLS large (50-1500 user) 10baseT nets and cable
plants.   Also FDDI.

10baseT is only cheaper when the net is over 100 users big.  Savings is in
administration costs.(adds moves and changes) and existing wire savings.
Little departmental nets don't benefit that way.
Large nets also benefit from existing phone wire.  We do cable plant audits
to test existing wire for 10baseT.  Almost 100% is suitable for ethernet
if we change out the 66 blocks for 110 or Krone...plus a few other secrets.
Alan Crawley
VP Engineering
APEX COMMUNICATIONS - MOUNTAIN VIEW CALIFORNIA - 415-967-9200

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 19:36:07 GMT
From:      mcitron@phad.hsc.usc.edu (Mark Citron)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   tn3270 under SCO Unix

I post this several months ago and got no reponses but it is so important
for us I figured it is worth another try. 

Does anyone have a 3270 emulator that runs under SCO Unix (we already have
tcp/ip)? We have a critical need and would even consider paying for
a port to SCO Unix. We need to communicate with a remote IBM mainframe
via ethernet-tcp/ip (no other protocols or media). Any help or suggestions 
would be greatly appreciated.

Mark Citron
Childrens Hospital Los Angeles

-- 
Mark Citron
mark@neurosci.usc.edu

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Apr 91 23:57:49 GMT
From:      yeh@ubvax.UB.Com (David Yeh)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP site for RFCs?

In article <FRANCIS.91Apr5021203@daisy.zaphod.uchicago.edu> francis@zaphod.uchicago.edu writes:
>
>Is there an FTP site with RFCs? I'm kinda interested in seeing the
>protocol specs for the stuff I'm using, but I'm just a student (not
>even a CS student at that :-), so I don't have any clue about who
>handles this stuff.
>
>
>--
>/============================================================================\
>| Francis Stracke	       | My opinions are my own.  I don't steal them.|
>| Department of Mathematics    |=============================================|
>| University of Chicago	       | Earth: Love it or leave it.	     	     |
>| francis@zaphod.uchicago.edu  |  					     |
>\============================================================================/


For the ftp site on RFC:

	1. ftp nic.ddn.mil

	2. login with name "anonymous" and password "guest".

	once logged in, make a connection to the correct directory:

	3. cd rfc:
	   and send password "ascii" after you are asked.

	4. It's s good idea to get an introduction and index first:

	   get rfc-index.txt


Or, you can e-mail to SERVICE@NIC.DDN.MIL and indicate the RFC you need
in subject.(e.g. SUBJECT: RFC XXX).


David,

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 00:10:20 GMT
From:      ersys!wmah@nro.cs.athabascau.ca (Wayne Mah)
To:        comp.protocols.tcp-ip
Subject:   Re: Two machine ethernet?

faunt@CISCO.COM (Doug Faunt N6TQS 415-688-8269) writes:

> Yes. It's speced that way. It works.
> 
>    Date:         Fri, 05 Apr 91 13:35:03 EST
>    From: SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
> 
> 
>    Out of curiosity, I have a question regarding 10BASET wiring:
> 
>    Can two PC's with 10BASET cards be wired back to back using a single
>    twisted pair wire (RJ45s) with the transmit and receive pairs swapped
>    via a crossover block -- effectively producing a two machine ethernet?
> 
>    ======================================================================
>    Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
>    Systems Programmer                                 (919) 757 - 6401
>    East Carolina University                          Greenville, NC 27858
>    ======================================================================

I have successly done what you propose.  I have the WD EtherCard Plus
10BaseT card that shows a successful connection by lighting its link
light.

Wayne Mah             ersys!wmah@nro.cs.athabascau.ca
Edmonton Remote Systems:  Serving Northern Alberta since 1982

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 01:13:00 GMT
From:      JRJONES@ALEX.STKATE.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: 10baseT Installation costs

Alan Crawley,

Could you please elaborate on the following, what are 110 or Krone, and
what is the benefit of them over 66 blocks?

> Almost 100% is suitable for ethernet if we change out the 66 blocks 
> for 110 or Krone...plus a few other secrets.
> Alan Crawley
> VP Engineering
> APEX COMMUNICATIONS - MOUNTAIN VIEW CALIFORNIA - 415-967-9200

Having a lot of 66 blocks and thinking about 10baseT, I would like additional
info if possible.

Jim Jones

jrjones@alex.stkate.edu
612-690-6856

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 01:14:05 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10baseT Installation costs

In article <40993@cup.portal.com> amc@cup.portal.com (Alan Michael Crawley) writes:
>10baseT is only cheaper when the net is over 100 users big.  Savings is in
>administration costs.(adds moves and changes) and existing wire savings.

Administration costs depend heavily on circumstances.  If you've got
an abundance of unsophisticated users who will happily unplug things at
random times, bus-based technologies like thinwire are a serious mistake,
and 10baseT is just what the doctor ordered, even for a small net.
-- 
"The stories one hears about putting up | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 are all true."  -D. Harrison|  henry@zoo.toronto.edu  utzoo!henry

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 16:28:58 GMT
From:      km3t@jjmhome.UUCP (Dave Pascoe)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   NCSA Telnet-like program for PC w/ LocalTalk card?


Is there a program like NCSA Telnet for IBM PCs with Apple LocalTalk cards?
We have a PC on LocalTalk bridged to Ethernet with a Fast Path and would like
it to have TCP/IP capability.....

Any help appreciated....
-- 
Dave Pascoe | Internet: km3t@jjmhome.m2c.org  or  dhp1@gte.com
KM3T        | UUCP: km3t@jjmhome.UUCP

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 18:22:57 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson)
To:        comp.protocols.tcp-ip
Subject:   Re: Two machine ethernet?


I have a question about making a two-node ethernet.  I will be getting
an Amiga 3000UX-D (AUI and thinnet) and a Sun 2 w/ only an AUI port.
The machines will be close (within 10 ft, probably within 5 ft).  What
I want to know is if I can someway reliably tie the two machines
together via the AUI ports, excusing me from the cost of a
thinnet-to-AUI transciever.  If the solution costs more than an
AUI-to-thinnet transeiver, then I will just buy the transeiver.

On that note, is there someone out there that would be willing to sell
(cheaply) a transeiver for thinnet?

Please reply via e-mail, I will follow-up if there is intrest.

	Thank's in advance,
	-Chris


--
Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057
 DDN: (CDS6)   INTERNET:  swansonc@acc.stolaf.edu  UUCP: uunet!stolaf!swansonc
  AT&T:		Work: (507)-645-4528			Home: (507)-663-6424
	I would deny this reality, but that wouldn't pay the bills...

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 18:33:29 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson)
To:        comp.protocols.tcp-ip
Subject:   CSlip and PPP w/ compression modems


I will be running either PPP or CSlip (any other suggestions for
compressed IP over serial lines) over a 2400 bps modem link (yuck - I
know, but I am a poor college student)  Using compressed SLIP, will
MNP5 or V42.bis provide additional througput?  If not, what would I be
better running - CSLIP or like product w/ MNP 4 error correction, MNP
5 w/ regular SLIP, or V42.bis w/ regular SLIP?

Please follow-up to me as I do not always get a chance to peruse the
news.

Thank's in advance,
-Chris
--
Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057
 DDN: (CDS6)   INTERNET:  swansonc@acc.stolaf.edu  UUCP: uunet!stolaf!swansonc
  AT&T:		Work: (507)-645-4528			Home: (507)-663-6424
	I would deny this reality, but that wouldn't pay the bills...

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 20:55:32 GMT
From:      maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
To:        comp.protocols.tcp-ip
Subject:   Re: Message compression

In article <obz08jq00WCpE4ddc4@andrew.cmu.edu>, ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes:

) > is that they need to be able to look at the entire data stream before
) > being able to compress any part of it.  In this case, it would be about
) > the same as running compress yourself and then FTPing the resulting file.
) 
) 
) From empirical evidence, I don't believe this is true.

	It isn't.  I've written LZW compression code before, and it is highly stream oriented.  The hash table is created and updated on both ends on the fly, with only one special case.

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Apr 91 20:56:51 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  Message compression

Regarding compressing TCP packets for serial transmission. I've developed an
extension to Jacobsons TCP header compression routines that will compress
the TCP data portion using Splay tree compression. This routine uses
'state trees' with a variable number of trees being assigned to each
active TCP connection (and depending on the major data direction of the stream).

The routine dynamically moves state trees to connections where it does the most
good, and can do so without entirely resetting the trees of existing connections
that gain or lose trees.

For example, I can support 32 state trees in about 32K of memory. This
gives me a 5 to 1 compression on 3278 type datastreams, 3  - 4 to 1 for
standard text.

The advantage of using state trees where two fold: 

	1. Low memory overhead in the kernel
	2. the ability to dynamically reconfigure memory usage
	    (in this case, moving trees between connections as needed)
  	   without having to dump 'all learned patterns' each time.

The routine automatically detects uncompressible data (for ftp's of
already compressed files, for example). etc etc.

Anyway, this is all quite experimental, runs on top of PPP for Sun OS,
and isn't yet available for general consumption (please don't ask for the
code yet).

I know that compressing modems are becoming more prevelant these days, but
this cheap solution gives my 2400 baud modem 5600 baud throughput
(best case). I have not had a chance to compare this method with 
compression of the entire datastream within the modem. However I think
even using splay trees (which are not as effective as adaptive LZW), I get
better compression on serial links which are supporting different TCP
sessions, since the compression state information is tracked by TCP
connection, and the TCP header data (already 'compressed' by VJC) is not
examined during the compression process.

Of course, when packets are dropped, VJ compression gives the splay routines
enough information to have both the compressor and decompressor reset their
trees.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Sr. Network Engineer   Clarkson University              (315)268-2292

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 07:53:48 GMT
From:      neil@pio.gid.co.uk (Neil Todd)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   TCP benchmarking


In the next few months I'm going to be required to benchmark a number of
IP implementations. I would like to identify some readily available
benchmarking packages, further I would like at least one of the packages
to be testing in an "industry standard" way. Any ideas ?

Neil


Neil Todd			| ..In general, it is best to assume that the
PSI%234237100122::neil		| network is filled with malevolent entities
neil@gid.co.uk			| that will send in packets designed to have
Group-ID Ltd			| the worst possible effect...

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 11:34:10 GMT
From:      kevin@msa3b.UUCP (Kevin P. Kleinfelter)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   Re: TCP tunnelled in IBM/SNA (more)

IBM can do this.  We were interested because we have an existing SNA
network, and needed to let two TCP/IP machines communicate over the
existing network.  Trouble is that you have to have a 370 to wrap
the IP packets AND a 370 to unwrap.  We had a 370 on one end of the link,
and would have had to put a 370 on the other end -- too expensive! :-)
-- 
Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347
...gatech!nanovx!msa3b!kevin
Warning: There seem to be multiple 'msa3b' nodes on Usenet, and it is
nanoVX, not nanovAx.

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 14:05:07 GMT
From:      kirchner@informatik.uni-kl.de (Reinhard Kirchner)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   WinQVT problem using NI5210

I have downloaded the packet drivers from sun.soe.clarkson.edu, which allow
to use the WinQVT program with MS Windows 3.0. I have installed all the 
programs and drivers needed and after starting WINQVT from Windows I get the
message "packet class invalid (not supported)". My packet class is 0, using
NI5210 Ethernet card. Can anybody tell me, what I do wrong in the installation.
Do I need some other software to run WinQVT?
 
Thank you

Please answer to the following e-mail address:   ae18@dkauni2.bitnet

Thanks, Michael Neaga

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 14:07:08 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.protocols.tcp-ip
Subject:   Packet drivers for Proteon Pronet-10

Can anyone tell me if packet drivers for Proteon Pro-net 10 boards
exist?  If not, is anyone using NCSA telnet with the Pronet-10 cards,
and how are you doing it?

Thanks,
Jim

-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.cts.com
UUCP:	    nosc!jadpc!jdeitch

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 15:28:34 GMT
From:      jgd@Dixie.Com (John G. DeArmond)
To:        comp.protocols.tcp-ip
Subject:   Ethernet spec. - where to get


I'd like to find out where to order the original Ethernet specification.
NOT 802.3, which I already have, but the original "Green Book" specification.  
Commercial or PD sources are fine.  Please reply by email.

Thanks in advance,
John

-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
jgd@dixie.com                 |"Politically InCorrect.. And damn proud of it  

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 15:38:39 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring ARPs


    The research community has been pushing for all MAC addresses carried
    as data in communication protocols to always be in cannonical format.

I don't think this is the "research community".  Instead, I think it is
primarily commercial companies which "believe" in multi-media "bridges"
instead of "routers".
    
    I'm curious as to if and when this might have an effect on products in
    the marketplace.  I believe there is a large installed base that uses
    the RFC1042 style ARPs where the MAC addresses are in wire order.

The proposal I've seen makes it necessary to supply all new 802.5 IP
software with a "new/old bit order" configuration switch, and upgrade
all existing IP  hosts on your ring before it can be set to "new" on any
of them.  A truly Herculean support hassle, given how much 802.5 is out
there working the old way (IBM, FTP Software, Proteon, cisco, Wellfleet,
3Com, Woolongong etc.).

    Are there any products out there that use cannonical order?

No; I've seen a couple of beta test releases that have reached the field
in ignorance of the true state of the world, but it gets fixed quite quickly
once the vendor understands about the installed base.

    Are there any coming?  Does anyone have any other information?

I don't know of any, barring accidents of the sort I mention above.

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

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 16:45:57 GMT
From:      tono@sm.luth.se (Tomas Nordstr|m)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Information about TCP/IP drivers.

Is there anyone who has written drivers for TCP/IP ?

We would like to get some hints and if possible also some useful
source code. We have a motorola system using the 68030 and the
AM7990-LAN controller.  There is no OS running at the moment, but we
have a locally made realtime Kernel with higher performance that most
of the commercial one. Any code or pointers to code for communication
to/from unix workstations or PC/mac computers using ethernet and
TCP/IP would be appreciated.

Thanks in advance,

Tomas Nordstrom posting news for Martin Jonsson <p89-mjn@sm.luth.se>
Please send any reply to Martin (p89-mjn@sm.luth.se).

PS. Spring time is here, the snow has melted from 1m to 1/2m.
-- 
Tomas Nordstrom  	      	  	Tel:   +46 920 91061
Dept. of Computer Engineering     	Fax:   +46 920 98894
Lulea university of Technology    	Telex: 80447 LUHS
S-95187 Lulea, SWEDEN   	  	Email: tono@sm.luth.se   (internet)

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 17:47:00 GMT
From:      J_ALVAREZ@UPR1.UPR.CLU.EDU (JUNIOR)
To:        comp.protocols.tcp-ip
Subject:   AUTOMATIC COKE MACHINE


I read a mail from Hollings on Wiscosin that have a Automatic Coke machine
activate by Computer, and I want more information about how he,she or they
constructe the hardware and software for this aplication.

.. My name is Jose Alvarez from University of Puerto Rico. We have a Coke,
Juice and Snack Machine and I want information about mechanism that put your
Coke machine activate by Computer... "Or As a Part of the Internate"... 

					Regards.
					Junior..





Any information plse send to: j_alvarez@upr1.upr.clu.edu
or 			      j_alvare@upr2.clu.net

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 18:15:21 GMT
From:      greene@coral.com (Jeremy Greene)
To:        comp.protocols.tcp-ip
Subject:   Token Ring ARPs


) I don't think this is the "research community".  Instead, I think it is
) primarily commercial companies which "believe" in multi-media "bridges"
) instead of "routers".

I agree that, because of ARP, bridges highlight the multi-media problem.
But what about other applications, say for  network management, which
also send MAC addresses in data? A router presents the same problem as
a brigde in this case. It makes a lot of sense to start now in making
sure we do not propagate the mistake made in 1042. Of course, then 1042
implementations would most likely eventually have to be changed... so 
why not now?

Dose 1042 actual say to use wire order? I couldn't find it.

JAG

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 18:21:33 GMT
From:      ELINSKY@YKTVMZ.BITNET ("Jay Elinsky")
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring ARPs

>     Are there any products out there that use cannonical order?
>
> No; I've seen a couple of beta test releases that have reached the field
> in ignorance of the true state of the world, but it gets fixed quite quickly
> once the vendor understands about the installed base.

Actually, Version 2 of IBM's VM and MVS TCP/IP products have the "new/old
bit order configuration switch".  It's the "CANONICAL/NONCANONICAL"
parameter of the LINK statement for network type IBMTR.  The VM manual
mentions it for IBMTR links on LCS devices only, but it applies to ILANS
devices also.  The default is NONCANONICAL, of course.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 19:30:44 GMT
From:      KOEHLER@awiwuw11.wu-wien.ac.at (Wolfi)
To:        comp.protocols.tcp-ip
Subject:   Troubles with BOOTP from FTP

I have troubles using the ethernet generic version of BOOTP from FTP Inc.
Although there are 6 BOOTP Servers responding (definitely right responding),
my PC cant't get its IP address. I have tried all options and
different packet drivers, too. This error is really mysterious, because
sometimes it works, but in 95%, it won't. I am using an IBM P70 with an
3C523 Ethernet card, but had the same problem with an IBM 50Z and
a WD8003E card, too.
Please write, if someone has had similar problems, and if a workable
solution is possible.

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 21:22:31 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring ARPs


    But what about other applications, say for  network management, which
    also send MAC addresses in data? A router presents the same problem as
    a brigde in this case.

If an arbitrary protocol obtains a MAC address in a local LAN context, and
can restrain itself from using the MAC address outside that LAN's context,
there is no problem.  Bit order doesn't matter if you treat the address as
opaque.  Because not all MAC addresses conform to IEEE 48 bit formats, you
need to know the LAN's physical layer to parse them anyway.  Canonical bit
order on all 802.2 LANs would make the parser a little simpler...

    ... It makes a lot of sense to start now in making
    sure we do not propagate the mistake made in 1042. Of course, then 1042
    implementations would most likely eventually have to be changed... so 
    why not now?

As of the moment, neither of the two widely distributed 802.5 driver specs
(IBM's ASI and 3Com/Microsoft NDIS between them represent 95% of the IBM PC
802.5 interfaces, and probably 90% of the total 802.5 installed base) even
have hooks in them to indicate which bit order the MAC address is presented
in.  Many of the ASI drivers are at least partly in ROM.  So, first you need
to upgrade the specs, then all software drivers that were shipped with the
boards, and maybe the ROMs.  It'll be a while.
    
    Dose 1042 actual say to use wire order? I couldn't find it.

It doesn't say.  However, IBM chose the order returned by their TOKREUI
program, and everyone else followed suit.

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

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 22:10:38 GMT
From:      obrien@Aero.org (Michael O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Oddball devices on the Internet

This thread about fingering Coke machines (I was previously only aware
of the installation at SAIL) has me fascinated.  Hence, I'll proceed to
collect entries in the form of answers to the following question:

What other oddball devices have been hooked to the net?

Ideally, entries should not be scientific instrumentation (unless it's
a real Dr. Wacko production), but more common things - such as the
reputed front door buzzer at the Tech Square building at MIT, where one
could supposedly press control-shift-meta-cokebottle-P (this was on an
ITS machine, after all) to open the front door, no matter what
application you were in.

I'll summarize the best responses.  Warning: I may also publish entries
in my column "Ask Mr. Protocol" in Sun Expert, unless requested not to
by the author.  Credit will be given, of course.
--
Mike O'Brien
obrien@aerospace.aero.org

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 22:18:45 GMT
From:      greene@coral.com (Jeremy Greene)
To:        comp.protocols.tcp-ip
Subject:   Token Ring ARPs


)     But what about other applications, say for  network management, which
)     also send MAC addresses in data? A router presents the same problem as
)     a brigde in this case.
) 
) If an arbitrary protocol obtains a MAC address in a local LAN context, and
) can restrain itself from using the MAC address outside that LAN's context,
) there is no problem.  Bit order doesn't matter if you treat the address as
) opaque.  Because not all MAC addresses conform to IEEE 48 bit formats, you
) need to know the LAN's physical layer to parse them anyway.  Canonical bit
) order on all 802.2 LANs would make the parser a little simpler...
) 

You were talking about sending mac addresses accross multi-media. I was
pointing out that the problem is with ANY mac address in data, not just
macs in ARP responses. For macs in data other than ARPs, multi-media
routers cause the same problem that bridges do.

You brought up another valid issue: how does an application which
runs on various media know what the address format is. The right
answer is that it always expects it in one format. I'm not sure
what you mean by opaque, the point is that the application wants
to see the data.


) As of the moment, neither of the two widely distributed 802.5 driver specs
) (IBM's ASI and 3Com/Microsoft NDIS between them represent 95% of the IBM PC
) 802.5 interfaces, and probably 90% of the total 802.5 installed base) even
) have hooks in them to indicate which bit order the MAC address is presented
) in. Many of the ASI drivers are at least partly in ROM.  So, first you need
) to upgrade the specs, then all software drivers that were shipped with the
) boards, and maybe the ROMs.  It'll be a while.

Is it really that bad? You mean there are 802.5 cards/drivers which
actually return a canonical format address? I find that hard to believe.
It would certainly be nice to have the driver hook, but I think the 
client of the driver could know the format based on the interface
type.

JAG

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Apr 91 23:40:19 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: TCP benchmarking


I've encountered another "benchmark."

First try the 4.3BSD `ping -l9999999 target` and look at the packet rate.
There are commercially available UNIX workstations that will deliver the
vast majority of the zillion 98-byte ether packets separated by only 9.6
microseconds.  The point is I think there are several vendors'
workstatsions that can write at or close to ethernet media speed, <<from a
user process>>.

Second, modify the more recent 4.3BSD-tahoe or reno ping.c to flush the "."
and "\b" characters only occassionally or when things get slow, so that
`ping -f` does not spend most of its time fiddling with stdio.  Then make
`ping -f` compute a packet/sec rate to be displayed at the end.  This
produces nice numbers that seem to vary depending on the speed of the
machines on both ends.

Neither of these are very interesting benchmarks; they're just fun.  Ttcp
is better for TCP or UDP, and FTP for overall file system and network speed.


Vernon Schryver,  vjs@sgi.com

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 02:00:48 GMT
From:      rvg@artemis.cs.wayne.edu (Rahul Vijay Garg)
To:        comp.graphics,comp.windows.x,comp.windows.open-look,alt.sources,alt.sources.wanted,comp.protocols.tcp-ip
Subject:   Graphical TCP/IP Manager

Hi Netters,

I am looking for some kind of a graphical Network Manager which 
could monitor and display a distributed systems application
(using TCP/IP) on an X interface.
Any pointers to something similar also would be of great help.

Thanks.

--
-rahul 
(rvg@cs.wayne.edu)

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 03:39:19 GMT
From:      hliu@UCSD.EDU (Hai-Ning Liu)
To:        comp.protocols.tcp-ip
Subject:   (none)

please delete my name!!!!

hliu@ucsd.edu liu@cs.ucsd.edu

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 14:46:47 GMT
From:      pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE)
To:        comp.protocols.tcp-ip
Subject:   NCSA and Tek 4014


I ask this question for a friend who cannot read this list.

He is trying to use NCSA telnet to do remote Tektronix  emulation.
However, it seems that the emulation is not complete, for exemple
the Grapical Cursor is not visible, which makes it very difficult
to use interactive tools. This happens both on NCSA for PC and Mac.

Is he doing something wrong, or is GIN an unimplemneted feature?

In the last case, are there any (preferably freeware...) package doing
full Tek 4014 ?

thanks a lot

Please respond to me. I will summarize if there is interest.

Jean-Jacques Pansiot,  Universite Louis Pasteur, Strasbourg, FRANCE
7, rue Descartes  67084 STRASBOURG CEDEX FRANCE
Email: pansiot@isis.u-strasbg.fr
Tel:  (33) 88 41 64 28
Fax:  (33) 88 61 90 69

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 16:44:03 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet drivers for Proteon Pronet-10

As far as I know, there never have been any implementations of Class 2
(Proteon ProNET-10 token ring) Packet Drivers.  PC-IP has a linked-in
driver for the P1300 interface, so do some of the commercial products.
Proteon has an non-board-independent interface-sharing spec, which
they've implemented in their Netware and we in our PC-222 part.

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 18:01:11 GMT
From:      dcm@baldur.dell.com (Dave McCracken)
To:        comp.protocols.tcp-ip
Subject:   How to set up subnets where logical subnet != physical subnet

I am trying to solve a problem we are having trying to set up a
subnet in our corporate network.

The current environment is an ethernet with MAC-layer bridges
between all subnets, which are necessary because we need to support
IP, Netware IPX, and 3com 3+share packets.

What we would like to do is split off the Unix development group
as an IP-only subnet, with the rest of the network as the other subnet.
What we would end up with is a small subnet with 30-40 machines
connected to a large subnet with 500-800 machines, of which probably
100-300 will use IP at least some of the time.

Our IP address numbering scheme is a class B network address, and
we would like to run with a 6-8 bit subnet mask.  We have already
assigned subnet numbers based on department for administrative reasons.

The real problem is when I try to set up a router for this arrangement.
Since most of the network is being routed by a layer below IP, it 
is necessary for several logical subnets, based on the subnet
mask, to be on the same physical network.  The routing code in the IP
driver will cheerfully accept that the other subnets are local when
I specify 0 hops to the route command, but it absolutely refuses
to let me specify an IP address for the router that is not in the
same logical subnet.  We are currently running mostly System V Release 4,
but the same problem exists on our Suns and in the straight BSD4.3
code (I looked in the source).

What I would like to know from the collected wisdom of Usenet is
why the restriction is there, and if you think anything would break
if I changed the IP driver in SVR4 to accept a router address outside
the subnet.  I would also like to know is there is a simple way in the
router to present miltiple IP addresses without plugging in extra
network cards.  This would be an alternate solution that would not
require changing all clients.

Thanks,

--
Dave McCracken      dcm@dell.dell.com      (512) 343-3720
Dell Computer       9505 Arboretum Blvd    Austin, TX 78759-7299

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 21:44:05 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

In article <1991Apr6.011139.1572@netcom.COM> cmilono@netcom.COM (Carlo Milono) writes:
>
>
>
>and their product is standard.  Secondly, it is a misnomer to use the RJ45
>name for an 8-pin jack - the correct terminology is the ISO 8877 jack.  The
							 ^^^^^^^^
OK, got it... All I knew was RJ45, but in keeping with my good intentions
toward solid international standards in technical communication, the above
use is noted, and adopted.
>
>Lastly, you can run your 10BASE-T on household 'quad' wire and get an
>appropriate cord (twisted preferably) to splay the four wires into the
>10BASE-T standard spacing within the ISO jack.  I have several locations
>where the only wire available was a six-conductor wire split between two
>four-wire jacks - the first being a true RJ11.  Works fine.
					  ^^^^
Huh? Now I feel ripped off. I learned "8-pin RJ45" = ISO 8877, but what is
the ISO number for RJ11? Why wasn't it used here? I be confuse.

>+--------------------------------------------------------------------------+
>|  Carlo Milono:  cmilono@netcom.apple.com   or   apple!netcom!cmilono     |
>|"When a true genius appears in the world, you may know him by this sign,  |
>|that the dunces are all in confederacy against him."   - Jonathan Swift   |
>+--------------------------------------------------------------------------+
 
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Minneapolis, MN 55416-1528
(612) 525-0000			Practicing the OSI Standard

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 22:39:24 GMT
From:      les@GANG-OF-FOUR.STANFORD.EDU (Les Earnest)
To:        comp.protocols.tcp-ip
Subject:   finger weather (really Coke machines)

>> As far as I know nothing similar has been done elsewhere, so CMU can
>> legitimately boast of having the only Coke machine on the Internet.
>
>  Here at the University of Wisconsin we were *FORCED* to computerize our Coke
>  machine a year ago (or they would take it away).
 .  .  .
>  The coke machine was also modified so
>  that it would NOT take money and could only be activated from the computer.
>  So I guess Wisconsin can claim the only Coke machine that can be controlled
>  via the Internet.

A vending machine was connected to the SAIL computer at Stanford
around 1973, which I believe was much earlier than any other computer-
controlled vending machine.  It sold snacks, soft drinks, and beer.
Everything could be purchased for cash or credit except the beer,
which could only be bought on credit and then only if the buyer was
over 21.  Any attempt by an underage person to buy beer elicited the
error message "Sorry, kid."

The national wire services ran a story on this machine at the time and
some representatives of one of the major vending machine manufacturers
came to see if they could turn it into a product.  They were
apparently deterred by the fact that they didn't understand diddly
about computers.  They also were put off by the fact that the computer
being used for this modest task (a large DEC 10) cost about $1 million.

SAIL was one of the earliest systems on ARPAnet and, for no good
reason, has been recording both its machine room temperature and the
outside air temperature at 10 minute intervals for the last 20 years.
SAIL and its vending machine are still in use today at the Computer
Science Department at Stanford, but they will soon part company --
SAIL is scheduled to die on June 6, its 25th birthday.  It has lived
a rather full life as computers go.

	-Les Earnest (Les@SAIL.Stanford.edu)

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 22:43:33 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

Well, the boss put the kaibosh on the 10baseT soliloquy, so all I can do is
comment on what you folks are talking about. No paper. Something about
having to make money and selling information being our business, and all
that. I suppose I can say a few things though.

10baseT is easier to install, requires less experience to connectorize, and
is more fault tolerant than coax. It is not, as far as we can tell, being
hyped by the box builders to generate sales, since we see a legitimate
application for it.

If you are going to do-it-yourself, make sure you are using cable that is
really rated for 10baseT. I have seen so many wierdo cable type from
non-descript manufacturers that does no do the job. This cheap stuff is
exactly what the cable vendor and your boss with the checkbook are going to
choose for you, so be ready with information. Don't even settle for a
written guarantee from the cable vendor that it's good wire, since such a
guarantee can rarely cover all the trouble and downtime necessary to
replace bad cable.

Don't go over spec. You need a certain number of twists per foot, and you
can't run it further than 100 meters, so stick with it. Fudge, and you pay
the price, or more specifically, you pay people like me to come fix it.

Cards? We have had trouble with a certain vendor's card. My advice is: It's
still early in the game. A few vendors still have cards that don't cut it.
Get an in house demonstration from the vendor. They'll do it for free, if
they think you're going to buy some cards. Run some data back and forth
across them (a process I call flossing), and see if they work okay. The
same goes for hubs. Usually a vendor will let you have a demo unit for a
week. For PCs, you can use a 3c503 card with a small 10baseT transceiver
plugged into the AUI port, and it runs just fine. 10baseT transceivers are
getting smaller and cheaper. We have some that are about the size of a
deck of playing cards cut in half. They're great.

Be careful of EMI. About all I can say is that it gets into 10baseT more
than the other cable types. It comes from some interesting places, many of
which are common in an office environment.

Test equipment? Yes. Use a pair tester. Use a cable scanner. That's about
all I can say about that.

Want some philosophy? 10baseT, ThinNet, ThickNet, and Fiber are all here to
stay. They all have their applications, and none can completely replace any
of the others. Add 10baseT to you list of solutions to apply. Networking is
growing as we speak. There is a lot of work and discovery and development
out there waiting to happen. I started out in Software Engineering, but now
I have made the switch to networking, and I travel all seven layers of the
OSI stack. I love it.

Have fun ...

-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Minneapolis, MN 55416-1528
(612) 525-0000			Practicing the OSI Standard

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      9 Apr 91 23:50:08 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather

>The RFC for finger specifies fingers behavior when applied to coke
>machines. It is my understanding that CMU used to have a coke machine
>on the internet that followed the stated behavior, although this may
>be an urban legend.

Well, the specified behavior is:

  2.5.5.  Vending machines

     Vending machines SHOULD respond to a {C} request with a list of all
     items currently available for purchase and possible consumption.
     Vending machines SHOULD respond to a {U}{C} request with a detailed
     count or list of the particular product or product slot.  Vending
     machines should NEVER NEVER EVER eat requests.  Or money.
	       
When last I tried fingering CMU's Coke machine, several years ago, it
did report the status of the Cokes - or, at least, what I received back
was a report that purported to be the status of the Cokes in the
machine.  I don't know if that was a *real* status report or not; I also
don't know if the machine in question ever ate money.

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 02:17:52 GMT
From:      kmcmilla@ub.d.umn.edu (Ken McMillan)
To:        comp.protocols.tcp-ip
Subject:   Network Sniffer questions...

Has anyone got any quick pointers for a soon to be novice Network
Sniffer user? We have acquired a Sniffer and have it connected to our
Ethernet, yet I haven't had time to read through the manuals yet. Is it
possible to monitor the traffic between two bridge boxes, or say a router
and a bridge box, or a list of boxes on a specific network segment? 

Any hints appreciated.

Ken McMillan
kmcmilla@ub.d.umn.edu

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 04:00:47 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: 'legal' protocol behavior (was: ARP question summary)

>The intent of my reply was to emphasise the importance of standard
>practice over RFC definition as a guide for implementors decisions
>as to what is 'legal'.  As with the MILSTDs (which are absolutely
>and completely correct except when they are wrong), an RFC should
>not be strictly followed by an implementor if this causes most
>existing hosts to lose.

I'll stand by my comments - in general, the RFCs ought to be the
definition.  Certainly there needs to be room to correct errors,
resolve ambiguities, extend protocols, and, in some cases, to make
allowance for an implementation error in a common implementation,
but such deviations ought to be strictly those that have been accepted
in the appropriate public forum (IETF, a mailing list, or whatever),
and ought to appear in the next revision of the spec.  The problems
with the MILSTDs have been well documented, as have other RFC errors
(such as those documented in the host requirements RFCs, for example).

I'm not willing to define "standard practice" as the way the first or
the most prevalent implementation does it, without some good justification
to go along with it.

And I'm not sure why we're dragging out this discussion, since the RFC
and "standard practice" are not in disagreement over the case in point! :->

Doug

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 04:13:05 GMT
From:      n8844062@unicorn.cc.wwu.edu (mizoguchi scott d)
To:        comp.protocols.tcp-ip
Subject:   SLIP???

I've heard some interesting things about SLIPs but don't know
how they work or how to install one. Can anyone enlighten me???

Thanks...
Scott Mizoguchi

n8844062@unicorn.cc.wwu.edu
n8844062@henson.cc.wwu.edu

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 05:39:06 GMT
From:      sgs@rand.mel.cocam.oz.au (Stuart Szabo)
To:        comp.protocols.tcp-ip,alt.sources.wanted,comp.sources.wanted
Subject:   LPD for Sys V

Anyone know of a public domain lpd for System V ?
I already have the 'lprclient' which was gratefully supplied by
cayman.com,  but still need something to act as the daemon 
on the other end.


		Thanks,


-- 
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-
Snail:	   Co-Cam Computer Services              |  sgs@rand.mel.cocam.oz.au 
           Abbotsford, VIC 3067                  |  +61 3 412-3411 (voice)      
	   Melbourne,  Australia                 |  +61 3 417-7857 (fax) 

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 06:37:16 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: How to set up subnets where logical subnet != physical subnet

In article <dcm.671220071@baldur.dell.com> dcm@baldur.dell.com (Dave McCracken) writes:
>I am trying to solve a problem we are having trying to set up a
>subnet in our corporate network.
>
>
 [ Description of their corporate network with MAC-layer bridges and
   multiple IP subnets on the same wire delted. ]
	

>is necessary for several logical subnets, based on the subnet
>mask, to be on the same physical network.  The routing code in the IP
>driver will cheerfully accept that the other subnets are local when
>I specify 0 hops to the route command, but it absolutely refuses
>to let me specify an IP address for the router that is not in the
>same logical subnet.  We are currently running mostly System V Release 4,
>but the same problem exists on our Suns and in the straight BSD4.3
>code (I looked in the source).

Let us be specific. Assume your campus network is 182.95 (nice unused
Class-B network), and that "subnets" 182.95.20, 182.95.21 and
182.95.22 are all on the same wire.

Your hostname is host-20-19 and its address is 182.95.20.19.
Your ethernet inteface has been configured as

# ifconfig le0 182.95.20.19 up netmask 255.255.255.0 -trailers

Your routing table looks something like:

# netstat -r -n
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
182.95.20            182.95.20.19         U        0      5          le0

Now, in order to access machines on the subnets .21. and .22., you add
static routes like this:

# route add net 182.95.21 182.95.20.19 0
# route add net 182.95.22 182.95.20.19 0

So that your routing table now looks like:

# netstat -r -n
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       0      0          lo0
182.95.20            182.95.20.19         U        0      5          le0
182.95.21            182.95.20.19         U        0      0          le0
182.95.22            182.95.20.19         U        0      0          le0

Now, for reasons that I'd rather not know (!), there exists a router
(call it router-21-1, address 182.95.21.1) to some other net(s), that
you want to use from subnets .20. and .22.. Evidently, you cannot say

# route add default 182.95.21.1 1 

on host-20-19; the route command will say (and with good reason):

add net default: gateway 182.95.21.1: Network is unreachable

>
>What I would like to know from the collected wisdom of Usenet is
>why the restriction is there, and if you think anything would break
>if I changed the IP driver in SVR4 to accept a router address outside

The "restriction" is there because of the way routes are set up with
SIOCADDRT. For gatewaying through another machine (metric > 0), the
code checks whether that gateway is on the same subnet as yourself. If
it is not, it gives you a "network is unreachable" error.

Conceivably, you may want to check whether the subnet of the gateway
you are trying to route through already has a route through yourself
(which is your case), and thus allow the addition of routes to
machines not on your subnet but still on the same physical network.
There is no reason this should create any problems, unless someone
deletes those static routes.

Of course, the whole reason for these network gymnastics is that you
need the *ethernet* address of a gateway to send the packets through.
The gateway may be on the same wire as you are (so you can send it the
packets), but the routing code will not allow you to add it.

Instead, you can fool your code into thinking it's using a gateway on
its subnet in the following (hacky) way: Assign a dummy IP address on
sunet 20 to your router and a machine on the same physical to
proxy-arp for it: We've already said that your router is 182.95.21.1.
Now, reserve the address 182.95.20.254 for it. On some machine on the
wire, add the following ARP entry:

# arp -s 182.95.20.254 <router-21-1's ethernet address>

and on all machines on subnet .20. add the routing entry:

# route add default 182.95.20.254 1

On router-21-1, add the following static routes:

# route add net 182.95.20 182.95.21.1 0
# route add net 182.95.22 182.95.21.1 0

Now, every time you want to send something out that would have to go
through router-21-1, host-20-19 will arp for 182.95.20.254. The
machine with the static ARP entry will respond with .21.1's ethernet
address, and your host will send the IP packet to that ethernet
address. Now, the router does not care what the source is; it only
cares what the destination is. Upon receipt of a packet, if it can
route the packet, it will do so. So this takes care of routing packets
out. The static routes we set up on router-21-1 will take care of
routing packets back to hosts on .20. and .22. 

>the subnet.  I would also like to know is there is a simple way in the
>router to present miltiple IP addresses without plugging in extra
>network cards.  This would be an alternate solution that would not

CISCOs can do that. On BSD-derived Unixes, although there is a linked
list of addresses for each interface, there are no ioctl's that will
allow you to bind multiple addresses to an interface. The ifnet
structure has a pointer to a linked list of addresses for the
interface, but I suspect that too much code just assumes that there is
only one address per interface. I haven't looked at the multicast code
lately, but I don't think it uses the linked list of addresses;
someone please correct me if I'm wrong (I hope I am; I'll be needing
the ability to have the same interface have multiple addresses very soon!)


>require changing all clients.
>
>Thanks,
>
>--
>Dave McCracken      dcm@dell.dell.com      (512) 343-3720
>Dell Computer       9505 Arboretum Blvd    Austin, TX 78759-7299

Hope this helps

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 12:50:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: Graphical TCP/IP Manager

>I am looking for some kind of a graphical Network Manager which 
>could monitor and display a distributed systems application
>(using TCP/IP) on an X interface.
>Any pointers to something similar also would be of great help.

Sorry if I sound like a broken record, but take a look at RFC 1147, "FYI on a
Network Management Tool Catalog."   Look up Dual Manager, snmpxbar, snmpxconn,
snmpxperfmon, snmpxrtmetric, WIN/MGT Station, and xnetperfmon.

Hope this helps.

Bob Stine
bstine@MCIMail.com

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 13:19:18 GMT
From:      hal@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   whereis service needed


Here the issue:

I am seeing fully qualified domain names with parts I don't recognize.
Not that these are wrong but just unfamilar. It would be useful to
have access to a server of some kind that would map fragements of a
domain name into an geographical location by political subdivision.
This might be a useful extension to the current domain names system.
Any thoughts??

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 13:23:00 GMT
From:      axw@RELAY.PROTEON.COM
To:        comp.protocols.tcp-ip
Subject:   Public domain software


          Has anyone compiled a list of public domain routing
          software?  I'm interested in making a list of what protocols
          are available for what OS (in source form), and even a list
          of PD binary packages.

          Please reply to me and I'll repost results.

          Asher Waldfogel
          axw@proteon.com

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 15:25:22 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU
To:        comp.protocols.tcp-ip
Subject:   KA9Q SMTP Config problem

I'm trying to get SMTP in KA9Q to work, but without success.
I can FTP in using the id in /ftpusers, but SMTP sends back:

452 Temp file write error

After issuing a SMTP '.' to close the message.   Can anyone offer advice?

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 15:33:36 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP???

In article <1991Apr10.041305.12068@unicorn.cc.wwu.edu>, n8844062@unicorn.cc.wwu.edu (mizoguchi scott d) writes...
#I've heard some interesting things about SLIPs but don't know
#how they work or how to install one. Can anyone enlighten me???

	The way slips work is that they stay underneath the
	dresses and prevent... oh, you mean SLIP (singular) :-)
	
	SLIP (Serial Line IP) uses a serial communication line
	(RS232, 433, etc...) as the physical path over which IP
	traffic works.  It's usually implemented at driver level,
	much as the ETHERNET driver is.  IP over serial lines is
	for all practical purposes (except bandwidth and throughput)
	identical to IP over any other medium.

	Catch me via email for further info...
# 
#Thanks...
#Scott Mizoguchi
# 
#n8844062@unicorn.cc.wwu.edu
#n8844062@henson.cc.wwu.edu

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 15:37:56 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

In article <9104090339.AA07649@beowulf.ucsd.edu>, hliu@UCSD.EDU (Hai-Ning Liu)
writes...

#please delete my name!!!!

	Your name has been deleted, and you no longer exist.

	thanks,

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 16:07:57 GMT
From:      jj@dcs.leeds.ac.uk (J Jackson)
To:        comp.protocols.tcp-ip
Subject:   Wanted: /etc/hosts to DNS (rfc1035) format conversion program


Has anybody an off-the-shelf script of program that will read an 
/etc/hosts file and create the database fileformat required by the
named daemon?

cheers
=======================================================================
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.

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 16:19:48 GMT
From:      jj@dcs.leeds.ac.uk (J Jackson)
To:        comp.protocols.tcp-ip
Subject:   SYS V version of SUN's pcnfsd



We require a SYS V version of SUN's pcnfsd (the authentication
and print server daemon). Can anybody point us to a source?

cheers
=======================================================================
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.

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 17:21:04 GMT
From:      raj@hpindwa.cup.hp.com (Rick Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP tunnelled in IBM/SNA (more)


I believe that there are several solutions for TCP/IP over/under/in
SNA. At the last Interop, I seem to recall hearing something about
cisco's being able to tunnel IP thru SNA (or perhaps real soon
then...;-) 

Also, the HP MPE/XL systems offer a link type for their TCP/IP that puts
TCP/IP over an SNA backbone. It might be able to do what you are
looking for.

I'm sure that your local HP and/or cisco rep people could go on and on
about these things ;-)

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

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 17:27:56 GMT
From:      randall@Virginia.EDU (Randall Atkinson)
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   Re: universality of Latin-1


John Gilmore originally wrote:
% And my windows all use ISO Latin 1.  If Torbj|rn would send the
% umlauted letter in that standardized character set, it would look right
% in both the States and in Sweden.

In article <1110@sranha.sra.co.jp>, 
	Erik M. van der Poel <erik@srava.sra.co.jp> responded:

>Have you ever tried to send yourself a message in Latin-1? Did it
>work? And even if *you* have a reasonable version of sendmail (one
>that doesn't strip the 8th bit), what makes you so certain that
>Torbj|rn's message and anyone else's won't pass through a site that
>*does* strip the 8th bit?

It does work for a fair and ever increasing subset of the Internet.
BITNET doesn't do very well with it.  Clearly we need to move towards
8-bit and 16-bit and 32-bit transparent mail transport mechanisms.
Fortunately there are a number of possible transport mechanisms out
there to choose from, some of which are already 8-bit transparent.

>Also, what's so "standardized" about ISO Latin-1? What makes it more
>standard than, say, Latin-2?

ISO 8859/1 is NOT any "more standard" than ISO 8859/2, however sites
in the US are in fact migrating towards ISO 8859/1 from US ASCII and
most sites in the US are NOT migrating towards ISO 8859/2 (though they
might support it on the side as vendors begin to).  The languages that
are most commonly used in the US are in ISO 8859/1 and the languages
supported by ISO 8859/2 are less commonly used (again in the US as a
whole).  

Note that ISO Latin-1 is ISO 8859/1 which is the 8-bit character set
used for Western European languages.  ISO Latin-2 is ISO 8859/2 which
is the 8-bit character set for Eastern European languages.

Clearly we need to add additional information to the header of mail 
messages to indicate which character set to use.  I'm not sure of
the current state of the Internet protocols (RFC 822 et. al.) with
respect to this.  If there isn't the equivalent of a "Character-set:"
header yet, serious consideration should be given to adding one with
clearly defined values for at least existing ANSI and ISO character
sets.

Character sets that should have a defined string to use with such a
header field include at least:
	ASCII
	ISO 8859/1 
          ...
        ISO 8859/N  (where N is the last defined set)
        ISO 10646   (once it gets completed)

The Internet is the dominant mail transport network at present, partly
because so many other networks gateway with it.  Getting the Internet
to convert to supporting such needs would be a big step in the right
direction.  Perhaps someone on the IETF can comment on their current
activities in this area ??

Ran Atkinson
randall@Virginia.EDU

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 18:09:56 GMT
From:      benny@vlss.amdahl.com (Benny Schnaider)
To:        comp.protocols.tcp-ip
Subject:   Internet broadcast: INADDR_BROADCAST

Hi,

I am trying to broadcast a message over the internet by using the
INADDR_BROADCAST shorthand notation. I tried this on SunOS 4.01
and got: Network is unreachable... On other system that I tried
the same code it worked.
Code is enclosed.

1. What is the problem ?
2. How common is it to use INADDR_BROADCAST ?

Thanks,
Benny.

____________________________________________________________________________

  int sd, on;
  struct sockaddr_in sockAddr;

  /*
   * zero out the socket structures
   */
  bzero(&sockAddr, sizeof(sockAddr));

  /*
   * Open the socket
   */
  if ((sd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
    close(sd);
    BPCerror(LOG_WARNING, "in socket creation (request)");
    return(ERROR);
  }
 
  /*
   * Mark the socket to allow broadcast.
   */
  on = 1;
  if ((setsockopt(sd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on))) == -1) {
    close(sd);
    BPCerror(LOG_WARNING, "in SO_BROADCAST");
    return(ERROR);
  }

  /*
   * Fill sockAddrAs
   */
  sockAddr.sin_family       = AF_INET;
  sockAddr.sin_port         = IPPORT_BOOTPS;
  sockAddr.sin_addr.s_addr  = INADDR_ANY;

  /*
   * Bind the socket
   */
  if (bind(sd, &sockAddr, sizeof(sockAddr)) == -1) {
    close(sd);
    BPCerror(LOG_WARNING, "in socket binding (request)");
    return(ERROR);
  }

  /*
   * Broadcast the request
   */
  sockAddr.sin_addr.s_addr  = INADDR_BROADCAST;
  if (sendto(sd, msg, sizeof(*msg), 0, &sockAddr, sizeof(sockAddr)) == -1) {
    close(sd);
    BPCerror(LOG_WARNING, "sendto");
    return(ERROR);
  } /* sendto */

  close(sd);
  return(OK);

} /* BPCrequestIP() */

-----------------------------------------------------------------
Benny Schnaider    benny@vlss.amdahl.com
                   Amdahl Corporation, 1250 EAST Arques Avenue,
                   M/S 246, Sunnyvale CA, 94088-3470
                   (408) 296 - 0596, (408) 746-3440
-----------------------------------------------------------------
--
-----------------------------------------------------------------
Benny Schnaider    benny@vlss.amdahl.com
                   Amdahl Corporation, 1250 EAST Arques Avenue,
                   M/S 246, Sunnyvale CA, 94088-3470
                   (408) 296 - 0596, (408) 746-3440
-----------------------------------------------------------------

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 19:04:29 GMT
From:      gordon@FTP.COM (Gordon Lee)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet spec. - where to get

>From: ogicse!emory!dixie.com!jgd@decwrl.dec.com  (John G. DeArmond)
>Subject: Ethernet spec. - where to get
>   
>I'd like to find out where to order the original Ethernet specification.
>NOT 802.3, which I already have, but the original "Green Book" specification.
>Commercial or PD sources are fine.  Please reply by email.
    
Green ?  Don't you mean Blue Book ?  As in DIX (DecIntelXerox) ethernet ?  

contact:   Fonda Lix Pallone
	   Xerox Systems Institute
	   475 Oakmead Parkway
	   Sunnyvale, CA  94086
	   (408) 737-4652

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

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 19:26:52 GMT
From:      liu@cornelius.ucsd.edu (Hai-Ning Liu)
To:        comp.protocols.tcp-ip
Subject:   Sorry, but here is the story

I sincerely apologize to those who feel being annoyed by
my multiple deleting-from-mailing-list requests.

The story is the following:
I sent to tcp-ip-request some time ago and asked to add my name
on it. It was added the second day.
Later on, I found I can read those message in the mailing
list from Usenet comp.protocols.tcp-ip and I do not like to 
handle all those emails.
So I sent requests to tcp-ip-request and asked them
to delete me.

Day by day, I kept receiving them and yes,
I kept asking tcp-ip-request to delete my name.
No answer. I did not know what was going on.
I felt being ignored.  I asked people around also. 
Some of them suggested I should sent to tcp-ip-relay.
I did sent only one copy it to tcp-ip.
However, I did not see it back. 
( I just found out our postmaster@ucsd deleted that message.)
So I thought tcp-ip was monitored. 
Finally, I was out patient and mailed multiple copies to the net
under the above assumption.

Again, please accept my humble apology.
Also, if you want to delete your name from the list
in the future, you may have to wait for very long
time after sending email to tcp-ip-request.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 20:21:48 GMT
From:      rickt@wybbs.mi.org (Rick Tucker )
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 under SCO Unix

In article <31719@usc> mcitron@phad.hsc.usc.edu (Mark Citron) writes:
>I post this several months ago and got no reponses but it is so important
>for us I figured it is worth another try. 
>
>Does anyone have a 3270 emulator that runs under SCO Unix (we already have
>tcp/ip)? We have a critical need and would even consider paying for
>a port to SCO Unix. We need to communicate with a remote IBM mainframe
>via ethernet-tcp/ip (no other protocols or media). Any help or suggestions 
>would be greatly appreciated.
>-- 
>Mark Citron
>mark@neurosci.usc.edu

Have you tried Cleo 3270?
They can be reached at 800-233-2536 (some areas)
			313-662-2002
Ask for Teresa Rupert.
I have used Cleo 3270 in the past and have found it to be a pretty good
product.  Teresea stated to me that they do have a way to utilize
a tcp/ip/ethernet connection.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 21:15:02 GMT
From:      jcrowder@GroupW.cns.vt.edu (Jeff Crowder)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10BaseT installation

In article <1991Apr9.224333.13034@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes:
>stay. They all have their applications, and none can completely replace any
>of the others. Add 10baseT to you list of solutions to apply. Networking is


And THAT'S the Truth...
Forget the rest of the rubbish.  Andrew has it right.

Jeff Crowder

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 21:54:12 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring ARPs


    You brought up another valid issue: how does an application which
    runs on various media know what the address format is. The right
    answer is that it always expects it in one format. I'm not sure
    what you mean by opaque, the point is that the application wants
    to see the data.

By 'opaque' I mean "uninterpretable, monolithic".  The less applications
have to know about the detailed format of addresses (IP or MAC), the better.
Arbitrary MAC addresses can't be parsed without the context of what sort
of LAN they originated on, so applications that need to know e.g. whether
a specific packet was broadcast or multicast have to have tables of LAN
address formats in any case.
    
    ....
    It would certainly be nice to have the driver hook, but I think the 
    client of the driver could know the format based on the interface type.

If you're going to be passing MAC addresses around at all, even if you
don't parse them, you *really* need to be uniform across all protocols.
Otherwise you'll be in real trouble if a node supports two protocol
stacks, one which canonicalizes the bit order and the other which doesn't,
and you only have a management tool for one stack.  Thus, everyone I've
discussed the issues with to date assumes that the ASI or NDIS drivers
would have to canonicalize the bit order presented at their API in order
to implement this change.

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

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 Apr 91 22:14:37 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  whereis service needed


 > From tcp-ip-RELAY@nic.ddn.mil Wed Apr 10 18:08:51 1991
 > From: hal@gateway.mitre.org
 > To: tcp-ip@nic.ddn.mil
 > Subject: whereis service needed
 > 
 > 
 > Here the issue:
 > 
 > I am seeing fully qualified domain names with parts I don't recognize.
 > Not that these are wrong but just unfamilar. It would be useful to
 > have access to a server of some kind that would map fragements of a
 > domain name into an geographical location by political subdivision.
 > This might be a useful extension to the current domain names system.
 > Any thoughts??
 > 

WHOIS does a reasonably adequate job of starting one on
one's way -- for domains that are registered at the NIC.

Here is the output when I "whois" my domain......

europa{kasten}147: whois clearpoint.com
Clearpoint Corporation (CLEARPOINT-DOM)
   35 Parkwood Drive
   Hopkingon, MA 01748

   Domain Name: CLEARPOINT.COM

   Administrative Contact:
      O'Conner, Russell  (RO88)  russ@CLEARPOINT.COM
      (508) 435-0900 ext 7454
   Technical Contact, Zone Contact:
      Emery, David I.  (DIE2)  die@CLEARPOINT.COM
      (508) 435-0900 ext 7462

   Record last updated on 28-Sep-90.

   Domain servers in listed order:

   CRACKERS.CLEARPOINT.COM      131.226.1.60
   NIC.NEAR.NET                 192.52.71.4
   TIBERIUS.CLEARPOINT.COM      131.226.3.1


To see this host record with registered users, repeat the command with
a star ('*') before the name; or, use '%' to show JUST the registered users.

Frank Kastenholz
<take a guess where I work!>

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 02:57:02 GMT
From:      brinkema@fjc.GOV (John R. Brinkema)
To:        comp.protocols.tcp-ip
Subject:   (Practically) How fast go I go?

I am designing a rather crude 'mirrored' database system built out of
an standard database product.  The baseic idea is to copy transaction
entires in the backup-journal file over to the mirror system and post
the transactions there also.  The mirror database is read only.  If
something goes wrong (ie the transaction journal is messed up -- which
apparently happens although *I* have not experienced the phenominon) the
whole master database must be copied from the primary system to the mirror
system.  The database is about 800Mb (and growing).

The question is from your experience, how fast can this be done.  The
connection between the two systems will be Ethernet;  the two systems
will be quiescient at the time; they are 486-based running Unix, Enet
boards are (currently) 'dumb' with tcp-ip the 'standard' protocol.
The two machines are physically next to each other (ie. no internet to
deal with - just Ethernet (Enet) ).

Specifically:
1) where are the bottle necks in such a configuration: the cpu's, disk, the
network (Enet), the protocol?

2) I am willing to consider writing a network program using special
protocols to do the transfer if the transfer speed would significantly
be reduced.  So -- if the time to transfer the file using (Unix's) rcp
command is '1', what factors would I get if I used ftp; socket/tli level
routines in my own program; lower level (ip-connectionless) routines in my
own programs; direct Enet access (if I can do it), via my own routines.

Rule of thumb or numbers are fine. tnx.   jb.

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 05:53:29 GMT
From:      ljm@FTP.COM (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: 'legal' protocol behavior

>>The intent of my reply was to emphasise the importance of standard
>>practice over RFC definition as a guide for implementors decisions
>>as to what is 'legal'....
>
>I'll stand by my comments - in general, the RFCs ought to be the
>definition.  Certainly there needs to be room to correct errors...
>but such deviations ought to be strictly those that have been accepted
>in the appropriate public forum (IETF, a mailing list, or whatever)...
>
>...I'm not willing to define "standard practice" as the way
>the first or the most prevalent implementation does it, without some
>good justification to go along with it.
>

I just get tired of having to debug yet another implementation which was
written by someone going off in a corner and developing communications
software 'according to the RFC' when the RFC deviates from existing practice.
I know a number of TCPs which were written by this method (I'll name names
privately if you'ld like) which don't actually work all that well.

As for acceptance in a public forum, the last IETF saw yet another rousing
cheer for considering conformance testing, much less simple belief in
conformance to a document, to be worthless in judging if an implementation
is ready to be distributed to the world at large.  

The point being that it is only by conducting interoperability testing with
as many different implementations as possible can the quality or 'legality'
of an internetworking product be judged.  And that the ability to quote a
section from a MILSTD or RFC is insufficent cause to loose a noninteroperable
implementation on poor users.

enjoy,
leo j mclaughlin iii
ljm@ftp.com

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 08:44:47 GMT
From:      kzm@hls.com (Keith McCloghrie)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring ARPs

Jeremy,

> I agree that, because of ARP, bridges highlight the multi-media problem.
> But what about other applications, say for  network management, which
> also send MAC addresses in data? 

The IETF 802.5 MIB (which has been submitted for publication as an RFC) 
specifies the use of the (802.1a) canonical ordering for MAC addresses
when accessed by SNMP, rather than 802.5 transmission ordering.

Keith.

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 13:52:35 GMT
From:      lap@dvncnms.Devoncnms.Unisys.COM (Lisa A. Phifer)
To:        comp.protocols.tcp-ip
Subject:   Re: Graphical TCP/IP Manager



>I am looking for some kind of a graphical Network Manager which 
>could monitor and display a distributed systems application
>(using TCP/IP) on an X interface.
>Any pointers to something similar also would be of great help.

I suggest getting a copy of the DataPro publication "SNMP Product
Guide Part 1: Management Systems", October 1990. This publication
lists a few dozen products which provide what you are looking for,
along with contact info for the vendors. You can reach DataPro
at 609-764-0100.
 

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 14:28:32 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re:  Troubles with BOOTP from FTP

What version are you running? Also, do you have a direct email address? 
Your path is beyond my interpretive skills (or, at least, patience).



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

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 16:13:39 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Troubles with BOOTP from FTP


    I have troubles using the ethernet generic version of BOOTP from FTP Inc.

Let our tech support people know what version of PC/TCP you have; in one
release we didn't catch a buggy bootp client until we'd shipped a few.

    Although there are 6 BOOTP Servers responding (definitely right
    responding), my PC cant't get its IP address.

If there are six servers, and sometimes it works, it could simply be that
they are all responding at once, and the PC misses the answer.  What sort
of LAN monitoring tools do you have available?

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

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 16:25:56 GMT
From:      bstrong@sleepy.bmd.trw.com
To:        comp.protocols.tcp-ip
Subject:   Goofy Router?

Hello,

I have a problem.  We have lost connection to a site we need to
get to (for e-mail mainly).  Pinging it gives no response, although
Nslookup can tell me its ip address.  They are not down and can get
out onto the rest of the Internet as can we.  I think I'm getting
"stuck" at one certain router and I'd like confirmation/correction on
this.  Here's what's going on:

    we're oz.bmd.trw.com (129.193.100.6) and we're trying to get to
          afsc-bmo.af.mil (132.62.71.1)


    When I did a traceroute to afsc-bmo.af.mil on 4/10/91 I got this -
    1   outdsg.nba.TRW.COM
        .
        .
        .
    13  192.52.195.1
    14  * * *
    15  * * *
        .
        .
        .
    30  * * *

    This tells me why I can't get to afsc-bmo - I'm exceeding 30 hops - but
    what the heck is happening?  I know there's no way it's even 30 hops to
    this site - we could mail to them last week.  What is this router at
    192.52.195.1 doing?  When I traceroute just to 192.52.195.1 I got this -
    1   outdsg.nba.TRW.COM
        .
        .
        .
    13  192.52.195.1 (192.52.195.1)  1080 ms  1030 ms  1070 ms
    14  192.52.195.1 (192.52.195.1)  1060 ms !P  1020 ms !P  1050 ms !P

    What does the second hop with the bang 'P' for?  I've never seen this !P
    and didn't see anything in out documentation (using Wollongong TCP/IP for
    VMS).  Now, one more thing,  I did another traceroute this morning
    (4/11/91) and got the same thing except that the IP address, 192.52.195.1,
    now has a logical address and shows up as MOFFETT-FLD-MB.DDN.MIL in the
    traceroute, but the trace is still identical to the previous one.  Are
    these guys just configuring a new router or what?  I don't know who to
    contact to ask in person about it.  Could someone help???
    As is obvious, I'm a real novice so please look past my ignorance.


===============================================================================
Bryan Strong                    TRW * Ogden, UT * USA
                                Computing Services / Software Support
Internet:                       bstrong@oz.bmd.trw.com
Phone:                          801.625.8090

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 18:00:45 GMT
From:      ken@racerx.UUCP (Ken Hardy)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet broadcast: INADDR_BROADCAST

In article <BENNY.91Apr10110956@dimona.vlss.amdahl.com>, benny@vlss.amdahl.com (Benny Schnaider) writes:
> Hi,
> 
> I am trying to broadcast a message over the internet by using the
> INADDR_BROADCAST shorthand notation. I tried this on SunOS 4.01
> and got: Network is unreachable... On other system that I tried
> the same code it worked.
> Code is enclosed.
> 
> 1. What is the problem ?
> 2. How common is it to use INADDR_BROADCAST ?
> 
> Thanks,
> Benny.


You need to have a valid network in the network portion of
the internet address.  This is a routine I use on Suns to
build a broadcast address.  May not be cleanest code, but
it works on Sun 4.0 & 4.1.  The print statements yield:

		Name = [racerx]
		Host ID 80420006
		Net  ID 00008042
		Bcast ID 8042ffff

This get physically resolved on our system to a broadcast ethernet
address.  This may or may not be passed by bridges.  IP routers
may not pass it based on the network portion of the IP address,
and even if a bridge or router passes it, other IP hosts on another
network may not pay attention to it if they have another network
i.d.


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

int     bcast_address ()
/*
 *
 */
{
    struct in_addr bcip;
    unsigned ipad,
            netp;
    extern struct hostent *getmyhostent () ;


    if (my_he == (struct hostent *)0)
    {
        my_he = getmyhostent () ;
        memcpy (&myip.s_addr, my_he->h_addr, sizeof (myip.s_addr));
        memcpy (&my_ipaddr[0], my_he->h_addr, sizeof (myip.s_addr) ) ;
    }
    netp = inet_netof (myip);
    bcip = inet_makeaddr (netp, INADDR_BROADCAST);
    if (bug)
    {
        printf ("Name = [%s]\n", my_he->h_name);
        printf ("Host ID %08lx\n", htonl (myip.s_addr));
        printf ("Net  ID %08lx\n", netp);
        printf ("Bcast ID %08lx\n", htonl (bcip.s_addr));
    }

    RETURN (bcip.s_addr);
}

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


-- 
Ken Hardy		uunet!racerx!ken		ken@racerx.UUCP

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 18:05:20 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip
Subject:   looking for "spray" source

Can someone point me to an archive (I haven't FTP capabilities) that contains
the source for the "spray" utility?

bd
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 18:41:24 GMT
From:      sfalken@caen.engin.umich.edu (Steve Falkenburg)
To:        comp.protocols.tcp-ip
Subject:   Re: HyperFTP

In article <9103181622.AA01779@elroy.cit.cornell.edu>, dug@CORNELLC.CIT.CORNELL.EDU writes:
> 
> There was a question on this list about client FTP implementations for
> the Macintosh.  Here's some information from the author, Doug Hornig,
> about a Hypercard-based FTP client from Cornell.
> 
> Mark Bodenstein  (mab@cornellc.cit.cornell.edu; 607-255-8059)
> Cornell University
> ----------------------------Original message----------------------------
> Mark,
> Yep HyperFTP is in the public domain.  I first send copies to
> sumex-aim.standford.edu where it can be anonymously FTPd from the
> /info-mac/comm directory.  I've seen it show up in other places as well.
> -- Doug
> 
>

Just for some self-advertising, there is a Macintosh Application to
do FTP available from mondo.engin.umich.edu (141.212.68.14).  It's
called XferIt, and is based on a multi-window browser type
interface.  It supports multiple connections, and will transfer
files in the background (including bulk transfers).

For more info, etc... just download it from mondo.engin.umich.edu,
or mail me (I'm the author) for more info.

-steve

(P.S. also coming soon: yet another Mac newsreader in the next
issue of Apple's "develop" magazine, and probably posted to
the net soon after)

----------------------------------------------------------------------
Steve Falkenburg (sfalken@mondo.engin.umich.edu)   | Great pate', but
Macintosh Programming/Support                      | I've gotta motor!
Computer Aided Engineering Network, U of Michigan  |  -Heathers

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 19:01:19 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP traffic characterization

I was just thinking about running benchmarks/test-suites for TCP/IP and
realized that I haven't noticed any really thorough traffic characterizations
in the literature.  I have in mind things like a probability-density function
for number of octets sent during a connection, possibly correlated with some
burstiness measures and mean throughput.  Then there are even cooler things to
wonder about, for instance, what percentage of connections are to passive
(listening) sockets (I would guess 99+%)? And what percentage of connections
follow the "A calls B, B finishes and closes its end of the connection, A
closes in response" pattern?  How often do SYNs and/or FINs "cross" in the
network? What percentage of TCP packets ever require retransmission?

I could go on, but you get the point.  If I wanted to exercise my TCP/IP in a
"realistic" way, I would have to argue that my load-generator did "screwy"
things (like active connect-requests crossing in the mail) more or less the
right percentage of the time (or enough not to throw all my numbers off).  I
could see things such as the average number of TCP connections mattering to a
benchmark (a naive search algorithm for finding connection descriptors only
bites you if there are more than a few of them active at any time, for
instance).

Does anyone know of what sorts of traffic characterizations for TCP/IP there
are out there? Just wondering...

-Johnny Curious

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 22:08:39 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program

jj@dcs.leeds.ac.uk (J Jackson) writes:


>Has anybody an off-the-shelf script of program that will read an 
>/etc/hosts file and create the database fileformat required by the
>named daemon?
 
>cheers
>=======================================================================
>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.

I was faced with a similar problem on my network, but fortunalty I have a
few HP9000 running HP-UX 7.0, which just happerns to have a function
that does what you want.  It will even produce config files for non-HP 
machines if you throw that right parameters at it (I manage the configuration
on a Pyramid MIS with it.

Have a look around you network to see if there is a HP9000, and that will 
solve your problem.  

Email me if you want more info on how to do it.



Regards 

-- 
Rob Logie                                    EMAIL: logier@cheops.qld.tne.oz.au
Telecom Australia                            FAX:   +61 7 837 4704
TNE Computer Support Services                PH:    +61 7 837 5174
Brisbane Office                              "These are my opinions alone"

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Apr 91 22:20:12 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet drivers for Proteon Pronet-10

as jbvb@ftp.com writes:
>As far as I know, there never have been any implementations of Class 2
>(Proteon ProNET-10 token ring) Packet Drivers.  PC-IP has a linked-in

I'd have to agree with James as far as Class 2 goes, but not Class 1.

While the proNET 10 technology is nice, you are better off using it
to imitate a Class 1 ethernet system.  That's what I did and it works
perfectly for every commercial and PD TCP/IP package configured for Ethernet 
The 48 bit Ethernet address space can be nicely made from a zero extended
8 bit proNET address or even a zero extended 32 bit IP address.

I'd love to give you our driver, but it works using our local network/disk
bios so it would not be at all useful to you.  However, if you are willing
to do the development, I could offer some useful hints.

Erick 
-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 00:19:02 GMT
From:      dlv@cunyvms1.gc.cuny.edu (Dimitri Vulis, CUNY GC Math)
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   Re: universality of Latin-1

In article <1991Apr10.172756.4991@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes:
>        ISO 10646   (once it gets completed)
 "Unicode" seems both more practical and more realistic.
>Ran Atkinson
>randall@Virginia.EDU
Dimitri Vulis, D&M
BITNET:            DLV@CUNYVMS1
Internet:          DLV@CUNYVMS1.GC.CUNY.EDU
Snail:             Department of Mathematics/Box 330
                   City University of New York Graduate Center
                   33 West 42 Street
                   New York, NY 10036-8099
                   USA

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 00:23:12 GMT
From:      elf@oldearth.EBay.Sun.COM (Ed Fleschute)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Looking for comments on network analyzers

In article <4669@dftsrv.gsfc.nasa.gov>, lanmaint@nssdcb.gsfc.nasa.gov
(Dave Yoest) writes:

|> (TEXT DELETED)
|> We have a LANALYZER (bought from Excelan before the Novell buyout)
|> that we have used for 4 or 5 years. I have also demo'ed the SNIFFER
|> and find them to be comparable. In my opinion the SNIFFER is just
|> a little better at protocol decoding and the LANALYZER is a little
|> better at finding physical layer hardware problems. Overall they 
|> are just about equal, If you're more into protocol "problem tracking"
|> then you might be better off with the SNIFFER. If you do more hardware
|> problem solving then the LANALYZER might be a better choice.
|> 

I'll second the evaluation that Dave has performed.  The LANALYZER is
a great tool for doing physical layer analysis.  If you are experiencing
hardware problems on a cable the LANALYZER is phenominal at pinpointing
the source of the trouble very quickly.

The SNIFFER is excellent at higher level protocol analysis.  If I was looking
to find a NFS protocol bug I definitly would prefer the SNIFFER.


|> 
|> Not to cloud the issue since you have already narrowed the field, but 
|> did you look at the Hewlett Packard 4972 LAN protocol analyzer.
|> I like it better than both the SNIFFER and LANALYZER (my opinion).
|> (TEXT DELETED)
|> 

Two things I don't like about the HP 4972.  

	1) It is VERY heavy.  If this isn't going to be mounted in a rack
	   or on a cart, get something else.

	2) I found the HP difficult to program.  With the software they
	    had two years ago it was difficult to do a display sorted on the
	    hosts with the highest error counts.  This may have been updated
	    in the last couple of years.

 
Ed Fleschute (My opinion only)

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 02:36:20 GMT
From:      dsamperi@Citicorp.COM (Dominick Samperi)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Thin wire or twisted pair?

My organization is considering the use of twisted pair point-to-point
connections as an alternative to thin wire Ethernet. The motivation is
to reduce our expenses. The environment is one where there is little
tolerance for network failures (a trading floor). I'm familiar with
thin wire Ethernet, but know little about twisted pair technology.

Could somebody comment on their experiences with twisted pair
connections. Are they cheaper than thin wire? More/less reliable?
Is there a throughput/bandwidth hit in using twisted pair? How
large? Is twisted pair easier/harder to maintain?

Thanks for any information on this.


-- 
Dominick Samperi -- Citicorp
dsamperi@Citicorp.COM
uunet!ccorp!dsamperi

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 03:31:17 GMT
From:      HANK@TAUNIVM.TAU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Where does one get old RFCs?

I was trying to retrieve an old RFC (468) and tried NIC.DDN.MIL and
NIS.NSF.NET (as RFC 1177 tells me to) and each no longer have the old
RFCs apparently online.  Or am I looking in the wrong place?  Can anyone
tell me where I should look and perhaps update RFC1177 with the correct
information?

Thanks,
Hank

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 04:30:24 GMT
From:      Andy.Linton@comp.vuw.ac.nz (Andy Linton)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program


In article <1991Apr11.220839.17490@cheops.qld.tne.oz.au>,
logier@cheops.qld.tne.oz.au (Rob Logie) writes:

|> I was faced with a similar problem on my network, but fortunalty I have a
|> few HP9000 running HP-UX 7.0, which just happerns to have a function
|> that does what you want.

What is it called????

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 04:31:30 GMT
From:      jay@axiom.maths.uq.oz.au (Joseph Young)
To:        comp.sys.mac.comm,aus.mac,comp.protocols.tcp-ip
Subject:   Will KA9Q talk to a Mac SE ethernet card?

I have a Mac SE with a Novell NAE1000 ethernet card ... can KA9Q talk
to this card? Most of the documentation I have refers to PC hardware ...
I  have an example autoexec.net file that shows how to use the AppleTalk
port but no mention is made about Macintosh EtherNet cards.

Any help would be appreciated.

Joe Young
jay@axiom.maths.uq.oz.au    ... Internet
j.young@qut.edu.au          ... Internet

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 04:44:21 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Is the data received using recvfrom() in SOCK_RAW fragmented by IP?


Hi netlander,
        In BSD socket, one can implement a new protocol on top of IP using
SOCK_RAW with the designated protocol number. Then, one can receive the
data using recvfrom() call. The recvfrom() returns the data with the IP header.
So far so good. But if the sender sends large amount of data in one single
send(), and the IP layer needs to fragment the data to a few packets, then
can we receive the data in onr single recvfrom() [Note: this implies the IP
layer on the receiver side re-assemble all the packets b4 passing the data
up to us]? Or do we need to take care of the fragments ourself by inspecting
the IP header and do re-assemble if necessary?
        Which one is true? Could somebody shed some light on me please?
        Thanks a lot.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 06:04:32 GMT
From:      brett@solar.card.inpu.oz.au (Brett Sealey)
To:        comp.protocols.tcp-ip
Subject:   SLIP problems under SunOS 4.1.1

Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by
Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's
running SunOS 4.1.1 (This may well be the problem).

Occasionally these machines crash with a "panic: mget" or even more rarely
a "panic: mfree" message.

Looking into the SLIP code I can see a MGET call within the tty_slip.c
file. MGET is a macro which can cause a "panic: mget" if the next mbuf on
the free list (mfree) is not correctly marked as "MT_FREE".

As I see it this is reasonable, the question is why does this condition
arise in the first place and, even more importantly, how can it be
prevented.

A comment in tty_slip.c indicates that :-
	/* (SLIP_CLUSTERS doesn't work under SunOS 4.0) */
Is this true under SunOS 4.1.1?

If anyone has any clues as to what could be causing this rather
embarassing problem I'd be very keen to hear from them.

Thanks (in advance :-)
       Brett Sealey
______________________________________________________________________________
  __   __   ___ ____ ____
 /__) /__) /_    /    /				brett@solar.card.inpu.oz.au
/__) / \  /__   /    /					       Brett Sealey
______________________________________________________________________________

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 06:30:37 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP benchmarking


>
> I've encountered another "benchmark."
>
> First try the 4.3BSD `ping -l9999999 target` and look at the packet rate.
>

   ...but before you do that, be sure your mbuf code is fixed.  On BSD
systems of early 4.3TAHOE vintage or earlier, you could get an mbuf
panic from all those unprocessed ICMP Echo Replies.  Sure surprised us.

				Later,
				    Bob

P.S.  It has been long enough to forget the exact details, but it was
caused by a mget() with DONT_WAIT flag set on a receive, or something
like that.

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 11:54:25 GMT
From:      nrm1838@dsacg3.dsac.dla.mil (James D. Cassell)
To:        comp.protocols.tcp-ip
Subject:   Network Management


  We are interested in anyone's experience in managing large router networks.
  Our network currently consists of 23 routers (cisco) connecting large
  (600+ hosts) LANs.  The router network will be expanded to bring in 
  another 250-350 LANs (mostly much smaller LANS than are now on the 
  network).  

  We currently have no network management hardware or software (for the
  WAN stuff).  We have looked at cisco's NetCentral Station, but have 
  heard mixed reviews of this product from other users (too slow, can't
  handle very large networks, etc.).

  Any information, experiences, war stories, etc. will be greatly 
  appreciated.  We have our hands full managing the current 23 routers,
  I can't immagine 400 of them!
       
	     Thanks,
		 Jim

-- 
Jim Cassell              | jcassell@dsac.dla.mil   
DSAC-RMB, P.O. Box 1605  | 614-238-9971
Columbus, Ohio 43216     | Input standard disclaimer here ...

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 12:33:02 GMT
From:      rja7m@calico.cs.Virginia.EDU (Ran Atkinson)
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   Re: universality of Latin-1

UNICODE isn't a sufficient solution as it doesn't fully support (for
example) Vietnamese.  DIS 10646 is a sufficient solution.

I wish it were otherwise, but I have to live in the real world...

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 12:46:14 GMT
From:      barryf@aix01.aix.rpi.edu (Barry B. Floyd)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather (really Coke machines)

Is anyone archiving this thread of postings (interesting devices attached
to networks)? I am interested in receiving the archive when this discussion
dies down.
 
respond directly to me or post to the group.
 

-- 
+--------------------------------------------------------------------+ 
| Barry B. Floyd                   \\\       barry_floyd@mts.rpi.edu |
| Manager Information Systems - HR    \\\          usere9w9@rpitsmts |
+-Rensselaer Polytechnic Institute--------------------troy, ny 12180-+

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 12:47:41 GMT
From:      eliot@chutney.rtp.dg.com (Topher Eliot)
To:        comp.std.internat,comp.protocols.tcp-ip
Subject:   Re: universality of Latin-1

In article <1991Apr10.172756.4991@murdoch.acc.Virginia.EDU>, randall@Virginia.EDU (Randall Atkinson) writes:
|> In article <1110@sranha.sra.co.jp>, 
|> 	Erik M. van der Poel <erik@srava.sra.co.jp> responded:
|> >Have you ever tried to send yourself a message in Latin-1? Did it
|> >work? And even if *you* have a reasonable version of sendmail (one
|> >that doesn't strip the 8th bit), what makes you so certain that
|> >Torbj|rn's message and anyone else's won't pass through a site that
|> >*does* strip the 8th bit?
|> It does work for a fair and ever increasing subset of the Internet.
|> BITNET doesn't do very well with it.  Clearly we need to move towards
|> 8-bit and 16-bit and 32-bit transparent mail transport mechanisms.

I expected to see someone else post a more authoritative answer, but since
none has been forthcoming, I will venture.  The folks who work on such things
have been considering the 8-bit, different-codeset issues, as part of a much
larger picture of including such things as graphics and other binary
information in mail.  Since those are harder problems, it means that they
won't have solutions all that quickly.  There is a mailing list on this
subject; if you really need it I can probaly dig out a lead on how to get
onto that mailing list.

|> Fortunately there are a number of possible transport mechanisms out
|> there to choose from, some of which are already 8-bit transparent.
Ack!  "Fortunately"?  There is an ancient curse:  "may you live in interesting
times".  I think it's modern equivalent is "may you have many standards to
choose from".  

-- 
Topher Eliot                           Data General DG/UX Internationalization
(919) 248-6371        62 T. W. Alexander Dr., Research Triangle Park, NC 27709
eliot@dg-rtp.dg.com                           {backbone}!mcnc!rti!dg-rtp!eliot
Obviously, I speak for myself, not for DG.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 13:02:38 GMT
From:      clu@malihh.hanse.de (Carsten Lutz)
To:        comp.protocols.tcp-ip
Subject:   DialUp-IP with Telebit-Modems

Hi !

Some weeks ago, someone posted a pointer to an FTP-archive, where one could
get a DialUp-IP-Source for Telebit-Modems. I missed this posting, could
someone please mail me the name/adress of this FTP-site ?

Thanks in advance,
                        Carsten

-- 
+             Carsten Lutz, Rellingen, FRG / clu@malihh.hanse.de           +
+   Voice : +49 4101 207871  Fax: +49 4101 27757  Traily : +49 4101 22306  +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ ...This is usually because the networks transfer the mail by emulating   +
+       punched cards ! - Donnalyn Frey                                    +

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 13:29:07 GMT
From:      caserta@athena.mit.edu (Francesco Caserta)
To:        comp.protocols.tcp-ip
Subject:   finger weather is discontinued


Well, I've been the one who has announced in this list the services
provided to the Internet community by stormy.atmos.washington.edu, and
now announce its death (temporarily?). This is what you will now get
by fingering weather @stormy.atmos.washington.edu

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

[stormy.atmos.washington.edu]
Dear Users of Weather Forecasts,

The Department of Atmospheric Sciences at the University of Washington
receives NWS weather information through a 3rd party vendor.  We get
this data at a reduced rate from the vendor.  However, as part of the
contract we are not supposed to distribute this data outside the
University without paying an additional $150/month licensing fee.  My
department is unwilling to pay such a fee (they aren't too crazy
about providing such a service in the first place).

Therefore, I must restrict access to our forecast information to the
University of Washington.  I am sorry to do this, but I will not
knowingly violate the terms of our contract.  I do not think offers to
pay the extra $150/month will make any difference in this decision.
If you are on a campus with a Meteorology or Atmospheric Sciences
Department, you might try seeing if they will locally distribute such
information.

I hope you found the service useful while it lasted, and I hope that
the situation will change someday, and that I can provide such a
service in the future.

        Harry Edmon (harry@atmos.washington.edu)

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

At least my initial posting has been useful to bring up information
(see the subsequent postings) that were unknown to the most.

Francesco Caserta 

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 13:29:12 GMT
From:      davecb@yunexus.YorkU.CA (David Collier-Brown)
To:        comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: SLIP problems under SunOS 4.1.1

brett@solar.card.inpu.oz.au (Brett Sealey) writes:
| Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by
| Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's
| running SunOS 4.1.1 (This may well be the problem).
|
| Occasionally these machines crash with a "panic: mget" or even more rarely
| a "panic: mfree" message.
|
| Looking into the SLIP code I can see a MGET call within the tty_slip.c
| file. MGET is a macro which can cause a "panic: mget" if the next mbuf on
| the free list (mfree) is not correctly marked as "MT_FREE".

	Oy veh ist mir!

	We suffered a minor variant of this on StunDOS 3.5, where one could
	get mgetclr panics by essmingly exhausting the mbuf space.  This
	sounds similar enough to make me suspicious.

	Can someone comment on the version of tcp/ip code used in SunOS 4.1.1?
	We only have sources for 3.0, and that's maybe BSD4.2 at the best (:-()

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

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 13:47:08 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   Sniffer


We are looking at the possibility of purchasing a Sniffer....anyone
out there have any experience with it?

Thanks,

Bryan Miller
Network Engineer
Virginia Commonwealth University
bmiller@cabell.vcu.edu

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 14:04:04 GMT
From:      jessea@homecare.uucp (Jesse W. Asher)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   What protocol is used for leased lines?

Our company is planning to hook up 7 remote sites up to our Sun Server
via digital point to point leased lines.  My question comes from not
knowing enough about leased lines and about tcp/ip.  What the phone
company proposes is DSUs connected to RS-232 ports at each of the
connection.  Here is where I get lost.  What should I run on either end?
Should I be running SLIP or PPP because the DSU is connected to an
RS-232 port?  This doesn't seem right since many people out there are
using leased lines and are not using slip.  Can anyone give me any
insights as to how _you_ would connect up two sites via leased lines
and how you would use tcp/ip to do it?  Thanks much.


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

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:04:59 GMT
From:      karl.kleinpaste@osc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP problems under SunOS 4.1.1

brett@solar.card.inpu.oz.au writes:
   Lately we have been playing with the "Beta SLIP for SunOS 4.0" written by
   Rayan Zachariassen. We have been using it on Sun SPARCstation IPC's
   running SunOS 4.1.1 (This may well be the problem).

   Occasionally these machines crash with a "panic: mget" or even more rarely
   a "panic: mfree" message.

I am using Rayan's code on a SunOS 4.1.1 Sun4/110.  It works fine
after you install Sun PatchID 100149-02, except for an occasional
assertion panic of the following form when sliplogin goes down (in my
case, when the modem line drops; I'm using it for dialup SLIP):

| assertion failed: vp->v_stream == stp, file: ../../os/str_io.c, line: 609
| panic: assertion failed

I've written a note about the problem to sunbugs@sun.com, but since it
involves use of a non-standard driver, I doubt it'll get much
attention.  Before installing 100149-02, I consistently got "panic:
mclput" whenever substantial amounts of data would begin to transfer.

Note that there exist both -01 and -02 versions of this fix; install
-02 to be maximally up-to-date.  The README for -02 notes that the -01
version didn't deal in IP options properly.

100149-02.tar.Z can be ftp'd from saqqara.cis.ohio-state.edu:pub/slipware.

--karl

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:35:35 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program

1 each stupid awk script that handles 90% of our needs for conversion of
hosts table to domain database format:

/^#/	{print ";	"$0;next}
/^$/	{next}
{
split($2,hn,".");
printf("%s\tIN\tA\t%s\n", hn[1], $1);
for(i=3; i< 9; i++)
	{
	if (!$i) break;
	split($i,nn,".");
	if (hn[1] != nn[1])
		printf("%s\tIN\tCNAME\t%s\n", nn[1], hn[1]);
	}
}

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:48:00 GMT
From:      Sabo@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   Re: Graphical TCP/IP Manager

>>I am looking for some kind of a graphical Network Manager which
>>could monitor and display a distributed systems application
>>(using TCP/IP) on an X interface.
>>Any pointers to something similar also would be of great help.
>
>I suggest getting a copy of the DataPro publication "SNMP Product
>Guide Part 1: Management Systems", October 1990. This publication
>lists a few dozen products which provide what you are looking for,
>along with contact info for the vendors. You can reach DataPro
>at 609-764-0100.

You can also reach DataPro toll-free at (800) 328-2776.  Ask for
extension 2444.  This is Jill Huntington-Lee's line.  Jill will
send out copy's of the "SNMP Product Guide Part 1: Management
Systems" free of charge.  Also, a new publication entitled
"SNMP Product Guide Part 2: Agents" has just been completed, for
those who are interested in knowing what networking products
current have SNMP agent support.

_Michael

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:49:43 GMT
From:      bjork@NISC.SRI.COM (Steven Bjork EJ223)
To:        comp.protocols.tcp-ip
Subject:   Re: Where does one get old RFCs?

In article <9104120331.AA03866@ucbvax.Berkeley.EDU> HANK@TAUNIVM.TAU.AC.IL (Hank Nussbacher) writes:
>I was trying to retrieve an old RFC (468) and tried NIC.DDN.MIL and
>NIS.NSF.NET (as RFC 1177 tells me to) and each no longer have the old
>RFCs apparently online.  Or am I looking in the wrong place?  Can anyone


The NIC has hard copies of all RFC's in its archives. Some of the
early RFC's that may have been online seem to have become "lost",
perhaps on someone's backup tapes out there. If you consult the
file rfc-index.txt, it will list the online status of any RFC.

Any leads, rumours, or otherwise, leading to retrieval of the
Missing RFC's, will be rewarded with a batch of my Chocolate Chip
Cookies... P.S. The TeX recipe is available on ftp.nisc.sri.com,
netinfo/cookies.tex.

--Steven

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:54:14 GMT
From:      fxs@stowe.UUCP (Fran Sullivan)
To:        comp.protocols.tcp-ip
Subject:   setting up mail on SCO


One of my co-workers has SCO-Unix running on a AT-386 PC.

He is fully connected to our local net with TCP/IP etc.
He would like to be able to send mail to other boxes on the
local net, but does not have the appropriate software support.
IE: SMTP

Does anyone know of any Public Domain software i can use to
do this.

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:55:25 GMT
From:      fxs@stowe.UUCP (Fran Sullivan)
To:        comp.protocols.tcp-ip
Subject:   setting up mail on SCO



One of my co-workers has SCO-Unix running on a AT-386 PC.

He is fully connected to our local net with TCP/IP etc.
He would like to be able to send mail to other boxes on the
local net, but does not have the appropriate software support.
IE: SMTP

Does anyone know of any Public Domain software i can use to
do this ??

                                               |\/\/\/|
* Fran Sullivan                                |      |
* fmrco!fxs@uunet.uu.net                       |      |
* Unix Tech Support                            | (o) (o)
* Fidelity Information Systems                 C      _)   ...Hey Dude!
* Boston, MA    02109                           |  `__|     
* ( 617 ) 570-2762                              |   /   
                                               /    \
                                              / ---- \ 

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 15:57:22 GMT
From:      echan@cadev6.intel.com (Eldon Chan ~)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program

IBM RS6000 running AIX 3.1 has such scripts  build in too.  
They are pretty small scripts, it should work on most UNIX.

Eldon Chan
------------------------------------------------------------------------
From tcp-ip-RELAY@NIC.DDN.MIL Fri Apr 12 02:37:12 1991
Received: by scdt (5.57/10.0i); Fri, 12 Apr 91 02:37:08 PDT
Received: by hermes.intel.com (5.57/10.0i); Fri, 12 Apr 91 02:22:24 PDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 11 Apr 91 17:17:51 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA28297; Thu, 11 Apr 91 17:07:36 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 Apr 91 22:08:39 GMT
From: uhccux!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!cheops!logier@ames.arc.nasa.gov  (Rob Logie)
Organization: Telecom Australia, TNE Computer Support Services
Subject: Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program
Message-Id: <1991Apr11.220839.17490@cheops.qld.tne.oz.au>
References: <7571.9104101607@csunb0.dcs.leeds.ac.uk>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil
Status: R

jj@dcs.leeds.ac.uk (J Jackson) writes:


>Has anybody an off-the-shelf script of program that will read an 
>/etc/hosts file and create the database fileformat required by the
>named daemon?
 
>cheers
>=======================================================================
>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.

I was faced with a similar problem on my network, but fortunalty I have a
few HP9000 running HP-UX 7.0, which just happerns to have a function
that does what you want.  It will even produce config files for non-HP 
machines if you throw that right parameters at it (I manage the configuration
on a Pyramid MIS with it.

Have a look around you network to see if there is a HP9000, and that will 
solve your problem.  

Email me if you want more info on how to do it.



Regards 

-- 
Rob Logie                                    EMAIL: logier@cheops.qld.tne.oz.au
Telecom Australia                            FAX:   +61 7 837 4704
TNE Computer Support Services                PH:    +61 7 837 5174
Brisbane Office                              "These are my opinions alone"

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 16:25:17 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP??? Scores. MNP???

On Wed, 10 Apr 91 04:13:05 GMT <tcp-ip-relay@NIC.DDN.MIL> said:
>I've heard some interesting things about SLIPs but don't know
>how they work or how to install one. Can anyone enlighten me???

I'll comment about the other often asked questions: whether to, why so slow...
SLIP performance (on low bit rate lines) is that of the (sending) TCP's.
This holds for any slow line, but is aggravated by SLIP's unreliability.
Indeed, a TCP sending data has to figure the timeouts used to resend data
carefully. Too short makes it a plague of duplicate packets. Line errors
may get the value occasionally very high and get things slow if the TCP is
sluggish in reducing the timeout value.

Some rough figures (9600 bauds MNP modems) when FTP receiver is:
SunOS 4.0.3            1.1  Kb/sec (presumably any BSD 4.3)
VM TCP/IP 1.2.2 (IBM)   .75
CUTCP                   .25 (could be improved with other parameters, but
                             had better do without such customization).

All hosts were on Ethernet, SLIP was between routers.
MNP means that the impact of line errors was almost nil (but another cause
for loosing packets got me mad for some time).
MNP made the throughput very slightly better, nothing to speak of,
but shows an annoying echo latency in terminal mode that doesn't exist without
it. I guess it's because of a time value it uses to wait for enough bytes to
assemble into packets to minimize the checksum overhead, and this has no
reason to be for what's the noninterrupted flow of datagrams.

Is there a way to get rid of this latency?

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

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 16:48:26 GMT
From:      arena@goethe.UUCP (mike arena)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   TCP/IP programming library for PC's

I am looking for an implementation of TCP/IP on the PC which provides
a programming library.  I would only need the PC to act as a client.

Specifically, I am looking for the socket family of functions (socket(),
connect(), etc.)

I don't need TELNET or FTP (but that wouldn't preclude me from buying the
package).

Also, if SLIP or even dialup SLIP are supported, I would be very interested.

I have information about SUN's PC-NFS product and it seems that it would do
all that I want (plus NFS), however, it costs $395 per PC.  I would prefer
a product which either had a lower run-time system cost or a library which
would not need a run-time distribution (i.e. all of the TCP/IP facilities my
program uses would be linked into my application).
-- 
--------------------
Michael Arena
Credit Technologies
bu.EDU!icad!goethe!arena

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 18:10:08 GMT
From:      ced@bcstec.uucp (Charles Derykus)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   ftp problem


We've encountered a problem ftp'ing from an RS/6000 AIX 3.1 running the 3003 
update.  No matter what Unix platform is the target, the login fails as
though an extra carriage return were appended to the account name.

A sample session is included:

srloads:/u/sks6373> ftp n1
Connected to n1.ca.boeing.com.
220 n1 FTP server (IBM RT) ready.
Name (n1:root): sks6373
331 Password required for sks6373.
500 'PASS ': command not understood.
Login failed.
ftp>

The target here was an IBM/RT but other unix platforms behave identically or
pretty near.

Has anyone encountered this?  Other than a ".netrc" file are there any 
workarounds?

Thanks,


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

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 18:48:29 GMT
From:      j_rodin@hpfcso.FC.HP.COM (Jon Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet drivers for Proteon Pronet-10

>As far as I know, there never have been any implementations of Class 2
>(Proteon ProNET-10 token ring) Packet Drivers.  PC-IP has a linked-in
>driver for the P1300 interface, so do some of the commercial products.
>Proteon has an non-board-independent interface-sharing spec, which
>they've implemented in their Netware and we in our PC-222 part.

Proteon is working on NDIS drivers for their cards, which should be available
real-soon-now.  Whenever those driver become available, one could use the
dis_pkt driver to run packet driver based protocols over Proteon cards.

Also I believe Proteon supports the ASI interface.  I don't know if a packet 
driver-to-ASI translater exists, but ASI does support multiple concurrent 
protocol stacks.

Jon
j_rodin@cnd.hp.com

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 19:49:10 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: 'legal' protocol behavior

The News Manager)
Nntp-Posting-Host: na
Reply-To: donp@novell.com (don provan)
Organization: Novell, Inc., San Jose, California
References: <9104110553.AA03082@ftp.com>
Date: Thu, 11 Apr 1991 22:04:41 GMT

In article <9104110553.AA03082@ftp.com> ljm@ftp.com writes:
>I just get tired of having to debug yet another implementation which was
>written by someone going off in a corner and developing communications
>software 'according to the RFC' when the RFC deviates from existing practice.

On the other hand, i got a little tired of people measuring
protocol correctness by whether it interoperated with BSD 4.2.

>The point being that it is only by conducting interoperability testing with
>as many different implementations as possible can the quality or 'legality'
>of an internetworking product be judged.

Interoperability testing is certainly important, but a failure to
ineroperate still requires a way to determine which implementation is
in error, and the specs provide a mechanism for making that
determination.  Depending on interoperability testing only is exactly
what got the TCP/IP community into the "BSD mess" that we're finally
leaving behind us.  I, for one, would rather not see that era
repeated.
						don provan
						donp@novell.com

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 20:23:51 GMT
From:      ric@ace.sri.com (Richard Steinberger)
To:        comp.protocols.tcp-ip
Subject:   need network advice


	I have a few networking questions that I could use some help 
answering.  I'm still reading Stevens' Unix Coimmunications book and am
not a guru.  Thanks in advance to all who reply.

Configuration: We have a uVAX with TCPIP SW (from DEC, UCX I think) and an
attached Aptec interface.  The uVAX needs to xfer files to another (unix)
computer, and at the moment this computer is a Multiflow (basically a Unix
mini-super based on VLIW architecture).  In the future, the Multiflow might
be replaced by a SUN, DEC or other machine acting as a fileserver.  The
usual procedure is that the unix computer retrieves files via FTP or by
using the APTEC bus.  FTP (TCP over enet) transfer rates have been as high
as about 100K bytes/second.  Aptec rates have been less that that, but the
company that developed the Aptec interface promises that they now can
transfer files at 2 - 3 times FTP rates.  (Aptec sells what they call
IO computers.  Their forte' is the rapid transfer of data from computer
to computer, generally VAX to VAX, but they have an interface for SUN
and some [incomplete, if you ask me.  Allegedly Mitre has a turnkey
file xfer package] interface SW).

Question 1: Is FTP considered the fastest reliable way to transfer medium to
large files (500KB - 10MB) between a VAX/VMS machine and a BSD-4.3 unix
machine (using ethernet as the physical medium)?  Would adding another enet
interface card to each computer and connecting a second enet cable make any
sense?  I.e., could a second cable allow multiple (2) file transfers
simultaneously, and could a vax and unix machine use both interfaces at
once?  Would this be transparent to the end user?  Are there other
(enet-based HW and/or SW) possibilities?
	A colleague at another company mentioned that something he called a
"DECnet-Internet Gateway" would allow file xfer at 2 - 3 times FTP rates.
Perhaps he means DECnet-Ultrix network SW.  Is this mush?  Or can DECnet
xfer rates dramatically exceed FTP over enet (or is it the reverse, or
is it more complicated than that)?

Question 2: I would like a repeatable way to put a known traffic load on an
ethernet-based LAN?  Is there something more scientific than continuously
transfering a large file from one host to another?  Are there any (bundled)
utilities in VMS or MultiNet that can display some quantifiable measure of
network traffic (updating at a selectable interval)?  Or, conversely, would
it be better to attach a network analyzer (or buy monitoring SW)?

Question 3:  This is about fileserver performance.  Does anyone know of any
PD fileserver benchmark tests.  I would like to propose a simple (but
hopefully not simple-minded) test strategy for evaluating the performance of
a few candidate fileservers.  We are primarily concerned with a server's
ability to provide (via NFS) files to 2 or 3 clients with "minimal" delays.
This same server would simultaneously be receiving files via FTP (or
other enet SW) and perhaps doing some computation (to reformat the files).
Is there something more elaborate than doing one (or several) rcp(s) to/from
server to client and measuring the time?  What is likely to be the performance
"bottleneck"?  The ethernet itself, or the fileserver's ability to retrieve
and store data from/to disks?


	Again, thanks to anyone who can provide help, guidance or suggestions
on these questions.  I do appreciate it.  Suggestions for books to read
also welcome.

regards,

	ric steinberger
	ric@rml2.sri.com    ric@ace.sri.com

	415-859-4300

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Apr 91 21:38:04 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Oddball devices on the Internet

Here is my contribution for the unusual devices discussion.  This is
not all strictly network related, but the connected history is itself
interesting.  These are my personal recollections of the last 18 years
at Tech Square, home of the MIT AI Lab and Project MAC (now LCS).

When I first arrived at MIT (1973), the AI Lab's Knight TV (KTV) front
end was already hooked up to control several unusual devices in the
building.  The KTVs were special video displays connected through a
PDP11 operating as a front end for the KA10 (at that time MIT-AI,
later AI.AI.MIT.Edu, now scrap metal).  The keyboards had several
extra keys for special uses (most were available for special use in
programs).  One of these was labeled ESCAPE (there was also an ALTMODE
that generated ASCII code 27 octal) and reserved for interacting with
the front end.  There were lots of mundane functions connected with
the key (e.g.  ESC-F for "finger" or "free" showed the current list of
users), but there were two that were special.  ESC-D operated the
electric lock on the door to the computer room (the entire ninth floor
of the building, which also included a number of hackers offices, the
rest were one floor down).  ESC-E summoned an elevator, it knew
whether your display was on the 8th or 9th floor and pushed the
appropriate button.  The time it took for an elevator to arrive from
the first floor in the dead of night was about the same as the time to
walk out to the lobby.  Initially these were only available from the
special consoles and worked directly off the front-end system, the
host had no real way of affecting this.

Then, in the late 70's, the AI Lab was developing a new style of
operation that used special purpose individual workstations (nobody
had invented the name workstation yet, as I recall, but that's what
they were) that were the predecessors of the Lisp Machines later
manufactured by Symbolics, LMI, TI, and others.  These workstations
needed some communications media that was faster than what we commonly
used then and the CHAOSnet was developed.  Based loosely on the Xerox
3Mbps Ethernet developed a little earlier, it ran at the blinding
speed of 10Mbps!  CHAOSnet was CSMA/CA (that's Collision Avoidance, as
opposed to Ethernet which only does CD, Collision Detection).  The
routers used in this net ran on LSI11 systems and the door controls
and elevator controls were moved to one of these boxes so that the
workstations could get the same functionality as the old displays
(they initially used the same keyboards and later an expanded version
referred to as the "Space Cadet" keyboard).  As the CHAOSnet expanded
around campus this meant that anyone could open the door or summon an
elevator, even outside the building and these were eventually
disconnected.

Another addition around this time was the Weather Computer and the
Weather Reporting Service.  The Weather Computer was an LSI11
(seperate from the routers, but only connected to the network) with a
parallel interface to a HeathKit (I think) weather station.  By using
a datagram protocol over the CHAOSnet any system could interrogate the
Weather Computer for the current info about inside and outside
temperature, pressure, and wind speed (actually, I think the "inside
wind speed" was hard coded as zero, we didn't buy two of these).  The
Weather Computer didn't have any state, it just engaged in a datagram
exchange where it read the current values and returned them.  Then a
daemon was written to run on one of the Labs timesharing systems which
interrogated the Weather Computer frequently and assembled longer term
information.  If you fingered "weather" on this machine you got back a
summary report of current and recent past readings, I believe daily
(today and yesterday) and weekly high/low/average for each value.


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

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

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 01:52:04 GMT
From:      vcerf@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   RARE Networkshop at Blois May 13-16, 1991 (France)



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

                      2nd European Networking Conference
                      ----------------------------------

                           Blois, 13.5. - 16.5.1991

                                Final Programme
                                ---------------

                               Organised by RARE
                             in collaboration with
               EARN, EurOpen, Internet Activities Board, NorduNet,
                 Ministere de la Recherche et de la Technologie



Monday, 13. 5. 1991
- -------------------


    Morning : Registration

    12h30 Buffet lunch


Plenary Sessions
- ----------------


    Opening
    -------
                                  Christian Michau, CNRS, Paris

    14h00 Opening Remarks
                                  Juergen Harms, Univ. Geneve
    14h10 Official Welcome
                                  Paul Quiles, Ministre des Postes,
                                  Telecommunications et de l'Espace
    14h30 The Challenge of Workstations to Networking
                                  Louis Pouzin, THESEUS, Sophia Antipolis
    15h15 The Challenge of Networking to Workstations
                                  Greg Chesson, Silicon Graphics, Mountain View

    16h00 Coffee


    The IT Campus
    -------------
                                  Howard Davies, Univ. Exeter

    16h30 The Networked Campus
                                  Bernard Levrat, Univ. Geneve
    17h00 Workstation to Internet : Problems, Solutions and Challenges
                                  Lee G. Caldwell, Novell, Salt Lake City
    17h30 Information Services on the Wired Campu
                                  Bruce Royan, Univ. Stirling

    18h00 Recess
          (18h30 : Welcome Reception City of Blois at the Palais des Congres)



Tuesday, 14. 5. 1991
- --------------------


Session Group A
- ---------------


    Funding and Policy
    ------------------
                                  Jaime Perez-Vidal, CEC, Bruxelles

     9h00 Organisational Structures for Providing International Services
                                  Klaus Ulmann, DFN, Berlin
     9h30 Transmission Services in a Deregulated Europe
                                  NN, France Telecom, Paris
    10h00 Acceptable Use Policy
                                  James Hutton, JNT, Didcot

    10h30 Coffee

    11h00 NREN : The Need for High Performance Services
                                  Bill Bostwick, Washington DC
    11h30 Report on the RARE High-Speed Networking Symposium
                                  Paul van Binst, Univ. Libre Bruxelles
    12h00 Expanding the Internet to a Global Environment.
          But ... How to Get Connected?
                                  Elise Gerich, Merit, Ann Arbour
    12h30 Lunch


Session Group B
- ---------------


    CONS / CLNS Interworking
    ------------------------
                                  Les Clyne, JNT, Didcot. Phil Gross

     9h00 Transatlantic Workshop : Background
                                  Les Clyne, JNT, Didcot
     9h15 Transatlantic Workshop : Reports and Recommended Actions
                                  Christian Huitema, INRIA, Sophia Antipolis
     9h50 Transatlantic Workshop : Agreed Policy, Subsequent Activities
                                  Phil Gros, CNRI, Washington DC

    10h30 Coffee


    Lower Layer Technology
    ----------------------
                                  Sylvain Langlois, EDF, Paris

    11h00 FDDI Concentrators and their Environment
                                  Michael Franzen, Siemens, Munchen
    11h30 TCP/IP Internetwork Communication Through LANs
          Interconnected by Dikon Meganet.
                                  Trond Arne Kongsli, FORUT, Tromsoe


    European Engineering Planning Group
    -----------------------------------
                                  Sylvain Langlois, EDF, Paris

    12h00 Presentation of the EEPG Report
                                  Kees Neggers, SURFnet, Utrecht

    12h30 Lunch


Plenary Sessions
- ----------------


    Network Management Strategies and Techniques
    --------------------------------------------
                                  Christian Michau, CNRS, Paris

    14h00 Management of the Operation of the NSF Backbone
                                  Elise Gerich, Merit,  Ann Arbour
    14h30 NORDUnet Experiences in Network Management
                                  Bernhard Stockmann, NORDUnet, Stockholm
    15h00 LAN Management by Cooperation : HP and the University of Geneva
                                  Charlie Solomon, HP Labs, Bristol

    15h30 Coffee


    Group Communication
    -------------------
                                  Claus Sattler, Akad. Wiss., Berlin

    16h00 Building Group Communication on OSI
                                  Steve Benford, Univ. Nottingham
    16h30 Supporting Collaboration in a Distributed Electronic Environment
                                  Pippa Hennessy, Univ. Nottingham
    17h00 Computer supported Cooperative Work;
          Origins, Concepts and Research Initiatives
                                  Paul Wilson, CSC, Slough

    17h30 Recess
          (20h00 : Gala Dinner at the Chateau de Blois)



Wednesday, 15. 5. 1991
- ----------------------


Morning : available for unscheduled meetings


Session Group A
- ---------------


    Applications and Services
    -------------------------
                                  Dennis Jennings, Univ. College Dublin

    14h00 The NSF X.400 Pilot Project
                                  Alf Hansen, Univ. Wisconsin
    14h30 Implementing an E-mail Fax Gateway from Scratch
                                  Peter Flynn, Univ. Cork
    15h00 The Integration of the X Window System
          and ISO Virtual Terminals for a "European Workstation Environment"
                                  John Dyer, JNT, Didcot

    15h30 Coffee

    16h00 Naming Strategies and Techniques
                                  Christian Huitema, INRIA, Sophia Antipolis
    16h40 X.500 Pilot Status
                                  David Goodman, Univ. College London
    17h05 The COSINE Information Service
                                  Graham Knight, Level 7 Ltd, Bracknell

    17h30 Recess
          (Evening : Dinner at the Caves de Montlouis)


Session Group B
- ---------------


    High Performance Strategies and Techniques
    ------------------------------------------
                                  Paul van Binst, Univ. Bruxelles

    14h00 Jargon Tutorial and Techniques
                                  John Burren, Rutherford Lab, Didcot
    15h00 Global WAN-MAN Architecture for the 90's
                                  Remy Despres, RCE, Paris

    15h30 Coffee

    16h00 From Megabits to Gigabits : Theory and Practice
                                  Francois Fluckiger, CERN, Geneve
    16h30 CHEOPS: Really Using a Satellite
                                  Brian Carpenter, CERN, Geneve
    17h00 Transport System for an Integrated Broadband Communication
          Environment Proposals of ESP
                                  Horst Westbrock, DETECON, Berlin

    18h00 Recess
          (20h00 : Dinner at the Caves de Montlouis)



Thursday, 16. 5. 1991
- ---------------------


Session Group A
- ---------------


    Multimedia Techniques
    ---------------------
                                  Robert Cooper, JNT, Didcot

     9h00 Facilities for Proposed Pilot Activity Using Office Document
          Architecture Facilities from University College London
          and the PODA Project
                                  Peter Kirstein, Univ. College, London
     9h30 Media Synchronization and High Speed Networking in MultiG
                                  Steve Pink, SICS, Stockholm
    10h00 Multimedia Workstations
                                  Jean-Louis Leonhardt, IRPEACS, Lyon

    10h30 Coffee


    Security
    --------
                                  Sven Tafvelin, Chalmers Univ., Gothenburg

    11h00 The X.500 Directory Service and the Data Protection Act
                                  Julia M. Hill, Herriot-Watt Univ., Edingburgh
    11h30 CERT - Computer Emergency Response Team
                                  Chris Harvey, Observatoire de Paris


Session Group B
- ---------------


    Protocol Interworking Techniques
    --------------------------------
                                  Vint Cerf, CNRI, Washington

     9h00 TCP-IP / OSI Interoperation
                                  Bernard Sales, Univ. Brussels
     9h30 DoD Internet Protocols and JANET
                                  Jon Crowcroft, Univ. College London
    10h00 Integrated Routing for Dual TCP/IP - OSI Environments
                                  Ross Callon, DEC, Littleton

    10h30 Coffee


    Distributed Systems
    -------------------
                                  Bernard Delcourt, RARE, Amsterdam

    11h00 Open Distributed Processing
                                  
    11h30 Remote Procedure Calls : a Stepping Stone to ODP
                                  David Robinson, DEC, Reading


Plenary Session
- ---------------


    Closing
    -------
                                  Klaus Ullmann, DFN, Berlin

    12h00 Closing Remarks
                                  Klaus Ullmann, DFN, Berlin

    12h15 Recess, buffet lunch

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 01:56:38 GMT
From:      vcerf@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   RARE Networkshop REGISTRATION Information


                      2nd European Networking Conference
                      ----------------------------------

                           Blois, 13.5. - 16.5.1991

                                Final Programme
                                ---------------

                               Organised by RARE
                             in collaboration with
               EARN, EurOpen, Internet Activities Board, NorduNet,
                 Ministere de la Recherche et de la Technologie


Registration
- ------------
 
 
REGISTRATION FEE
 
The registration fee covers: coach transfer from and to the
railway station (on May 13 and May 16), a collection of summaries
of presentations distributed in the Conference package, a copy
of the Conference Proceedings (to be distributed in Autumn, 1991),
entry to all sessions, refreshments daily, four lunches, the
Welcome reception on May 13 and the Gala dinner on May 14.
Please note that accompanying persons are welcome to attend all
social events but may not attend any of the technical sessions.
 
	EARLY Registration Fee	FF 2,200
	LATE Registration Fee	FF 2,500
 
The early registration fee applies to all fees received before
March 15th. Please ensure that your payment is made net of all
bank charges and in French Francs.
Please note that an administration charge of FF 40 will apply in
respect of cancellations received by us, in writing, before April 10.
No registration fees can be refunded in case of cancellations
received by us, in writing, after April 10.
 
Registration will take place in La Halle aux Grains at Blois,
on Monday May 13 from 9.00 to 14.00.
 
 
VENUE
 
The event will take place in the historic region of the "Chateaux
de la Loire" at Blois, France. The conference itself will be
organized in the ancient building of the "Halle aux Grains",
converted into a modern conference center with ample space for
small meetings in the margin of the conference. The conference aims
at an attendance of no more than 400 participants registered on a
first come - first served basis.
 
 
LANGUAGE
 
The official language of the conference will be English.
 
 
ACCOMPANYING PERSONS SOCIAL PROGRAMME
 
Monday May 13    	Evening - Welcome Reception
 
Tuesday May 14    	Visiting Beauregard, Cheverny &
Chambord Castles - FF 350 per person including lunch -
Departure at 09.30hrs from Blois in coach, first visit
of Beauregard Castle and its park. Then Cheverny Castle
which is a seigniorial house with sumptuous decoration
and furniture of the 17th century. At 12.15hrs, lunch at
'Les 3 Marchands' in Cheverny. In the afternoon, visit of
Chambord Castle, which is the biggest Castle of La Vallee
de la Loire, built by King Francois Ier. Back in Blois at 17.00 hrs.
 
Wednesday May 15	Morning - Visiting Clos Luce, Leonard
de Vinci House - FF 120 per Person (minimum 30 participants) -
Departure at 08.45hrs and back in Blois at 12.30hrs- afternoon -
Visiting Blois, the old town and the Castle - FF 75 per person
or, visiting Chaumont Castle which looks down upon the Loire
river, and its luxurious stables - FF 110 per person
(minimum 30 participants) -
			Evening - Dinner at 'Les Caves de Montlouis'
restaurant - FF 250 per person, including cocktail and coach from
and back to Blois.
 
All tours are based on a minimum of paying participants. In case
there are not enough participants, the right is reserved to cancel
the tour(s), in which case a full refund will be made.
 
 
ACCOMMODATION
 
Accommodation has been reserved in several hotels in Blois,
both 2** and 3*** categories and single and twin rooms.
Please note that no accommodation can be reserved without a
deposit of FF 500 per person and that an administration charge
of FF 40 will apply in respect of cancellation received by us,
in writing, before April 10th. Refund of FF 210 can be made in
respect of cancellations received by us, in writing, between
April 10th and May 10th. No refund can be made after May 10th.
For people wanting to travel during the week-end, some accommodation
will be possible for May 11 and May 12.
Rates include hotel service charges, government taxes and continental
breakfast:
		Sharing 	Single
		Twin Room	Room
		in FF per room	in FF
2**    	hotel  	260 - 450	210 - 390
3***  	hotel 	400 - 550	300 - 460
 
Hotel prices are correct at time of going to print. However, the
right is reserved to amend some of these prices should any increase
in hotel rates and/or Government taxes occur.
 
 
     GETTING TO BLOIS
 
By car  	Blois is 180 kilometers from Paris (Porte d'Orleans),
		driving on the autoroute direction Tours/Bordeaux
		until Blois.
By train	Trains depart from Paris/Austerlitz station at:
 
	06.25 -> 08.08 in Blois
	07.02 -> 08.45 (not on Saturday and Sunday)
	07.41 -> 09.09
	10.09 -> 12.01 (not on Sunday)
	12.00 -> 13.27
	13.48 -> 15.40
	16.43 -> 18.36 (not on Saturday and Sunday)
	17.15 -> 18.39
	17.47 -> 19.08 (not on Saturday)
	19.32 -> 21.12
	On Thursday May 16, trains depart from Blois station at:
	08.51 -> 10.33 in Paris
	10.29 -> 12.19
	12.17 -> 13.43
	13.40 -> 15.09
	15.37 -> 17.10
	16.40 -> 18.25
	17.28 -> 19.00
	19.05 -> 20.56
 
The above timings are given in good faith for delegates' assistance.
However, no responsibility can be accepted for changes in these
timings.
 
Coach transfers to the Conference location will be provided from
the station on Monday 13 May in the morning from 08.45 to 13.27
and on Thursday from the conference location to the station.
It is recommended that all delegates requiring a coach transfer
complete the relevant section on the registration form.
 
If you need more information, please contact Mrs. Denyset
by e-mail: Denyset@FRORS12.Bitnet
 
Please complete and return registration form to:
 
	2nd Joint European Networking Conference 1991
	La Halle aux Grains
	Place de la Republique
	41000 - BLOIS
	FRANCE
	Tel. : 	(33) 5474 2122
	Fax  :	(33) 5474 8261
	Tlx  : 	752 332 F (Ref: CNRS / JENC)
 
 
 
- ------------please cut here--------please cut here-------------
 
 
 
 
		REGISTRATION FORM
 
 
 
Only One Delegate Per Form (Please photocopy extra forms if required)
 
 
 
family name (1).........................first name ............Mr/Mrs
 
organization/company.................................................
 
postal address:	street..................city ........................
 
state/county ...................postal code .........................
 
country ........................e-mail ..............................
 
telephone:	office .................home ........................
 
		telex ..................fax .........................
 
 
accompanied by	(2) .................................................
 
		(3) .................................................
 
 
 
I require accommodation for ........... people as follows:
 
...............single room(s) ............... twin/double room(s)
 
Arriving May ........ Departing May ........  No. of nights ..........
 
Hotel PREFERRED:  2** O       3*** O    (Please mark)
 
 
I shall  arrive :   	by car		O
 
			by train 	O
 
I shall use coach transfer: 	on Monday May 13  	O
 
				on Thursday May 16 	O
 
 
 
PAYMENT:
 
1. by cheque in French Francs to 'CONGRES RARE'
2. by Bank Transfer in French Francs to:
    		CONGRES RARE
    		BRO BLOIS No. 10528 00001 01 00257893 C 26
     		Bank address : 3, rue Gallois - 41000 BLOIS - FRANCE
 
Please ensure payment is net of all charges and attach a copy of
your bank slip to assist us in matching this form with your payment.
 
Payment to cover:
 
..ONE Registration Fee (FF 2200/FF 2500 late)		       FF .......
 
..Ticket(s) for Dinner at Montlouis on May 15 @ FF 250 p.p.    FF .......
 
..Ticket(s) for Chambord/Cheverny tour on May 14 @ FF 355 p.p. FF .......
 
..Ticket(s) for Clos Luce tour on May 15 morning @ FF 120 p.p. FF .......
 
..Ticket(s) for Blois tour on May 15 afternoon @ FF 75 p.p.    FF .......
 
..Ticket(s) for Chaumont tour on May 15 afternoon @ FF 110 p.p.FF .......
 
..Accommodation Deposit(s) @ FF 500 p.p.                       FF .......
                                       				__________
 
							       FF .......
 
 
SIGNED :                                                         Date:
 
 
 
Please complete and return to:
	2nd Joint European Networking Conference 1991
	c/o Palais des Congres
	La Halle aux Grains
	Place de la Republique
	41000 - BLOIS
	FRANCE
 
	Tel.: 	(33) 5474 2122
	Fax:	(33) 5474 8261
	Tlx.: 	752 332 F (Ref: CNRS/JENC)

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 03:15:29 GMT
From:      RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith)
To:        comp.protocols.tcp-ip
Subject:   tn3270 key mapping for DECstations

Has anyone devised a key mapping for tn3270 on DECstations that takes
advantage of the function keys on the keyboard?  I would love to
received a copy of the map file if you have.  Many thanks in advance.

                                           --Bob Haring-Smith
                                             rhh@brownvm.brown.edu
                                             401-863-1982

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 03:33:31 GMT
From:      proberts@disk.uucp (Phil Roberts)
To:        comp.protocols.tcp-ip
Subject:   Re: whereis service needed

kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz) writes:


> > From tcp-ip-RELAY@nic.ddn.mil Wed Apr 10 18:08:51 1991
> > From: hal@gateway.mitre.org
> > To: tcp-ip@nic.ddn.mil
> > Subject: whereis service needed
> > 
> > 
> > Here the issue:
> > 
> > I am seeing fully qualified domain names with parts I don't recognize.
> > Not that these are wrong but just unfamilar. It would be useful to
> > have access to a server of some kind that would map fragements of a
> > domain name into an geographical location by political subdivision.
> > This might be a useful extension to the current domain names system.
> > Any thoughts??
> > 
 
>WHOIS does a reasonably adequate job of starting one on
>one's way -- for domains that are registered at the NIC.

[[ His domain listing deleted. ]]

I thought the NIC was for the Milnet only.  Am I understanding you correctly
that the NIC can also provide me with domains outside the Milnet?  If that
is true, how does one go about finding a site when one doesn't have Telnet
capability?

-- 
  ***************************************************************************
                         |
  Phil Roberts           |      Internet:  proberts@disk.uucp 
                         |          

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 03:41:08 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   packet driver on ODI converter


	A new version of the PD-on-ODI converter is available
for anonymous ftp from husc6.harvard.edu in pub/odipkt.  All 1.09
functions are now implemented but note the following:

-reset_interface and set_address always return failure.

-as_send_pkt is as described in the 1.09 spec--this probably
isn't what you want.

-set_rcv_mode claims success but the ODI interface doesn't allow
control of receiver mode anymore.  (However multicast support *does* work.)

	Operation has been tested for blue book and 802.3, but not
for 802.5.  As I have received no feedback about the last version
I'll assume it was bug-free (or unused :).

				Dan Lanciani
				ddl@harvard.*

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 07:00:12 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the data received using recvfrom() in SOCK_RAW fragmented by IP?

In article <912473B7FC7F400347@nusdiscs.bitnet> TAYBENGH@NUSDISCS.BITNET (THE AGEIS) writes:
>
>Hi netlander,
>        In BSD socket, one can implement a new protocol on top of IP using
>SOCK_RAW with the designated protocol number. Then, one can receive the
>data using recvfrom() call. The recvfrom() returns the data with the IP header.

Correct. Remember to set the proper protocol type in the third field
of the socket(2) call. There is a kernel patch (see, e.g., the
distribution notes for traceroute) so that if you set IPPROTO_RAW,
you place your own IP header in the packet you are sending rather than
rely on the system for it. This can be useful, e.g., for sending your
own options. In 4.3Reno (at least), you can also accomplish that by
setting the RINPF_HDRINCL flag. 

>So far so good. But if the sender sends large amount of data in one single
>send(), and the IP layer needs to fragment the data to a few packets, then
>can we receive the data in onr single recvfrom() [Note: this implies the IP
>layer on the receiver side re-assemble all the packets b4 passing the data
>up to us]? 

All of the above. When send-ing the packet, the IP layer will fragment
the datagram if you are trying to send a packet larger than your MTU.
A limitation you may come up against is the send buffer size (2K by
default). You can change that by setting the appropriate socket-level
option, as in the following code:

	...

 	int bufsz=16384; /* send messages up to 16K in length */
	int sd;
	
	sd = socket(AF_INET, SOCK_RAW, 42);
	if (sd < 0)
	  perror("rawsocket"), exit();

	if (setsockopt(sd, SOL_SOCKET, SO_SNDBUF, &bufsz, sizeof bufsz) < 0)
	  perror("setting options"), exit();
	
	....
	
	
Upon receipt, if the receive buffer size is large enough (again,n
settable with the SO_RCVBUF option), the IP layer will reassemble your
packet and pass it to you. Remember that when the raw socket interface
passes you a packet back, the ip_len field contains the length of the
*protocol* part of the packet (i.e., total length - IP-header lenght),
and that all sizes are in host order (network addresses are still in
network order).

>         Or do we need to take care of the fragments ourself by inspecting
>the IP header and do re-assemble if necessary?

I don't think you can do that even if you want. 

>        Which one is true? Could somebody shed some light on me please?
>        Thanks a lot.
>
>- Beng Hang (email: taybengh@nusdiscs.bitnet)

I hope that's enough light! 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 17:04:33 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP programming library for PC's

FTP Software's dev kit costs (I think) about $500, but you can license
a kernel-and-configuration-only run time for around $150 or so. (You
better verify those numbers; it's been a while since I knew them for
sure) You can ask info@ftp.com for more details. The dev kit includes
sockets.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 17:18:18 GMT
From:      csu@alembic.acs.com (Dave Mack)
To:        comp.protocols.tcp-ip,comp.dcom.modems,alt.sys.sun
Subject:   Looking for PPP Connection in DC Area

I am looking for someone in the DC area (local phone call from
Northern Virginia) who is interested in establishing a Point-to-
Point Protocol dialup connection. I would prefer someone who knows
more than I do about PPP, but if not, I guess we'll learn together.
I would also prefer a V.32 connection (or PEP, but I hear that doesn't
work so well.)

If you're interested but don't have the software, I can provide a
version of the Clement/Fox PPP software for Suns running OS4.x.
I also have an older version that allegedly runs on Vaxen under
BSD4.3, but I've never tried it. Finally, I have a copy of the
KA9Q package that includes PPP support. I've never tried that, either.
(Note: installation of anything other than the KA9Q package requires
a kernel rebuild, so you have to have root privileges.)

Any takers?

(For those who don't know, PPP is a data link layer protocol that
allows packet transport across serial lines. Its advantage over
SLIP is that it can be used with protocols other than IP and it provides
link and network control protocols. The PPP specification is contained
in RFC1171.)

-- 
Dave Mack
csu@alembic.acs.com
uunet!alembic!csu
(703)883-3812 (work)
(703)734-0877 (home)

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 19:41:06 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP programming library for PC's


   Reply-To: romkey@asylum.sf.ca.us
   Date: 13 Apr 91 10:04:33 PDT (Sat)
   From: romkey@asylum.sf.ca.us (John Romkey)

   FTP Software's dev kit costs ...

Sorry, I didn't mean to CC: that to tcp-ip...the mailer got the better
of me.
	- john

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 23:05:50 GMT
From:      fair@Apple.COM (Erik E. Fair)
To:        comp.protocols.tcp-ip
Subject:   Re: What Is Difference Between Internet And X.400 Style Names?

There is a good reason to have the transport address show through
everywhere, in the same format, like the Internet domain names do now:

It keeps the users from getting confused when they talk to each other,
and exchange business cards.

When I tell you that my address is "fair@apple.com", there is no
question about that on the Internet, or any other place that
(sensibly) accepts domain addresses. If I have to know what network
you're on (or worse, what mailer you use!) before I can give you my
address, then the design of the mail system is wrong.

	X.400 is the mail system of the future,
		and I hope it stays that way.

	Erik E. Fair	apple!fair	fair@apple.com

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Apr 91 23:40:05 GMT
From:      sardella@strfleet.gsfc.nasa.gov (Tom Sardella)
To:        comp.protocols.tcp-ip,comp.sys.novell,comp.realtime
Subject:   Excelan EXOS TCP/IP Software Problems


I am working with a custom embedded front-end system that I developed in 1986
which provides a bridge between some special purpose NASA data communication
circuits and a VAX computer.  Ethernet TCP/IP is used as the interface between
the front-end and the VAX.  The TCP/IP implementation on the front-end consists
of Excelan 201 intelligent Multibus controllers running the EXOS 8010 TCP/IP 
version 3.2 code.  This code runs on the EXOS 201 board.  We used the host
development package, which provides Unix host driver source code, to develop
a driver on the front-end host processor (Heurikon HK68ME 68000 board) running
under the VRTX real-time kernel to simultaneously operate 2 controllers.

TCP communications with the VAX have worked flawlessly with this configuration.
However, we have adapted this front-end for use with a MASSCOMP 6600 and have
had problems with the 8010 TCP/IP crashing when the MASSCOMP closes and then
reopens the window.  I was able to fix the problem by copying the version 3.3
TCP code from their PC-based product, an EXOS 205 board (it appears that
exactly the same code runs on all their boards), to the Multibus EXOS 201
board.  Further investigation found that buffer management problems with
version 3.2 were causing an EXOS PANIC and that version 3.3 fixed those
problems.

With that as background, this is my real problem:  I would like to avoid 
problems in the future caused by running old buggy versions of this TCP/IP
software.  I would like to get hold of the latest available version along
with the source code and other documentation (Application Notes on the Bus 
and Message-Level Interface) that are needed for developing and maintaining
the host device driver.  I'd also like to have the proper license to use it.
However, with Excelan having been acquired by Novell, I have had a difficult
time finding anyone that supports this code in any manner.  A couple of
years ago we couldn't even get a straight answer from Excelan on whether
we could purchase licenses to make additional copies of the software.
From what I've seen of Novell's product line, this on-board TCP/IP code
doesn't seem to be used at all anymore.

Even if we can't find current support for this product, I'd like to get the 
latest released version along with the documentation I mentioned.  Switching
to a different product would be a very expensive proposition at this point
and there aren't many vendors that support dual controllers.

Does anyone have any suggestions?  Please email as our news server seems to
have been having problems recently.  I'll post a summary if there is 
sufficient interest.  Thanks in advance.


			Tom Sardella
			Network Control Systems Branch, Code 532
			NASA/Goddard Space Flight Center
			Greenbelt, MD
			sardella@strfleet.gsfc.nasa.gov

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 00:33:33 GMT
From:      jrc@brainiac.mn.org (Jeffrey Comstock)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q SMTP Config problem

In article <1991Apr10.152522.2472@cs.wayne.edu> BHOLMES@CMS.CC.WAYNE.EDU writes:
>I'm trying to get SMTP in KA9Q to work, but without success.
>I can FTP in using the id in /ftpusers, but SMTP sends back:
>
>452 Temp file write error
>
>After issuing a SMTP '.' to close the message.   Can anyone offer advice?


Have you created the following subdirs ?

\spool
\spool\mqueue
\spool\rqueue

They must be present for it to work.  
-- 
Jeffrey Comstock
Work jrc@c2s.mn.org
Home jrc@brainiac.mn.org
Ampr nr0d@nr0d.ampr.org

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 02:52:53 GMT
From:      cryptkpr@cc.utah.edu (H. CARLTON DOE III)
To:        comp.protocols.tcp-ip
Subject:   Return mail routed to root mailbox, HELP!

I have just installed tcp/ip on my network of AT&T machines running SysV
3.2 and SysV 4.0 and have run into a couple of problems.

	1. I can send mail _to_ users on the SV 4 machines but they
	   can't send mail out.

	2. Users can send and receive mail between the SV 3.2 machines
	   provided they invoke the mailx command for each message they
	   want to send.  If, in reading their mail, they try to respond
	   immediately to the message from within mail, their response
	   is routed to the root mailbox of the machine they're on.  In
	   looking at the headers of the messages that are coming across
	   the net, it appears the mail is first being received by root
	   then routed to the addressed user.

Any help in fixing these problems would be appreciated.

    the Crypt Keeper
    aka Carlton Doe
    at Spectrum Field Services
===========================================================================
                                   |  WARNING!  This is only a test!  Had 
     cryptkpr@cc.utah.edu          |  the above been an insightful or
     cdoe@peruvian.utah.edu        |  original thought rather than a waste
            or                     |  of bandwidth, you would have been told
     attmail!alexis!carlton        |  where to tune in your area for official
                                   |  news and information.  I repeat, this is
                                   |  only a test!

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 03:08:09 GMT
From:      PLS@cup.portal.com (Paul L Schauble)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10baseT Installation costs

I think I missed the beginning of this discussion....

When you say 10BaseT is cheaper, what are you comparing it to?

    ++PLS

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 03:55:31 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP benchmarking

In article <9104120230.aa07219@SPARK.BRL.MIL>, reschly@BRL.MIL ("Robert J. Reschly Jr.") writes:
> 
> > First try the 4.3BSD `ping -l9999999 target` and look at the packet rate.
> >
>    ...but before you do that, be sure your mbuf code is fixed.  On BSD
> systems of early 4.3TAHOE vintage or earlier, you could get an mbuf
> panic from all those unprocessed ICMP Echo Replies.


I'll take your word for that.

To really test things, you don't want the replies cluttering up the net,
causing collisions.   I forgot to mention that you want to add a suitable
entry to your ARP cache so you can blast something that won't blast back.
And the best 9.6 usec numbers need an otherwise quiet net.

Of course, these fun games would be considered denial-of-service attacks by
anyone trying to use the ethernet for real work.


Vernon Schryver,   vjs@sgi.com

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 05:01:54 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: What protocol is used for leased lines?

The problem with what to run on leased lines is an old one.  Until PPP
there simply was no standard.  You ran what your router vendor gave
you or you ran SLIP over an async link.  Interoperability was limited
to SLIP and because SLIP runs only on async links, you were limited to
relatively slow speeds. 

Now you did not mention your hardware base so I can't comment too
much.  If you are trying to plug directly into an async serial port on
a workstation, your speeds and options are limited.  If you are
establishing connections between routers that is a different story.

You mention DSU's but you also mention RS-232.  Usually when someone
mentions a DSU he/she is running a 56Kbps or T1 synchronous link, the
former being only marginally compatible with RS-232 (the official
"top-speed" of RS-232 is 20Kbps but you can push it to 56bps) and the
latter is totally incompatible with RS-232.

All of that aside, I would consider adopting PPP as your
point-to-point link protocol.  It will run on either sync or async
lines.  PPP is supported by just about all of the router manufacturers
for their synchronous serial links.  It can also be used on
asynchronous links too so it is a win all around.  There are public
domain versions of async PPP floating around so you can put a network
together on a shoestring budget.  

Actually, you are going to be out of pocket quite a bit if you are
talking about leased lines so you might as well do it right and get
good routers to tie the whole thing together.  Run sync PPP.

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

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 05:53:43 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   Re: Help designing address allocation in a metronet


GAK!  You certainly can eat up a lot of address space using SLIP
links.  The problem is inherent in the "an IP address per interface"
and in the "everybody in a (sub)net must share the same (sub)net
number" concepts.

In spite of the fact that it violates tradition and the router
requirements RFC, we chose not to assign a unique IP address to each
interface in the Telebit NetBlazer dial-up router.  The SLIP or PPP
links do not need their own unique IP address and, in fact, all
interfaces are allowed to share the same IP address.  This GREATLY
reduces the number of (sub)nets required to build a network.

The trick that we use is to use an interface name in the routing table
rather than the gateway address to determine which interface to use.
We count on the fact that in a point-to-point SLIP or PPP connetion
there can be only one destination for a packet that is shoved into one
end of a link.  Therefore we really do not care what the IP address is
on either end of the link.  We trust that the remote peer will behave
in a router-like manner and forward the packet along the way toward
its ultimate destination.

Bottom line is that it works and doesn't eat up address space.
-- 
Brian Lloyd, WB6RQN                              Telebit Corporation
Network Systems Architect                        1315 Chesapeake Terrace 
brian@napa.telebit.com                           Sunnyvale, CA 94089-1100
voice (408) 745-3103                             FAX (408) 734-3333

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 05:59:16 GMT
From:      gah@hood.hood.caltech.edu (Glen Herrmannsfeldt)
To:        comp.protocols.tcp-ip
Subject:   Re: How to set up subnets where logical subnet != physical subnet

More than one subnet on a physical cable....

This is possible.  I understand that cisco routers actually know
how to do this.  Otherwise, the two interface method.
THe two interface method does not work for machines that assign
the same ethernet (hardware) address to all ports on the machine.
Suns do this, I don't know about others.

The next possible problem is that some machines (suns, again)
complain if they see routing packets for the wrong subnet.
This can probably be fixed in syslog.conf, but is something to
know about.  THe messages appear on the console, ordinarily.

Here, we have more than one subnet on one cable, in anticipation
of splitting it when a new router arrives.  All except one are
not broadcasting routes, so that static routing must be used.u!

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Apr 91 18:32:45 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Machine names and trademark law

I have a strange question:

Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a
trademark or a registered trademark, e.g., the name of a video game, a
brand of consumer electronics, the make of an exotic car, or the name
of a computer manufacturer. Have I violated trademark law? 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 20:17:52 GMT
From:      ho@hoss.unl.edu (Tiny Bubbles...)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Machine names and trademark law

ji@cs.columbia.edu (John Ioannidis) writes:

>Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a
>trademark or a registered trademark, e.g., the name of a video game, a
>brand of consumer electronics, the make of an exotic car, or the name
>of a computer manufacturer. Have I violated trademark law? 

I hope not.  Remember, Zilog trademarked the letter "Z" and Microsoft
trademarked the letters "MS" when placed next to each other.

Thus naming anything "ZOOMS" would be a double trademark infringement.

I'm probably wasting my time posting this, as our news server doesn't seem
to be letting mail out of the University of Nebraska-Lincoln.
--
        ... Michael Ho, University of Nebraska
Internet: ho@hoss.unl.edu  |  Harry was too homely for Sally.  (I have proof.)
Disclaimer:  Views expressed within are purely personal and should not be
	     applied to any university agency.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Apr 91 21:16:31 GMT
From:      jkrey@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   re: Where does one get old RFCs?

Hank,

Many of the early RFCs were never on-line files.  No concerted effort 
was made to capture on-line versions of those that were.  Hence, very few 
of the RFCs before about RFC 500 are available on line.

Joyce and --jon.

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 02:39:47 GMT
From:      mcitron@phad.hsc.usc.edu (Mark Citron)
To:        comp.protocols.tcp-ip,comp.unix.xenix.sco
Subject:   "expect" for SCO unix

Does anyone have an executable copy of the expect program that 
runs under SCO Unix? It seems like a valuable utility but it is
beyond me to compile it under SCO.

Thanks for any help or suggestions,
Mark Citron
Childrens Hospital Los Angeles

-- 
Mark Citron
mark@neurosci.usc.edu

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 10:23:32 GMT
From:      barrett@Daisy.EE.UND.AC.ZA (Alan P. Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: How to set up subnets where logical subnet != physical subnet

In article <1991Apr10.063716.9725@cs.columbia.edu>,
ji@liberty.columbia.edu (John Ioannidis) writes:
> >router to present miltiple IP addresses without plugging in extra
> >network cards.  This would be an alternate solution that would not
> 
> CISCOs can do that. On BSD-derived Unixes, [you probably can't do it].

PC-Route can do that, if you get the declare.inc file right, which is
not very difficult.  However, the documentation doesn't even mention
that this is possible, much less explain how to do it.

OK, now a question for the standards folk.

Section 2.3 of RFC791 (the IP standard) has this to say:

rfc791> Care must be taken in mapping internet addresses to local net
rfc791> addresses; a single physical host must be able to act as if it were
                                          ^^^^
rfc791> several distinct hosts to the extent of using several distinct
rfc791> internet addresses.  Some hosts will also have several physical
rfc791> interfaces (multi-homing).

If the word "must" here really means MUST in the Host-Requirements
sense, then shouldn't all IP implementations allow a host to present
multiple IP addresses without having multiple interfaces?

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

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 12:16:01 GMT
From:      randall@Virginia.EDU (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: universality of Latin-1


Ran Atkinson originally wrote:
% Fortunately there are a number of possible transport mechanisms out
% there to choose from, some of which are already 8-bit transparent.

In article <1991Apr12.124741.11555@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes:
>Ack!  "Fortunately"?  There is an ancient curse:  "may you live in interesting
>times".  I think it's modern equivalent is "may you have many standards to
>choose from".  

I said what I meant, namely that there are several different transport
MECHANISMS (i.e. sendmail, MMDF, PMDF, etc.) not several different
transport PROTOCOLS.   The whole of the Internet uses the same mail
protocols and that is a good thing, but the availability of different
mechanisms to implement those protocols is also a good thing.  Especially
since some of the mechanisms are already 8-bit transparent, though not
all are.

I would like to see the 8-bit transparency with some kind of character
set definition be added to the protocol more rapidly than Eliot seems
to think likely.

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 15:40:36 GMT
From:      eric@picard.sbi.com (Eric Ho)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip,comp.sys.mac.comm
Subject:   printing to Mac printers....

Hi,

Can anyone give me some pointers on freeware on sending print jobs from Unix
machines to printers hooked to Macs where the Macs are connected to the
ethernet via Gatorbox'es ?  I've done setup the other way round -- sending Mac
print jobs to Unix printers (and at that time I also heard of solutions to
send Unix print jobs to Mac printers but I forgot what those packages are and
where to get them).

Any poniters appreciated.

--

==========================================
+ Eric Ho                          Email: eric@sbi.com
+ Salomon Brothers, Inc.  [SISS]   Phone: (201) 896-4356
==========================================

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 15:59:39 GMT
From:      reschly@BRL.MIL ("Robert J. Reschly Jr.")
To:        comp.protocols.tcp-ip
Subject:   Re: RARE Networkshop at Blois May 13-16, 1991 (France)


      Vint,

   Thanks for posting the agenda.  I must say, this RARE conference
looks well done.

				Later,
				    Bob

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 16:00:55 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   Sniffer


Thanks to all who replied about my Sniffer question....

Does anyone have a contact name or name at Network General?  I need
to call about local dealers...are they on the Internet?

Please respond by 3:00pm EST....under a budget crunch!

Thanks,

Bryan Miller
bmiller@cabell.vcu.edu

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 16:55:08 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

In article <1991Apr12.023620.6227@Citicorp.COM> dsamperi@Citicorp.COM (Dominick Samperi) writes:
>My organization is considering the use of twisted pair point-to-point
>connections as an alternative to thin wire Ethernet... little
>tolerance for network failures (a trading floor)...

You might want to go have a look at comp.dcom.lans, where 10BaseT (standard
twisted-pair Ethernet) has had considerable discussion of late.  This isn't
really a Unix or TCP/IP issue.

(To sum up the c.d.l discussions excessively tersely...  10BaseT works well.
Relative costs are somewhat debatable; there is no huge difference, but
thinwire may still be somewhat cheaper.  10BaseT is parsecs ahead on
reliability for complex networks with large user communities, because
its star topology tends to localize failures to a single machine, whereas
thinwire takes down a whole network segment when one ignorant clod unplugs
or damages a connection.)

>Is there a throughput/bandwidth hit in using twisted pair? ...

There are slower twisted-pair technologies in use, but 10BaseT is Ethernet
in all respects as far as performance goes.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 17:01:56 GMT
From:      jessea@homecare.uucp (Jesse W. Asher)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Sources for PPP wanted.

I'm looking for 1) a public domain version of PPP what will run on a
Sparcstation, Sun Server, and 386 based unix, and 2) information about
commercial versions (where to get them) the same as #1.  I can ftp the
public domain versions (in other words, ftp site suggestions welcome).
Thanx for any suggestions on this.

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

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 17:03:43 GMT
From:      ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun Technical Marketing - Boston)
To:        comp.protocols.tcp-ip
Subject:   Re: How to set up subnets where logical subnet != physical subnet

In article <gah.671608756@hood> gah@hood.hood.caltech.edu (Glen Herrmannsfeldt) writes:
>More than one subnet on a physical cable....
>
>This is possible.  I understand that cisco routers actually know
>how to do this.  Otherwise, the two interface method.
>THe two interface method does not work for machines that assign
>the same ethernet (hardware) address to all ports on the machine.
>Suns do this, I don't know about others.

Some machines default to using the same Ethernet address on all
interfaces, some default to using different Ethernet addresses on all
interfaces, and some don't allow you to override the default with
whatever you really want.  Sun machines have flip-flopped their default
behavior, since half the world is unhappy if the default is one way,
and the other half the world is unhappy if the default is the other
way.

More important than the default is that Sun machines don't _force_ you
do do it either way -- you're welcome to override the default to meet
your needs.

cheers!
---
chuck kollars    <ckollars@East.Sun.COM>
Sun Technical Marketing, located in Sun's Boston Development Center

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 17:08:09 GMT
From:      spgdrp@GANGES.UCOP.EDU ("Donald R. Proctor   spgdrp@ganges.ucop.edu")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 key mapping for DECstations


  Has anyone devised a key mapping for tn3270 on DECstations that takes
  advantage of the function keys on the keyboard?  I would love to
  received a copy of the map file if you have.  Many thanks in advance.

  --Bob Haring-Smith
  rhh@brownvm.brown.edu
  401-863-1982

Gee, I'd even settle for the cursor keys (and maybe more reasonable
handling of highlighted screen characters).  Would you send me a note if
you get replies to this?

Thanks, Don.

Donald R. Proctor			<spgdrp@ganges.ucop.edu>
University of California		<spgdrp@uccvma.bitnet>

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 17:11:15 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Machine names and trademark law

In article <1991Apr14.183245.345@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
>Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a
>trademark or a registered trademark, e.g., the name of a video game, a
>brand of consumer electronics, the make of an exotic car, or the name
>of a computer manufacturer. Have I violated trademark law? 

Caution:  I am not a lawyer.  Consult a pro before doing anything rash. :-)

The idea behind trademark law is that a trademark denotes a particular
vendor's product, so that it will not be confused with competing products.
The theory is that you infringe on someone's trademark only when you use
it in a way that could cause such confusion.  The practice is that different
companies have very different ideas about what constitutes potential for
confusion, and being sued is painful and costly even if it fails.

In practice, the odds are that nobody would care.  The odds are good that
if anyone did care, they'd send you a nasty letter saying "change those
names or we'll sic our lawyers on you".  This still wouldn't be fun, mind
you.  Me, I'd be wary of using names that have anything to do with
electronics, but the exotic cars sound reasonably safe.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 17:44:40 GMT
From:      osh@jhereg.osa.com (John M. O'Shaughnessy)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

Twisted Pair networks are likely to cost more in terms of hardware than
thin Ethernet networks because they require a concentrator, and you can't
daisy chain stations.  

Twisted Pair 10Base T may save you money in installation costs if the
wiring in your facility is up to spec, and if you have enough spare pairs
to use for Ethernet (2-pairs).

We have found twisted pair networks to be much more reliable due to the
terminal-hub nature of the network connection.  One station's problems
won't affect anyone else.  There are also a number of management tools
available frm the concentrator manufacturers that help you to manage the
network, keeping track of usage, etc.

In an area not staffed with technical people, users appreciate the simple
telephone cord-like connection as opposed to a cable TV like coaxial
connection.

I still prefer thin Ethernet for lab areas, or other areas with many
machines in close proximity, but for the office environment, we almost
always choose twisted pair 10BaseT Ethernet.

John


-- 
John M. O'Shaughnessy            osh@osa.com
Open Systems Architects, Inc.    Minneapolis, MN

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 18:19:31 GMT
From:      lyndon@cs.athabascau.ca (Lyndon Nerenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP problems under SunOS 4.1.1

karl.kleinpaste@osc.edu writes:

>Note that there exist both -01 and -02 versions of this fix; install
>-02 to be maximally up-to-date.  The README for -02 notes that the -01
>version didn't deal in IP options properly.

Note that there now exists a -03 version of said patch :-)

>100149-02.tar.Z can be ftp'd from saqqara.cis.ohio-state.edu:pub/slipware.

100149-03.tar.Z can be ftp'd from ftphost.cs.athabascau.ca:sun-patches/

-- 
    Lyndon Nerenberg  VE6BBM / Computing Services / Athabasca University
           atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca
                    Packet: ve6bbm@ve6bbm.ab.can.noam
      The only thing open about OSF is their mouth.  --Chuck Musciano

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 20:56:51 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: 10baseT Installation costs

In article <41255@cup.portal.com> PLS@cup.portal.com (Paul L Schauble) writes:
>I think I missed the beginning of this discussion....
>
>When you say 10BaseT is cheaper, what are you comparing it to?
>
>    ++PLS

To this point, the main contender has been ThinNet (RG58 Coax), since it
does not require a Hub. I think 10baseT is better because it is physically
more reliable, and easier to connectorize and maintain. The wire is
cheaper, too.

Hey folks, I've noticed hubs are getting down in the $50/port range. Where
does that put us with this discussion? Are you ThinNet types gonna go away
and cry in your cornflakes yet? :-) (Just kidding, I like ThinNet too.)
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 21:27:33 GMT
From:      ash@omega.UUCP (Andrew Hardie)
To:        comp.protocols.tcp-ip
Subject:   Novell 802.3

There was some traffic on the net a month or so ago about Novell 802.3
packets (datagrams, I think, to be accurate), with the comment that these,
to *really* be OSI conformant, should have inside them an 802.3 header
and a SNAP field. The penny only dropped on me about this one after reading
something this week. Does this mean that Novell's "OSI Support" is just
protocol tunnelling of IPX inside 802.3 packets and that all that has
actually been done is to change from an Ethernet packet with a type
field of 8137, useful for separating it from TCP/IP, and replaced it
with an 802.3 packet by putting in the ISO "length" field the protocol
doesn't actually need in order to operate?
This all sounds a bit marginal to me, or have I got the wrong end of
the stick here? 
Andrew
-- 

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

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Apr 91 22:11:32 GMT
From:      rrj@hpctdjl.HP.COM (Roger Jones)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP site for RFCs?


> Is there an FTP site with RFCs? I'm kinda interested in seeing the
> protocol specs for the stuff I'm using, but I'm just a student (not
> even a CS student at that :-), so I don't have any clue about who
> handles this stuff.

  Try to ftp to  nic.ddn.mil, which is 192.67.67.20. This is the main
  source for rfc's. Use the user anonymous and your ident as a password.
  cd to RFC:  <--- the colon is important. The file rfc-index.txt
  is the key to all of the files. If you "get" the files using lower
  case representation it will create a file locally with lower case, my
  personal preference.

  Here is part of the 00readme file from there.

  Welcome to the DDN Network Information Center!  The following public
  directories are located on the NIC.DDN.MIL computer system:

  DDN-NEWS:          DDN Management Bulletins and DDN Newsletters
  IEN:               Internet Experimental Notes
  INTERNET-DRAFTS:   Internet Engineering Task Force (IETF) Idea Papers
  NETINFO:           Contains Admin. notes, Documents, Host/TAC info,
	       Domain/Internet info, PC/Kermit info, NSC/HA lists,
	    Network program info, DDN Vendors Guide and DDN New Users Guide
 NETPROG:           Network programs for WHOIS, HOSTNAME, getting the NIC
                    host table and host table compiler
 PROTOCOLS:         Network Protocols Information
 RFC:               Requests For Comments

  To get a listing of filenames within one of these directories while using
  FTP, use the "dir" (directory) command, as in "dir RFC:".

  Each directory contains an index or indexes to the files within that
      directory:

  DDN-NEWS:DDN-NEWS-INDEX.TXT

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 00:31:56 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        comp.protocols.tcp-ip
Subject:   connection from remote host


Hi,
	Is there a way under Unix (esp. SunOS 4.1.1.) to check from which
host a user is logging in from and limit logins to a particular set of hosts
or domains. This would be handy for setting up secure nopassword logins. With
irises a REMOTEHOST variable is set which can be user. No such variable
is defined with our Suns.


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

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 00:34:15 GMT
From:      wb8foz@mthvax.cs.miami.edu (David Lesher)
To:        comp.protocols.tcp-ip,misc.legal
Subject:   Re: Machine names and trademark law


>>Suppose I name a machine "foo.cs.columbia.edu", where "foo" is a
>>trademark or a registered trademark, e.g., the name of a video game, a
 
>The idea behind trademark law is that a trademark denotes a particular
>vendor's product, so that it will not be confused with competing products.
>The theory is that you infringe on someone's trademark only when you use
>it in a way that could cause such confusion.  

On the other hand, guess (;-}) which aerospace firm sued the
two-bit manufacturer of the:
	Stealth Condom - They'll never see you coming!

No cheating, now, class...........

-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 03:48:19 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Request For Info On Dynamically Acquiring IP Addresses At Boot

Can someone give me a reference to any research or commercial products
that attempt to solve the problems of 1) allowing a PC or workstation
to dynamically acquire an IP address at boot time, and 2) making it
easier to install IP on a PC or workstation (i.e., an attempt to make
things in general more dynamic so that each client doesn't have so
much static information hard-coded into it at install time).

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

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 05:19:28 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP problems under SunOS 4.1.1

In article <1991Apr12.140605.29819@oar.net> karl.kleinpaste@osc.edu writes:
>brett@solar.card.inpu.oz.au writes:
>I've written a note about the problem to sunbugs@sun.com, but since it
>involves use of a non-standard driver, I doubt it'll get much
>attention.  Before installing 100149-02, I consistently got "panic:
>mclput" whenever substantial amounts of data would begin to transfer.

I have been using SLIP 4.0 on SLC's under 4.1.1 for about three weeks now
and have run a goodly number of megabytes through them.  I saw this mclput
panic fairly frequently for a while and then saw a real high correlation
with the answering side of the connection (I'm using dialup over T2500's)
panicing when the connection was dropped.  When I switched to V.42 mode
the panic's went away.  My feeling is that the utter garbage you get
when the other side hangs up is confusing the TCP routines incredibly
since they aren't used to being fed complete crap.

--
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 07:20:26 GMT
From:      rup@guug.guug.de (Rupert Grafendorfer)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.iso
Subject:   MOP Protocol implementations

Does anybody know about implementations of MOP for non-DEC PC-controllers
for remote booting. I once heard about a implementation at MIT, but I lost
the mail-adress.

Any help (even just hints or ideas) are welcome. Please mail me.

Thanx.
-rup

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 10:50:51 GMT
From:      rainer@hwsw.gedas.de (Rainer Raupach)
To:        comp.protocols.tcp-ip
Subject:   PD-SNMP-software

Hi net.lan.ders,

we have a company-X.25 network currently working with DECNET and SNA/3270
X.29 ... and installed some ciscos for testing. We are now
purchasing some more ciscos with X.25, Ethernet and FDDI for use
in the inhouse as well as the wide area net.
For general network management we need some SNMP-software. Is there
some PD-software somewhere?
Hardware is a SUN Spark, X11 is installed.

Rgds Rainer 
-- 
---
Rainer Raupach		Internet: rainer@hwsw.gedas.de
Network Coordinator	X.400:	S=RAUPACH C=DE A=DBP P=VW-GEDAS
VW-GEDAS Berlin, GER 	Phone:	+49 30 39007-629  / FAX : ext -999

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 12:46:29 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Goofy Router?

Several points to consider.  Afsc-bmo.af.mil is at 131.62.71.1 rather than
132.62.71.1.  From my vantage point on DDN, I get a network unreachable.
Chances are an AF Concentrator has recently been installed or has failed.

The !P response from MOFFETT-FLD-MB.DDN.MIL is a port unreachable.  Look at
the man page in [NETDIST.DOCS] for the distinction between port (!P), host
(!H), and network (!N) unreachable states.

MOFFETT-FLD-MB.DDN.MIL appears to be down or overloaded at the moment as
the traceroute to your site is getting routed through MCLEAN-MB.DDN.MIL,
SURAnet, NSFnet, and CERFnet even though we're only about 45 miles apart.

Merton Campbell Crockett
Contel Federal Systems, GSysG/WLO

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 13:41:26 GMT
From:      malis@BBN.COM (Andy Malis)
To:        comp.protocols.tcp-ip
Subject:   Re: Goofy Router?

Bryan,

>     we're oz.bmd.trw.com (129.193.100.6) and we're trying to get to
>           afsc-bmo.af.mil (132.62.71.1)

afsc-bmo.af.mil (actually 131.62.7.1) is an Air Force host at
Norton Air Force base, behind an Air Force Concentrator (Cisgo
gateway) connected to the MILNET.  The Concentrator is
norton-piv-1.af.mil, with addresses 26.8.0.39 and 131.62.0.1.

>     When I did a traceroute to afsc-bmo.af.mil on 4/10/91 I got this -
>     1   outdsg.nba.TRW.COM
>         .
>         .
>         .
>     13  192.52.195.1
>     14  * * *
>     15  * * *
>         .
>         .
>         .
>     30  * * *

As of 09:30 EDT on 4/16, it appears that norton-piv-1.af.mil is
dead.  I'm able to ping 26.0.0.39 (another host on the same
MILNET PSN), but 26.8.0.39 isn't answering.  When trying a
traceroute from BBN to afsc-bmo.af.mil, the NSFNET reports that
the destination network is unreachable:

 7  princeton-nss.near.net (192.80.80.1)  40 ms !N  40 ms !N  20  ms !N

I also tried a traceroute via your host, by using
"traceroute -g oz.bmd.trw.com afsc-bmo.af.mil", and found a
router at TRW was reporting host unreachable:

20  129.193.76.252 (129.193.76.252)  340 ms !H *  400 ms !H

>     What is this router at 192.52.195.1 doing?  When I
>     traceroute just to 192.52.195.1 I got this -
 
>     14  192.52.195.1 (192.52.195.1)  1060 ms !P  1020 ms !P  1050 ms !P

192.52.195.1 is MOFFETT-FLD-MB.DDN.MIL, a Mailbridge between the
NSFNET (and several other nets) and the MILNET.  It is responding
to traceroute by reporting that it is receiving datagrams using
an unsupported protocol (the !P flag).  You should read the
traceroute man page for more information on how it works, and
other indications you can receive from traceroute.

In general, if you are having trouble reaching a host on the
MILNET, or on a network behind a MILNET-attached router, such as
an Air Force Concentrator, you should call the MILNET Monitoring
Center at (800) 451-7413, or (202) 692-5726.  They are also
reachable by email at DCA-MMC@DCA-EMS.DCA.MIL.

Regards,
Andy Malis
BBN Communications

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 16:47:01 GMT
From:      bill@platypus.uofs.edu (Bill Gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather is discontinued


I'm not sure how this commercial outfit gets the data, but it apparently
originates at the various NWS offices.  There was a real nice X-windows
Weather Map program that just suffered the same fate.
Now I have a suggestion for a possible solution.
Maybe what is needed is for people to find out how this information is
collected from the NWS and then if possible, try and find INTERNET sites
near each of the NWS stations (I am near AVP) and get them a connection
so that we can gather the info ourselves.  Then all we need is a central
site to hold and distribute the information.  After all, isn't it our tax
money that is generating this data in the first place??

bill


-- 
     Bill Gunshannon          |        If this statement wasn't here,
     bill@platypus.uofs.edu   |  This space would be left intentionally blank
     bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 18:09:01 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet drivers for Proteon Pronet-10


    Proteon is working on NDIS drivers for their cards....

I am guessing here, but I suspect that these NDIS drivers are actually for
their 802.5-compatible interfaces.  NDIS does not attempt to hide the
characteristics of the LAN media from the protocol stack, and the spec
recommends that driver developers who have something which isn't 802.3 or
802.5 (and ProNET-10 certainly isn't) make it look like one or the other
(presumably so that LAN Manager only has to understand those two media).
You could do a ProNET-10 NDIS driver that understood the differences between
IP-over-Ether and IP-over-Pro10 and translated, but I don't think they have...

    Also I believe Proteon supports the ASI interface.

Only on 802.5-compatible interfaces.

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

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 19:08:32 GMT
From:      kurt@photon.tamu.EDU (Kurt Freiberger)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather is discontinued

In article <441@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes:
|> 
|> I'm not sure how this commercial outfit gets the data, but it apparently
|> originates at the various NWS offices.  There was a real nice X-windows
|> Weather Map program that just suffered the same fate.
|> Now I have a suggestion for a possible solution.
|> Maybe what is needed is for people to find out how this information is
|> collected from the NWS and then if possible, try and find INTERNET sites
|> near each of the NWS stations (I am near AVP) and get them a connection
|> so that we can gather the info ourselves.  Then all we need is a central
|> site to hold and distribute the information.  After all, isn't it our tax
|> money that is generating this data in the first place??

Tsk, tsk, tsk.  Bill, I'm surprised at your naivete!!  They are charging you for the SERVICE of providing this valuable information!  After all, it probably takes the equivalent of a bank of Crays to process this so it can be
sent to all the radio and TV stations so that they can come up with their authoritative weather predicions.  We mere mortals cannot be trusted with this raw information.  It might upset the balance of civilization as we know it!

As Louie XIV said, "It's good to be the king."

#include <boatload_of_smileys>

Cheers, Kurt

P.S.  Willis still doesn't have his call; he's climbing the wall!!!! 8-}

-- 
Kurt Freiberger, wb5bbw	  kurt@cs.tamu.edu   409/847-8706
Dept. of Computer Science, Texas A&M University

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 19:30:28 GMT
From:      j_rodin@hpfcso.FC.HP.COM (Jon Rodin)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet drivers for Proteon Pronet-10

>Proteon is working on NDIS drivers for their cards, which should be available
>real-soon-now.  Whenever those driver become available, one could use the
>dis_pkt driver to run packet driver based protocols over Proteon cards.
>
>Also I believe Proteon supports the ASI interface.  I don't know if a packet 
>driver-to-ASI translater exists, but ASI does support multiple concurrent 
>protocol stacks.

Well, I was only partially right here.  Proteon is only working on NDIS drivers
for the ProNET-4 cards.  And the ASI is probably only for ProNET-4, as well.

Jon
j_rodin@cnd.hp.com

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 19:36:49 GMT
From:      majumdar@bgsuvax.UUCP (anindo Majumdar)
To:        comp.protocols.tcp-ip
Subject:   servers using SUNS rpc protocol

Are the servers created using SUN's rpcgen mechanism capable of supporting
multiple clients? If so how many can they support at one time and do they
have to fork another process for each new client?Is there any way wherby
these servers can have multiple threads of control thus enabling them to supportmultiple clients without the overhead of context switches,new child processes ?
Any pointers will be greatly appreciated.  
                                              Thanks
                                         Anindo Majumdar
Internet address : majumdar@andy.bgsu.edu

            

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 20:48:28 GMT
From:      mahesh@pyrhard2.pyramid.com (Mahesh Jethanandani)
To:        comp.protocols.tcp-ip
Subject:   Generation of CRC as part of Frame Check Sequence Field.

We are bringing up a Ethernet board for our machines, using the LANCE chip.
I have to be able to test the CRC logic on the board, by comparing the 
CRC that I generate in software with what the hardware generates and appends
to each packet. I have the 802.3 specs and I can see the polynomial 
equation used to generate the CRC.

What I need is a C program, that I can use to generate CRC for a 32 byte
data packet. Has anyone out there written a program to do this.

Thanks in advance.

mahesh

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Apr 91 21:34:54 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Request For Info On Dynamically Acquiring IP Addresses At Boot

In article <41315@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Can someone give me a reference to any research or commercial products
>that attempt to solve the problems of 1) allowing a PC or workstation
>to dynamically acquire an IP address at boot time, and 2) making it
>easier to install IP on a PC or workstation (i.e., an attempt to make
>things in general more dynamic so that each client doesn't have so
>much static information hard-coded into it at install time).
>

I do this for my 500+ PCs because I could not be botherred doing an installa-
tion for each.  You need some method of getting ip numbers, I have something
running similar to BOOTP which gets run in the batch file immediately after
the packet drivers is loaded.  My BOOTP-similar program can write the ip
address to a file or to an environment variable.

With NCSA, Clarkson CUTCP, and Waterloo TCP, you simply insert the line
with the correct ip address into the ASCII configuration file using some
automatic process such as the one I have described or you select BOOTP for the
TCP stacks which support it.

Beame&Whiteside's system includes an automated IP generation scheme which,
if memory serves me correctly, uses the lowest n bits of the Ethernet 
address where n is (32 - the number of bits in the network mask).  B&W
also supports the normal methods listed below.

For PCIP based products such as FTP, Wollongong, Beame&Whiteside,
etc., you can:
  1.  Use BOOTP (I think they all support it)
  2.  Use the configure program with a batch file 
  3.  figure out the data structure and write to it yourself

Since you ask about research, the following is a description of what
is being done, but not commercially available.

The Waterloo TCP system when running on Watstar (a proprietary DOS network) 
need not be configured with an IP address.
It uses one if so supplied, but otherwise requests the address from the 
the Watstar network.  The Watstar system responds with the computers IP
address, or generates a new one if the computer is new.  Addresses are
managed by the subnet's gateway, meaning the gateway never needs to
arp a station because it is the authority.

Erick
-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 04:21:34 GMT
From:      doug@psy.uwa.oz.au (Doug Robb)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

dsamperi@Citicorp.COM (Dominick Samperi) writes:

>My organization is considering the use of twisted pair point-to-point
>connections as an alternative to thin wire Ethernet. The motivation is
>to reduce our expenses. The environment is one where there is little
>tolerance for network failures (a trading floor). I'm familiar with
>thin wire Ethernet, but know little about twisted pair technology.
 
>Could somebody comment on their experiences with twisted pair
>connections. Are they cheaper than thin wire? More/less reliable?
>Is there a throughput/bandwidth hit in using twisted pair? How
>large? Is twisted pair easier/harder to maintain?

I have recently been to a few seminars where the suggestion
has been made that the way to go is to blanket wire with
unshielded twisted pair and have a concentrator at some
point. With the appropriate cards in the concentrator you can
run ethernet, apple talk, token ring etc without having
to re-wire the building. Since the seminar's were put on by
companies in the market for the above hardware then naturally I'm a
bit suspicous as to whether this is any cheaper than using
thin wire ethernet in combination with twisted pair as I do
here. For a start the concentrator and cards are big dollars....

On the other hand running twisted pair back to a 10baseT hub
may be quite cost effective if you are not sure about location of
(or want the flexability of moving) serial printers/faxes/terminal 
etc around the building. The rational would be that you have to
run the twisted pair anyway for the above so why not use it for
your ethernet devices as well. In the Psychology dep we run twisted
pair back to terminal servers, have thick and thin wire coax
connecting out mini's, sparcstations and pc's. 
I think this is the cheapest way to go? 
Any comments?

You could consider running thin wire ethernet and twisted pair?
Since thin wire is about $A1.50 a metre you can run one or
two segments (up to 180m) on each floor and dont bother with
the T connectors etc until you need them. 
Then for example you want to connect a sparc station you open 
up the cable tray, fit a faceplate and connector and simply plug in. 
Since you can hang 29 devices off each segment it seems to me that
this is easier than having 29 SEPARATE runs of wire going back to
the 10baseT hub rather than the one in the case of the thin wire.
Also the mac length of the 10baseT run is 100m , 180 for thin wire
and about 500m i think for thick wire.

Just to give you an example. I heard of a firm that got 3 floors
of a new building in Perth wired up recently. Two thin wire segments
on each floor and thick wire segment between floors. No connectors
terminators, delni, desta etc because as yet the don't have a computer
system. The cost for this $A7,000.

They also had 8 pair, PDS (unshielded twisted pair) to 100 outlets
with rj45 connectors back to a distrib board put in at the
same time, cost $A48,000. To actually get a computer network
will need a 10baseT hub etc as you know.
Since they don't have a network yet I don't know that the final
cost of each scenario would be.

doug@psy.uwa.oz.au

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 12:20:10 GMT
From:      gme@DOLPHIN.NO (Melbye/Nd)
To:        comp.protocols.tcp-ip
Subject:   LAN Manager


We would like to use Lan Manager on a TCP/IP network that
includes IProuters.
Due to the fact that Lan Manager is using netbios, this
configuration seems to be impossible.

There have been some rumours about some "netbios routers"
applications on either DOS/OS2 or Unix that can solve
this problem.

Does anyone know about this ?

Brit Jensen, Norsk Data



-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 12:54:31 GMT
From:      backman@FTP.COM (Larry Backman)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN Manager


 >> 
 >> 
 >> We would like to use Lan Manager on a TCP/IP network that
 >> includes IProuters.
 >> Due to the fact that Lan Manager is using netbios, this
 >> configuration seems to be impossible.
 >> 
 >> There have been some rumours about some "netbios routers"
 >> applications on either DOS/OS2 or Unix that can solve
 >> this problem.
 >> 
 >> Does anyone know about this ?
 >> 
 >> Brit Jensen, Norsk Data
 >> 
 >> 
Our OS/2 TCP Netbios has a hack built into it that if a certain switch
(-nfilename I think) is set, it searchs that file for a name/internet address
combination whenever NETBIOS name queries fail.  Thus if your file
had:

	joe	silly.foo.com
	tom	128.127.44.33

and you tried a

	net use q: \\joe\public

when the name query for joe failed on your local net; the netbios would
then go off to silly.foo.com via DNS lookups & look there.


Does this help you?



				Larry Backman
				backman@ftp.com

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 14:06:49 GMT
From:      scott@hsvaic.boeing.com (Scott Hinckley)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather is discontinued

'finger weather' still works for me,...

I just stick my finger out in the weather.

If it gets wet it is raining, if it gets bright it is sunny, if it turns
white it is snowing, if it gets frost bite it's cold...

:-)
-- 
<<<<<<<<<<<Scott Hinckley<<<<<<<<<<<<>>>>>>>>>>VW&Apple][Forever!!!>>>>>>>>>>
Internet:scott@hsvaic.boeing.com|UUCP:...!uunet!uw-beaver!bcsaic!hsvaic!scott
DISCLAIMER: All contained herein are my opinions, they do not|+1 205 461 2073
represent the opinions or feelings of Boeing or its management|  BTN:461-2073

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 14:40:54 GMT
From:      lhl@CS.WISC.EDU (L.H. Landweber)
To:        comp.protocols.tcp-ip
Subject:   (none)

Below please find the electronic version of the second announcement.
It includes the preliminary program, conference information and a
registration form. 
 
This announcement is also on a server as a file for anyone to retrieve
by sending email to listserv@vm.uni-c.dk with the command:
 
          GET INET91 PROGRAM
 
The social program is in a another file called INET91 SIGHTSEE, which
can be retrieved in the same way.  
======================================================================
 
     -------------------------------------------------------------------
                              DON'T MISS
         THE FIRST TRULY GLOBAL CONFERENCE ON ACADEMIC NETWORKING
     -------------------------------------------------------------------
      II
                                                ''''
      II    NNN     NN  EEEEEEEEEE  TTTTTTTTTT  ''''   99999999     111
      II    NNNN    NN  EE              TT        ''  99      99   1111
      II    NN NN   NN  EE              TT       ''   99      99  11 11
      II    NN  NN  NN  EEEEEEE         TT             99999999      11
      II    NN   NN NN  EE              TT                   99      11
      II    NN    NNNN  EE              TT                  99       11
      II    NN     NNN  EEEEEEEEEE      TT                99         11
 
 
                   International Networking Conference
                      Copenhagen - June 18-20, 1991
 
The first international conference focusing on worldwide issues of
research and academic networking - INET'91 - is scheduled for June
18-20, 1991 in Copenhagen, Denmark. University, industry and
government representatives from around the world are invited to meet
and discuss important issues related to planning, implementing,
managing and funding national, regional and international networks.
 
INET'91 sessions cover the main application areas of physics and
chemistry, space science, education, libraries and life sciences.
Technology sessions include topics such as the Internet,
collaboration techniques, new technology and perspectives of the
future. A track on policy includes sessions in relation to commercial
services, international links, security and open communication.
Finally there will be sessions for discussion of regional issues,
among these a session on Eastern Europe.
 
Before the conference, on June 17th, two tutorial sessions are
arranged on the topics of building a network and on IP networking.
 
Furthermore, a workshop for delegates from developing countries will
be held in connection to INET'91. The topic is "How to plan for and
implement research and academic networks". This workshop is held on
June 15-16 (the weekend before INET'91) with a closing session
immediately after INET'91 on June 20th.
 
 
Corporate sponsors (preliminary list)
-------------------------------------
  IBM, DEC, Novell and Advanced Network & Services Inc.
 
 
Sponsoring Organizations
------------------------
  Coalition for Networked Information, CREN, EDUCOM, FARNet, IAB and
  Net North in North America.
 
  WIDE, TISN and JAIN in Japan.
 
  EARN, NORDUNET, EurOpen (EUnet) and RARE in Europe.
 
 
Conference co-chairs
--------------------
  Frode Greisen       Europe
  Jun Murai           Pacific Rim
  Larry Landweber     North America
 
Program Committee co-chairs
---------------------------
  David Farber        USA
  Juha Heinanen       Finland
  Yutaka Matsushita   Japan
 
 
----------------------------------------------------------------------
                       CONFERENCE INFORMATION
-----------------------------------------------------------------------
INET'91 takes place in Copenhagen, Denmark on June 17-20, 1991.
Hotels are available covering a wide range of cost categories. The
conference will be held at the SAS Scandinavia Hotel, located near
the center of town, but no more than 15 minutes from the airport. The
hotel is the largest in Copenhagen and offers luxurious guest rooms
and suites, an indoor swimming pool, a fitness center and three
excellent restaurants.
 
 
Registration
------------
One registration procedure is to use the electronic registration form
appended to this announcement. You can fill out the form and return it
to <inet91@vm.uni-c.dk> and at the same time transfer the money
by cheque or bank order to DIS Congress Service Copenhagen A/S. The
electronic registration becomes valid when the payment has been
received. You will of course be notified.
 
Alternatively you can register by ordinary mail.  You can print the
registration form below or request a copy of the program and
registration form from either <inet91@vm.uni-c.dk>,
<inet91@educom.edu> or <inet91@wide.ad.jp>.  Please send the
registration form together with the registration fee and other payments
as a a bank cheque, a bank transfer or a credit card order in Dansish
currency as soon as possible to the INET'91 conference registration:
DIS Congress Service Copenhagen A/S, see address below.
 
April 15th is the deadline for early registration at the reduced fee.
All registrations postmarked by April 15th, at the latest, will be
accepted (airmail from outside Europe). Registration at the time of
the conference cannot be guaranteed. If you have any questions
regarding the registration, please phone DIS Congress Service
Copenhagen A/S.
 
Payment must be remitted as follows:
------------------------------------
* Either by bankers' draft or cheque drawn on a Danish bank and
  made payable to "INET'91", c/o DIS Congress Service Copenhagen A/S.
 
* Or by bank transfer to: Account No. 3112-07395-7 (INET)
                          Den Danske Bank
                          Nytorv 7
                          DK-1450 Copenhagen K
                          Denmark
 
* Or by credit card order which requires your signature on the
  printed registration form to be sent by postal mail.
 
All payments must be made in Danish Kroner (DKK).
 
Please remember to state INET'91 and your name on all money transfers
to the conference registration bureau.
 
All inquiries concerning registration and hotel accommodation must be
directed to DIS Congress Service Copenhagen A/S.
 
Registration fees
-----------------
The registration fees are (1 US dollar is approximately 6 DKK
(March 1991):
 
    Delegate registered until April 15, 1991    DKK  2,300
             registered after April 15, 1991    DKK  2,700
    Tutorial on June 17                         DKK  1,300
    Accompanying Person                         DKK      0
 
The following items are included in the conference registration
fee: The fees cover all conference sessions, one copy of the book of
abstracts, the conference banquet with TIVOLI entrance, luncheons and
coffee breaks for all three conference days June 18 -- 20, 1991.
 
The following items are included in the tutorials registration fee: All
sessions, printed material, luncheons and coffee breaks for June 17,
1991.
 
On site registration for INET'91 will begin Monday, June 17 from 7:00
p.m. to 9:00 p.m. and continues Tuesday, June 18 at 7:30 a.m.. There
will be a welcoming reception Tuesday evening from 6:30 p.m. to 8:00
p.m. The Conference will end Thursday, June 20, at noon.
 
 
Cancellation Policy
-------------------
Preregistered participants who are unable to attend the Conference
will have their paid fees refunded less DKK 300 provided that a
written notice of cancellation (by letter, telefax or telex) is
received by DIS Congress Service Copenhagen A/S before June 10,
1991. If cancellation is made after June 10, 1991 no refund of fee
can be expected.
 
 
Hotel Reservations
------------------
The conference bureau, DIS Congress Service Copenhagen A/S, offers
participants hotel rooms at a special conference price. Rooms will be
booked in the price category indicated on the registration form. If
you register after April 15, please note that some price categories
may be fully booked.
 
Hotel rooms will be booked only if a deposit has been received by the
Conference Bureau. The deposit will be deducted the hotel bill when
you check out.  All conference hotels are situated in the centre of
Copenhagen. The conference is held at the 'A' hotel.
 
    Deposit for A, B and C hotel:    DKK  1,100
            for D hotel:             DKK    450
 
In case of cancellation please note that hotel deposits will be
refunded until May 15, less an administration fee of DKK 300. After
May 15, refunds will only be made if the cancelled room can be relet
to a third party.
 
 
Ground Transportation
---------------------
Just outside the Danish customs at the airport, you can board the SAS
bus directly to the Conference hotel. The first stop is the SAS
Scandinavia (Please inform the driver). You can also take a taxi for
approximately 60 DKK.
 
 
Exchange Rate and Banks
-----------------------
The present exchange rate (March 1991) is approx. 6 DKK per US
dollar. In other words, a Danish krone is worth 16 US cents.
 
The banks are open Monday through Friday from 9:30 a.m. to 4:00 p.m.
On Thursday, hours are extended until 6:00 p.m.
 
All major credit cards are accepted at most restaurants, shops and
hotels. You can draw cash in Danish currency (DKK) on your VISA or
EURO card from cash dispensers 24 hours a day using your cash
dispenser code.
 
 
Travel Documents
----------------
A valid passport is required for all international travellers.  For
citizens of the U.S., Western European countries, and some other
countries, a visa is not required for entrance into Denmark. Visitors
from other countries may required a visa to enter Denmark. Check with
the Danish Embassy in your country.  Foreign nationals coming from
the USA and other countries should also check their visa status for
re-entry to their country of departure.
 
Social events
-------------
On Tuesday evening, June 18, the participants of INET'91 are invited
to a reception. A gala banquet will take place Wednesday evening at
the restaurant NIMB in the centre of the city. This restaurant is
situated adjacent to the world famous amusement park TIVOLI, where an
ambience of good-will blends itself with the uniquely beautiful
surroundings to give you an unforgettable experience. After the
banquet, the participants will enter the TIVOLI garden, where the
evening ends with the traditional display of fireworks.
 
 
E-Mail facilities at INET'91
----------------------------
Access to the Internet will be supplied at the conference site. This
will enable you to attend to your E-Mail activities, while being in
Copenhagen. The terminal room will be open from 7:30 a.m. to 10:00
p.m. for the duration of the conference and attached meetings.
 
 
Book of Abstracts
-----------------
All participants will receive a copy of abstracts of all the talks
when they register. Additional copies may be purchased at the
conference for DKK 180.
 
 
Tourist and spouse program
--------------------------
If you would like to know more of the spouse program and tourist
opportunities connected to INET'91, please order the hard copy
program or send e-mail to LISTSERV@VM.UNI-C.DK with the command
 
               GET INET91 SIGHTSEE
 
in the mail body.
 
Useful Addresses
-----------------------------------------------------------------
Conference Registration, Hotel Reservations and Tours in Denmark.
Office hours 9:00 a.m. -- 16:00 p.m. (time zone GMT + 1):
 
  DIS Congress Service Copenhagen A/S
  Herlev Ringvej 2 C
  DK-2730 Herlev
  Denmark
 
  Telephone +45 44 92 44 92
  Telefax   +45 44 92 50 50
  Telex      15 476 dis dk
 
-----------------------------------------------------------------
Conference Hotel:
 
  SAS Scandinavia Hotel
  Amager Boulevard 70
  DK 2300  Copenhagen S
  Denmark
 
  Telephone +45 33 11 23 24
  Telefax   +45 31 57 01 93
 
-----------------------------------------------------------------
North American regional conference secretariate:
 
  EDUCOM, INET'91 secretariate
  1112 16th Street, NW
  Washington DC 20036
  USA
 
  Telephone +1 202 872 4200
  Telefax   +1 202 872 4318
  EMail     <inet91@educom.edu>
 
-----------------------------------------------------------------
Pacific Rim regional conference secretariate:
 
  WIDE project, INET'91 secretariate
  5322 Endo, Fujisawa
  Kanagawa 252
  Japan
 
  Telephone +81 466 48 9433
  Telefax   +81 354 90 7002
  EMail     <inet91@wide.ad.jp>
 
-----------------------------------------------------------------
Europe regional conference secretariate and local organizers:
 
  UNI-C, INET'91 secretariate
  DTH, bygning 305
  DK-2800 Lyngby
  Denmark
 
  Telephone +45 45 93 83 55
  Telefax   +45 45 93 02 20
  EMail     <inet91@vm.uni-c.dk>
 
 
--------------------------cut here-------------------------------
    E L E C T R O N I C   R E G I S T R A T I O N   F O R M
                           for the
              International Networking Conference
                 Copenhagen - June 18-20, 1991
 
                                             ________________________
                                            I For secretariat use    I
                                            I                        I
                                            I                        I
                                            I                        I
                                            I                        I
                                            I112                     I
DELEGATE                                    I________________________I
--------
 
Family name:_______________________________________________________
 
First name(s):_____________________________________________________
 
Institution/Company:_______________________________________________MLV
 
Institution address:_______________________________________________MLV
 
                    _______________________________________________
 
 
Postal code:_________ City:__________________ Country:_____________
 
Telephone:_________________             Telefax:___________________
 
Telex:______________      E-mail address:__________________________
 
 
ACCOMPANYING PERSON (Mr./Ms.)
------------------------------
 
Family name:_______________________________________________________
 
First name(s):_____________________________________________________
 
 
Date of arrival  :___________ June 1991    Flight no:______________
 
Date of departure:___________ June 1991    Flight no:______________
 
 
___________________________________________________________________
INo of.  I Fee category                         I        I        I
Ipersons I (all in Danish currency = DKK)       I   DKK  I   DKK  I
I________I______________________________________I________I________I
I    1   I Delegate reg. until April 15         I  2,300 I        I
I or 1   I Delegate reg. after April 15         I  2,700 I        I
I        I Tutorial-IP networking, June 17      I  1,300 I        I
I or     I Tutorial-Network building, June 17   I  1,300 I        I
I        I Accompanying person(s)               I      0 I********I
I        I Hotel deposit (room category A, B, C)I  1,100 I        I
I        I Hotel deposit (room category D)      I    450 I        I
I________I______________________________________I________I________I
I  Social program                                                 I
I_________________________________________________________________I
I        I North Zealand tour, June 16          I    490 I        I
I        I Welcome reception, June 18           I   incl.I********I
I        I Banquet, June 19 -- delegate         I   incl.I********I
I        I Banquet, June 19 -- companion        I    300 I        I
I________I______________________________________I________I________I
I  Accompanying persons program                                   I
I_________________________________________________________________I
I        I Copenhagen City tour, June 18        I    190 I        I
I        I Danish art and design tour, June 19  I    410 I        I
I        I Danish porcelain tour, June 20       I    350 I        I
I________I______________________________________I________I________I
I  Post congress tour                                             I
I_________________________________________________________________I
I        I Denmark at the sea, June 21--23      I  3,400 I        I
I        I Extra for single accomodation        I    500 I        I
I        I Forward post congress tour info.     I      0 I********I
I________I______________________________________I________I________I
I  Total DKK                                    I        I        I
I________I______________________________________I________I________I
 
 
PAYMENT
-------
 
All payment must be made in Danish kroner (DKK) only to the order of
INET'91, c/o DIS Congress Service Copenhagen A/S. No personal cheques
are accepted.
 
No registration or room reservation can be confirmed until DIS
Congress Service Copenhagen A/S has received your payment.
 
Please tick off as appropriate:
 
___The TOTAL amount has been posted to DIS Congress Service
  Copenhagen A/S on banker's cheque/draft drawn on a Danish bank.
 
___The TOTAL amount has been transferred to account No.  3112-07395-7
  (INET) in Den Danske Bank, Nytorv 7, 1450 Copenhagen K, Denmark.  (Not
  applicable for payments made from Denmark).
 
___The TOTAL amount, DKK ____________ may be charged to my credit card:
 
  ___Access   ___Amex   ___Diners   ___Eurocard   ___Master   ___Visa
 
  Card No:______________________   Expiration date:____________________
 
  Date:__________________          Signature:__________________________
 
Please remember to state DELEGATE NAME and INET'91 on all payments.
 
 
HOTEL ACCOMODATION
------------------
 
Date of arrival   :______________ June 1991
 
Date of departure :______________ June 1991
 
_______________________________________________________________
I Price      I Single room I No. of I Double room I  No. of   I
I category   I DKK / night I  rooms I DKK / night I   rooms   I
I____________I_____________I________I_____________I___________I
I Conference I             I        I             I           I
I  hotel (A) I     1080    I        I     1320    I           I
I____________I_____________I________I_____________I___________I
I     B      I 790 -- 940  I        I 920 -- 1190 I           I
I____________I_____________I________I_____________I___________I
I     C      I      610    I        I      890    I           I
I____________I_____________I________I_____________I___________I
I     D      I      375    I        I      450    I           I
I____________I_____________I________I_____________I___________I
 
All rooms are with private bath or shower. The price per night
includes service charge, tax and breakfast buffet (except category D
hotels). The paid deposit will be deducted from the final hotel bill.
 
Special wishes:_______________________________________________________
 
______________________________________________________________________
 
 
Return this registration form to <inet91@vm.uni-c.dk> and at the same
time send the payment to:
 
  INET'91
  c/o DIS Congress Service Copenhagen A/S
  Herlev Ringvej 2 C
  DK-2730  Herlev
  Denmark
 
  Telephone +45 44 92 44 92
  Telefax   +45 44 92 50 50
  Telex      15 476 dis dk
 
Or print the form and send to the address above with your payment
or payment order.
 
Please remember to keep a copy of this form for your own record.
 
-------------------------------------------------------------------
                         P R O G R A M
-------------------------------------------------------------------
DRAFT PROGRAM INET '91
10.4.1991

PARALLEL TRACKS

Track 1: Application Areas
Track 2: Technology and Services
Track 3: Policy Issues
Track 4: Regional Issues

MONDAY 17.6

Tutorials
	Coordinator: Craig Partridge
	- Van Jacobson (Lawrence Berkeley Laboratory, USA)
	  "Issues in Gigabit IP Networking"
	- Daniel Karrenberg (CWI, Netherlands) and Niall O'Reilly
          (EARN, Netherlands)
          "Starting a Research Network: Choosing a Strategy!"

TUESDAY 18.6

8:30-10:30  Plenary Session
	- Welcome: Frode Greisen (UNI-C)
	- Keynote Talk: "Europe '92"
	  Horst Huenke, Head of Coordination Operations Division,
	  DG XIII-A2, Commission of the European Communities
        - Plenary Talk: "Future Networking and Infrastructure"
	  Robert E. Kahn, (Corporation for National Research Initiatives, USA)

10:30-11:00 Coffee

11:00-12:30 Parallel Sessions 1
	Track 1: Physical Sciences
		 Coordinator: Brian Carpenter <brian@cernvax.cern.ch>
		 - David Williams (CERN, Switzerland-France)
		   "Worldwide aspects of networking for particle physics"
		 - Jean-Pierre Peltier (ONERA, France)
                   "Worldwide aspects of networking for
                   aerodynamics/fluid computation"
		 - Lynn F Ten Eyck (SDSC, USA)
                   "Worldwide aspects of networking for chemical computation"
	Track 2: Internet Issues
		 Coordinator: Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
		 - Phill Gross (NRI, USA)
		   "** title not known yet"
		 - Marshall Rose (PSI Inc.)
		   "Internet Network Management: History, Status
		   Report, and Future"
		 - Massimo Tartamella (Centro Universitario Calcolo, Italy)
		   "** title not known yet"
	Track 3: The Role of Commercial Service Providers
		 Coordinator: Hank Nussbacher <hank@vm.tau.ac.il>
                 Presentations by network providers:
	         - Martin Schoffstall (PSI, USA)
	         - Rick Adams (Alternet, USA)
	         - George Abe (Infolan, Europe)
	         - Dai Davies (IXI, Europe)
	Track 4: Europe
		 Coordinator: Dennis Jennings <jennings@irlearn.bitnet>
		 - Howard Davies (Univ. of Exeter, Great Brittain)
		   "Networking in Europe: The COSINE Perspective"
		 - Rob Blokzijl (NIKHEF, The Netherlands)		 
		   "Networking in Europe: The RIPE Perspective"
		 - Frode Greisen (EARN, Denmark)
                   "The Regionalisation of EARN"
		 - Roman Tirler (Commissariat a l'Energie Atomique, France)
		   "European High Speed Networking: A Critical Survey"

12:30-14:00 Lunch

14:00-15:30 Parallel Sessions 2
	Track 1: Space Science
		 Coordinator: Tony Villasenor <villasen@nsipo.arc.nasa.gov>
	Track 3: The Role of Commercial Service Providers
                 Presentation by network provider:
	         - Al Weis (ANS/USA)
                 Panel:
	         - Rob Blozkzijl, Dai Davies, Martin Schoffstall,
		   Al Weis, Stephen Wolff
 	Track 4: Eastern Europe
		 Coordinator: Peter Bakonyi <h25bak@ella.hu>
		   Soviet Union - Valerij Udalov
		   Hungary - Laszlo Csaba
		   Poland - Daniel Bem
		   Zechoslovakia - Jan Gruntorad
		   Bulgaria - Kiril Boyanov

15:30-16:00 Coffee

16:00-17:30 Parallel Sessions 3
	Track 1: Education
		 Coordinator: Hidea Aiso <aiso@sfc.keio.ac.jp>
		 - Lee Caldwell (Novell Inc., USA)
		   "** title not known yet"
		 - Susan Calcari (MERIT, USA)
		   "Education over the International Internet"
	Track 2: Collaboration Technologies
		 Coordinator: Glenn Ricart <gricart@dcsc.umd.edu>
		 - Florencio Utreras (?, Chile)
		   "** title not known yet"
		 - ** two more not yet confirmed
	Track 4: Asia & Pacific Rim
		 Coordinator: Bob Kummerfeld <bob@cs.su.oz.au>
		 - Geoff Huston (AARNet, Australia)
		  "Developing an Academic and Research Network: the
		  Australian Experience"
		 - Mohamed b. AwangLah (?)
		  "The academic and research network in Malaysia"
		 - ** one more still unconfirmed

WEDNESDAY 19.6

9:00-10:30  Announcements, Keynote and Plenary Talks (15 min + 2 x 45 min)
	- Keynote talk: "High Performance Computing and Communications"
	  Gene Wong, Associate Director
	  Office of Science and Technology, The White House, USA
	- Plenary Talk: Paul van Binst (University of Brussels)
	  "Future of Networking in Europe"

10:30-11:00 Coffee

11:00-12:30 Parallel Sessions 4
 	Track 1: Library
		 Coordinator: Paul Peters <padler@umdc.umd.edu>
		 - Clifford A. Lynch (Univ. of California, USA)
		   "Application layer protocols and other architectural
		    and standards issues presented by networked
		    information resources and services"
		 - Peter H. Van Wiechen (Elsevier Science Publishers,
		   The Netherlands)
		   "Opportunities and threats for publishers presented
		    by the application of advanced networks to
		    scientific and technical communication" 
		 - Peter Stone (Univ. of Sussex, United Kingdom)
		   (** to be confirmed)
		   "The organization of libraries and library services
		    in a national networking setting:  The case of the
		    JANET National Library Users Group"
	Track 2: Technologies of the 90s
		 Coordinator: Christian Huitema
		<Christian.Huitema@mirsa.inria.fr>
		 - David J. Farber (Univ. of Pennsylvania, USA)
		   "The National Backplane -- a Different Approach to Gigabit
		    Networking"
		 - Jim Leighton (ESnet, USA)
		   "Evaluating US Fast-packet Services for Future 
		    Network Designs"
		 - Christian Huitema (INRIA, France)
		   "High speed networks and the design of application
		    protocols"
	Track 4: North America
		 - Ira Fuchs, Session Chairman (Princeton Univ., USA)
		 - Guy Almes (Rice Univ., USA)
		 - Steve Wolff (NSF, USA)
		 - Richard Mandelbaum (Univ. of Rochester, USA)

12:30-13:30 Lunch

13:30-15:00 Parallel Sessions 5
	Track 2: Mail and Directory Services
		 Coordinator: Alf Hansen <hansen@cs.wisc.edu>
		 - Shoichiro Asano (U of Tokyo, Japan)
	           "Japanese Inter-university Mail Service"
		 - Robert Hagens (UW-Madison, USA)
                   "Common User-Interfaces for multi protocol
		    mail-services, case: the ECI project"
		 - Erik Huizer (SURFnet, The Netherlands)
		   "European OSI Directory Services, Paradise or
                    Fata Margana?"
	Track 3: Open Scholarly Communication vs. Telecommunications Policy
		 Coordinator: David Kunkel <kunkel@psi.com>
	Track 4: Latin America
		 Coordinator: Florencio I Utreras <FUTRERAS@UCHCECVM.BITNET>
                 - Daniel Pimienta (Republica Dominicana)
                   "REDALC: A Feasibility Study for a Network in Latin America
                    and the Caribbean"
		 - Florencio Utreras (Chile)
		   "SIRIAC: A Latin American Networking Initiative"
		 - Roberto Loran (Puerto Rico)
                   "CUNet:  A Caribbean Universities Network: A SIRIAC Project"
		 - Guy de Teramond (Costa Rica)
                   "A Satellite Internet for Latin America: A SIRIAC Study"
		 - Victor Cid (Chile)
                   "SCARNET: The Southern Cone Academic and Research Network: A
                    SIRIAC Project"
                 - Alonzo Alvarez (Venezuela)
                    "Internetworking over X.25: The REACCIUN Network"

15:00-15:30 Coffee

15:30-17:00 Parallel Sessions 6
	Track 1: Workstation Teleconferencing
		 Coordinator: Peter Kirstein <P.Kirstein@cs.ucl.ac.uk>
		 - Hide Tokuda (CMU, USA and Keio Univ., Japan)
		   "Operating System Support for Continuous Media Applications"
		 - S. R. Wilbur (UCL, UK)
		   "Personal Multimedia Conferencing for CAD/CAM"
                 - ** one more speaker to be announced
	Track 2: Networks and Network Services of Year 2000
		 Coordinator: Richard Mandelbaum <rma@tsar.cc.rochester.edu>
                 - Tony Rutkowski (CERN, CH)
                   "** Title not known yet"
		 - Vint Cerf (Corp. for National Research Initiatives, USA)
                   "** Title not known yet"
		 - Charlie Catlett (NCSA, Champaign-Urbana, USA)
                   "Life after Internet: Making Room for New Applications"
		 - Toshiharu Aoki (NTT, Japan)
                   "Network Service Evolution Toward 2005"

	Track 3: CCIRN and Global Networking
		 Coordinator: Kees Neggers <neggers@surfnet.nl>
		 - Jon Crowcroft (UCL, Great Britain)
		   "Traffic on the UK-US Fat Pipe: Usage Patterns"
                 - ** two other talks to be confirmed
	Track 4: Special Issues for the Third World
		 Coordinator: Werner Zorn <zorn@ira.uka.de>

19:00-	Conference Dinner including a Dinner Talk
	- Dinner talk: Charles Brownstein (Federal Networking Council, USA)
	  "Impact of Networking on Science"

THURSDAY 20.6

9:00-10:30  Plenary talk and Rapporteur session
	- Plenary Talk: Jun Murai (Keio Univ, Japan)
	  "Evolution, Technology, and Future of Japanese Research Networks" 
	- Rapporteur coordinator: Mike Roberts <roberts@educom.edu>

10:30-11:00 Coffee

11:00-12:30 Rapporteur Session continues, a Panel, and Closing
	- Rapporteur coordinator: Mike Roberts <roberts@educom.edu>
	- Panel on "Pressing needs and things to do"
	   - Steven Goldstein (NSF, USA), panel chairman
           - Panel members:
              - Mats Brunell (NORDUNET, Sweden)
              - Erik Huitzer (SURFnet, The Netherlands)
              - Tadoa Takahashi (PRP, Brazil)
              - Florencio Utreras (U de Chile, Chile)
	      - Erik Naggum (Naggum Software, Norway)
	- Closing: Larry Landweber (UW-Madison, USA)

12:30-13:30 Lunch

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 15:33:00 GMT
From:      XELDIVE@VAX1.CC.LEHIGH.EDU
To:        comp.protocols.tcp-ip
Subject:   PPP patch for SunOS 4.x

Does anyone have or know where I can find a PPP patch (as opposed to SLIP)
for SunOS 4.x.  Please send any responce directly to xeldive@vax1.cc.lehigh.edu
as I can't read news regularly.

Thanks in advance,
-- Gene.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 16:00:42 GMT
From:      bryan@tdd.sj.nec.com (Bryan Wear)
To:        comp.protocols.tcp-ip
Subject:   Static routes with SLIP under SUNOS4.0.3


I`ve been trying to get a remote SLIP machine to communicate through a point
to point link, and a static route, to another machine not running SLIP.  So far
the only success was an ICMP reply to a ping. Will slip work over a static 
route?  I know gated is out there, but I only need my point to point link to
contact one other machine.


Bryan Wear				bryan@tdd.sj.nec.com
NEC America			
San Jose, CA 94002
408-922-3887

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 16:17:38 GMT
From:      bob@netlabs.com (Bob Rench)
To:        comp.protocols.tcp-ip
Subject:   ETHERNET tapping


I really enjoyed Tomer Geminder's request.

    > Is whould thank anyone who will be willing to mail me names of
    > products, or program of its oun which can tap to ETHERNET and format the
    > received information into readable format. I look also for names of
    > workstations and PC boards which their ETHERNET address is writen in the
    > software and is not hardware fixed.

I'm not sure how many of you folks in are familiar with an American icon,
Maxwell Smart, a TV spy popular in the '60s, known for being quite a
bumbling fool (worse than Sellers' Inspector Clouseau).  Tomer's request
sounds like something from "Get Smart".  A sample snippet of dialog from
"Get Smart" goes something like this:

KAOS agent (disguised as a Trap-Net repairman):

	Mr. Smart, can you tell me where your hidden Trap-Net is, and
	how it works?

Maxwell Smart:

	It's the old 'KAOS-agent-asking-for-information-about-my-hidden-
	Trap-Net-trick'.  That's the oldest trick in the book.  Sorry, but
	I can't tell you that.

KAOS agent:

	But, I'm not a KAOS agent, I'm a Trap-Net repairman, and I'm here
	to do some preventative maintenance on your Trap-Net.  Got to keep
	those things oiled, you know.

Smart:

	Well, in that case, pretend that I am a KAOS agent.  I stand over
	here, and you, pretending to be me, can press that button over by
	the door.

[At this point, Trap-Net falls from ceiling trapping Smart.]

KAOS agent (in his German accent):

	You haff fallen into our trap, Herr Schmart!

Smart:

	Don't tell me you really are a KAOS agent!

KAOS agent:

	I am really a KAOS agent!

Smart:

	I asked you not to tell me that.

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

These ramblings produced by the twisted mind of

Bob Rench
10920 Wilshire Blvd., # 1860
Los Angeles, Ca.,  90024
(213) 824-2500
(213) 443-9740 - FAX

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 16:41:36 GMT
From:      jonson@SERVER.AF.MIL (Lt. Matt Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re:  Goofy Router?

<Merton Campbell Crockett writes>
> Subject: Re:  Goofy Router?
> 
> Several points to consider.  Afsc-bmo.af.mil is at 131.62.71.1 rather than
> 132.62.71.1. 
Further point to consider:  afsc-bmo is at 131.62.7.1...
                                                 ^^^
> From my vantage point on DDN, I get a network unreachable.
> Chances are an AF Concentrator has recently been installed or has failed.
> 
Whoa!  The concentrator must not have as good a rep as I thought.  As it
happens, the concentrator has been at Norton for quite a while, and 
yesterday the cisco gateway's line to the PSN had hung up - probably why 
you got the net unreachable.  Last night, it hung again at around 1130, so
today (this morning) it had been flushed from the Core Gateways' tables, and
again should have been showing net unreachable.  We couldn't get ahold of
anyone at the site to check it during the odd hours.  It is now up.

We have had an outstanding problem with ciscos using the MCI card hanging
on the line to the Milnet Node.  We have also had a problem with the Milnet
monitors just deciding to loop back ports that concentrators are connected
to without contacting us.

Oh, and if you look it up, the NIC still has the concentrator registered
as NORTON-PIV-I, which is the name of a Unisys mainframe that has been
rehomed behind the concentrator.

You can contact us for further questions, but things seems to be back to
normal.

/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

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 17:27:03 GMT
From:      paulo@durin.sparta.COM (Paul Oddo)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Problem Configuring SLIP


	Help, I have been trying to configure a slip connection from
my home machine to the office network for TOO long with no success. I
NEED SOME HELP! At home I am running Esix System V R.3.2.D with a SLIP
connection configured on com port 2. Hanging off that is a Hayes
Smartmodem 9600 configured for 9600 bps connections. At work we have a
TCP based (of course) network of Sun Workstations and an Annex II
Terminal Server all on the same ethernet backbone. I have configured
one of the Annex's ports for a slip connection by setting the mode to
slip and the line speed to 9600 bps. This also has a Hayes Smartmodem
9600 attached. I am trying to get a direct connection link. I would 
like to be seen as a remote node on the office network. Everything on 
the Esix Sys V side seems to be working properly. The modems seem to
connect properly at 9600 and any telnet commands to remote hosts
apparently route packets through the modem. The problem seems to be
getting the Annex II to recognize its slip connection. A netstat -iS
command on the Annex shows no slip interface in use when the modems are
hooked up and no received or transmitted packets in the stats.

	I have tried every different configuration I can think of 
including all the suggested configurations from every manual I could
find. Nothing Works. If anyone has had any luck with this sort of
configuration (I know that it cannot be as difficult as it seems) 
I would appreciate any and all help in setting up the port parameters
and configuration files. Thanks.

	Send replies to this news group or mail to:
		paulo@durin.laguna.sparta.com

		voice phone: (714) 768-8161

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 18:32:24 GMT
From:      davison@menudo.uh.edu (Dan Davison)
To:        comp.protocols.tcp-ip
Subject:   Need CMU VMS TCP/IP--where can I get it?

I have been looking for the CMU TCP/IP, but according to ARCHIE it
isn't available for FTP.  Is there a FTP site somewhere, or a phone
number to call?

Thanks in advance,
dan
--
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU
Disclaimer: As always, I speak only for myself, and, usually, only to
myself.

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 19:25:42 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

Just a suggestion, but wouldn't this subject work a little better in
comp.dcom.lans? The discussion there is about cable and boxes. My
impression of comp.protocols.tcp-ip is that it is above the physical layer
of the OSI stack.
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 19:43:43 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.protocols.tcp-ip
Subject:   Re: whereis service needed

In article <1991Apr13.033331.7658@disk.uucp> proberts@disk.uucp (Phil Roberts) writes:
>
>I thought the NIC was for the Milnet only.  Am I understanding you correctly
>that the NIC can also provide me with domains outside the Milnet?  If that
>is true, how does one go about finding a site when one doesn't have Telnet
>capability?
>
>-- 
>  ***************************************************************************
>                         |
>  Phil Roberts           |      Internet:  proberts@disk.uucp 
>                         |          

Yes, it does include sites outside the Milnet. It also includes the names
of the system administrators, and all the registered names of the users.
Since the government is fairly good about registering it's employees, you
can find out the name, address, and phone number of just about any person
who works for the government and who has a login ID on an Internet
connected host. Finger food.

Try a whois on my site. You will see a couple of contacts, and a couple of
the machines in the domain, but since I am not a registered user, you will
see no entry for me.

-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 20:01:40 GMT
From:      us267388@mmc.mmmg.com (Bradley D. Rhoades)
To:        comp.protocols.tcp-ip
Subject:   Re: Need CMU VMS TCP/IP--where can I get it?


In article <1991Apr17.183224.10404@menudo.uh.edu>, davison@menudo.uh.edu (Dan Davison) writes:
 > I have been looking for the CMU TCP/IP, but according to ARCHIE it
 > isn't available for FTP.  Is there a FTP site somewhere, or a phone
 > number to call?


	Dan:

	The package costs roughly $150 for a site license.  You can
	reach CMU at:

		Lori Blasik
		(412) 268-5896

	or electronically:

		tcpip+@andrew.CMU.EDU

	Good luck,

	Brad
-- 
Bradley D. Rhoades	          E/Mail: bdrhoades@mmc.mmmg.com
3M, 2465 Lexington Ave So         NIC: BR79
Building 60-1N-01                 WRK: +1 (612) 736 2874
Mendota Heights, MN  55120        FAX: +1 (612) 736-0431

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 20:26:35 GMT
From:      sck@watson.ibm.com (Scott C. Kennedy)
To:        comp.sys.amiga.misc,compsys.amiga.datacom,comp.protocols.tcp-ip
Subject:   Once again... ka9q help for Amiga

I am setting up my Amiga at home to slip into work via ka9q yet, I am having
problems which is not covered in the documentation, I need to know what ka9q
calls the Amiga Serial Port. If anyone has a clue I would be grateful, I have
tried all of the obvious ie: ser, ser:, com, com:, sl0, sl0:, sl, sl:, aux:,
etc.. etc... And none of these work. 

If anyone could also answer what is the best defaults for a 9600 baud 
modem on a clean line, I would also be happy.


-- 
------------------------------------------------------------------------
Scott C. Kennedy (sck@watson.ibm.com)     | "All we are saying ...
Distributed High Performance Computing    |  is give peace a chance..." 
I.B.M. Thomas J. Watson Research Facility | John Lennon - Dec. 8, 1980
------------------------------------------------------------------------

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 21:04:32 GMT
From:      geoff@vax1.mankato.msus.edu
To:        comp.protocols.tcp-ip
Subject:   Request for: TCP/IP information...

Is there and archive anywhere that has a description of the tcp/ip protocal?
ie.  the Ieee definition of writeup of the standard..

please send me information.  I am trying to put a reasearch paper together on
the subject.  Send me any information you might have on the TCP/IP standard.


Thanks
Geoff...


geoff@att1.mankato.msus.edu
geoff@vax1.mankato.msus.edu
...

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Apr 91 22:00:13 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: Help designing address allocation in a metronet


The current 4.3BSD routed (maybe tahoe, certainly reno) allows you to put
more than 1 interface on the same IP host number.  That is, SLIP works fine
for us, with the ethernet interface and the point-to-point SLIP interface
using the same network/host number.  There are a few improvements to routed
that can be made to improve things in this situation, but they're fairly
obvious.


Vernon Schryver,   vjs@sgi.com

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 00:59:40 GMT
From:      jclark@sdcc6.ucsd.edu (John Clark)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather is discontinued

In article <14784@helios.TAMU.EDU> kurt@photon.tamu.EDU (Kurt Freiberger) writes:
+Tsk, tsk, tsk.  Bill, I'm surprised at your naivete!!  They are charging you
+for the SERVICE of providing this valuable information!  After all, it
+probably takes the equivalent of a bank of Crays to process this so it can be
+sent to all the radio and TV stations so that they can come up with their
+authoritative weather predicions.  We mere mortals cannot be trusted with
+this raw information.  It might upset the balance of civilization as we
+know it!

There is a magazine titled, 'Weather', which has a number of gizmos
to pull down weather maps which are broadcast on some frequency or
another, I can't recall specifically. The results can be displayed
on the ubiquitus PC or the like.
-- 

John Clark
jclark@ucsd.edu

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 03:05:07 GMT
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather is discontinued

In article <441@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) writes:
> 
> I'm not sure how this commercial outfit gets the data, but it apparently
> originates at the various NWS offices.  There was a real nice X-windows
> Weather Map program that just suffered the same fate.
> Now I have a suggestion for a possible solution.
> Maybe what is needed is for people to find out how this information is
> collected from the NWS and then if possible, try and find INTERNET sites
> near each of the NWS stations (I am near AVP) and get them a connection
> so that we can gather the info ourselves.  Then all we need is a central
> site to hold and distribute the information.  After all, isn't it our tax
> money that is generating this data in the first place??
> 
> bill
> 
> 
> -- 
>      Bill Gunshannon          |        If this statement wasn't here,
>      bill@platypus.uofs.edu   |  This space would be left intentionally blank
>      bill@tuatara.uofs.edu    |         #include <std.disclaimer.h>   

Hmmm.  How many institutions have a group that is doing some sort of long term
weather data gathering.  I seems to be a popular study subject here in the
midwest, perhaps because of all these fields of crops arround here.  Here at
GAC we have an Apple // that is hooked to a  unit that records temp, wind
speed, air presure, etc.  It is hooked to the Apple // by a serial port.  The
Apple // records the data to disk and draws graphs on the screen.  Ever since
the weather info server was localized I have been wondering if its data and
data from others like it could be combined into something usefull.  It wouldn't
be as much fun as forecasts, but might get a group trying to make it work a
grant.  The grant might even be able to pay for a couple of years of forcasts
from a weather service.  It is data that is usefull to researchers, sounds like
just the thing NSFnet exists for.  Hmmm...

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Apr 1991 03:33:45 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.unix.wizards,comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

andrew@jhereg.osa.com (Andrew C. Esh) writes:
>Just a suggestion, but wouldn't this subject work a little better in
>comp.dcom.lans? The discussion there is about cable and boxes. My
>impression of comp.protocols.tcp-ip is that it is above the physical layer
>of the OSI stack.

In fact, a discussion about relative merits of thin Ethernet and 10BaseT
has been going on there for a couple of weeks. I'm afraid I caused it by my
question   8-()  Very true, that doesn't necessarily have much to do with
TCP/IP. I've gathered some of the responses - will be glad to send them on
request. Please use mail, not a followup to this group.    E.
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 09:13:40 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell 802.3

The News Manager)
Nntp-Posting-Host: na
Reply-To: donp@novell.com (don provan)
Organization: Novell, Inc., San Jose, California
References: <280a1ac8@omega.uucp>
Date: Thu, 18 Apr 1991 00:18:19 GMT

In article <280a1ac8@omega.uucp> ash@omega.UUCP (Andrew Hardie) writes:
>...Does this mean that Novell's "OSI Support" is just
>protocol tunnelling of IPX inside 802.3 packets...

No.  Novell has an FTAM product which provides a full seven layer OSI
stack for NetWare 3.11.  This allows FTAM clients to access the
NetWare file system.  The IPX inside 802.3 is something Novell's been
doing for years.  It has never, to my knowledge, been referred to as
"OSI Support".
						don provan
						donp@novell.com

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 11:22:43 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Request for: TCP/IP information...

In article <1991Apr17.150433.477@vax1.mankato.msus.edu> geoff@vax1.mankato.msus.edu writes:
   Send me any information you might have on the TCP/IP standard.

Here's the current revision of a "suggested reading" list we tossed
together.  On paper, it fills a conveniently-sized notebook that can
be left on a client's reference shelf, so they aren't such a
continuing presence on the support telephone lines.

.\" Feed me to troff -ms
.TL
A Reading List for the New Internet User and Administrator
.AU
Compiled by Robert A. Sutterfield
.I
bob@morningstar.com
.R
.AI
Morning Star Technologies
1760 Zollinger Rd
Columbus, Ohio 43221
+1 614 451 1883

.ds CH A Reading List for the New Internet User and Administrator

.PP
We recommend that newly-connected Internet users and administrators
become familiar with the contents of the following documents, some
themselves reading lists:

.IP \(bu 2
.B
RFC 1180: A TCP/IP Tutorial
.R
by T. Socolofsky and C. Kale (1991, 28 pps.)

.IP \(bu 2
.B
Introduction to the Internet Protocols
.R
by Charles L. Hedrick (1987, 27 pps.)

.IP \(bu 2
.B
RFC 1206: Answers to Commonly asked "New Internet User" Questions
.R
by G. Malkin and A. Marine (1991, 32 pps.)

.IP \(bu 2
.B
RFC 1207: Answers to Commonly asked "Experienced Internet User"
Questions
.R
by G. Malkin, A. Marine, and J. Reynolds (1991, 15 pps.)

.IP \(bu 2
.B
RFC 1208: A Glossary of Networking Terms
.R
by O. Jacobsen and D. Lynch (1991, 18 pps.)

.IP \(bu 2
.B
RFC 1173: Responsibilities of host and network managers: A summary of
the "oral tradition" of the Internet.
.R
by J. VanBokkelen (1990, 5 pps.)

.IP \(bu 2
.B
Introduction to Administration of an Internet-based Local Network
.R
by Charles L. Hedrick (1988, 46 pps.)

.IP \(bu 2
.B
RFC 1118: The Hitchhiker's Guide to the Internet 
.R
by Ed Krol  (1989, 24pps.)

.IP \(bu 2
.B
Internetworking with TCP/IP \*- Principles, Protocols, and Architecture
.R
by Douglas Comer  (1988, Prentice-Hall, 261 pps. plus 5 appendices,
bibliography, and index; ISBN 0-13-470154-2)

The first three chapters of this textbook are of particular value to
beginners.  Comer should be available at any good technical bookstore.
A second edition is rumored nearly ready for publication.

.IP \(bu 2
.B
RFC 1175: A bibliography of internetworking information
.R
by K. L. Bowers (1990, 42 pps.)

.IP \(bu 2
.B
Network Manager's Reading List: TCP/IP, UNIX, and Ethernet 
.R
by Charles Spurgeon (1990, 27 pps.)

.bp
.PP
We also recommend that the following be kept available for convenient
reference:

.IP \(bu 2
.B
Improving The Security Of Your UNIX System
.R
by David A. Curry (1990, 51 pps.)

.IP \(bu 2
.B
RFC Index: Citations for the Internet Requests For Comment.
.R
(continuously updated by the Network Information Center)

.IP \(bu 2
.B
RFC 822: Standard for the format of ARPA Internet text messages
.R
by David Crocker  (1982, 47 pps.)

.IP \(bu 2
.B
RFC 1035: Domain Names \*- Implementation and Specification
.R
by Paul Mockapetris  (1987, 55 pps.)

.IP \(bu 2
.B
A Brief Tutorial on Sendmail Rules
.R
attributed to Charles L. Hedrick (1985, 16Kb).

.IP \(bu 2
.B
RFC 1036: Standard for interchange of USENET messages
.R
by Mark Horton and Rick Adams  (1987, 19 pps.)

.IP \(bu 2
.B
RFC 977: Network News Transfer Protocol
.R
by Brian Kantor and Phil Lapsley (1986, 27 pps.)

.IP \(bu 2
.B
RFC 1129: Internet time synchronization:  The Network Time Protocol
.R
by Dave Mills  (1989, 27 pps.)

.IP \(bu 2
.B
RFC 1122: Requirements for Internet Hosts \*- Communications Layers.
.R
(1989, 116 pps.)

.IP \(bu 2
.B
RFC 1123: Requirements for Internet Hosts \*- Application and Support.
.R
(1989, 98 pps.)

.IP \(bu 2
.B
RFC 1200: IAB Official Protocol Standards
.R
(1991, 31 pps.)

.IP \(bu 2
.B
RFC 1087: Ethics and the Internet.
.R
(1989, 2pps.)

.IP \(bu 2
.B
RFC 1178: Choosing a Name for Your Computer
.R
by D. Libes (1990, 8 pps.)

.IP \(bu 2
.B
Inter-Network Mail Guide
.R
by John J. Chew et al (1990 and 1991, 20 Kb)

.IP \(bu 2
.B
USENET Software: History and Sources
.R
by Gene Spafford (1991, 15 Kb)

.IP \(bu 2
.B
List of Active Newsgroups
.R
by Gene Spafford (1991, 37 Kb)

.IP \(bu 2
.B
Netiquette Guides:
.R
.RS

.IP \(bu 2
.B
Rules for posting to Usenet
.R
by Mark Horton (1990, 9Kb)
.IP \(bu 2
.B
Emily Postnews Answers Your Questions on Netiquette
.R
by Brad Templeton (1990, 15Kb)
.IP \(bu 2
.B
A Primer on How to Work With the Usenet Community
.R
by Chuq Von Rospach (1991, 18Kb)
.IP \(bu 2
.B
Hints on writing style for Usenet
.R
by A. Jeff Offutt VI (1991, 4Kb)
.RE

.\" Local Variables:
.\" mode: electric-nroff
.\" compile-command: "groff -ms -TX75 mst-reading-list.ms"
.\" End:

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 13:21:41 GMT
From:      tommyp@ida.liu.se (Tommy Pedersen)
To:        comp.protocols.tcp-ip
Subject:   NetBIOS vs. TCP/IP

Can anyone tell me the diffs and similarities between NetBIOS and TCP/IP
or where to look for info?

I would also like to know the same about IP and X.25.

Thanks,

/Tommy Pedersen
 ________________________________________________________________
|E-mail: tommyp@isy.liu.se       ||    Telephone: +46 13 282369  |
|S-mail: Tommy Pedersen          ||          FAX: +46 13 289282  |
|        Dept. of EE             ||______________________________|
|        Linkoping University    ||                              |
|        S-581 83 Linkoping      ||                              |
|        SWEDEN                  ||                              |
|________________________________||______________________________|

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 14:40:22 GMT
From:      alan@pluto.dss.com (Alan Warwick)
To:        comp.protocols.tcp-ip
Subject:   Public Domain TCP/IP for Vax/VMS


Hello -

	Does anyone know of a public domain (or rather cheap) version of 
TCP/IP that runs on a vax under VMS 4.7 ? Please reply via E-mail to
alan@doc.dss.com since I do not have regular access to this group.
Thank you very much in advance.


						Alan Warwick
						Datability
						alan@doc.dss.com
-- 
+-----------------------------------------------------------------------------+
|  Alan Warwick                                   Datability Software Systems |
| alan@doc.dss.com  		                  New York City               |
+-------------HELP !!! My PC has crashed and I can't boot up------------------+

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 15:36:46 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Amiga question...


Mr. Kennedy,

I caught your note about running ka9q on an Amiga, and I had a question:

Are you using one of the new 3000-UX{B | D} machines? Under System V
Release 4? If so, give me a quick idea of their usefulness. I'm
evaluating machines for home/work, and I hate the idea of buying some
lousy Intel-based machine, just because they're easy to find. (I far
prefer Motorola CPU's).

If you're not using a 3000, then tell me how the 2000's are, as I may
pick one of those up anyway.

Thanks in advance!

Bob Stratton
Stratton Systems Design
+1 703 823 6463
strat@gnu.ai.mit.edu
c_bstratton@hns.com

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 17:00:40 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   programming question


I have a problem that is driving me crazy...and was hoping someone
could help me.  Here is the story:

We have an old 3Com NCS-150 along with several CS/1's connected
to our Ethernet backbone.  Also connected to the backbone is a
Pyramid mini.  What we want to do is connect the printer port
on the NCS-150 to a port on the CS/1.  Then, a program running
on the Pyramid would be used to gather the log data from the
NCS-150 and store it in a file.....

Has anyone done anything like this, or something similar, maybe
with different equipment?  Any pointers, suggestions, or other
solutions would be greatly appreciated.

Thanks,

Bryan Miller

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 17:05:27 GMT
From:      ian@unipalm.uucp (Ian Phillipps)
To:        comp.protocols.tcp-ip
Subject:   Re: Wanted: /etc/hosts to DNS (rfc1035) format conversion program


jj@dcs.leeds.ac.uk (J Jackson) writes:

>Has anybody an off-the-shelf script of program that will read an 
>/etc/hosts file and create the database fileformat required by the
>named daemon?

This updates the version number automatically. I run it from a make file in
/etc on our host.

I just noticed that I hard-coded the name (diamond) of our primary server.
Yechhh...

----cut here and put in your domain/network address----
/usr/local/bin/perl <<'END_SCRIPT'
# This script takes the /etc/hosts file, and makes up copies of host->name (named.net) and name->host (named.db) tables
#
$_ =`grep 'serial number' /etc/named.db`;
$major=1; $minor=1;
if ( /([0-9]+)\.([0-9]+).*;.*serial number/ )
	{ $major = $1; $minor = $2 + 1; }

$zone = "unipalm.co.uk";
$net = '192\.9\.200';

open( db, '>/etc/named.db' ) || die;
open( net, '>/etc/named.net' ) || die;
open( stdin, '/etc/hosts' ) || die;

print db "@	IN	SOA	$zone.	diamond.$zone.  (
			$major.$minor		; serial number
			7200		; refresh every two hours
			7200		; retry every two hours
			12096000	; expire in twenty weeks
			86400 )		; time-to-live
		IN	NS	diamond.$zone.
";

print net "@	IN	SOA	$zone.	diamond.$zone.  (
			$major.$minor		; serial number
			7200		; refresh every two hours
			7200		; retry every two hours
			12096000	; expire in twenty weeks
			86400 )		; time-to-live
		IN	NS	diamond.$zone.

$zone.	IN	MX	0	mailhost.$zone.
		IN	A	192.9.200.5
";

    while( <> )
	{
	next unless /^192\.9/;
	s/#.*$//;
	($number,$name,@alias)=split;
	($net1,$net2,$net3,$net4)=split(/\./, $number );

	print db "$name\tIN\tA\t$number\n";
	print net "$net4\tIN\tPTR\t$name.$zone.\n"
		;#if $number =~ /[^0-9]192\.9\.200\./;
		#if $number =~ /[^0-9]$net\./;
	while( $alias=pop alias )
	    { print db "$alias\tIN\tCNAME\t$name\n"; }
	}
END_SCRIPT

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 17:12:36 GMT
From:      dunford@NISD.CAM.UNISYS.COM (Stephen Dunford)
To:        comp.protocols.tcp-ip
Subject:   Raw Ip sockets

Dear TCP/IPers

I am interested in finding out if there are any Unix applications which
use a raw socket interface directly to IP (not ICMP).  I would like
to get the source code if possible as an example.

-Rayna



Please send replies to <rayna@cam.unisys.com>

-------

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 18:15:04 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   self-referential arp?


	Does it make any sense for something to arp for its own ethernet
address?  This is some tcpdump output from a Kinetics FastPath I'm trying
to configure to use KIP/IPTalk:

13:18:44.62  wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:44.62  arp who-has 128.122.136.160 tell 128.122.136.160
13:18:45.66  wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:45.66  arp who-has 128.122.136.160 tell 128.122.136.160
13:18:46.68  wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:46.68  arp who-has 128.122.136.160 tell 128.122.136.160
13:18:47.70  wombat.phri.nyu.edu.16513 > 128.122.136.160.at-nbp: udp 43
13:18:47.70  arp who-has 128.122.136.160 tell 128.122.136.160
13:18:48.72  wombat.phri.nyu.edu.16514 > 128.122.136.160.at-nbp: udp 43
13:18:48.72  128.122.136.160.16514 > wombat.phri.nyu.edu.at-nbp: udp 43
13:18:48.78  wombat.phri.nyu.edu.at-nbp > 128.122.136.160.16513: udp 43
13:18:48.78  128.122.136.160.at-nbp > wombat.phri.nyu.edu.16513: udp 43

	What do the "arp who-has 128.122.136.160 tell 128.122.136.160"
packets mean?  This is the kbox asking for its own ethernet address.  Is
that normal, or something I might have configured wrong, or a bug in the
gateway code?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 19:05:27 GMT
From:      ruggeri@ready.com (Francesco Ruggeri)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP test suites and benchmarks



I would like to get some information on public domain or commercially available
test suites and benchmarks for the TCP/IP protocol suites.
Does anyone know where I can get it ?
Thanks,

Francesco Ruggeri

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 20:05:21 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Finger services (surf server)


I came in on this (neat) discussion a tad late, so forgive me if this
question has already been answered.

I have heard apocryphal stories about the existence of a "surf server"
somewhere on the Left Coast. (UCSD maybe?) The tale describes a wave
height/frequency sensor with a line in to a PDP-11 or somesuch, with a
finger server on the internet.

Can anyone confirm this beastie's existence? Inquiring minds want to know.

Bob Stratton
strat@gnu.ai.mit.edu
c_bstratton@hns.com

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 20:24:42 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Request For Info On Dynamically Acquiring IP Addresses At Boot

PC/TCP for DOS has included a BOOTP (RFC 951) client since 10/89.  It
helps a lot, but because of the limit on the BOOTP packet's size and
the amount of space reserved for other items, it isn't the be-all and
end-all for automatic configuration.

The IETF Dynamic Host Configuration working group was chartered
sometime in 1990 to figure out what to do next, but I don't know how
much progress they've made since.  Originally they were considering
BOOTP extensions, but they may have swung over to developing a new
protocol.  One hard problem they're faced with is short-term dynamic
IP address assignment, where a PC picks a new address on each boot,
and uses it for the life of that bootload....

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

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 20:50:31 GMT
From:      rlg@STYX.DESKTALK.COM (Richard L. Gralnik)
To:        comp.protocols.tcp-ip
Subject:   An informal survey

Hi.  A recent discussion of the comparative merits of slide latches versus
screw/thumbscrew as a means of attaching a cable to a system port has
prompted this unofficial opinion poll.

Which do you prefer and why?  

or put another way -

Do you like slide latches (the connector used for ethernet cables)?  Why 
or why not?

Do you like screw on connectors?  Why or why not?


Feel free to forward this note to friends.  Also, please reply directly,
not to the list.  I'll publish the results if there are any.

Thanks,

Richard Gralnik
(rlg@desktalk.com)

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 22:03:27 GMT
From:      ted@blia.sharebase.com (Ted Marshall)
To:        comp.os.vms,comp.sys.dec,comp.protocols.tcp-ip
Subject:   Query: performance of VMS TCP/IP implementations

We are in the process of selecting a TCP/IP vendor for VAX/VMS for a
special project. I am in the process of contacting the vendors for
information but I have two questions that may be difficult to get
answers for that I was hoping that the net could help with.

The implementations I am looking at are:
	UCX from DEC (is this officially called the "VMS/ULTRIX connection"
		or are these two different products?);
	WIN/TCP from The Wollongong Group;
	Fusion TCP/IP from Network Research; and
	MultiNet TCP/IP from TGV.
I already have a copy of CMU-TEK TCP but this project requires a commercially
supported product.

My basic requirements include:
	TCP and IP (supported by ARP and ICMP);
	Share DEC Ethernet interface with DECnet;
	Process-to-process TCP connections (other protocols and utilities
		desired but not required; socket library not required, QIO
		interface adequite);
	At least 200 simultaneous TCP connections to other hosts (given a
		large enough VAX).
I believe that all of the implementations I've listed meet these requirement,
possibly excepting the last. If anyone knows of other vendors, please feel
free to suggest them.

My two basic questions:

(1) Does anyone know what the actual limit of simultaneous connections is for
a given implementation. Or at least, conformation that an implementation can
make it to 200.

(2) Has anyone benchmarked any of the implementations against another? I am
interested in performance of TCP and IP only. For example, Given two VAXen
on an Ethernet, a small program on one feeding data to a small program on the 
other over TCP, how many KB per second?

Please mail any information to "ted@airplane.sharebase.com". I will summarize
the responses, along with anything I get from calling the vendors. Email from
vendors is also welcome.

Thanks in advance.

-- 
Ted Marshall                                       ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Apr 91 23:06:37 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Is the DNS "working"?

In article <1234@foo.bar> name@changed.to.protect (The Guilty) writes:

   Hi, there,
   	Could somebody mail me the common pc-ftp sites' IP address
   	to me ? My computer cann't check the site's internet name.

   	Thanks,

Per the quoted message, I'd have to say "No, the Domain Name System
(DNS) is not working".  Requests like these are not uncommon.  They
would be even more common except for the fact that people publishing
site names have learned to include the IP address.

I run a well-used archive site (grape.ecs.clarkson.edu) that recently
(Feb. 20th) changed its IP address.  Since then, we have kept a
"victim" PC running on the old IP address [128.153.13.196].  The home
FTP directory on this PC has files that direct a user to the new IP
address.

In the past six days, we have had 287 FTP sessions initiated at the
OLD IP address.  This, to me, is evidence that users have learned to
avoid using host names, preferring to use IP addresses.

I suppose it's a little unfair to lay the blame at the feet of the
DNS.  After all, hosts using the DNS can simply FTP to grape.  Or, if
your host doesn't use the DNS, a moment with nslookup or dig will get
you grape's IP address.  But it is exactly this latter case that
causes the problem.  On these hosts, a user must use a program that
prints the IP address, then they must reenter the IP address to the
FTP client.  Once you know the IP address of a machine, why look it up
again?

Fairness, then, would dictate laying part of the blame on those system
administrators who use /etc/hosts in preference to the DNS.  And for
the sake of truth, both I (on grape) and the sysadmin of
sun.soe.clarkson.edu refuse to use the DNS (consider this message a
confession, and the TCP-IP list the confessional).  For my part, the
OS on grape.ecs.clarkson.edu experienced kernel crashes when using
the DNS.  I went back to /etc/hosts and the crashes went away.
But I think that's a minor problem.

A more serious problem is faced by servers on the Internet.  On the
one hand, the sysadmin would like users to be able to access any
machine on the Internet, and that means using the DNS.  On the other
hand, the sysadmin MUST (at least this one must) keep the machine
running even if access to the name server is cut off, even
temporarily.  A typical plaintive user cry is "Why can't we use
sun.soe.clarkson.edu just because omnigate.clarkson.edu is down?"

Perhaps there is a work-around.  If there is, it's not well
documented, because as I showed earlier, sun.soe.clarkson.edu is
not the only machine relying on /etc/hosts.

I think we need a hero to document the work-around.  I don't think the
grand Usenet tradition of volunteering the complaintant should apply
in this case because I'm not the sysadmin on sun.soe.clarkson.edu.
Besides, I don't *know* what the work-around is.  I just want the
person who DOES know to step forward, or at least to remain still while
the rest of us step backwards.

Thank you, you wonderful person, whoever you might turn out to be.

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 01:20:19 GMT
From:      wong_a@summer.chem.su.oz.au
To:        comp.protocols.tcp-ip
Subject:   Can't ftp to Apollos



For some reason we can't seem to ftp to our Apollo's. The standard
login prompt appears but after entering the user-name we get,

530 User <user> access denied
login failed

Is there some security set-up that we've missed?


-----------------------------------------------------------------------------
Adrian Wong, Dept.of Theoretical Chemistry     wong_a@summer.chem.su.oz.au
University of Sydney NSW 2006 Australia        061-2-692 4137
-----------------------------------------------------------------------------

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 04:13:26 GMT
From:      emv@OX.COM (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   call for discussion of usenet newsgroup 'comp.protocols.ppp'.

[This will be familiar to you if you have read news.groups or comp.dcom.lans
recently.  I am not posting it from news because the gateway eats my 
address.]

I am gathering opinions and interest for a new Usenet newsgroup,
to be called 'comp.protocols.ppp'.  It will discuss the Internet
"Point to Point Protocol", implementations, protocol details, 
interoperability reports, software, hardware, etc.

Currently there is a fair amount of discussion of PPP on Usenet; though
it's scattered around in a number of groups, I was able to count on the
order of 50+ relevant articles in a span of two weeks.  Unfortunatly
these articles were in more than a dozen different groups, and there's no
single one group where the discussion would ordinarily gravitate.

This group would cover the following subject:
	- the Point to Point Protocol
	- IETF efforts at standardizing and extending the protocol
	- free and commercial software implementations
	- interoperability reports
	- other protocols occupying similar ecological niches, including
	  SLIP, compressed SLIP, and various HDLC things (but not 
	  other async protocols like Kermit or xmodem)
	- hardware details of async and sync communications, whenever
	  that ends up being relevant.

The usual Usenet ritual involves a "request for discussion", a period
of time for hair-tearing and gnashing of teeth to determine whether the
name is suitable, and then a "call for votes".  The discussion thus
far has centered on whether the name is too narrow and shouldn't be
widened to encompass SLIP; I suspect that the actual discussion in
a "ppp" group will include slip discussion for a while if only because
of the installed base.

Comments can go to me or to the list; discussion regarding the name
is traditionally the playpen of news.groups.  Substantive discussion
of PPP would be best done in the two existing usenet groups that get
most of the traffic (comp.dcom.lans and comp.dcom.modems) or on the
IETF PPP mailing list (mail to ietf-ppp-request@ucdavis.edu to join).

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	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

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 05:37:49 GMT
From:      brian@NAPA.TELEBIT.COM (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   call for discussion of usenet newsgroup 'comp.protocols.ppp'.

I propose comp.protocols.serial-internetworking.  The name is more in
line with the likely discussion areas including slip, ppp, and using
all this stuff to build or extend networks.

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

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 06:09:40 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: self-referential arp?

In article <1991Apr18.181504.21390@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
>	Does it make any sense for something to arp for its own ethernet
>address?

Many systems do this when they first boot.  If it gets a reply, it means
that someone configured two hosts with the same address, and it can then
display an error message.

However, this doesn't seem to be what was happening in your case, because
it ARPs for itself whenever it receives the at-nbp packet.  My guess is
that it's a configuration problem.



--
Barry Margolin, Thinking Machines Corp.

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

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 10:41:06 GMT
From:      cnbs06@vaxa.strath.ac.uk (Bruce Rodger.)
To:        comp.os.vms,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc
Subject:   UCX server implementation problem


We are currently trying to port Geoff Huston's ANU-NEWS server to run under 
UCX. We are having one major problem - how to start a new server process 
each time a TCP call is received on the news server port (conventionally 
port 119), and assign that stream to that process.

Under Unix, it would be straightforward - you would just add an entry to 
/etc/services, specifying the program to be run when a call is received. 
Similarly, under CMU TCP and WIN TCP, you would modify 
sys$manager:internet.config or twg$tcp:[netdist.etc]servers.dat & 
twg$tcp:[netdist.etc]services respectively. Under multinet, you would use 
the $Multinet config/server command, and even under DECnet, you could use 
NCP. But how do you do this sort of thing under UCX ?

My own feeling is that it can't be done in this way - there is no mention 
of anything like this in the UCX manuals. We'll probably have to take an 
approach similar to that used by the UCX FTP utility - a daemon (UCX$FTPD) 
runs as a detached process, "listening" to the appropriate port. When an 
incoming call is detected, a server process (UCX$FTPC) is created, and the 
logical stream assigned to this process.

Obviously what we require is a program to performa function similar to the 
UCX$FTPD program.

However, as we don't have the source code for UCX$FTPD available, I'm 
unsure how to go about writing the news_daemon. In particular, how is the 
new process created, and how is the stream assigned to that process ?

Any information or example code would be gratefully received!


Bruce.

-- 
R.B. Rodger        |JANET:   R.B.Rodger@uk.ac.strath.vaxa
OptoElectronics Grp|Internet:R.B.Rodger@vaxa.strath.ac.uk
Elec. Eng. Dept    |
Strathclyde Univ   | Thank you for dealing with ByteSabre Software Inc. Your
Glasgow G1 1XW     | bill is in the post. When it arrives, remember our motto:
Scotland.          | "We know where you live!"

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 14:37:45 GMT
From:      splee@gnu.ai.mit.edu (Seng-Poh Lee, Speedy)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   How to change the login message of telnetd?

Hi,

Does anyone out there know how to change the default login message of
telnetd? For example, on my machine, when you telnet to it, it gives

HP-UX hostname 5.5 B 9000/330

login:

I want to be able to add an additional message to this login message. Is
there any way of doing this without having a customized version of /bin/login
or /etc/telnetd?

--
Seng-Poh Lee
splee@gnu.ai.mit.edu

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 15:00:32 GMT
From:      bergum@SRC.Honeywell.COM (David Bergum)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?


In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes:


>Russ> In the past six days, we have had 287 FTP sessions initiated at the
>Russ> OLD IP address.  This, to me, is evidence that users have learned to
>Russ> avoid using host names, preferring to use IP addresses.

Not neccessarily.  It takes time for the old IP address to age out of local
cache, so the users may be using the host name and dns, but getting some
old data from their local server.  A good thing to do when you are going to
change an IP address is to set a short TTL for the A RR some time in
advance of the change, so ti will age out more quickly and the old data
will be replaced with the new RR with a normal TTL.
      A
-----/|\---------------------------------------+
-   / | \   Bergum@CIM-VAX.Honeywell.COM       |
-  /__|__\  Dave Bergum [MN26-3190]            |
-  t--'--/   2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~  (612)870-5839                     |
-----------------------------------------------+

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 15:03:33 GMT
From:      tjs@MSC.EDU (Tim Salo)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

> Hi.  A recent discussion of the comparative merits of slide latches versus
> screw/thumbscrew as a means of attaching a cable to a system port ...

Screw connectors have never brought down our network.  Slide-lock connectors, 
on the other hand, have fallen off, (with or without help), and brought
down parts of our network.  (I once believed, without evidence, that slide-
lock connectors were the largest single source of [LAN] network downtime.)

Does anyone have experience replacing Ethernet slide-lock connectors
with screw connectors?  (Is there a reasonably easy way to do this?)

Tim Salo
Minnesota Supercomputer Center
(612) 626-3047
tjs@msc.edu

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 15:35:18 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Finger services (surf server)

Ask Brian Kantor about the surf server.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 17:33:03 GMT
From:      ckollars@deitrick.East.Sun.COM (Chuck Kollars - Sun Technical Marketing - Boston)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey

In article <9104182050.AA07838@desktalk.com> rlg@STYX.DESKTALK.COM (Richard L. Gralnik) writes:
>Hi.  A recent discussion of the comparative merits of slide latches versus
>screw/thumbscrew as a means of attaching a cable to a system port has
>prompted this unofficial opinion poll.
>
>Which do you prefer and why?  
>
>or put another way -
>
>Do you like slide latches (the connector used for ethernet cables)?  Why 
>or why not?

The results of your survey are likely to be seriously skewed.  Ethernet
transceiver cables often don't work, and most folks blame it on the
slide latch.  So I'd guess you're going to get a lot of responses
denigrating the slide latch.

But the full story is that, although the Ethernet transceiver cable
connector on many systems in fact doesn't work very well, it's _not_
the fault of the slide lock.  The spec (see drawing on page 94, just
above section 7.6.2) says that the connector should go on the _outside_
of the backpanel.  But in order for printed circuit boards to be
stuffed and soldered by automatic machinery then married to the system
later, the connector is often mounted on the _inside_ of the
backpanel.  Result -- the connector wobbles and makes poor electrical
connection even though the cable is inserted "all the way" and the
slide lock is "closed".

The Ethernet spec was apparently written by someone who either was not
a mechanical engineer, or did not have any experience with automated
manufaturing.  The reputation of the slide lock will probably never
recover from that oversight.
---
chuck kollars    <ckollars@East.Sun.COM>
Sun Technical Marketing, located in Sun's Boston Development Center

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 21:28:30 GMT
From:      hotz@isi.edu (Steve Hotz)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

In article <NELSON.91Apr18230637@sun.clarkson.edu>
nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:

>> Per the quoted message, I'd have to say "No, the Domain Name
>> System (DNS) is not working".

Whoa whoa whoa there net cowboy ;-).  That's a pretty amazing
statement considering the hundreds of thousands of hosts that rely
on DNS.  While it is true that some of the implementations floating
about could be better, and that DNS and YP still don't "play together"
very well, for the most part DNS problems are due to misconfigurations
by administrators.


>> I run a well-used archive site (grape.ecs.clarkson.edu) that
>> recently (Feb. 20th) changed its IP address.
>> In the past six days, we have had 287 FTP sessions initiated at the
>> OLD IP address.  This, to me, is evidence that users have learned to
>> avoid using host names, preferring to use IP addresses.

This is usually evidence that DNS caching is working as it is supposed
to, and that the reccommended procedure when changing DNS info of
reducing the RR TTL before such a change is made wasn't followed.

However, if it has been almost two months then there are either some
*really* goofy implementations not paying attention to TTLs (the most
common implementations do this correctly) or more likely, some folks
don't use DNS resolver to get current information, so they use the old
IP address they wrote down N months ago.


>> I suppose it's a little unfair to lay the blame at the feet of the
>> DNS.  [... some text deleted ...]

Now you're talking.  The problem, more generally, is stale data,
which by using the DNS mechanisms correctly, is quite nicely avoided.


>> A more serious problem is faced by servers on the Internet.
>> [... one hand deleted ...] On the other
>> hand, the sysadmin MUST (at least this one must) keep the machine
>> running even if access to the name server is cut off, even
>> temporarily.  A typical plaintive user cry is "Why can't we use
>> sun.soe.clarkson.edu just because omnigate.clarkson.edu is down?"
>> Perhaps there is a work-around.  If there is, it's not well
>> documented, because as I showed earlier, sun.soe.clarkson.edu is
>> not the only machine relying on /etc/hosts.

I believe it is documented with emphasis in the appropriate RFCs
[1034 & 1035] that domain servers are required to be replicated
(two is the required number).  In fact, to be delegated a section of
the namespace, one is supposed to show that this redundancy exists.
If a domain can't keep one of two machines up at all times, then it
makes sense to have further replication.  With this redundancy, and
a correctly configured /etc/resolv.conf life is good and peaceful!

>> I think we need a hero to document the work-around.

Although it may be reasonable to have the resolver library fall
back on hosts.txt (argh) if no nameserver can be reached, i think
i'd probably recommend that this "hero" be put on the "domain police"
wanted list for crimes against the forward progress of the Internet ;-).

Yours resolvedly,

	steve

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 22:45:40 GMT
From:      cathyf@lost.rice.edu (Catherine Anne Foulston)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
>I suppose it's a little unfair to lay the blame at the feet of the
>DNS.
 ....
>Fairness, then, would dictate laying part of the blame on those system
>administrators who use /etc/hosts in preference to the DNS.

Some of the blame should surely be laid at the feet of vendors who
implement tcp/ip but not DNS.  (Or who implement it so poorly that it's
unusable.)  If you're going to add tcp/ip capability to a system, you
should include the ability to use the nameservice.  (See RFC 1123.)

	Cathy
--
Cathy Foulston + cathyf@rice.edu + Rice University, Network & Systems Support

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Apr 91 23:00:15 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?


anonymous ftp sites are particular prone to stale data, to wit:

- the 'anonymous ftp site' list which gets posted monthly has ip 
  numbers in it
- 'comp.archives' postings have ip numbers in them (and I won't send
  one out unless I can identify an address
- various and sundry of these numbers have been squirreled away on
  machines of all persuasions, including systems (like pre-NOS
  versions of KA9Q) with no working name server.

If you capture the addresses of the originating sites to the old
machine, it would be interesting to see a breakdown of what operating
systems were involved.  Dollars to donuts quite a few are running KA9Q
net.exe. 

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	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

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 02:39:11 GMT
From:      mclay@zoyd.ae.utexas.edu (Robert McLay)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   PPP: Can't get PPP to work with sunOS 4.1.1 on SS2 (worked with 4.1)


I have been using PPP between a sun 4/330 and a sun SLC (4/20)
connected with 2 T2500 modems.  Both systems are running sunOS 4.1
I want to get PPP to work now with a SPARCstation 2 (4/75) running 4.1.1
and it won't work (for me).  

What happens is that  ppp0 won't come UP 

a) I have the source from 
         tut.cis.ohio-state.edu:pub/ppp/ppp-sparc4.1.tar.Z (patchlevel 4)

b) I installed the bug fix from ftphost.cs.athabascau.ca:
         sun-patches/100149-03.tar.Z

c) I have ppp.c which has the following at the remote end (work)
     if ((pgrpid = setsid()) < 0)
       pgrpid = getpgrp(0);
     if (tcsetpgrp(fd, pgrpid) < 0) {
       perror("ppp: tcsetpgrp()");
       exit(1);
     }
and the following code in the ppp.c  at the local end

     if (setsid() < 0)
       {
       perror("ppp: setsid()");
       exit(1);
       }

I had to do this strange thing at home to avoid the 
"ppp: tcsetpgrp ..." error.


What happen now when I try to connect to the SS2 running 4.1.1
is nothing ( there are no errors).  Running ifconfig -a:

(local end)
vato(10)$ ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 128.83.152.135 netmask ffff0000 broadcast 128.83.0.0
ppp0: flags=51<POINTOPOINT,RUNNING>
        inet 128.83.152.135 --> 128.83.152.200 netmask ffffff00
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000

*vato(11)$ netstat -rn
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
127.0.0.1            127.0.0.1            UH       26     4647       lo0
128.83.152.200       128.83.152.135       UH       0      0          ppp0
128.83.152.135       128.83.152.135       UH       0      0          le0
default              128.83.152.200       UG       2      0          ppp0

As you can see ppp0 is not UP.  The same is true at the other end

(remote end)
zoyd(1)$ ifconfig -a
le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
        inet 128.83.152.200 netmask ffff0000 broadcast 128.83.0.0
ppp0: flags=10<POINTOPOINT,RUNNING>
        inet 128.83.152.200 --> 128.83.152.135 netmask ffffff00
lo0: flags=49<UP,LOOPBACK,RUNNING>
        inet 127.0.0.1 netmask ff000000

*zoyd(2)$ netstat -rn
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
128.83.152.200       128.83.152.200       UH       21     22535      le0
127.0.0.1            127.0.0.1            UH       7      81         lo0
128.83.152.135       128.83.152.200       UH       0      0          ppp0
default              128.83.1.250         UG       0      35         le0
128.83.0.0           128.83.152.200       U        34     5496       le0

Anybody have any clues???

--

______________________________________________________________________________
Robert McLay                   | When you have a problem, put NO in front of
Manager CFD Lab                | it and you have:  NO PROBLEM.
Dept ASE-EM                    |
University of Texas at Austin  |           -- Eric Beckman's 2nd Law
                               |
mclay@wilbur.ae.utexas.edu     |

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 08:13:53 GMT
From:      jmg@cernvax.cern.ch (mike gerard)
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 key mapping for DECstations

In article <9104151708.AA14025@ganges.ucop.edu> spgdrp@GANGES.UCOP.EDU ("Donald R. Proctor   spgdrp@ganges.ucop.edu") writes:
>
>  Has anyone devised a key mapping for tn3270 on DECstations that takes
>  advantage of the function keys on the keyboard?  I would love to
>  received a copy of the map file if you have.  Many thanks in advance.
>
>Gee, I'd even settle for the cursor keys (and maybe more reasonable
>handling of highlighted screen characters).  Would you send me a note if
>you get replies to this?

Am I being stupid and missing something?
I run a strongly modified version of tn3270 on DECstations including
my own. I have various mappings, which are normally chosen as a function
of the TERM value (but can be overridden with a KEYMAP name).
Normally TERM is either xterm (if I run xterm) or vt300 (if I run a
dxterm window).
The function keys work fine except when the window manager is set up
to grab them first!
I don't understand the "highlighted screen characters" remarks: I do
actually do things with such characters, under the overall control
of the various termcap entries for blink, reverse, bold etc.
-- 
 _ _  o |            __                    |    jmg@cernvax.uucp
| | |   |     _     /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)    |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___   \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 10:15:30 GMT
From:      GBODSO1@NUSVM.BITNET (HC Eng)
To:        comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

>Just a suggestion, but wouldn't this subject work a little better in
>comp.dcom.lans? The discussion there is about cable and boxes. My
>impression of comp.protocols.tcp-ip is that it is above the physical layer
>of the OSI stack.

Can someone tell me how to subscribe to lists with names separated by
periods, like comp.dcom.lans?  I am on BITNET only.  From the above, am
I right to say that the list which I am now reading from, which I subscribed
to by sending a message to LISTSERV at UTDALLLAS, and is now distributed by
TCP-IP@NIC.DDN.MIL, is also called comp.protocols.tcp-ip somewhere else?

HC Eng - Singapore

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 10:30:52 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   convert Ethernet numbers into ASCII text

A simple way to get this list is:

	1) Find a unix system on the same wire
	2) Ping each of the hosts (once should be enough, i.e. "ping -n1")
	3) Type the command /etc/arp -a

You should get back a list of names, IP addresses, and Ethernet
addresses.  There, wasn't that simple?  Now for the hard question, are
you going to remember to do this every time any machine on your subnet
has maintenance performed on it?  That can change the Ethernet
address.  I can't tell you how many times someone tracking a problem
with numbers only got misled by using an out-of-date list, and you
often can't generate a new one if the network has problems you're
trying to fix.

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

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

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 17:14:09 GMT
From:      davidd@HITL.VRNET.WASHINGTON.EDU (David Doll)
To:        comp.protocols.tcp-ip
Subject:   convert Ethernet numbers into ASCII text


Hello,
	I'm going to be bringing a network analyzer (sniffer) into our 
department and it displays the Ethernet number (for example: 8:0:2b:18:96:bf).
I would prefer to look at the host name (for example: foo.cs.washington.edu).
So what I  would like to be able to do is to get the names from all the 
machine numbers in the department (~100 or so). Has anybody did this or know
how or know what to do...? I'd appreciate any help. Thanks. If you e-mail
me, I could post a summary if theres interest.


David Doll
Human Interface Technology Lab
University of Washington
M/S: FU - 20
Seattle, WA 98195 
(206) 543-5075
davidd@hitl.vrnet.washington.edu

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 21:24:19 GMT
From:      sardella@strfleet.gsfc.nasa.gov (Tom Sardella)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   SUMMARY - Excelan EXOS TCP/IP Software

Many thanks to all those who responded to my request for help on 
the current status of the EXOS product.  My main concerns were
the continued support of this product (updates, new licenses,
etc.) and getting a legal copy of the last released version.  The 
bottom line is that Novell and Federal Technology Corporation (FTC)
are currently negotiating for the rights on the software product
and that FTC hopes to provide the support that we need.  I guess
we'll have to wait and see what happens.

The following points were brought up in the responses and in other
research I have done:

	1.  EXOS software a "dead" product

	We weren't the only people confused about the state of this
	product.  Many people, including ourselves, thought that EXOS
	was placed in the public domain when Novell took over Excelan.
	We even had someone at Novell tell us in December, 1990, that 
	this was the case.  Representatives from both Novell and FTC
	now tell us that they are negotiating to turn the product
	over to FTC.


	2.  Excelan Hardware Support

	FTC does provide continued manufacture and support of
	the EXOS boards.  We have had no problems to date with this
	support that I am aware of.


	3.  Use of EXOS code in Novell products

	We acquired a copy of "LAN Workplace for DOS 4.0" and they
	are still using the EXOS NET code on an EXOS 205 board.


One thing I'm still confused about is what is the latest
version and what do the version numbers mean?  We originally
started with V3.2.  Avnish Aggarwal, who used to work for Excelan
and now works for Novell, says the latest version is 4.Na.
The version we got with LAN Workplace is 4.Ca.  The "Na" and
"Ca" suffixes seem odd.

What we think we can do about the licensing problem at this point
is to go ahead and buy all the LAN Workplace licenses we need
and then run NET on our Multibus EXOS 201 boards rather than
the PC EXOS 205 boards.  The license agreement states that you
can run object code on one licensed machine at a time, but they
don't distinguish what a "machine" is.  Are there any legal experts
out there?

It looks like our news server is OK now, so I can accept further
postings on this subject.


		Tom Sardella
		Network Control Systems Branch, Code 532
		NASA/Goddard Space Flight Center
		Greenbelt, MD
		sardella@strfleet.gsfc.nasa.gov

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 21:36:54 GMT
From:      sl@wimsey.bc.ca (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: call for discussion of usenet newsgroup 'comp.protocols.ppp'.

In article <9104190537.AA00924> brian@napa.telebit.COM writes:
>I propose comp.protocols.serial-internetworking.  The name is more in
>line with the likely discussion areas including slip, ppp, and using
>all this stuff to build or extend networks.

How about:
comp.protocols.a-gratuitously-long-name-that-may-or-may-not-adequately-describe-the-group-to-discuss-ppp-and-related-protocols

Personally I think that comp.protocols.ppp is succinct and to the point. As
Ed pointed out there is currently a lot of discussion in a wide range of
groups on ppp. We need to collect it together.

If you want to suggest a different group to discuss building internets or
WANS or whatever go to it. I suggest it should be seperate from
comp.protocols.ppp. 


-- 
Stuart Lynne	Computer Signal Corporation, Canada
		...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca 

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 Apr 91 22:53:15 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw Ip sockets

>I am interested in finding out if there are any Unix applications which
>use a raw socket interface directly to IP (not ICMP).  I would like
>to get the source code if possible as an example.

The BSD gated program is a working example of how to use raw socket. It is
available in uunet.uu.net:networking.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 91 01:30:24 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Netbios B-node to M-node converter (looking for).


	I remember a while ago someone posted the source to a program
which intercepted B-Node Netbios Name requests and did some sort of 
Domain Name Lookup and response, thus allowing B-Node Netbios implimentations
to function like M-Node stations.

	I saved this posting, but it got purged when I ran out of disk space.
I find that I now need a copy of the programs. (So whats new? :-) ). Can
anyone direct me to its location or email me a copy?


	- Thanks in advance,

	Carl Beame
	Beame@McMaster.CA

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 91 03:06:33 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Finger services (surf server)

In article <9104190835.AA25013@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
>Ask Brian Kantor about the surf server.
>		- john romkey			Epilogue Technology


      SIO Pier Weather:   Sat Apr 20 19:55:00 1991

        Air Temperature:  14.1 DegC  (57.4 DegF)

        Wind:   004.2 Mi/Hr   From 294.1 Degrees

        Barometer:                  30.05 Inches

        Water Temperature:
               Surface = OUT OF ORDER 
               Bottom  =  16.3 DegC  (61.3 DegF)

        Tide Gauge:                    03.85 Ft.

        Last Wave Data Record:  Sat Apr 20 16:05
               Sig Ht:  33.1 Cm   Period: 11 Sec

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 91 19:27:29 GMT
From:      emv@ox.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw Ip sockets

In article <89829A68693FA012DB@nusdiscs.bitnet> TAYBENGH@NUSDISCS.BITNET (THE AGEIS) writes:

   The BSD gated program is a working example of how to use raw socket. It is
   available in uunet.uu.net:networking.

More accurately, the home of gated is gated.cornell.edu in
/pub/gated/; the current release is gated.tar.Z (of 24 Jan 1990), and
the working version is 2.0.1.10 (of 16 Apr 1991).  uunet only has the
old version.

-- 
 Msen	Edward Vielmetti
/|---	moderator, comp.archives
	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

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      21 Apr 91 21:22:59 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.protocols.tcp-ip
Subject:   Re: finger weather

In <1991Apr21.205237.24332@mnemosyne.cs.du.edu>, caserta@athena.mit.edu writes:
>The Department of Atmospheric Sciences, University of Washington
>provides the following service, and also unusual application of finger.
>Do you know of any other unusual application of finger?

   NO, they do NOT anymore. The company they get the information from
  has it in their contract that the information can't be redistributed.
  (Without a $150 fee, but that's not applicable. They have to keep it
  on the UofW campus.)


-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
      "Does this person look relaxed to you?  Well, it's actually an
              experiment of Contour's new 565-E chair!"

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 01:46:25 GMT
From:      JCHAPMAN@MATHOM.CISCO.COM (John T Chapman)
To:        comp.protocols.tcp-ip
Subject:   [John T Chapman <CHAPMAN@mathom.cisco.com>: HSSI]


To Everyone Who Requested the HSSI Spec:


My apologies to everyone for taking so long to get back with copies
of the HSSI specification.  We have received so many requests that
we have decided to offer it in the form of an anonymous FTP at
FTP.CISCO.COM

The file name is HSSI.NOT .  There are two diagrams which are part of
appendix A and B which are not available yet until I can get the data
files translated.  The diagrams in Appendix A and B, however, are
redundant and are fully described in the text of the document.  They
will be called HSSI-A and HSSI-B with an extention of .PSF or
.NOT.

Attached is the original note explaining HSSI.  Thanks for everyone's
interest.

John T. Chapman

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

Mail-From: CHAPMAN created at 11-Mar-91 17:18:55
Date: Mon 11 Mar 91 17:18:55-PST
From: John T Chapman <CHAPMAN@mathom.cisco.com>
Subject: HSSI
To: ez@gandalf.ca
cc: tcp-ip@nic.ddn.mil, cs@cisco.com, chapman@mathom.cisco.com
Message-ID: <12668647454.23.CHAPMAN@mathom.cisco.com>


Eugene,

You were interested in HSSI.  HSSI stands for the High Speed Serial
Interface.  It is a serial data interface capable of running up to 52
Mbps.  The electrical signal levels are balanced ECL, and the
connector/cable used is the same as is used in SCSI-2.

HSSI was conceived and designed by cisco Systems and T3plus Networking
as an interface between cisco's router product and T3plus's DS3 DSU
product.  cisco and T3plus have put this spec forward as an open
specification for industry use.

Originally defined in October of 1989, it is now in use by over 50
companies world wide.  HSSI is becoming a defacto industry standard
for data interfaces which need to communicate to DS3 equipment, or to
other data facilities which exceed 10 Mbps.

I will send you a copy in the mail.  If anyone else would like a copy,
please contact me at the address below.  Your name will also go on a
distribution list to receive any future updates.

John T. Chapman

chapman@cisco.com

cisco Systems
1525 O'Brien Drive
Menlo Park, Ca 94555

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

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 03:32:37 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Is SunOS4.1 & above supports IPPROTO_RAW & IP_HDRINCL?

Hi netlander,
        We would like to use Van Jacobson's traceroute program. However,
in order to make it work, kernel patching is required for supporting
IPPROTO_RAW & IP_HDRINCL (i.e. to send IP data with IP header included)
in SunOS4.0.x and below, and BSD4.y (y<=3) OSs. I would like is it still
necessary to patch SunOS4.1 in order run traceroute. In another word, is
SunOS4.1 support sending IP data with header using IPPROTO_RAW & IP_HDRINCL?
        Please email to me, I will summarize.
        Thanks a lot.

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

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 05:44:27 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Re: Raw Ip sockets


        Gated is written by Cornell Univ, thus not a BSD program. I apologize
for the mistake made. I thanks Mark Bodenstein for correcting me.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 12:12:39 GMT
From:      powell@newyork.crd.ge.com
To:        comp.protocols.tcp-ip
Subject:   Communication clarification and information requested



I am an engineer and I have the task of trying to develop a
system for mechanical engineering design that involves running
programming tools such as fortran turbine design
programs, compressor design programs, a C database, and a rule
system(s) on different platforms. These platforms are
IBM PC 386 or higher, Sun 4, HP, Decstation, and Vaxstation.
All of my platforms are connected by TCP over ethernet.

My problem is which communication software do I use to develop
the client-server concept to run on each machine. I would appreciate
any and all comments that would enlighten me about the pluses and
minus of any given approach. Below I have listed some approaches
that I have read about but need clarification from you more experienced
software experts on the net.

1. I read about Sun's RPC which are suppose to allow the developer to
concentrate on the application and not the network software. These
sounded great in principle but is public domain RPC code available
for the Vax (VMS and Unix lines) along with the IBM PC and HP. If yes then
where can I get it? Suns manual says that RPC's have been run on these
machines.

To confuse me further, I understand that HP has a different version of
RPC's then Suns. Does this mean that there are two different
emerging standards? If yes then which is the one that appears to me winning?
Does each competitor also support the others standard?

2. Berkley sockets vs System 5 sockets. Should I deal at the socket level and
which type of sockets should I use? To run a program on a IBM PC from a Sun
which type of sockets do I need on the IBM PC. Do sockets come for free with
the TCP, and if yes then which type of sockets are they, and does a
software developer have access to the TCP library needed to use these sockets?


I appreciate any knowledge or pointers that I can use for helping me fill out
my knowledge so that I can concentrate on the best approach to my problem.
I have obtianed the Unix Network Programming book by Stevens. The book is
excellent in describing the berkley sockets and TLI but I am not sure about
which to use or if they are at all applicable when I have a VMS machine.


Regards
Dave

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 12:32:48 GMT
From:      cjsv@sserve.cc.adfa.oz.au (Christopher JS Vance)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   struct msghdr, passing fds between processes

I note that a BSD struct msghdr (used with sendmsg and recvmsg) allows the
passing of `access rights'.  I seem to remember someone indicating that this
meant open file descriptors, sort of like a call on dup, except to a different
process.

Could someone who knows please point me to some documentation of this feature,
or at least let me know what kinds of stream these can be passed over.  I assume
that the numbers change on the wire and come out as open fds at the other end.

I guess that the stream must probably be a UNIX domain socket or pipe.  Or am
I barking up the wrong tree?

What I'd like to do is start up a process which has access to my login terminal,
have it open a socket-based connection to a server process, and have it pass
access to my login terminal to the server process.

(Subsidiary question - if I can do this, and my server process had no
controlling terminal, does it suddenly inherit one?)

What colour dragons be here?  (i.e., what do I need to be wary of?)

A bit of working code would be a bonus.  If your reference is the BSD book by
Leffler et al., I can borrow a copy, but won't bother unless it helps.  I had
a copy of the Advanced IPC document, but I don't seem to remember seeing it
there, and the person who has my copy hasn't returned it.  I can get it back,
though, if it's worth it.

-- 
Christopher

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 15:03:19 GMT
From:      mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams)
To:        comp.protocols.tcp-ip
Subject:   Re:  convert Ethernet numbers into ASCII text

David Doll writes:

>Hello,
>	I'm going to be bringing a network analyzer (sniffer) into our 
>department and it displays the Ethernet number (for example: 8:0:2b:18:96:bf).
>I would prefer to look at the host name (for example: foo.cs.washington.edu).
>So what I  would like to be able to do is to get the names from all the 
>machine numbers in the department (~100 or so). Has anybody did this or know
>how or know what to do...? I'd appreciate any help. Thanks. If you e-mail
>me, I could post a summary if theres interest.

I don't think the straight conversion implied by your subject is possible.
To associate names with ethernet addresses in your Sniffer, you'll need to
use the name management tools to enter names for the addresses the Sniffer
finds on your network.  I don't know of a utility to do this for you.
In any event, the information has to exist somewhere before you can use it.

BTW, the Sniffer's name field is not real long -- 14 characters or so,
as I remember off-hand.  If you do have a list of hosts and ethernet addresses
somewhere, you'll have to make sure you can fit the whole name in the Sniffer's
name field.

Finally, deciding on the most useful naming convention for the Sniffer can
be a real challenge.  If your location is big and has multiple segments,
a good name can really help you locate a problem, while a bad name may not
help much.  However, if you incorporate potentially variable information
in the name, maintaining the name list can be a troublesome job.

Mark

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 17:07:19 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey

> The Ethernet spec was apparently written by someone who either was not
> a mechanical engineer, or did not have any experience with automated
> manufaturing.  The reputation of the slide lock will probably never
> recover from that oversight.

Yup.  I know the guy.  At the Ethernet 10 year reunion last fall, he asked
what the designers would do differently.  He (an electrical engineer)
perpetrated the slide lock.  He regrets it, and he wouldn't do it again.
For what it's worth, the idea of the slide lock comes from the late 70s,
when automated manufacturing techniques were probably a bit different.

	Bob

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 17:14:23 GMT
From:      benh@mom.corp.sgi.com (Ben Horowitz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Tunneled through X.25

Do any of you have experience tunneling ip through an X.25 leased-line?
I would be very interested in any empirical information regarding, 
performance, reliability and administrative costs of this configuration. 

Thanks,

Ben  

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 17:25:35 GMT
From:      eek@bcsaic.UUCP (Edwin King)
To:        comp.protocols.tcp-ip
Subject:   NetBIOS Name Server on a UNIX platform?

Does anyone know of a NetBIOS Name Server that will run on a
UNIX platform?  The NetBIOS Name Server would have to act as an DNS 
agent requesting name service from exiting DNS servers.

Thanks,

Ed King

Internet		 eek@atc.boeing.com

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 18:28:50 GMT
From:      jfv@cbnewsk.att.com (j.f.van valkenburg)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: How to change the login message of telnetd?

In article <1991Apr19.143745.14498@mintaka.lcs.mit.edu>, splee@gnu.ai.mit.edu (Seng-Poh Lee, Speedy) writes:
> Hi,
> 
> Does anyone out there know how to change the default login message of
> telnetd? For example, on my machine, when you telnet to it, it gives
> 
> HP-UX hostname 5.5 B 9000/330
> 
> login:
> 
> I want to be able to add an additional message to this login message. Is
> there any way of doing this without having a customized version of /bin/login
> or /etc/telnetd?
> 
> --
> Seng-Poh Lee
> splee@gnu.ai.mit.edu

The /etc/gettydefs has the login message 

Thanks,


------------------------
James F. Van Valkenburg         a.k.a.  "van"
AT&T 				Attmail: !jfv               jfv@cbnewsk.att.com
Atlanta, GA.			Voice  404-873-7920
===============================================================================

   ---- Standard Disclaimers included -- Just another grunt at AT&T ----

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

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 20:09:40 GMT
From:      markb@unix386.Convergent.COM (Mark Beyer)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

hotz@isi.edu (Steve Hotz) writes:

>In article <NELSON.91Apr18230637@sun.clarkson.edu>
>nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes:
 
>>> Per the quoted message, I'd have to say "No, the Domain Name
>>> System (DNS) is not working".
	:
	:
>           for the most part DNS problems are due to misconfigurations
>by administrators.

Personally, I think the DNS administrative interface was designed by the IRS.
It has to rank right up there with root canal work as one of the most fun 
things to contemplate.

But you're right, it's probably the administrators' fault(s).

( :-) ).
-- 
Mark Beyer
markb@convergent.com
{uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 20:34:04 GMT
From:      tengi@princeton.edu (Christopher Tengi)
To:        comp.protocols.tcp-ip
Subject:   Query: Standards work on IP over ISDN


We at Princeton are about to embark on some IP-over-ISDN
experimentation, and would like to know if there is any work being
done on standardizing what goes over the ISDN pipe.  We would also be
interested in hearing about what others are doing out there.  Our
eventual goal is to have a PRI line or 2 run into our computer center
and BRI lines to staff and faculty homes.  For now, we will be
experimenting with a couple of BRI lines and 2 IBM-PC/XT machines,
probably running ka9q.

					Thanks,
						/Chris

==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Apr 91 21:28:46 GMT
From:      splee@wookumz.gnu.ai.mit.edu (Seng-Poh Lee, Speedy)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: How to change the login message of telnetd? (Summary)

Thanks to all of those who responded suggesting the gettydefs or gettytabs
file, but that only does it for a serial login.  It doesn't work for a telnet
login.

The solution turns out to be replacing the telnetd entry in inetd.conf with
a script file which first puts out the message and then execs telnetd. This
works, I tried it.
--
Seng-Poh Lee
splee@gnu.ai.mit.edu

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 22:01:42 GMT
From:      mark@badger.dosli.govt.nz (Mark Wright)
To:        comp.protocols.tcp-ip
Subject:   telnet precedence over ftp?

We have several ethernets that will shortly be linked using intelligent
bridges and 9600 baud digital lines. The primary purpose of this is to allow
PCs to act as terminals (using telnet) over the link. We would like to have
the use of ftp available, but don't want it to interfere with the response of
the telnet sessions.

What means (short of disabling ftp during working hours and implementing some
sort of batching mechanism) are available to me? It WOULD be nice to have ftp
always available, but only sending packets when the line is free (e.g. with
low priority packets), although I guess this is nigh on impossible with
bridging instead of routing.

Any/all suggestions gratefully received - please mail me and I will summarise.
-- 

 Mark Wright.                    Dept. of Survey and Land Information,NZ.
 email: mark@dosli.govt.nz       phone: 64 4 710-380 ext 8688

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      22 Apr 91 23:43:12 GMT
From:      jik@athena.mit.edu (Jonathan I. Kamens)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Re: struct msghdr, passing fds between processes


  (Note Followup-To.  This isn't really related to the TCP/IP protocol.)

In article <1991Apr22.123248.8250@sserve.cc.adfa.oz.au>, cjsv@sserve.cc.adfa.oz.au (Christopher JS Vance) writes:
|> I note that a BSD struct msghdr (used with sendmsg and recvmsg) allows the
|> passing of `access rights'.  I seem to remember someone indicating that this
|> meant open file descriptors, sort of like a call on dup, except to a different
|> process.

  Yes.

|> Could someone who knows please point me to some documentation of this feature,
|> or at least let me know what kinds of stream these can be passed over.  I assume
|> that the numbers change on the wire and come out as open fds at the other end.

  The only documentation about it that I know of is the recvmsg(2) man page
(or, at least, that's the only place I've seen it mentioned; it may be
mentioned in other man pages as well).  According to that man page, fd's can
only be passed over sockets (although I suspect that it'll work with pipes
too, since pipes are implemented on top of sockets).  The way you pass a
descriptor is by assigning the address of an int containing the descriptor
number to the msg_accrights member of the msghdr structure and sizeof(int) to
the msg_accrightslen member of the structure, and then sending a message over
a socket to another process using sendmsg().  The other process receives the
mssage using recvmsg(), and the integer found in the msg_accrights member will
be the number of the open file descriptor that was passed (as you point out,
it may be a different number than what it was at the originating end).

  I'm not sure what happens if you send a descriptor from a process to itself;
I suspect it's just like a dup().

  Here's a really simple program, with absolutely no error checking, that
demonstrates how this works.  It works for me, but I make no guarantees :-).

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/file.h>
#include <stdio.h>

main()
{
     int pair[2];
     struct msghdr msg;
     int fd;
     char buf[BUFSIZ];
     int c;
     
     socketpair(AF_UNIX, SOCK_STREAM, 0, pair);

     msg.msg_name = 0;
     msg.msg_namelen = 0;
     msg.msg_iov = 0;
     msg.msg_iovlen = 0;
     msg.msg_accrights = (char *) &fd;
     msg.msg_accrightslen = sizeof(fd);
     
     if (fork()) {
	  /* Parent */
	  close(pair[1]);
	  fd = open("/etc/passwd", O_RDONLY, 0);
	  sendmsg(pair[0], &msg, 0);
     }
     else {
	  /* Child */
	  close(pair[0]);
	  recvmsg(pair[1], &msg, 0);
	  while ((c = read(fd, buf, sizeof(buf))) > 0)
	       write(1, buf, c);
     }
}
 
-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 00:11:51 GMT
From:      glenn@grenada.ign.island.COM (Glenn Harden)
To:        comp.protocols.tcp-ip
Subject:   SLIP, MTI and flow control

We're running SLIP 4.0 under SunOS 4.0.3 and using (on each end of a leased
line) a UDS modem (DDS/MR) and mux (SM-8A) connected to a 3/280 through a
Systech MTI 1600.   It's working, but, echoing of characters when logged on
to the remote machine is rather sporatic which is, one suspects, due to the
absence of flow control between the mux and the MTI board.  (Software flow
control is disabled since XON/XOFF can't be sent in IP encapsulated data -
correct me if I'm wrong here.)

Any help greatly appreciated.

--
Glenn Harden                              |     Island Graphics Corporation
glenn@island.COM                          |     149 Stony Circle
{sun,moon,uunet}island!glenn              |     Santa Rosa, CA  95403

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 00:17:27 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

In article <9104191503.AA25029@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
> I once believed, without evidence, that slide-lock connectors were the
> largest single source of [LAN] network downtime.

	And something happend to change your mind?  I am firmly convinced
that not only are they the largest single source of network problems, but
they are larger than all other sources combined.

> Does anyone have experience replacing Ethernet slide-lock connectors
> with screw connectors?  (Is there a reasonably easy way to do this?)

	We do it all the time.  If you take apart the end of a cable and/or
a board-mounted connector, you will usually find that the slide-lock
mechanism can be removed fairly easily by undoing a few small (4-40?)
screws and/or nuts.  This leaves you with mounting holes on the cable and
board connector that align.  Just insert plain old RS-232-style mounting
screws that you can get from Inmac, or anyplace else, and suddenly you've
got a connector that you can count on not to fall out.  It won't meet
official 802.3 standards, but the standards people know what they can do
with themselves (I'm usually a pretty rabid pro-standards kind of guy, but
when the standard is so obviously brain dead, I gotta be a little
practical, you know?)

	I'm certainly no fan of U/B, as I think I've ocassionaly made clear
on the net, but one thing they did right (in my mind) was to violate the
standard and put screw-mount connectors on their gear.

	I once heard a horror story (probably on the net but I've long
since forgotten when and who told it) about a tranciever cable that came
partially detached.  The power and transmit pins made contact, but the
receive circuit was broken; the damn thing could talk, but couldn't hear.
Apparantly it did very bizarre things to the network.

--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 02:21:59 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        comp.protocols.tcp-ip
Subject:   Accessing a DOS disk from unix over ethernet


Is it possible to transfer files to and from a PC from the unix side?
We have PC-NFS but this only allows transfers to be made from the PC side.

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

If anybody can point to a solution (hints, public-domain or commercial 
software) it would be appreciated.
--
Dr. Roberto Togneri                         Phone: +61-9-380-2535
Dept. of Electrical & Electronic Engineering
The University of Western Australia         Fax:   +61-9-380-1065
NEDLANDS WA 6009 Australia                  Email: robert@swanee.ee.uwa.oz.au

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 02:35:39 GMT
From:      wisner@ims.alaska.edu (Bill Wisner)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   Re: How to change the login message of telnetd? (Summary)

If you want to change your telnet banner, get the latest version of telnet
from ucbvax.berkeley.edu (pub/telnet.91.03.25.tar.Z), modify the banner
at the end of telnetd/ext.h, and install it.

Even if you don't want to change your telnet banner, get the latest version
of telnet from ucbvax.berkeley.edu (pub/telnet.91.03.25.tar.Z) and install it.

Bill Wisner <wisner@ims.alaska.edu> Gryphon Gang Fairbanks AK 99775
"Syzygy, inexorable, pancreatic, phantasmagoria--anyone who
can use those four words in one sentence will never have to
do manual labor." -- W. P. Kinsella

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Apr 1991 06:07:17 GMT
From:      stealth@engin.umich.edu (Mike Pelletier)
To:        comp.protocols.tcp-ip
Subject:   Multi-port transcievers -- any advantage?

I currently have two machines heating my cubicle, and I currently
have each of them hooked to an individual thinnet transciever.
However, I have the option of hooking them to a dual-port transciever,
and I'm wondering if there's any advantage to doing so besides freeing
up one of the single-port transcievers?
Thanks for any information...
-- 
Mike Pelletier             | "Wind & waves are breakdowns in the commitment of
The University of Michigan |  getting from here to there, but they are the con-
  College of Engineering   |  ditions for sailing.  Not something to eliminate,
Student/Systems Admin      |  but something to dance with."

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 14:01:17 GMT
From:      pcl@robots.ox.ac.uk (Paul Leyland)
To:        comp.os.vms,comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,comp.sys.dec
Subject:   VMS lpd (Line Printer Daemon) wanted.


We have a VAX cluster, with a number of printers attached.  We also
have a few Suns, a DECsysttem 5500 and a Convex C120.  The cluster
runs VMS 5.4 and the other machines run various flavours of Unix.  we
are in the process of installing VAX-Ultrix Connection software on the
cluster.

The problem to be solved is enabling the Unix machines easily to send
files to be printed on the VMS peripherals.  Much the cleanest
solution would be to run the "lpd" daemon on the cluster.  We have
source for the Unix version of lpd, but porting it to VMS looks like a
major task.

Does anyone know of an implementation of lpd under VAX/VMS?  Source
code would be especially nice.

Please mail me, and I'll summarize responses to the net.

Thanks in advance,
	Paul Leyland (pcl@convex.oxford.ac.uk by preference)

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 15:45:46 GMT
From:      tkevans@oss670.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: convert Ethernet numbers into ASCII text

davidd@HITL.VRNET.WASHINGTON.EDU (David Doll) writes:


>	I'm going to be bringing a network analyzer (sniffer) into our 
>department and it displays the Ethernet number (for example: 8:0:2b:18:96:bf).
>I would prefer to look at the host name (for example: foo.cs.washington.edu).
>So what I  would like to be able to do is to get the names from all the 
>machine numbers in the department (~100 or so). Has anybody did this or know
>how or know what to do...?

My sniffer (a Tektronix) allows a disk file to be set up on it which
contains hardware-to-hostname mappings.  Once you go through the
exercise of gathering this info, save it!  I'd think other sniffers
would allow this same capability.

-- 
INTERNET	tkevans%woodb@mimsy.umd.edu
UUCP 		...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
US MAIL		6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD  21235	
PHONE		(301) 965-3286

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 16:01:03 GMT
From:      splee@gnu.ai.mit.edu (Seng-Poh Lee, Speedy)
To:        comp.sys.hp,comp.unix.questions,comp.protocols.tcp-ip
Subject:   Anyone has Network manuals for HP9000/3XX running HP-UX 5.5?

The reason I need this is because I cannot get more than one ftp process
out of my machine, a hp9000/330. I have an old version of HP-UX (5.5), can't
afford an upgrade. I inherited this machine and don't have all the manuals,
including the all important network services manual. I need to know how
to configure the network to allow more buffer space (? or whatever) to 
allow more telnets and ftp accesses. Basically, if someone is telnetting
or ftping out from the machine, nobody else can do an ftp, either in or out.
It allows the ftp login, but after that, you can't even do a dir or anything.
It just says File Transfer started, but it justs locks up. I can do about
2 telnets before it starts saying 'out of buffer space' or something.

If anyone has a manual, and can help me out, I'd be grateful. TIA


--
Seng-Poh Lee
splee@gnu.ai.mit.edu

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 16:06:57 GMT
From:      owens@acsu.buffalo.edu (bill owens)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

In article <1991Apr23.001727.26953@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes:
>In article <9104191503.AA25029@uh.msc.umn.edu> tjs@MSC.EDU (Tim Salo) writes:
>> I once believed, without evidence, that slide-lock connectors were the
>> largest single source of [LAN] network downtime.

They're certainly the biggest cause of sudden network failures, anytime
someone has to do anything inside a crowded rack cabinet they're liable
to wipe out whole buildings. They're the only component that, once it
works, is likely to fail 'spontaneously'. Coax, taps, etc. may not work
immediately, but once they're set they seldom give you any more
trouble...

I have had some luck 'tuning' the slide-locks by bending them with pliers
or a screwdriver, but that's obviously not practical for the hundreds we
have in use. Unfortunately, replacing them with screws is also considered
impracitcal for the same reason.

>	I once heard a horror story (probably on the net but I've long
>since forgotten when and who told it) about a tranciever cable that came
>partially detached.  The power and transmit pins made contact, but the
>receive circuit was broken; the damn thing could talk, but couldn't hear.
>Apparantly it did very bizarre things to the network.

That just happened to me two weeks ago; someone moved a small EOT to
see its lights, and partially disconnected the cable; the power and
receive pins were still in contact, but not transmit. So it could hear,
but couldn't talk; my traffic was getting there, but his wasn't coming
back. About two hours to find the problem...

Bill.

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 16:45:12 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey

In article <5634@eastapps.East.Sun.COM> ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston) writes:
>... The spec (see drawing on page 94, just
>above section 7.6.2) says that the connector should go on the _outside_
>of the backpanel.  But in order for printed circuit boards to be
>stuffed and soldered by automatic machinery then married to the system
>later, the connector is often mounted on the _inside_ of the
>backpanel.  Result -- the connector wobbles and makes poor electrical
>connection...

There is absolutely no problem with having the connector on the inside
of the panel provided the slide lock is mounted there too.  Manufacturers
have been known to get this right.  Of course, it's harder, and we all
know that most manufacturers would rather do things the easy way than
the right way.  Especially a certain workstation vendor whose name starts
with S...

The *intentions* of the slide-lock advocates were good.  All too often,
screw-equipped connectors aren't screwed in because the relevant screwdriver
is not handy.  A poor locking system which gets used is better than a good
one that doesn't.  Unfortunately, they didn't realize that (a) transceiver
cables are sufficiently heavier than rs232 cables that use of locking is
effectively mandatory anyway, and (b) the slide locks are flimsy and easily
damaged.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 16:57:29 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

In article <7335@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes:
>Personally, I think the DNS administrative interface was designed by the IRS.
>It has to rank right up there with root canal work as one of the most fun 
>things to contemplate.

This may be a little off topic, but isn't sendmail's configuration
files even harder to comptemplate, let alone complete :-)

Warner
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 17:19:31 GMT
From:      rajiv@ultra.com (Rajiv Dhingra)
To:        comp.protocols.tcp-ip
Subject:   SUN TCP delayed acks



I have a question regarding acks sent out by SUNs implementation
of TCP/IP.  
 
If SUNs TCP receives a data packet of 1024 bytes followed 
by a second data packet of 410 bytes, it sends an ACK packet
acknowledging the 1434 bytes immediately.
 
However, if it receives a data packet of 1024 bytes followed
by a second data packet of 409 bytes, it delays sending
an ACK packet for 200 milli-seconds.
 
The window that it advertises in both cases is 4096 bytes.
 
Under what cases does it decide to delay sending out
an ACK packet?
 
Thanx in advance for replies.
 
Rajiv Dhingra
  Ultra Network Technologies     domain: rajiv@Ultra.COM
  101 Daggett Drive            Internet: ultra!rajiv@Ames.ARC.NASA.GOV
  San Jose, CA 95134               uucp: ...!ames!ultra!rajiv
  408-922-0100
 
 

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 17:25:33 GMT
From:      jstahlhu@athena.mit.edu (Julie Kozaczka Stahlhut)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

Speaking of slide lock connectors, does anyone know of a source for those
little screw adapters for them?  Some vendors supply them with LAN cards, but I just need a bag 'o adapters and matching screws.

We have the fiber and 10 Base T network of the future, held together with those
miserable 15-pin connectors of the past.  In the tradition of educational
institutions with lots of equipment but no space, our computer room here at
Harvard Medical School is impossibly cramped.  Five minutes of work on any
connection behind our rack is likely to dislodge two or three subnets from
their connections into our two routers.  I've also had only a minimum of luck
with electrical tape, abusing the latches with screwdrivers, ad nauseam.
Not that the little stamped-metal-and-screw jobbers work that well, but they're
the best of a bad lot as far as I can tell.

Who invented those slide latches, anyway?  I'd like to meet this person,
maybe shake his or her throat ..... :-(

--
Julie Kozaczka Stahlhut
"I'm not especially responsible but it's not my employer's fault."

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 17:28:21 GMT
From:      stacy@sobeco.com (s.millions)
To:        comp.protocols.tcp-ip
Subject:   Re: Sniffer

In <9104121347.AA21041@cabell.vcu.edu> bmiller@CABELL.VCU.EDU writes:

>We are looking at the possibility of purchasing a Sniffer....anyone
>out there have any experience with it?

Yes, I do. If you need to analyze the protocol stacks, the sniffer is
great. It is, however, a terrible cable tester. At the time I ordered
it, I needed a protocol analyzer, and I have not regretted getting
the sniffer. I understand that there is now some serious competion
among the protocol analyzers, and that it may be worth your while
to look around.

-stacy

-- 
>Doesn't Sun talk about being standards based?                 stacy@sobeco.com
>Novell is THE standard in PC networks.                         stacy@sobeco.ca
Show us the RFC :-)   - aronb@gkcl.ists.ca (Aron Burns)      uunet!sobeco!stacy

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 17:53:57 GMT
From:      pace@tabarzin.usace.mil (Joe Pace)
To:        comp.protocols.tcp-ip
Subject:   Time servers


Would anyone know of machines on the Internet that support the
DARPA Time Server Protocol (timed; port 37) and syncronize their
clocks off an atomic clock or some other accurate source?

Thanks

Joe
-- 
Joe Pace
US Army Corps of Engineers                                     pace@usace.mil
Sacramento District                                     JPPACE@UCDAVIS.BITNET
650 Capitol Mall, Sacramento, CA  95814         (916) 551-1133, FAX: 551-1100

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 19:11:38 GMT
From:      rgirard@ncs.dnd.ca (Roger Girard)
To:        comp.protocols.tcp-ip
Subject:   Looking for tcp/ip network simulator

I understand there is a PD network simulator software package called
XSIM which can simulate a tcp/ip network. I would like to know how it
can be obtained and any information on how it can be ported to a 386
PC.

I am also interested in any other network simulator in the public domain.

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 19:16:19 GMT
From:      ftpam1@acad3.alaska.edu (MUNTS PHILLIP A)
To:        comp.lang.pascal,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   TCP/IP for Turbo Pascal?

Has anybody heard of a TCP/IP library for Turbo Pascal?

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks 

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 20:06:39 GMT
From:      xeee02@mixcom.COM (Dean A. Roth)
To:        comp.protocols.tcp-ip
Subject:   Sockets made easy - where do I get this software?


Once upon a time in the last two years a software
library was distributed via Usenet that put an
"easier to use" layer over sockets. (The software
hid all socket interface code from the application.)

Where can I get a copy - via email or UUCP?
(No Internet access.)  Thank you.
-- 
Dean Roth           deanr@mixcom.com

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 21:19:46 GMT
From:      lance@motcsd.csd.mot.com (lance.norskog)
To:        comp.protocols.tcp-ip
Subject:   Configuration File Hell

>>Personally, I think the DNS administrative interface was designed by the IRS.
>>It has to rank right up there with root canal work as one of the most fun 
>>things to contemplate.
 
>This may be a little off topic, but isn't sendmail's configuration
>files even harder to comptemplate, let alone complete :-)

Every designer of network software makes the same mistake: they design
the configuration files using the relative rather than absolute model.
The absolute model uses one configuration file for an entire site;
each machine uses it as a map and says to itself, "I am here, so I
will go this direction".  The relative model uses a different config
file for each machine which says, "go this direction".

It is horrifying to see this one occur over and over.  It ties in
with the general problem that people who are capable of implementing
software are put in charge of architecting said software; they run off 
and skillfully design, debug, and maintain a mess.

Lance

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Apr 91 21:58:15 GMT
From:      stevew@helios.unl.edu (Steven Wu)
To:        comp.protocols.tcp-ip
Subject:   SLIP dialing problem.


  I am trying to set up the communication between a Sun 3 and a Sparc
2 through CSLIP, and both machines are running SunOS 4.1.1. I
reconfigure the kernal and run the slattach on both machine without
problem (I think). Since I need a dialing program, I compile tip which
comes with SLIP-4.0 and find the tip doesn't working.

  The following messages are what I get when I run tip:
	/dev/ttya file does not exsit
	all ports busy

  or sometime, they are:

	lock file ...
	all ports busy.

  Can anyone give me any suggestion?

  Thanks for your help.

  steve
--
stevew@helios.unl.edu  |=| \ Fender / |=| ... smoke on the water, fire 
 		       |=|   \    /   |=| in the sky smoke on the water.
stevew@hoss.unl.edu    |=|     \/     |=|(36 bars guitar solo)
			Deep purple the best

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 00:09:33 GMT
From:      bambi@kirk.nmg.bu.oz.au (David J. Hughes)
To:        comp.lang.pascal,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP/IP for Turbo Pascal?

From article <1991Apr23.191619.1230@ims.alaska.edu>, by ftpam1@acad3.alaska.edu (MUNTS PHILLIP A):
> Has anybody heard of a TCP/IP library for Turbo Pascal?

A group of people here at Bond Uni developed a Turbo Pascal interface
for FTP Inc's PC/TCP.

For more information please contact Miles Gillham at 
mhg@lance.hss.bu.oz.au.


bambi
+----------------------------------------------------------------------------+
| David J. Hughes   (AKA bambi)	 |   bambi@kirk.bu.oz.au                     |
| Senior Systems Programmer	 |   bambi@kirk.bu.oz.au@uunet.uu.net        |
| Comms Development & Operations |   ..!uunet!munnari!kirk.bu.oz.au!bambi    |
| Bond University, Gold Coast    |   Phone : +61 75 951450                   |
| Queensland,  Australia  4229   |   Fax :   +61 75 951456                   |
+----------------------------------------------------------------------------+

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 02:02:24 GMT
From:      JCHAPMAN@MATHOM.CISCO.COM (John T Chapman)
To:        comp.protocols.tcp-ip
Subject:   HSSI Revision Level



The current Revision Level of the HSSI specification is 
March 16, 1990, Revision 2.11, with a 1 page Addendum Issue #1
added on January 23, 1991.

These are included together in the file HSSI.NOT available
via anonymous ftp at ftp.cisco.com

John T. Chapman
-------

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 02:04:33 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.protocols.tcp-ip
Subject:   Re: servers using SUNS rpc protocol

In <7334@bgsuvax.bgsu.edu> majumdar@bgsuvax.UUCP (anindo Majumdar) writes:

>Are the servers created using SUN's rpcgen mechanism capable of supporting
>multiple clients? If so how many can they support at one time and do they
>have to fork another process for each new client?Is there any way wherby
>these servers can have multiple threads of control thus enabling them to supportmultiple clients without the overhead of context switches,new child processes ?
>Any pointers will be greatly appreciated.  

You can do anything you want, as long as you mind the tradeoffs.  RPC
programs are collections of 'remote procedures' that can be accessed by
local or remote processes without much regard to where the server
lives.  RPC does not itself provide concurrency or lightweight process
contexts.  If you wish to use a threads package inside the dispatch
routine, you can probably go ahead and do that.  Normally. you code
what you need.  If a procedure is doing something that can be turned
around very quickly, your server can simply allow clients to wait until
it gets to them.  If the procedure is more time-consuming, it may be
better to fork a new process to handle an individual transaction.  The
best place to start is Sun's RPC/XDR Programmer's Reference; the examples
are good, and will give you an idea of how the programs are structured.

Rob T
--
Rob Thurlow, thurlow@convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 03:59:29 GMT
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?dir

In article <7335@unix386.Convergent.COM>, markb@unix386.Convergent.COM (Mark Beyer) writes:
> Personally, I think the DNS administrative interface was designed by the IRS.
> It has to rank right up there with root canal work as one of the most fun 
> things to contemplate.
> 
> But you're right, it's probably the administrators' fault(s).
> 
> ( :-) ).
> -- 
> Mark Beyer
> markb@convergent.com
> {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb

Hmmm...  DNS was tough, but I have run into lost worst since.  SNMP, the
sendmail.cf file, and others make DNS seem like a pleasant dream.  They too all
made sense after falling into an approximation of the mindset of a
stereotypical Berkeley grad student.  Even using UNIX has become enjoyable. :-)

Seriously, a document describing how named really works, with a how and why it
should be set up to work on the Internet.  I got lots of good advice on setting
up named from my secondary sites.  I had not heard about setting the TTL value
low on sites whos addresses are about to change.  I have had few problems using
named on a UNIX system, however the mostly VMS site down the road has had many
problems with two unstable DSN implimentations.  Because of the unstable DNS
servers any site wanting to talk to the site down the road also have problems. 
DNS has its flaws, but you won't catch me going back to host tables any time
soon.

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 14:02:56 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Let's create comp.protocols.netmanagement

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

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 14:10:09 GMT
From:      evan@IS.RICE.EDU (Evan R. Wetstone)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

Warner Losh writes:
> 
> In article <7335@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes:
> >Personally, I think the DNS administrative interface was designed by the IRS.
> >It has to rank right up there with root canal work as one of the most fun 
> >things to contemplate.
> 
> This may be a little off topic, but isn't sendmail's configuration
> files even harder to comptemplate, let alone complete :-)

I suppose DNS could be 1040EZ, but then sendmail.cf would be Form 1040
with schedules A,B,C,D,E, and supplemental worksheets.  You know, I
believe I would rather write a sendmail.cf file from scratch then have
to figure out my taxes......;-)


-- 
Evan Wetstone
Network Support
Rice University/SesquiNet

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 14:11:00 GMT
From:      zentelis%sdav01.decnet@WIN1.IMS.ABB.COM ("SDAV01::ZENTELIS")
To:        comp.protocols.tcp-ip
Subject:   Lokking for course UNIX - TCP/IP.

Hi

I'm going to be in Santa Barbara during July 1991.
I'm looking for a course one or two weeks on UNIX
or TCP/IP networking or similar.

Thanks in advance.

======================================================================
Nicolas Zentelis  **                         Voice:    (+46) 21-323537
Asea Brown Boveri **                           FAX:    (+46) 21-127635
ABB Data AB       **                      ABB MEMO:     SEDAT.DATNIZE
S-721 80 Vasteras **                  ABB VMS/Mail:   SDAV01::ZENTELIS
SWEDEN            ** Internet: zentelis%sdav01.decnet@win1.ims.abb.com
======================================================================

   

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 14:31:13 GMT
From:      djl@MSC.EDU (Dennis Longar)
To:        comp.protocols.tcp-ip
Subject:   yet more slide locks.

->Speaking of slide lock connectors, does anyone know of a source for those
->little screw adapters for them?  Some vendors supply them with LAN cards,
-> but I just need a bag 'o adapters and matching screws.

You can probably get them from the same place that you buy your cables.
Suppliers of Bulk cable and connectors usually sell them.  It's turns out 
it's almost harder to find a name for them than ordering them!!  :)  You'll
probably end up calling them cable connector screw thing-a-ma-jigs...   ;)

I would suggest just sticking out the slide locks, and going around and doing
periodic checks of all easily accessed slide lock connections.  Here at MSC
we ended up buying a bunch of screws, but found that in most hardware is was
not a trivial task to replace the slide locks.  The Cables are easily fixed,
but the DTE's and DCE's gets a little harder.  Then the worst part comes....
You have a few screw locks and a few slide locks, then anytime you need a
cable, you grab the wrong kind and can't get any connectivity...

->Who invented those slide latches, anyway?  I'd like to meet this person,
->maybe shake his or her throat ..... :-(

I'm sure it was a Network Manager who felt he needed more job security.
          lots of  :-) here!!!


-- 
Dennis Longar (Network Manager)        		EMail:  djl@msc.edu
Minnesota Supercomputer Center			Phone:  (612) 625-8509
Minneapolis, MN                        		FAX:    (612) 624-6550

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 15:53:28 GMT
From:      tkevans@oss670.UUCP (Tim Evans)
To:        comp.unix.xenix.sco,comp.protocols.tcp-ip
Subject:   SCO's TCP/IP:  "out of streams resources"

We're running SCO Xenix 2.3.2 with SCO TCP/IP and have been getting
error messages "out of streams resources".  These generally come
when a series of rcp's are executed in a short time--i.e., a 
backup via the network.

Can anyone suggest a workaround, or a fix that might be available?

Thanks.  Please use the address *BELOW* for E-mail replies.
-- 
INTERNET	tkevans%woodb@mimsy.umd.edu
UUCP 		...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
US MAIL		6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD  21235	
PHONE		(301) 965-3286

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 16:35:06 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

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

   If you capture the addresses of the originating sites to the old
   machine, it would be interesting to see a breakdown of what operating
   systems were involved.  Dollars to donuts quite a few are running KA9Q
   net.exe. 

I'll take you up on that bet.  I studied a more-or-less random sample
of machines over a day and a half[1].  I telnetted to the machine, and
captured the output.  Of the machines listed below, only 6 could
*possibly* be KA9Q, and none are *definitely* KA9Q.

    [1] For the statistically-minded, I took the first 40 machines
    that tried to FTP to the old machine on Monday and Tuesday (4/22
    and 4/23).  I discarded duplicate attempts.  All results are included,
    even failures to connect.  This would *seem* to be random, but then
    again, statistics are full of surprising correlations.

I'll take a dozen please (plain donuts will be fine):

	Russell Nelson
	11 Grant St.
	Potsdam, NY 13676

The machine identifications are (and some of them are *really* weird):

                              Node MV218
                    Curtin Computing Centre VAX7 - VMS 5.3
                    VAX 8650 VMS System
4.3 BSD UNIX (olivej)
4.3 BSD UNIX (sdcsvax.ucsd.edu) (ttyp1)
4.3 BSD UNIX (tbd2.brl.mil)
Bull DPX (riri)
Connection closed by foreign host.
DYNIX(R) V3.0.17.9  (hydra.gatech.edu)
Domain/OS sr10 (sys2)
Enter validation for service access.
NeXT Mach (calvin) (ttyp0)
PRIMENET 21.0.4m APOLLO
SunOS UNIX (att)
SunOS UNIX (bill.UCSC.EDU)
SunOS UNIX (cec2)
SunOS UNIX (dip.eecs.umich.edu)
SunOS UNIX (engr)
SunOS UNIX (gilmer)
SunOS UNIX (gumbo)
SunOS UNIX (homer)
SunOS UNIX (kiss)
SunOS UNIX (mesunw54)
SunOS UNIX (splinter)
SunOS UNIX (sun.nsfnet-relay.ac.uk)
SunOS UNIX (sunee)
System V.3.1 / UTS 2.0 (tamuts)
ULTRIX V4.0 (Rev. 179) (neptune)
ULTRIX-32 (lepus)
UNISYS 5000 Series         - This login banner resides in /etc/issue
USC Student Computing Facility -- SunOS Unix (aludra.usc.edu) (ttypc)
VAX/VMS V5.2 on RUGR86 (VAX 8650 at RuG)
VIRTUAL MACHINE/SYSTEM PRODUCT                     
login:
telnet: connect: Connection timed out
telnet: connect: Connection timed out
telnet: connect: Host is unreachable
telnet: connect: Host is unreachable
telnet: connect: Host is unreachable
telnet: connect: Network is unreachable
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 16:51:23 GMT
From:      bstrong@sleepy.bmd.trw.com
To:        comp.protocols.tcp-ip
Subject:   File size limitation


This is undoubtedly a very basic question - When I ftp to a 386 host running
SVR3.2 from any host (PC, Sun Workstation, VAX) I seem to have a 1.5MB file
limit where transfers just stop at this number; is this a ulimit limitation
on the 386 hosts end?  Thanks for any replies.

-----------------------------------------
Bryan Strong     TRW * Ogden, UT
                 bstrong@oz.bmd.trw.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 16:54:25 GMT
From:      imp@Solbourne.COM (Warner Losh)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement


comp.protocols.snmp.

Maybe even gateway the snmp list to it, or create
comp.protocols.snmp.tech?

Just some random thoughts from the keyboard of

Warner Losh		imp@Solbourne.com
"Does this mean we can't use your phone?"
-- 
Warner Losh		imp@Solbourne.COM
We sing about Beauty and we sing about Truth at $10,000 a show.

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 17:21:25 GMT
From:      kreis@abbins.ladenburg.abb.de (Oskar Kreis)
To:        comp.protocols.tcp-ip
Subject:   Dialup IP for SCO opendesktop


We have got a release of Dialup IP, with following 

..
.. Introduction
.. 
.. The Dialup IP software package provides full IP support over dialup
.. phone lines.
.. It runs on systems based on the 4.3BSD kernel, and requires a modem
.. connected to a serial port on the machine.
..

Because we use SCO opendesktop (non-BSD Unix) we tried to recode this
Dialup packet, but this seems to be difficult.

Is there a release of Dialup IP for SCO opendesktop ?

-- 
  #   ###  ###  | Oskar Kreis, Abteilung INS/GT, ABB Installationen GmbH
 # #  #  # #  #	| Wallstadter Str. 59, D-W-6802 Ladenburg
#   # ###  ###	| Phone....: +49 6203 71 2646, Fax......: +49 6203 3993
##### #  # #  # | E-Mail...: kreis@abbins.ladenburg.abb.de, kreis@abbins.uucp
#   # ###  ###  | Building automation ---> GA2000 <--- Gebaeudeautomation

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 17:53:59 GMT
From:      mandrews@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Byte and bit order within packet headers


I have a question concerning concering the byte and bit order of fields
within packet headers. Many of the RFCS (including RFC1060) state rules
about the byte (octet) order:

Data Notations

   The convention in the documentation of Internet Protocols is to
   express numbers in decimal and to picture data in "big-endian" order
   [21].  That is, fields are described left to right, with the most
   significant octet on the left and the least significant octet on the
   right.

   The order of transmission of the header and data described in this
   document is resolved to the octet level.  Whenever a diagram shows a
   group of octets, the order of transmission of those octets is the
   normal order in which they are read in English.  For example, in the
   following diagram the octets are transmitted in the order they are
   numbered.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       1       |       2       |       3       |       4       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       5       |       6       |       7       |       8       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       9       |      10       |      11       |      12       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Transmission Order of Bytes


So, all multi-octet fields are transmitted in big-endian byte order.

This is a small problem for little endian machines (most significant byte is
on the right). They must correct their byte order before the packet is
transmitted. In BSD systems, this job is performed by the htonl() and htons()
functions (host to network long, host to network short), but what about the
bit order? It is still little-endian (bits are numbered right to left instead
of left to right)! What order is are the bits transmitted in?

This is further complicated by the following code fragment from
/usr/include/netinet/ip.h:


	struct ip {
	#if BYTE_ORDER == LITTLE_ENDIAN
	        u_char  ip_hl:4,                /* header length */
	 	        ip_v:4;                 /* version */
	#endif
	#if BYTE_ORDER == BIG_ENDIAN
	        u_char  ip_v:4,                 /* version */
	                ip_hl:4;                /* header length */
	#endif
		<etc.>


When all this is translated, there are two views of the first byte of the
ip structure; one little endian:

	7              0
	+------+-------+
	| ip_v | ip_hl |
	+------+-------+

and one big endian:

	0              7
	+------+-------+
	| ip_v | ip_hl |
	+------+-------+

Now according to the 4.3BSD C Reference Manual by B. Kernighan, the addresses
of a structure increase as the declarations are read left to right
(irrelevant of the bit or byte order), so in terms of a C addressing model,
the first byte of the ip structure is:

	0              7
	+------+-------+-----
	| ip_v | ip_hl | other elements of ip structure
	+------+-------+-----

Perhaps the bits are transmitted MSB to LSB based on the C model. I don't
know.


Any clarifications on my confusion or any other help would be appreciated.

Thanks,

Mark

------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
Mail box: mark@alias.com

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 18:03:39 GMT
From:      ez@mentor.gandalf.ca (Eugene Zywicki)
To:        comp.protocols.tcp-ip
Subject:   error detection information requested


	Although my request is not directly related to this group, I
expect that there are readers out there who can help me.

	I am looking for good reference materials/books that discuss
error detection techniques in high speed communications systems.
Specifically I am looking for hardware implementations along with the
kind of error coverage you get.

	For instance, what error coverage do you get from the checksum used
in TCP and IP?

	I am already familiar with CRC-16 and 32, so please save bandwidth
on those two.

	You can e-mail me directly.

				Thanks in advance,
-- 
Eugene E. Zywicki          CAnet: ez@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 18:24:52 GMT
From:      crm413c@bcars19.bnr.ca (Peter Ng)
To:        comp.protocols.tcp-ip
Subject:   SNMP UDP port

Hi,

  We have questions regarding the UDP port number used
in the SNMP message.

  In the RFC 1157 section 4 "Protocol Specification", it
states "A protocol entity receives messages at UDP port
161 on the host ....".

Here are the questions:

(1) Does the statement implies that a Network management
    station must receive SNMP message (other than traps)
    on UDP port 161?
   (1.1) If (1) is yes, then NMS and the agent cannot
         both reside on the hosts (e.g.workstation)?

(2) Is it a protocol violation to receive messages on any
    other UDP ports (other than traps on 162)?

(3) In practice, could we assign any unreserved port to
    the source port of the outgoing get_request message
    (with destination port 161)?  Should we expect to receive
    a get_response on the same port that we assigned to
    the outgoing get_request? In this case is the statement
    quoted from RFC 1157 violated?

Thanks in Advance

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 19:56:57 GMT
From:      shapiro@oucsace.cs.OHIOU.EDU (Brian Shapiro)
To:        comp.protocols.tcp-ip
Subject:   help! problem making IBM RISC-6000 work with AIX/TCP-IP


Help,
 
I am attempting to help one of our researchers here at O.U. get his TCP-IP
software working on his RISC 6000 computer (running AIX). We have been using
the SMIT program to do the configuration. I have set the minimum parameters
such as address, host name, interface, and netmask to values that are
appropriate.
 
Now comes the problem, when I try to ping or otherwise communicate with
another tcpip address I get nothing (ie. ping send packets but receives 
none back). If, however, we attach a PC with an ethernet adapter on the
same segment of the network the Risc 6000 can sucessfully communicate
with this PC and this PC can communicate with the Risc 6000. Also, other
known working tcp-ip devices on other segments of our network can 
communicate with the RISC 6000.
 
A simplified diagram is below:
 


       PC1>----|
               |
               |
RISC 6000>-----|
               |
               \
                \--dempr--lanbridge 150---|
                                          |
                                          |
                                          |---bridge--dempr--PC2
 

So,  RISC 6000 sees PC1
     PC1 sees RISC 6000
     PC1 sees the world (ie. PC2)
     PC2 sees the world (including RISC 6000 and PC1)
 
Needless to say I think this is a simple problem but alas the Docs for
the AIX/TCP-IP are non-existant. If you have gone through this and might
be able to help send me email or call me on the phone or send me email and
i'll call you on the phone.

Any and All help will be greatly appreciated!
 
thanks.....
 
brian

-- 
Brian Shapiro, Assistant Manager, Information Center
Ohio University, Athens, Ohio 45701
(614) 593-1517
shapiro@oucsace.cs.ohiou.edu or SHAPIROB@OUACCVMA.BITNET

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 23:11:16 GMT
From:      sfalken@mondo.engin.umich.edu (Steve Falkenburg)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   New XferIt Mac FTP Client Available

XferIt 1.3, my Macintosh FTP client, has just been released.  For those not
familiar with it, it's FTP with a graphical user interface.

This new version adds scripting capability, along with the ability to
send and retrieve entire directory trees.

XferIt is shareware.  A single-user license is $10, for one AppleTalk
zone is $45, and for an AppleTalk internet site license costs $175.
Details, including a pseudo-license agreement are included in the
archive.

-steve falkenburg
 Cyberite Systems
 sfalken@mondo.engin.umich.edu

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 23:14:16 GMT
From:      sfalken@mondo.engin.umich.edu (Steve Falkenburg)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: New XferIt Mac FTP Client Available

> XferIt 1.3, my Macintosh FTP client, has just been released.  For those not
> familiar with it, it's FTP with a graphical user interface.
> 
> This new version adds scripting capability, along with the ability to
> send and retrieve entire directory trees.
> 
> XferIt is shareware.  A single-user license is $10, for one AppleTalk
> zone is $45, and for an AppleTalk internet site license costs $175.
> Details, including a pseudo-license agreement are included in the
> archive.
> 
> -steve falkenburg
>  Cyberite Systems
>  sfalken@mondo.engin.umich.edu
>

Oh, and XferIt 1.3 is available by anonymous ftp from mondo.engin.umich.edu
(141.212.68.14) and is located in /pub/XferIt.sea.hqx

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      24 Apr 91 23:28:06 GMT
From:      logier@cheops.qld.tne.oz.au (Rob Logie)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey [slide-locks]

jstahlhu@athena.mit.edu (Julie Kozaczka Stahlhut) writes:

>Speaking of slide lock connectors, does anyone know of a source for those
>little screw adapters for them?  Some vendors supply them with LAN cards, but I just need a bag 'o adapters and matching screws.
 
>We have the fiber and 10 Base T network of the future, held together with those
>miserable 15-pin connectors of the past.  In the tradition of educational
>institutions with lots of equipment but no space, our computer room here at
>Harvard Medical School is impossibly cramped.  Five minutes of work on any
>connection behind our rack is likely to dislodge two or three subnets from
>their connections into our two routers.  I've also had only a minimum of luck
>with electrical tape, abusing the latches with screwdrivers, ad nauseam.
>Not that the little stamped-metal-and-screw jobbers work that well, but they're
>the best of a bad lot as far as I can tell.
 
>Who invented those slide latches, anyway?  I'd like to meet this person,
>maybe shake his or her throat ..... :-(
 
>--
>Julie Kozaczka Stahlhut
>"I'm not especially responsible but it's not my employer's fault."


The first thing I do when I get anything using AUI cables with slide locks 
is to remve the slide locks and place them in the rubbish bin where they
belong.
I then replace them with normal old screws (Like on RS232 connections)
They never move when there screwed down.

I think slide locks are someones idea of a sick joke ..


Regards


-- 
Rob Logie                                    EMAIL: logier@cheops.qld.tne.oz.au
Telecom Australia                            FAX:   +61 7 837 4704
TNE Computer Support Services                PH:    +61 7 837 5174
Brisbane Office                              "These are my opinions alone"

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 00:45:26 GMT
From:      lapyun@smosjc.UUCP (Lap Yun Yau)
To:        comp.protocols.tcp-ip
Subject:   Internet Address Assignment

We just registered our Internet address and are now planning for reorganizing
of all networks within the company.

The following scheme shows the relationship of nets and subnets:

        ====+====================+===============         Backbone Network
            |                    |
            |Dept A              |Dept B
        =+==+==+==+=        ==+==+==+==+==o==o===         Departmental Networks
         |  |  |  |           |  |  |  |                        (=o=   node)
         |  |  | =+====       |  |  | =+=====Net B.1      Dept Subnet 1
         |  | =+=====         |  | =+=====Net B.2         Dept Subnet 2
         | =+=====            | =+=====Net B.3            Dept Subnet 3
        =+=====              =+=====Net B.4               Dept Subnet 4

------------------------------------------------------------------------------
We want more than one backbone networks, with each backbone net connect couple
departments while each of these departments may have several subnets.

How should I setup the subnet addresses?  Let's say we have a Class B address,
XX.YY., and we have two bytes (the third and the fourth octects) to play with.

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

Method 1:

Backbones - XX.YY.30, XX.YY.32, ..., XX.YY.38
Dept Nets - XX.YY.40, XX.YY.60, ..., XX.YY.240
Dept Subnets - XX.YY.41, XX.YY.42, ..., XX.YY.49 for dept net XX.YY.40
             - XX.YY.61, XX.YY.62, ..., XX.YY.69 for dept net XX.YY.60
             - ...

Is this setup a true subnetting?  Our concerns are some software like Interleaf
using network license requires license server runs on, say, dept B net and
serves all subnets B.1, B.2, etc.  At present, we have only backbone and dept
nets hook to it and each net has it own class B address.  When Interleaf
license server runs on, say, dept A's net, nodes in other dept's net cannot
run Interleaf.  Does anybody knows if the method 1 setting will work?

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

Method 2:

Let's play with the 3rd and 4th octects.
        3rd octect                              4th octect
+---+---+---+---+---+---+---+---+       +---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |       |   |   |   |   |   |   |   |   |
+---+---+---+---+---+---+---+---+       +---+---+---+---+---+---+---+---+
\      / \             / \                 / \                         /
backbone    dept nets         dept subnets             nodes

Then we can have 4 backbones, each backbone can have 16 dept nets, each
dept net can have 8 subnets, and each subnets can have 126 (128 minus all 0s
and all 1s) nodes.  By looking at books and references on Internet Addressing,
it seems to us that it should work and really follow the standard way for
subnetting.  The subnet mask for every networks is FFFFFF80.  Is it right?
Are we missing anything?  Can some network gurus confirm that or give us
some insight as to how to do it the right way?

If we follow this scheme, what should be the addresses for nodes like routers,
brideges, workstations, and computers attached directly to backbone net,
or dept nets.

================================================================= Super Backbone        |               |               |               |
        |               |               |       ========+======== Backbone 1
        |               |       ========+======================== Backbone 2
        |       ========+======================================== Backbone 3
==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+================= Backbone 4
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  .  .  .  .  .  .  .  .  .  .  .  .  .  . =+============ Dept net 1
  |  .  .  .  .  .  .  .  .  .  .  .  .  .  .                ...
  |                                                          ...
 =++==+===+===+===+===+===+===+============================== Dept net 16
 |   |   |   |   |   |   |   |
 |   .   .   .   .   .   . ==+=================== Subnet 1
 |   .   .   .   .   .   .                        ...
 |                                                ...
=+=============================================== Subnet 8

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

uunet!smosjc!lapyun

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 04:14:04 GMT
From:      ce1zzes@prism.gatech.EDU (Eric Sheppard)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware,comp.sys.ibm.pc.misc
Subject:   Packet driver over NDIS

I've been experimenting lately with the packet->NDIS converter from 
FTP Software.  I cannot seem to get the converter bound to the NDIS
driver; netbind.exe just hangs my machine.  One machine can load the
modules in and initialize the ethernet card, but no binding can take
place.   Another machine with a different (3Com 3c523) ethernet board
cannot get initialized (using the elnkmc.dos file dated April 9 at
FTP's site).   I would appreciate any pointers on putting the pieces
together in the right order; I feel I'm extremely close to a solution.
Has anyone successfully used this combination?
-- 
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

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 06:17:55 GMT
From:      echan@cadev6.intel.com (Eldon Chan ~)
To:        comp.protocols.tcp-ip
Subject:   Parallel routers running proxy-arp

As in the diagram, what would happen if router R1 crashed after the
unsubnetted_host established the connection to subnetted-host2 via
proxy-arp from R1?  Would the unsubnetted_host send another ARP request
or is it going to wait until the ARP entry aged out (20min?)

On the gateway side, would both routers response to the ARP
request for subnetted-host2  or just the router has a better route? In
the later case, I probably have to assign different default metric on
the routers to force a primary and a secondary route. Does IGRP take
care of this and provide some kind of load balancing? 


      subnetted-host1       unsubnetted_host
               |               |
  ----------------------------------------------
                           |             |
                           |             |
                        ------        -------
                        |  R1 |       |  R2  |  Both routers are 
                        ------        -------   running proxy-arp
                           |             |
                           |             |
  ----------------------------------------------
                |
        subnetted-host2

RFC1122 mentioned that there are four mechanisms to implement ARP
timeout.  I know most UNIX aged the arp table every minute, timeout the
incomplete entries every 3 minutes and complete entries every 20
minutes. What happens when the connection drops ? 

Would someone tell me which vendor is using which mechanism or point me
to the source files that I can check? In particular I am interested in
SunOS, Ultrix and AIX.

Thanks in advance.

Eldon Chan
echan@scdt.intel.com
-----------------------------------------------------------------------
-----------------------------------------------------------------------
RFC1122                        LINK LAYER                   October 1989



            DISCUSSION:
                 The ARP specification [LINK:2] suggests but does not
                 require a timeout mechanism to invalidate cache entries
                 when hosts change their Ethernet addresses.  The
                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
                 has significantly increased the likelihood that cache
                 entries in hosts will become invalid, and therefore
                 some ARP-cache invalidation mechanism is now required
                 for hosts.  Even in the absence of proxy ARP, a long-
                 period cache timeout is useful in order to
                 automatically correct any bad ARP data that might have
                 been cached.

            IMPLEMENTATION:
                 Four mechanisms have been used, sometimes in
                 combination, to flush out-of-date cache entries.

                 (1)  Timeout -- Periodically time out cache entries,
                      even if they are in use.  Note that this timeout
                      should be restarted when the cache entry is
                      "refreshed" (by observing the source fields,
                      regardless of target address, of an ARP broadcast
                      from the system in question).  For proxy ARP
                      situations, the timeout needs to be on the order
                      of a minute.

                 (2)  Unicast Poll -- Actively poll the remote host by
                      periodically sending a point-to-point ARP Request
                      to it, and delete the entry if no ARP Reply is
                      received from N successive polls.  Again, the
                      timeout should be on the order of a minute, and
                      typically N is 2.

                 (3)  Link-Layer Advice -- If the link-layer driver
                      detects a delivery problem, flush the
                      corresponding ARP cache entry.

                 (4)  Higher-layer Advice -- Provide a call from the
                      Internet layer to the link layer to indicate a
                      delivery problem.  The effect of this call would
                      be to invalidate the corresponding cache entry.
                      This call would be analogous to the
                      "ADVISE_DELIVPROB()" call from the transport layer
                      to the Internet layer (see Section 3.4), and in
                      fact the ADVISE_DELIVPROB routine might in turn
                      call the link-layer advice routine to invalidate
                      the ARP cache entry.

                 Approaches (1) and (2) involve ARP cache timeouts on
                 the order of a minute or less.  In the absence of proxy
                 ARP, a timeout this short could create noticeable
                 overhead traffic on a very large Ethernet.  Therefore,
                 it may be necessary to configure a host to lengthen the
                 ARP cache timeout.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 13:28:31 GMT
From:      tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
To:        comp.protocols.tcp-ip
Subject:   Re:  Internet Address Assignment

In general, I think your methods are partitioning the
address space up to much.  Strictly speaking, all a
address needs to have is net.subnet.host.  There is
no reason (as far as routing is concerned) to be able
to look at a subnet number and say "that subnet is on
backbone X, or in department Y".  Of course, it might
be convenient for a administrator to be able to do
that, but that's only a convenience, not a necessity.

The problem with putting too much into your addresses
is that in overly constrains the number of addresses
you can assign.  For instance, with your method 1...

> ------------------------------------------------------------------------------
> 
> Method 1:
> 
> Backbones - XX.YY.30, XX.YY.32, ..., XX.YY.38
> Dept Nets - XX.YY.40, XX.YY.60, ..., XX.YY.240
> Dept Subnets - XX.YY.41, XX.YY.42, ..., XX.YY.49 for dept net XX.YY.40
>              - XX.YY.61, XX.YY.62, ..., XX.YY.69 for dept net XX.YY.60
>              - ...
> 
> Is this setup a true subnetting?  Our concerns are some software like Interleaf
> using network license requires license server runs on, say, dept B net and
> serves all subnets B.1, B.2, etc.  At present, we have only backbone and dept
> nets hook to it and each net has it own class B address.  When Interleaf
> license server runs on, say, dept A's net, nodes in other dept's net cannot
> run Interleaf.  Does anybody knows if the method 1 setting will work?
> 
> ------------------------------------------------------------------------------

what happens when dept XX.YY.40 gets its 10th subnet?
Then, you have to give that subnet a number from a
different department, and you are worse off than if
you didn't group them so nicely in the first place,
because people will look at the new subnet number, and
expect it to be in a department where it is not.  
(Routing, however, won't be confused because it doesn't
care what department the subnet is in).


As for licensed software like Interleaf, I don't know.
I'm a bit surprised that they run their liscense such
that they look at the network number of the thing asking
for a liscense, and reject it if it is not network X.
You'd think they would allow for defining multiple net
numbers, or just part of a net number, for that matter.

Also, you might look at RFC 1219.  It discusses a method
of assigning subnet numbers that maximizes use of the
subnet number space.  This way, for instance, you don't
have to worry about how many hosts might be on a subnet,
or how many subnets you might eventually have, etc.  The
technique, however, results in variable length masks, so
you need a routing algorithm that handles variable length
masks, like OSPF.  I don't know what is available these
days.  What routers do you have between your subnets?

PT


Method 2:

Let's play with the 3rd and 4th octects.
        3rd octect                              4th octect
+---+---+---+---+---+---+---+---+       +---+---+---+---+---+---+---+---+
|   |   |   |   |   |   |   |   |       |   |   |   |   |   |   |   |   |
+---+---+---+---+---+---+---+---+       +---+---+---+---+---+---+---+---+
\      / \             / \                 / \                         /
backbone    dept nets         dept subnets             nodes

Then we can have 4 backbones, each backbone can have 16 dept nets, each
dept net can have 8 subnets, and each subnets can have 126 (128 minus all 0s
and all 1s) nodes.  By looking at books and references on Internet Addressing,
it seems to us that it should work and really follow the standard way for
subnetting.  The subnet mask for every networks is FFFFFF80.  Is it right?
Are we missing anything?  Can some network gurus confirm that or give us
some insight as to how to do it the right way?

If we follow this scheme, what should be the addresses for nodes like routers,
brideges, workstations, and computers attached directly to backbone net,
or dept nets.

================================================================= Super Backbone        |               |               |               |
        |               |               |       ========+======== Backbone 1
        |               |       ========+======================== Backbone 2
        |       ========+======================================== Backbone 3
==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+==+================= Backbone 4
  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
  |  .  .  .  .  .  .  .  .  .  .  .  .  .  . =+============ Dept net 1
  |  .  .  .  .  .  .  .  .  .  .  .  .  .  .                ...
  |                                                          ...
 =++==+===+===+===+===+===+===+============================== Dept net 16
 |   |   |   |   |   |   |   |
 |   .   .   .   .   .   . ==+=================== Subnet 1
 |   .   .   .   .   .   .                        ...
 |                                                ...
=+=============================================== Subnet 8

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

uunet!smosjc!lapyun

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 13:58:50 GMT
From:      fgreco@govt.shearson.com (Frank Greco)
To:        comp.protocols.tcp-ip
Subject:   Re: The ftp site of the Sun TI-RPC?

is......titan.rice.edu

also has *decent* asynchronous callbacks too...

Frank G.

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 14:22:35 GMT
From:      mcneill@udel.edu (Keith McNeill)
To:        alt.security,comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Need firewall telnet/ftp gateway

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

If anybody can point me to software like this, please let me know.

Thanks,

Keith

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

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 14:45:31 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet driver over NDIS

Here is the relevant part of my CONFIG.SYS:

	device=c:\etc\protman.sys
	device=c:\etc\ni5210.dos
	device=c:\etc\dis_pkt.dos

PROTMAN has to be first.  Here is my \LANMAN\PROTOCOL.INI:

	;The Protocol Manager:
	[protocol manager]
	    drivername = PROTMAN$

	; MACs:
	; Racal Interlan NI5210
	[NI5210]
	    BASEMEM    = 0XD0000
	    DRIVERNAME = NI5210$
	    IOBASE     = 0X360
	    IRQ        = 2

	; PC/TCP Protocol Stack:
	[PKTDRV]
	    drivername = PKTDRV$
	    bindings   = NI5210
	    intvec     = 0x60
	    chainvec   = 0x65

Other people in-house use the 3Com NDIS drivers as well; there were problems
with very early ones, but they've been fixed for quite a while.

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

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 15:37:48 GMT
From:      wil@hpcndm.CND.HP.COM (Wilson E Brumley)
To:        comp.protocols.tcp-ip
Subject:   Seeking SNMP Agent Tests

Does any know where I might get a test (or set of tests) for an SNMP
agent?  Have any of the standards groups developed such tests?

Wil Brumley

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 15:43:45 GMT
From:      Keith_Smith.pittsburgh@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Accessing a DOS disk from unix over ethernet

Exactly the question i was going to ask. Look forward to responses

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 17:14:20 GMT
From:      keith@KARA.CCIT.ARIZONA.EDU (Keith DiNicola)
To:        comp.protocols.tcp-ip
Subject:   Re: help! problem making IBM RISC-6000 work with AIX/TCP-IP


I think you don't have the gateway defined correctly.  That is the address of
the device that connects your segment to the outher ethernet(s) etc.  I'm not 
sure what level of AIX you have but mine originally (& wrongly) assumed MY 
address as the gateway.  If it wasn't on my segment it couldn't get to it.  Just
changed the gateway address and all was fine.

 Take Care! 

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 18:49:22 GMT
From:      c_bstratton@HNS.COM (Bob Stratton)
To:        comp.protocols.tcp-ip
Subject:   Is the DNS "working"?


   Date: 24 Apr 91 19:35:06 GMT
   From: <horrendous return address deleted!>  (Russ Nelson)
   Organization: Clarkson University, Potsdam NY
   References: <NELSON.91Apr18230637@sun.clarkson.edu>, <17653@venera.isi.edu>
   Sender: tcp-ip-relay@nic.ddn.mil

      If you capture the addresses of the originating sites to the old
      machine, it would be interesting to see a breakdown of what operating
      systems were involved.  Dollars to donuts quite a few are running KA9Q
      net.exe. 

   I'll take you up on that bet.  I studied a more-or-less random sample
   of machines over a day and a half[1].  I telnetted to the machine, and
   captured the output.  Of the machines listed below, only 6 could
   *possibly* be KA9Q, and none are *definitely* KA9Q.

		<stuff deleted>

Well, I'll agree with you that some of those are really weird, and
that most probably aren't running ka9q. I CAN, however vouch for one
of these namely:

   Domain/OS sr10 (sys2)

which is an Apollo at my site (Hughes Network Systems). It's not
running ka9q.

I missed the beginning of this thread. What was the selection criteria
for these machines? I know that this machine has some problems -
that's why I'm here. If someone has noticed something losing about it,
please let me know.

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

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 20:16:46 GMT
From:      rmilner@zia.aoc.nrao.edu (Ruth Milner)
To:        comp.protocols.tcp-ip
Subject:   PC-NFS routing/subnetting

We will be rearranging our network in a month or two, and I have a couple of
questions about PC-NFS routing support:

    1. Does PC-NFS understand subnetting properly?
    2. How can I make them talk to systems off our local network? 

Despite telling PC-NFS to use YP, I have also put entries in the hosts table 
for the BIND/YP server and the default router (a cisco which is our Internet 
connection), and some of the remote systems, explicitly. Every other system 
on the net, except *all* of the PC's (set up by 3 different people over a 
period of time), can talk to systems at our other sites, all connected to
Internet. The PC's just sit there. They don't say "host unknown", they don't 
say "network unreachable", they just sit there. I know the YP information (or 
perhaps from named, it really doesn't matter which in this case) is getting to 
them because they can reach all of the systems on our local Ethernet even when 
they aren't in the PCs' hosts table. But they can't talk to anything else.

Do I have to do anything peculiar to make them understand the routing?

Most of them are running PC-NFS 3.0.1. The pcnfsd server is a Solbourne (read
Sun 4) running the equivalent of SunOS 4.0.3. It is the master YP(NIS) server
and runs BIND. As an aside, even if we make one of our Convexes the server,
it doesn't make any difference.

Will upgrading the PC-NFS software to 3.5 help?
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 22:42:44 GMT
From:      greene@coral.com (Jeremy Greene)
To:        comp.protocols.tcp-ip
Subject:   Byte and bit order within packet headers


) This is a small problem for little endian machines (most significant byte is
) on the right). They must correct their byte order before the packet is
) transmitted. In BSD systems, this job is performed by the htonl() and htons()
) functions (host to network long, host to network short), but what about the
) bit order? It is still little-endian (bits are numbered right to left instead
) of left to right)! What order is are the bits transmitted in?
) 

Byte order is a host to host issue. One host has a different view of
byte order than the other. Fortunately, there is an agreed upon inter-host
(network) format which is big-endian.

Bit order is not a host problem; it is only network related, and more
specifically, MAC layer related. In otherwords, you always have the
same hardware at both ends of the connection and from the host
perspective the bit order is treated the same. If you send 0x01 on
fddi you will receive 0x01 on some other fddi interface. Same for
Ethernet.  Unlike the byte order issue, you never send from fddi to
Ethernet, which would make a big mess.

The fact that bits are sent in a different order do not present a
problem in getting data from one host to another.

The problem is that the actual network hardware interprets the
mac address. Given that:

   - the address on both rings and Ethernets are the same: group
     bit first and,

   - rings transmit the left most bit from a byte first, Ethernet
     transmits the right most bit

the same address has to be placed in memory in a different bit order
depending on the media type.

So, if the address starts 0x01 in Ehternet land (which is a group
address) then it must start 0x80 for a fddi interface. From the
network perspective it's the same address.

In other words, similar to the byte order problem, you want to have
the macros 'ntomac' and 'macton'. To do this, there has to be a
canonical foramt, which IEEE has (recently) stated is the Ethernet format.

The bottom line is that you only have to worry about bit order if
you're wokring at the MAC layer.

Jeremy

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 22:42:50 GMT
From:      bernard@cs.colorado.edu (Bernie Bernstein)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: New XferIt Mac FTP Client Available

In article <1991Apr24.231416.16415@engin.umich.edu>, sfalken@mondo.engin.umich.edu (Steve Falkenburg) writes:
> 
> > XferIt 1.3, my Macintosh FTP client, has just been released.  For those not
> > familiar with it, it's FTP with a graphical user interface.
> > 
> > -steve falkenburg
> Oh, and XferIt 1.3 is available by anonymous ftp from mondo.engin.umich.edu
> (141.212.68.14) and is located in /pub/XferIt.sea.hqx


I had a problem at first using this version of the program under 7.0 but
Steve solved it.  Most people have MacTCP in the System Folder ROOT with
an alias to it in Control Panels.  That is because the programs (Eudora, etc)
search for the TCP file in the System Folder.  Newer programs (XferIt 1.3)
search for MacTCP in the Control Panels folder (if running 7.0).

If you have MacTCP in the System Folder with an alias in Control Panels,
the XferIt 1.3 will fail to find MacTCP.  So you should put MacTCP in
the System Folder AND in Control Panels (not an alias) so MacTCP will
work with all programs that search in either place for it.

Eventually, all programs will work with MacTCP in just the Control Panels
folder (maybe).  So we are now in the changover process where we need to
accommodate programs that work either way until they are all recompiled
using the newer libraries.


      o,  ,,   ,      | Bernie Bernstein                      | ,    ,,
      L>O/  \,/ \    ,| University of Colorado at boulder     |/ \,,/  \
     O./  '  / . `, / | office: (303) 492-8136                |     / ` \  ,.
    ,/   /  ,      '  | email: bernard@cs.colorado.edu        | /        ''  \

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Apr 91 22:56:21 GMT
From:      ted@blia.sharebase.com (Ted Marshall)
To:        comp.os.vms,comp.sys.dec,comp.protocols.tcp-ip
Subject:   SUMMARY: my query on VMS TCP (LONG)

Hello all. One week ago, I posted the following query:

- We are in the process of selecting a TCP/IP vendor for VAX/VMS for a
- special project. I am in the process of contacting the vendors for
- information but I have two questions that may be difficult to get
- answers for that I was hoping that the net could help with.
- 
- The implementations I am looking at are:
-         UCX from DEC (is this officially called the "VMS/ULTRIX connection"
-                 or are these two different products?);
-         WIN/TCP from The Wollongong Group;
-         Fusion TCP/IP from Network Research; and
-         MultiNet TCP/IP from TGV.
- I already have a copy of CMU-TEK TCP but this project requires a commercially
- supported product.
- 
- My basic requirements include:
-         TCP and IP (supported by ARP and ICMP);
-         Share DEC Ethernet interface with DECnet;
-         Process-to-process TCP connections (other protocols and utilities
-                 desired but not required; socket library not required, QIO
-                 interface adequite);
-         At least 200 simultaneous TCP connections to other hosts (given a
-                 large enough VAX).
- I believe that all of the implementations I've listed meet these requirement,
- possibly excepting the last. If anyone knows of other vendors, please feel
- free to suggest them.
- 
- My two basic questions:
- 
- (1) Does anyone know what the actual limit of simultaneous connections is for
- a given implementation. Or at least, conformation that an implementation can
- make it to 200.
- 
- (2) Has anyone benchmarked any of the implementations against another? I am
- interested in performance of TCP and IP only. For example, Given two VAXen
- on an Ethernet, a small program on one feeding data to a small program on the
- other over TCP, how many KB per second?

I have received ten responses. Although for the most part they did not address
my specific questions, they were all very helpful. I have sent individual
thank-you messages to each sender. If you sent something but did not get a
response, either your mail or my response got eaten by the email monster;
sorry.

The over all winner seems to be Multinet from TGV. Six of the messages
specificly recommended it. One message only had negative comments and those
seemed to be monor (he went with it anyway). Several of the messages gave 
informal comparisons of performance; these all said that Multinet was the 
fastest, though no one had numbers to back that up.

Two messages gave positive evaluations to WIN/TCP from Wollongong. However,
one of these senders went with Multinet anyway and the other sender did not 
seem to have actually compared to against the other implementations; he simply 
said "it seems to work fine". Five messages recommended against Wollongong; 
Reasons cited were bugs, poor support, and that Multinet was better.

No one seemed to like UCX from DEC. Four messages recommended against
it, citing lack of features, buggy installation and again, that Multinet was
better.

Two messages mentioned Fusion TCP from Network Research. One stated that
the sender felt that it would not meet my requirements and the other stated
that its performance was subjectively poor.

Additionally, one person suggested TCPware from Process Software. He is very
happy running their RSX-11 product and suggested I check on their VMS product.

The last message, included in the total count but not in any others, was from
Kenneth Adelman at TGV. He made the following useful comment:
-     MultiNet has no architectural limit on the number of incoming
- TELNET or RLOGIN connections.  Each connection requires about 500
- bytes of memory, and the CPU resources are about the same as a
- hardwired DZ11 terminal line.  You'll find that whatever those users
- are doing on the machine is going to require more resources than the
- TELNET server itself and that you can ignore the overhead of the
- TELNET server when sizing your machine.  The same can also be said for
- Wollongong's product; I'm not familiar with the others.
He also made some suggestions on how to benchmark TCPs against each other.

Well, everything seems to be pointing to Multinet. If WIN/TCP and UCX have
the same number of supporters, I didn't hear from them. When we get closer
to starting our project, I plan to request evaluation copies of WIN/TCP and
Multinet and check them out myself. (This was suggested by several messages.)

Finally, Ben Pashkoff of Technion IIT in Israel (BEN@VMSA.TECHNION.AC.IL)
sent a detailed evaluation of TCP products he did and gave permission to
post it. IMPORTANT: this was done in 1989 and some things have changed since
then. He later wrote that it hasn't been updated because they selected Multinet
and are very happy with it.

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

              VAX/VMS Tcp/Ip Evaluation  July 1989
              ------------------------------------
                         Ben Pashkoff
                       Computer Center
                        Technion, IIT
                        Haifa, Israel

	The following document is a summary evaluation of a series of
products for VMS network communication. This document was written in
conjunction with research and tests performed by the author as well as
Mr. Yehavi Bourvine of the Hebrew University Computation Center.

DEC, Digital, VMS, VAX, Ultrix, VAXBI are registered trademarks of 
Digital Equipment Corp.
UNIX is a registered trademark of AT&T.
NFS is a registered trademark of Sun Microsystems Inc.

Introduction

The Tcp/Ip protocol has been established as the de facto standard for
inter-computer and workstation communication. The protocol defines a 
description for inter-process communication between computers. The 
standard descriptions are available for public inspection as a series 
of articles. 

I. Criterion

	In order to evaluate a Tcp/Ip product for VMS, a set
of criterion and limitations was developed. These included:

1) Availability: Is the product immediately available for inspection
from the company or a representative of the company developing the
product?

2) Support: Is the company located in Israel? If not, does it have a
duly authorized agent for sales and support in Israel? If so, does
this  agent have the necessary personnel, experience and expertise to
completely guarantee assistance with the product? If there is no local
agent, is the company available for consultation by Phone, facsimile, telex
or electronic mail?  Is there a fee involved for any of these services
to the customer? Does the company guarantee to notify and update the
customer when and/or if any problems are found and fixed with the
product?

3) SMP: Does the product support VMS 5.x? or DEC/VMS SMP (Symmetric
Multi-Processing)? These two questions become imperative 
with the introduction of 6000 class VAX machines on each of the major
university campuses and with the introduction of parallel processing.

4) Installation: Is the product relatively simple to install,
customize, manage, and maintain? Is sufficient documentation available
to inform the system manager what to change and how to customize the
product to suit the environment? Does the product require any system
parameter changes in order to install and operate? 

5) Special Hardware: Is special hardware required to install, or
operate the product? Is the product versatile enough in order to
operate over a variety of hardware configurations? 

6) Standard Protocol Applications:
   A) TELNET- Does the product conform to the documented TELNET
standards? Is a IBM 3270 terminal emulation supplied/supported (e.g.
tn3270)? What is the theoretical and actual limit to the number of 
TELNET logins? What is the system overhead of a typical TELNET login 
and at what point will system degradation be noticeable to the end-user?
Is there an on-line help available?
   B) FTP - Does the product conform to the documented FTP standards? 
Does the product support 3rd part transfers? Is there a clear and 
concise on-line help facility? Is there proper security restrictions 
built into the product? Are the commands similar enough to other 
versions of this product under other operating systems that end-users 
do not have to re-learn a new facility? Are extensions for VMS file
types included?
   C) SMTP - Is the SMTP server included in the base product?
If not, what is the extra charge? If included, is there a mail user
interface included? Does the SMTP implementation include routing
capabilities and mail handlers?
   D) Subnets - Is subnetting included?

7) Extra Utilities and Applications:
   A) LPR/LPD - Is this available for both client and server operation? 
How difficult to install as well as to maintain? Which Lpr/Lpd
features are supplied?
   B) Nameserver - Does the product support an implementation of BIND
Nameserver either as client, server, or both?
   C) R-commands - Are the Berkeley R client/server services included? 
This includes rlogin, rshell, rcopy, rexec, etc.
   D) NFS - Does the product support an implementation of Sun NFS
(Network File Server) either as client, server, or both?  How is file
name mapping handled in each? 
   E) talk - Does the product support the UNIX talk facility (similar
to VMS PHONE)? If so, is it 4.2 or 4.3 UNIX compatible?
   F) finger - Does the product support a finger process? If so, is it
compatible to UNIX Finger processes?
   G) Statistics - What kind of diagnostics  and statistic information
is provided by the implementation to aid the manager in following net
traffic, and measuring network load? 
   H) Gateway - Can the implementation support a gateway configuration? 

8) USER Interface: Is the user interface easily accessible by any
end-user? How much time will be involved in training a new user to use
the facility? Is the response time (apart from system overhead) short
enough to be easily acceptable to the end-user? Are on-line help files
available? If so, how well written and usable are they? In any case,
what is the status and availability of written documentation for the
user as well as the system and network manager?

9) Cost: What is the pricing schedule for this product? Is the
company willing to consider a site license? an academic discount? a
group pricing scheme? 

10) Source: Are program sources available? If so, to what extent,
what media, and at what cost? Would the source material be usable by
system maintenance personnel if they had it?

11) Programming interface: Is there a programming interface available
for expansion and implementation of new applications? If so, is this
at the Socket level? at the $QIO interface level ($QIO is the VMS low
level Queue Input and Output programming interface)? Is there
documentation and support at this level?

II. Product Candidates

There are several products on the market that advertise themselves as
Tcp/Ip implementations for VMS. Product Information from each vendor
is available on request, or may be appended at a later date. For one 
reason or another, most are not suitable for use here. The following 
are available, but for the reason stated were not considered:

A. VMS/Ultrix Connection: This is a DEC supported product that is
still in its 'software infancy'. Though purported to be a Tcp/Ip
implementation, it does not support SMTP at the present time. It does
support an NFS Server implementation, which is its main selling point.
A version was not made available for our inspection, though without
SMTP, it was not considered worthwhile. Mixed reports have been
received. TELNET is not supported and FTP is only partially supported.

B. CMU-Tek: This is a joint product in the public domain between
Carnegie Mellon University, and the Tektronix Corp. It is written in
BLISS, and requires a BLISS compiler to be on-site in order to
operate. There is no formal support for the product from either of the
parties involved in its production. At last notice, it also does not
support SMP as yet.

C. Wollongong, V/IP:  Wollongnong, in its first version, was not at all
suitable for use. The second version is reportedly a much better
product. Digital is supposedly a sales agent for Wollongong, but
attempts to even request a price quote for this have not been
answered. It is a ported product from the Berkeley UNIX Tcp/Ip, so it
does conform to almost all known standards. 
	The following comments are courtesy of Mr. Benzi Mizrachi of the
Weizmann Institute. Weizmann currently runs both Win/Tcp (Wollongong)
and Fusion at their site.
	Wollongong does support various hardware interfaces as well as the
ability to share the DEC ethernet controller. The next version is
scheduled to support DEC SMP. The current version supports tn3270
though is supposed to be very CPU time consuming. Weizmann reports
that this is still bearable, and that the tn3270 interface is very
convenient to work with. Wollongong does support a Nameserver.
The current version was reportedly easy to install and maintain. SMTP
is also through the VMSmail interface, similar to that of Fusion or
Multinet. There is a good $QIO interface. The current product has been
in use for 4 years at Weizmann and there have been very few problems
to report. Documentation is considered better and easier to use than
that of Fusion (see below).
	The local agent for V/IP is Bricom, the same as was for EXOS, so 
support is not expected to be any better. V/Ip is reportedly an OEM 
adaptation of Wollongong, though there is no word or credit to 
Wollongong in any of the literature received. The price quotation for 
this that was received was more than for any of the other candidates.
	A price quote that was received for this product for one VAXBI
based computer (e.g. VAX 6000 series) was approximately $17,000, not
including NFS. This price does not include source code and is 
non-transferable to other machines.


The last three candidates are Exelans' EXOS, NRC-Fusion, and
the SRI/TGV Multinet version. Since these were given
considerable more testing, the results from these will be covered in
the next sections.


D. EXOS/Exelan: This is the Tcp/Ip product currently in use at
Technion and the Hebrew University. At last notice, though it does
support VMS 5.x, SMP support was not available. EXOS also requires its
own hardware interface to ethernet which is not currently available
for a VAXBI bus implementation nor for the VAX 6000 class computers.
Bricom, the local agent that was responsible for EXOS has now decided 
not to sell or support this product.
Customer support for this product has not been up to satisfactory
standards over the past 2 years of its use. Further information on
this product is available on request, but since it does not meet some
basic requirements, it will not be elaborated upon here.

E. NRC-Fusion:
	The NRC-Fusion implementation is very complete in many aspects.
The design philosophy used to develop it was different from other
implementations. It is, by design, not a port of the Berkeley Tcp/Ip
product, rather the developers designed a VMS product from scratch
that comply to the requisite Tcp/Ip standards. This would seem to lead to
the conclusion that NRC-Fusion would be a more efficient and better
suited product for VMS. 
	NRC-Fusion is sold and supported by an NRC representative here in
Israel, COMDA Ltd. COMDA is not a subsidiary of NRC, but has a
commitment to support of this product. They have claimed to have an
extensive support service available, with a second source from NRC in the
U.S. Telephone response and support has been fairly decent. The
representatives from COMDA are interested in establishing group discount 
either via each individual university or via MACHBA. 
	This product does have a SMP, and a Version 5.x capability.
Installation of the product and operation for TELNET, FTP and other
utilities was achieved in approximately two hours including some
minor, but disturbing problems. Fusion does support a Nameserver,
which is reportedly simple to implement. Without this, all hosts must
be separately defined, if using dbedit. The interface to their tables,
is either via a special program that is supplied (dbedit) or a regular 
test editor.
In the implementation tested, only the dbedit proved possible, and
after a short while it became annoying to use. The database itself is
different from those used in other implementations. 
	FUSION runs in parallel and on the same hardware as DECnet, thus
most VAXen need no additional hardware installation. 
	Pricing information for the NRC-Fusion was received. The basic
Tcp/Ip product (including TELNET, FTP, finger, diagnostics) was
$10,800. An additional $1800 was required for SMTP and the mail
interface. Another additional $1800 for the R-commands, and another
$4500 for an NFS server. After 30% academic discount, this package
would be $13,230. This price does not include sources, nor is it
transferable or take into account any smaller VAXen on campus. 
	TELNET from the VAX is slow, as were all functions with Fusion. 
TELNET to the VAX is also slow. There is a definite feeling of sluggishness 
when connected via TELNET (response time approx. 1 sec.). A control key 
guide is also written to the terminal to inform the user as to the 
proper exit key.
	Fusion also supports a very nice third party file transfer via
FTP. In other words, it is possible to be logged into A and transfer a
file from B to C. The  FTP suite will prompt for all necessary user
information as well as source and target for files. FTP also has the 
ability to submit files to remote  VMS print queues
	SMTP is supported as a separate product, and not part of the base
product. At the time of the original test, it was not available so it
was not tested. It has since been made available, and a testing of it
could be performed. Weizmann reports that the Fusion SMTP mailer uses
either the VMSmail interface or their own unix-like mail interface,
which is fairly convenient.
	Fusion does support a finger utility, and a nice variety of
diagnostic tools. 
	As to extra utilities and functions, while LPR/LPD was promised
to be available, it is not mentioned in the documentation, nor in the
advertisements. A domain Nameserver and resolver is included, Berkeley R
commands, as stated above, are available, but as a separate package.
There is no talk facility.
	The user documentation is excellent. Unlike other VMS third party
software developers, it makes no attempt to emulate VMS documentation.
The documentation for managers as well as users is well written and
carefully and logically organized. There is a lack of a troubleshooting
guide, but this is natural in a product that expects no problems.
Unfortunately, a completely problem-free software package has yet to
be produced. On-line help facilities are equally well written and the
guide for the end-user is concise and simple, integrating where
necessary with other concepts of VMS.
	Installation of this product, as stated previously, was in
approximately two hours. There are some anomalies that are disturbing.
The databases are case dependent, and this is not stated anywhere.
When the dbedit program is run, and information is given in
lower-case, it will not be received by the program. There is no error
checking for this, but the manager has ample error documentation in
a full set of error log files. Changes to the configuration as well
as customization are best done via dbedit. This program is a full
screen based question and answer routine that allows the manager to
change the basic configuration of the implementation as well as to
expand the host and routing tables. However, additions are included
one at a time, and a full conversion for a downloaded host-table was
not found. One annoying problem with dbedit is that it never paused as
it was supposed to on page boundaries to display explanatory text,
rather scrolled through the complete text without stopping.
	Fusion, while not including sources with their product (this is
also an extra charge that could well be above $20,000), does include a
programmers $QIO interface.

F. Multinet:
	Multinet is essentially a code port from Berkeley UNIX 4.2 and
4.3, developed and distributed to the academic community by SRI
International, and marketed and supported by the TGV company in
California. SRI International is attached to the Stanford Research
Institute and its primary function is the distribution of research
reports including the above-mentioned Tcp/Ip Standards reports 
concerning the standards for Tcp/Ip. TGV is an admittedly small 
company (3 plus people) whose sole function is support for this product. 
According to the software product description it is a very complete 
product, and for the most part very professionally produced. 
	There is no local Israeli representative for SRI or for TGV, and
all discussion concerning sales and support has been handled to this
date via e-mail and facsimile. Both TGV and SRI are available on Arpa-net
and thus have good e-mail access. Response time for support has been
approximately 12 hours, which is very good, taking into account a 10
hour time difference between Israel and California. 
	Multinet supports the widest number of hardware configurations
available as a Tcp/Ip product for VMS. The list includes all known DEC
ethernet controllers as well as many third party controllers
(including Execelans' EXOS family of controllers). Multinet can also
be configured to use more than one controller on a computer and thus
serve as a gateway between two networks. According to TGV, the
technical support for Multinet, the EXOS cards run approximately
10% faster than the DEC ethernet controllers. (Please note that the
EXOS cards run in 'dumb' mode in any case.) 
	Multinet is one of three producers of a SMP and Version 5.x
compatible Tcp/Ip implementation. At the time of this study, only two
were available for inspection (Fusion and Multinet). 
	Multinet installation was incredibly quick, easy, and painless.
Installation and operation was achieved in approximately 25 minutes.
This included installation and operation of the Domain Nameserver and
SMTP. Like other implementations installation is via the VMS VMSINSTAL
program with a simple question and answer routine to establish Hosts
and Nameserver parameters. All tables are either identical or
sufficiently similar to UNIX implementation to pose no compatibility
problems with the tables.
	Multinet, as a base package for universities, includes all base
applications and most utilities except for NFS and a mail interface. 
All connections are handled by a master server, so there is only one
process running for inbound connections. Inbound TELNET connections
are routed through the standard VMS TTYDRIVER so all VMS supported
terminals are supported. Outbound connections support tn3270 for 
connection to IBM hosts running Tcp/Ip. The response times are very 
good (typically <0.5 sec.) and the tn3270 is a very efficient emulator. 
The TELNET server tries to negotiate  the terminal type if possible. 
There is no described limit on the number of TELNET sessions to the 
computer and other sites have reported more than 100 sessions on a 
VAX 6000 class computer with before noticeable degradation in performance. 
Each TELNET connection requires approximately 0.2 Kbyte of memory 
for the connection.
	FTP is also fairly efficient and quick (measurements in the range
of 30 were seen as opposed to 10 with Fusion). Outgoing FTP does not 
ask for Username and Password as a default, but will not allow any 
actions until the appropriate commands for User and Password are given. 
All standard FTP commands are supported and the On-line helpfile is 
quite explicit. FTP transfers between to other Multinet implementations 
can also be made using a Lempel-Ziv Compression routine. The FTP 
client can also be asked to negotiate a VMS file-type transfer with 
another Multinet implementation. This allows transparent binary and 
image file transfers. 
	The SMTP server is included as a standard part of the base
product. There is an optional Mail interface available, but this is
not necessary for use by the end-user. The SMTP implementation can use
the Nameserver to resolve addresses. Mail headers are also written 
according to Tcp/Ip standards. Incoming mail must be sent using a 
VMS external Mail carrier. This is defined from the user point of 
view in the Send line as:
	SMTP%"user@host" or BITNET%"user@host". 
Since this is compatible with what is currently in use, this should 
pose no problems for end-users at this site.
	Multinet supports the Berkeley BIND Nameserver in either client
or server mode. In client mode it queries the server to reply with the
required resolved address, if the address is not resolved it resorts
to its own internal host tables. All tables are stored in memory for
faster access. This also uses what could be much needed memory on
smaller systems. In server mode, the definition tables are identical
to those used in UNIX implementations. Personnel already familiar with
the Berkeley implementation have no trouble utilizing this one. Like
the Berkeley BIND, a primary and secondary made be designated. 
There were some documented commands in the current inspection copy
that were not clearly functional. TGV has assured us that a new
documentation set is in process. (See below)
	A full set of R-commands is also included in the base set. This
includes rlogin, rshell, etc. These work as expected (i.e. not
different than their UNIX counterparts.), but are not suggested due to
security considerations. 
	As a side note, the managerial software is designed in such a way
that certain servers may be enabled or disabled as the manager deems
necessary. This means that the R-commands features may be completely
disabled.
	NFS is available as an additional feature from SRI. It was not
requested as a necessary component for this test. 
	Multinet also includes both old-talk and new-talk as a part of
the base set. This has been tested and works very well with both UNIX
4.2, UNIX 4.3 and SUNos. The talk facility provides a VMS-Phone like
utility between UNIX and VMS.
	Finger is available as a part of the base package. It is useful
on the local computer as well as other computers connected via the
network.
	Both RIP and SLIP protocols are supported by Multinet according
to the documentation.
	LPR/LPD protocol is supplied. This was installed and tested. 
Installation was very easy and quick, though these are not in
the current documentation set received. As a client, the foreign print
queue appears as a VMS native print queue, and as a server, incoming
jobs are treated as VMS print jobs. There are no facilities currently
available to observe the foreign queue or for the remote machine to 
observe the local queue, nor is there a facility to remove the job once 
it has left the local machine. Remote jobs, sent to a remote computer, 
appear on the remote computer with a file name like:
"Remote print file from node xxxx" and not the actual file name.
	The Multinet documentation is sorely lacking in the present
version. While it is pretty to look at, there leaves a lot to be
desired in completeness and organization. We have received assurance
from TGV that a new version of all documentation is in process and is
due to be distributed this Fall. The Installation section basically
says to run the standard VMS Install procedure, which is more than
ample to install and begin the product. The user section very cleanly
and basically describes the currently available features. The on-line
help is similar and is equally clean and direct. Documentation
concerning additional features is sparse, e.g. tn3270 is not mentioned
at all in the current set.
	SRI is willing to give favorable pricing to universities. The
basic package is available at $5500 for a single CPU and $2750 for
each additional CPU on a site. They also have a special discount of
$16,500 for 13 VAX units. (1 Vax unit = 1 VAX 7xx, 8xxx, 6xxx or 3
microVaxen, or 10 Vaxstations). NFS is available for $750/CPU or
$4688/site. All of the above prices are subject to a further 10%
discount on condition if the SRI standard license agreement is signed
with no major modification or negotiation. Partial sources and a
Public Domain C language compiler are also included for academic
institutions. Partial sources include all but the kernel code
concerning the SMP interface.
	In addition to partial sources, Multinet also includes a $QIO
programming and a socket programming interface. Both have been used
and are quite easy to work with and understand for the systems
programmer. 

Conclusions

In order to decide which of the preceding packages is worthwhile to
purchase all of the above criterion must weighed. There is a benefit
and a deficit to not having direct support here in Israel, however,
having good support even via e-mail is far better than poor support
next door. On a price-per-performance basis, we see that Multinet is
both reliable and efficient in use and performance. The main drawback
for Multinet is the documentation, which is sadly the same situation
with many equally large commercial packages. Even though a package
specifically designed for VMS may be advantageous to the VMS system
point of view, this was not obvious in performance, and having a
Berkeley based and similar product expands the possible support group
to include UNIX personnel that are already familiar with the product
from the UNIX perspective. It is the authors' opinion that the
Multinet product be purchased.
	The 13 unit license is advantageous only if there are more than 6
computers to be installed. With the growing number of Vaxstations on
the Technion campus, it would seem that this may be possible. It is 
recommended that the Multinet NFS server be tested as well.


											31-July-1989
 
Comparison of Product features VAX/VMS TCP/IP.  
================================================

The following table is based on a comparison of Wollonong and Fusion, 
received from Comda and NRC Inc. 
Expanded to include Multinet and pricing information by Ben Pashkoff.

 
FEATURE                 Wollongong              NRC-Fusion      Multinet
==========================================================================
Source of product       Berkeley Port           In-House        Berkeley Port
Source code available   No                      OEM             Most
Multi-protocol          No                      Yes             Yes
Program Interface       FTP                     FTP,SMTP(mail)  All
QI/O Support            Yes                     Read/Write      Yes
Socket Lib              BSD 4.3                 BSD 4.2         BSD 4.3,RPC
GATED-RIP,HELLO
  EGP                   YES                     PLANNED         YES
DEC-SMP                 ALMOST                  YES             YES
VMSINSTAL               PLANNED                 YES             YES
NET MANAGEMENT UTILS    NO                      PROPRIETARY      YES
SHARED DECNET           YES                     YES             YES
MULTI-CONTROLLER        EXTRA $$$               YES             YES
VAN JACOBSEN ALGORITHM  YES                     PLANNED         YES
DOMAINNAME SERVER       YES                     YES             YES
 
FTP Features
==========================================================================
Copy, Move Append       No                      Yes             No
Print Queue             No                      Yes             No
VMS Loginout            No                      Yes             Yes
RMS-RMS                 No                      Yes             Yes
Command Complexity      62                      <40             56
3 rd Party Copy         No                      Yes             No
Wildcard copy           Yes                     Yes             Yes
Multiple connects ???   No                      Yes              -
Lempel-Ziv compression  ?                       ?               Yes
 
 
TELNET Features
=============================================================================
Line at a time ???      No                      Yes              -
Terminal Type           No                      Yes             YES
TN3270 support          Yes                     NO              Yes
Print Queue    ???      No                      Yes              -
 
Options available
===========================================================================
NFS Server              Extra $$$               Extra $$$      Extra $$$
RPC/XDR Lib             No                      Extra $$$       Yes
Mail/SMTP               Yes                     Extra $$$       Yes
'R' Commands            Yes                     Extra $$$       Yes
X.25 ??                 Yes(w/Hdwre)            Yes(w/Hdwre)    Yes
DMV/DMR Synch           Yes                     Yes             Yes
Asynch DDCMP            No                      Yes             Yes
Talk                    No                      No              Yes
Finger                  Yes                     Yes             Yes
LPR/LPD                  ?                      No              Yes
SLIP                     ?                      ?               Yes 
 
Security Features
==========================================================================
Tcp/Ip Security option  No                      Yes             Yes
Host/Network Security   No                      net_secure      Yes
 

Price Features
==========================================================================
Pricing information not given for Wollongong. 
Site based on approximation of current Technion configuration and
assumption that all known VMS nodes.
Configuration of:
6 VAXen (7xx,6xxx)
5 micro-VAXen (uVax 2 or 3 with multi-user license)
15 Vaxstations (1-2 User license)

Tcp/Ip                                          $31500             $14850						  
SMTP                                            $ 5442             included
R-commands                                     included            included
NFS                                             $19325              $ 4688
===========================================================================
Total                                           $56267             $19538

Future Expansion                                 (1)                (2)

(1) NRC-Fusion prices are on condition that at least $10,000 worth is
ordered by end of December 1989, afterwards all prices are
re-negotiable.

(2) Multinet prices are based on a 13 Unit license for indefinite
period of time. Under this license 1 Vax is exchangeable at a rate of
1.5 microVaxes or 10 Vaxstations. The Configuration considered is
equal to 10 Vax units, thus leaving room for expansion.

________________________________________________________________________
|      Ben Pashkoff                 BEN@VMSA.TECHNION.AC.IL            |
|                                   BEN@TECHUNIX.BITNET                |
|      VAX/VMS Systems                                                 |
|      Computer Center              Phone:(972)-4-292177 office        |
|      Technion IIT                 FAX:  (972)-4-236212               |
|      Haifa, Israel 32000                                             |
|______________________________________________________________________|

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

-- 
Ted Marshall                                       ted@airplane.sharebase.com
ShareBase Corp., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 01:21:00 GMT
From:      0004219666@MCIMAIL.COM (Bob Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: How's the LAN doing (really, Internet Bibliography)

>I would be interested in the catalog "A Network Management Tool
>Catalog" but I do not know what the RFC in "RFC 1147" stands for.

RFCs are online documents maintained by the NIC (Network Information Center). 
The misleading acronym is "Request For Comments."  The name is a hold-over from
the days when the Internet was being put together, and was populated almost
exclusively by leading-edge hackers, now known as "old boys."   Today, RFCs are
most often Internet standards or draft standards.  Occasionally, as is the case
with RFC 1147, RFCs are informally informational.

If you have FTP access to the Internet, you can get RFCs from nic.ddn.mil.  Use
username "anonymous", and give your actual user@host as the password.  Change
directory to "rfc:" (the colon is _required_), and get "rfc1147.txt".  Better
yet, if you have a postscript printer, get "rfc1147.ps".

If you don't have FTP access, you can get RFCs by email.  Send a null message to
service@nic.ddn.mil.  For the subject line, use "RFC 1147" or "RFC 1147.PS".
For more info on the email document server, send it an empty message with
subject line "help".

I'd recommend that you also get RFC 1175, "FYI on where to start: A bibliography
of internetworking information," and RFC 1177, "FYI on Questions and Answers:
Answers to commonly asked `new internet user' questions".

Happy hunting,

Bob Stine

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 05:15:36 GMT
From:      erick@sunee.waterloo.edu (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

In article <9104241753.AA21589@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>
>I have a question concerning concering the byte and bit order of fields
>within packet headers. Many of the RFCS (including RFC1060) state rules
>about the byte (octet) order:
>

Much confusion stems from the fact that Intel processors store 
bits in the following order

  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
  |07 06 05 04 03 02 01 00 | 15 14 13 12 11 10 09 08 |
 +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
  |  first stored byte     |  second stored byte     |  etc.

whereas network order is

  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
  |15 14 13 12 11 10 09 08 | 07 06 05 04 03 02 01 00 |
  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+

so the bits and nybbles are already in network order, you simply need to
organize quantities larger than a byte, namely 16 and 32 bit values.

The intel code should have
    unsigned  ip_h : 4;
    unsigned  ip_v : 4;

I hope this clears it up a bit.

Erick


-- 
----------------------------------------------------------------------------
Erick Engelke                                       Watstar Computer Network
Watstar Network Guy                                   University of Waterloo
Erick@Development.Watstar.UWaterloo.ca              (519) 885-1211 Ext. 2965

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 12:09:48 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

I have received some mail on this suggestion. There are a few comments
about gatewaying the mailing list to the new newsgroup, which I would be
very happy to see. We should also consider where the new newsgroup should
go. One person pointed out that it would be better if we did not limit it
to protocols. How about comp.dcom.lans.management?
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 13:19:55 GMT
From:      blknowle@FRODO.JDSSC.DCA.MIL (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...

Folks,

Keith McNeill (<mcneill@udel.edu>), says
(in <9104251025.aa08966@louie.udel.edu>):

KM> We are setting up an internet gateway at work.  Currently, we're going
KM> to set it up as a firewall system. 

And later asks for help setting up a proxy-ftp and proxy-telnet system.

    My first question is: Why a firewall system?  Is it because David
Curry in "Improving the Security of Your Unix System" recommends it?

    Mitch Wright, System Administrator for a large network of machines
owned by 7th Communications Group of the United States Air Force (here in
the Pentagon), administrator for the Sun-386i mailing list, and in
general, a knowledgeable kind of guy about Unix says that a firewall
system is not necessary if you set up the security on all of your systems
to be as good as that of your proposed firewall system.  Additionally,
Mitch says that if you are dependant upon your firewall system to protect
you from system crackers, and they crack into your firewall system (based
upon the presumption that no useful system is 100% cracker-proof), then
you are left wide open to any attacks they may make.  In fact, you may be
even more vulnerable because the security on your other system might be
even more lax than it would be otherwise, because you were lulled into a
false sense of security because of your firewall system.  It was Mitch's
arguments that convinced me that David Curry was wrong, perhaps even
dangerously so.

    The short of it is, with good security practices on all of your
machines, nothing like what happened to Clifford Stoll (written about in
"The Cuckoo's Egg") is likely to happen to you.  No matter what machine
they crack into, it is just as tough for them to crack into any of your
other machines as it was for them to crack into the first.  Yes, it does
require additional work on your part, but with good perl and rdist
scripts, combined with cron jobs, you should be able to reduce this
workload significantly.  Additionally, you really do get a lot more
security, not just the illusion of more security.

    If you want to talk to Mitch directly on this subject, so that he can
get into a more detailed discussion of the subject, his e-mail address is
"mitch@hq.af.mil".

My second question is: Do you really know what you would be letting
yourself into by trying to set up a proxy-ftp and proxy-telnet system?

Two vendors that I am aware of have done this in the past (although they
may or may not currently have this kind of set up), Sun Microsystems and
Digital Equipment Corporation.  Both had to write their own custom
proxy-ftp and proxy-telnet software, which they appear to have kept
proprietary.  I understand that there is some work going on in an IETF
about standardizing on this kind of thing, but I don't know how far along
they are.  Jon Postel might be able to update you, but I would guess that
he has so many RFC's that he is editing that he doesn't really have the
time to stay up-to-date on this stuff.

Mike (mo@messy.bellcore.com), later says (in
<9104251505.AA04390@bellcore.bellcore.com>):

MO> Another alternative is to install (for example) a Cisco gateway that
MO> allows incoming packets for telnet, ftp, etc to go to ONLY the gateway
MO> machine, but allows outgoing packets to the same ports from any machine
MO> to proceed unimpeded.

Wow!  I didn't know that gateways like the cisco were capable of this kind
of thing.  Could you elaborate a little more as to how you set up your
gateway to do this?

Please respond via e-mail.  I will summarize and re-post, if appropriate.
 ________________________________________________________________________ 
| Brad Knowles                 | Internet: blknowle@frodo.jdssc.dca.mil  |
| System Administrator         |       or: blknowle@wis-cms.dca.mil      |
| DCA/JDSSC/JNSL               | Ph: (703) 693-5849  Fax: (703) 693-7329 |
| The Pentagon, Room BE685     |_________________________________________|
| Washington, D.C.  20301-7010 | my opinions != DCA's opinions or policy |
|______________________________|_________________________________________|

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 13:31:36 GMT
From:      pww@bnr.ca (Peter Whittaker)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

In article <1991Apr26.120948.26126@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes:
>I have received some mail on this suggestion. There are a few comments
>about gatewaying the mailing list to the new newsgroup, which I would be
>very happy to see. We should also consider where the new newsgroup should
>go. One person pointed out that it would be better if we did not limit it
>to protocols. How about comp.dcom.lans.management?
                                   ^^^^
At the risk of splitting too fine a hair, we won't be discussing LAN mgt
exclusively, will we?  How about comp.dcom.network.management (or some
such variance)?

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

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 14:58:51 GMT
From:      mo@MESSY.BELLCORE.COM
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...

See the Cisco documentation "Packet Filtering"

I was quite impressed myself when I heard about it.

	-Mike

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 15:35:24 GMT
From:      mark@alias.com (Mark Andrews)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

From NIC.DDN.MIL!tcp-ip-RELAY@utcsri Fri Apr 26 03:20:29 1991
Date: 26 Apr 91 05:15:36 GMT
From: usc!rpi!news-server.csri.toronto.edu!utgpu!watserv1!sunee!erick@apple.com  (Erick Engelke)
Organization: University of Waterloo
Subject: Re: Byte and bit order within packet headers
References: <9104241753.AA21589@dino.alias.com>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

Erick Engelke (usc!rpi!news-server.csri.toronto.edu!utgpu!watserv1!sunee!erick@apple.com) responds to my question:

>In article <9104241753.AA21589@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>>
>>I have a question concerning concering the byte and bit order of fields
>>within packet headers. Many of the RFCS (including RFC1060) state rules
>>about the byte (octet) order:
>>
>
>Much confusion stems from the fact that Intel processors store 
>bits in the following order
>
>  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
>  |07 06 05 04 03 02 01 00 | 15 14 13 12 11 10 09 08 |
 +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
>  |  first stored byte     |  second stored byte     |  etc.
>
>whereas network order is
>
>  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
>  |15 14 13 12 11 10 09 08 | 07 06 05 04 03 02 01 00 |
>  +--+--+--+--+--+--+--+---+---+--+--+--+--+--+--+---+
>
>so the bits and nybbles are already in network order, you simply need to
>organize quantities larger than a byte, namely 16 and 32 bit values.
>
>The intel code should have
>    unsigned  ip_h : 4;
>    unsigned  ip_v : 4;
>
>I hope this clears it up a bit.
>
>Erick

Fine, this a good example. In my specific example, I was looking how BSD
code interprets the version number and  header length of an IP packet
header:

    struct ip {
    #if BYTE_ORDER == LITTLE_ENDIAN
            u_char  ip_hl:4,                /* header length */
                    ip_v:4;                 /* version */
    #endif
    #if BYTE_ORDER == BIG_ENDIAN
            u_char  ip_v:4,                 /* version */
                    ip_hl:4;                /* header length */
    #endif

Unfortunately, the bit order is machine and compiler dependent. On little
endian machines, the bit fields are assigned least significant bit first
(right to left), resulting in:

   MSB                     LSB
    +--+--+--+--+--+--+--+--+
    |   ip_v    |   ip_hl   |
    +--+--+--+--+--+--+--+--+
     07 06 05 04 03 02 01 00

On big endian machines, the bit fields are also assigned least significant
bit first, but this time the bit fields are assigned left to right:

   LSB                     MSB
    +--+--+--+--+--+--+--+--+
    |   ip_v    |   ip_hl   |
    +--+--+--+--+--+--+--+--+
     00 01 02 03 04 05 06 07


In which order are the bits transmitted such that the integrity of the
data is not compromised, independent of the endian order.

For example, if a big endian machine is talking to a little endian machine,
in what order are the bits transmitted so that the ip_v and ip_hl fields
from the big endian machine are interpreted properly on the little endian
machine.

In the case of the ip_v field, bits 0-3 of the big endian byte must be
transmitted to bits 4-7 of the little endian byte!

Thanks for any information,

Mark

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 17:05:38 GMT
From:      pkrause@triton.unm.edu (Paul Krause CIRT)
To:        comp.protocols.tcp-ip
Subject:   IP # Management & Assignment

The university has a class B network with several thousand users. I am looking
for advice in three general areas.  This seemed like the most appropriate
group to ask, but correct me if I am wrong.

1.  We need automated or semi automated procedures for keeping track of IP
    numbers.  We have a data base, but since it depends on manual reporting
    to track changes, it goes out of date quickly.

2.  How do network support people deal with issues of privacy, security,
    etc. when working in dorm rooms.  For example, something is reported
    stolen after a repair call.

3.  The university plans to lease fully wired and equiped space in a 
    research park.  How do IP #'s get assigned to these non-university
    people?

Thanks for the help.

Paul Krause

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 17:28:41 GMT
From:      andrew@jhereg.osa.com (Andrew C. Esh)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

In article <1991Apr26.133136.2172@bwdls61.bnr.ca> pww@bnr.ca (Peter Whittaker) writes:
>In article <1991Apr26.120948.26126@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes:
>>to protocols. How about comp.dcom.lans.management?
>                                   ^^^^
>At the risk of splitting too fine a hair, we won't be discussing LAN mgt
>exclusively, will we?  How about comp.dcom.network.management (or some
>such variance)?
>
>--
>Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
>pww@bnr.ca           [       DSA's'R'Us!        ]   Bell Northern Research 
>Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
>FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7

The only reason I suggested the lans group is because it already exists.
WANs, and anything else, if managable by SNMP or any other protocol,
should be included. What ever will get the discussion going. :-)
-- 
Andrew C. Esh			andrew@osa.com
Open Systems Architects, Inc.
Mpls, MN 55416-1528		Punch down, turn around, do a little crimpin'
(612) 525-0000			Punch down, turn around, plug it in and go ...

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 17:33:46 GMT
From:      simon@liasun2.epfl.ch (Simon Leinen)
To:        comp.protocols.tcp-ip
Subject:   Re: Is SunOS4.1 & above supports IPPROTO_RAW & IP_HDRINCL?

Traceroute works without kernel modification on this Sun (4/65) which
is running SunOS 4.1.
-- 
Simon.

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 18:36:23 GMT
From:      sivesh@nevada.edu (SIVESH PRADHAAN)
To:        comp.protocols.tcp-ip
Subject:   Re: help! problem making IBM RISC-6000 work with AIX/TCP-IP

Hi,

	I had the same exact problem. I am not sure which of the following
things solved it :-).

	1. Check to see if you have chosen the right Ethernet Adapter. You
	   can do this through smit-devices-comm-ethernet adapter-adapter-
	   change/show. If you have thick net you should have en0 configured
	   and have dix as the adapter/ for thin net ent0 and bnc.

	2. Try rebooting the system.

	3. If you have a domainserver then check to see if resolv.conf file in
	   /etc is ok.

	Hope this solves your problem.

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 19:02:44 GMT
From:      sivesh@nevada.edu (SIVESH PRADHAAN)
To:        comp.protocols.tcp-ip
Subject:   KA9Q Source - FTP Site for

Hi,

	I am trying to get source for KA9Q (router) software to run on a
unix machine (convex/ibm rs/6000). Can anyone tell me where to look up
for the source code?

	Help !!!

	Thanks in advance.

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 19:16:12 GMT
From:      dem@cbnewsc.att.com (David E. Martin)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

In article <1991Apr26.120948.26126@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes:
> How about comp.dcom.lans.management?

Many of the protocols are for WAN's, MAN's, and LAN's.  How about
comp.dcom.netmanagement?

David Martin
AT&T Bell Laboratories, Naperville, IL
dem@iexist.att.com

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 19:31:59 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

In article <9104241753.AA21589@dino.alias.com> mandrews@alias.com (Mark Andrews) writes:
>... what about the
>bit order? It is still little-endian (bits are numbered right to left instead
>of left to right)! What order is are the bits transmitted in?

Fortunately, this is not an issue, because the data is fed to the hardware
as bytes (usually) and consequently it is the hardware's business to get
the bit order right on both ends.  The usual practice is to send lsb first,
but this is completely invisible to the software.

There is sometimes confusion about how the bits are *numbered*, but that
is a separate issue.  The high-order bit is always the high-order bit and
is always in the same place, regardless of whether the manual calls it
bit 7 or bit 0.

>This is further complicated by the following code fragment from
>/usr/include/netinet/ip.h:

Here we have a different issue.  The reason why ip.h is #if'd is that C
does not define the order of bitfields within a word, and it is both
machine-specific and compiler-specific.  Using bitfields for this was
dumb, actually; convincing them to match an externally-defined storage
layout can be tricky.

>Now according to the 4.3BSD C Reference Manual by B. Kernighan, the addresses
>of a structure increase as the declarations are read left to right...

Bitfields do not have addresses and that rule does not apply to them.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 19:46:11 GMT
From:      lap@dvncnms.Devoncnms.Unisys.COM (Lisa A. Phifer)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

In article <1991Apr24.140256.23754@jhereg.osa.com>, andrew@jhereg.osa.com (Andrew C. Esh) writes:
> Lately I have been reviewing SNMP managers and agents. I have also found
> the related RFCs. What I have not found is the newsgroup where SNMP and
> similar net management protocols are discussed. Do we need to create one?

Yes!  We have a local newsgroup here into which we dump anything
coming in off the snmp or oim mail exploder.  It would be great
to have a public newsgroup of the same sort with wider distribution.

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 20:04:06 GMT
From:      zweig@cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

My solution is never to use bit-fields when decoding packets. Just mask things
with 0x0F and 0xF0 and let the compiler optimize it.

The problem is not a network thing but a C language thing. Quoting from K&R
(2nd ed.):

	Almost everything about [bit] fields is implementation-dependent.
	... Fields are assign left to right on some machines and right to
	left on others.

The term machine here is misleading -- it is actually the implementation of C
on a particular machine that decides what to do with bit fields. One could
imagine two different compilers on the same architecture that did it
differently.

So just get a compiler with inline expansion and a decent optimizer and define
functions to access fields inside of headers.

And this htonl() ntohs() is a poor solution to the problem. It is too easy to
forget what byte-order a particular int currently is in. In my TCP/IP
implementation (in C++) I have a class that hides all that junk. I just assign
values into number-holders according to what byte order they are in, and
retrieve the values in the appropriate order for manipulation.  This makes
errors such as calling htons() twice never happen....

-ynnhoJ redro-etyB

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 22:30:29 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Does FTP Define A C Level Protocol?

Does the FTP definition include a C level protocol?  I assume that
it does, but I'd like additional information.  I need to build
a user-friendly file transfer front-end to part of an application,
but I would also like to make use of the underlying FTP protocol
to do the file transfer over TCP.  How is the calling interface
FTP currently defined, and where can I read about this definition?

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

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      26 Apr 91 22:39:22 GMT
From:      Will@cup.portal.com (Will E Estes)
To:        comp.protocols.tcp-ip
Subject:   Need Access To A 3270 Host Over Internet For Demo

I am going to be demonstrating the virtues of TCP to a skeptical
SNA crowd in the near future, and I'm wondering if some kind soul
out there would be willing to give me temporary access to a guest
account on a VM/CMS host that is Internet-connected at a speed of
at least 56kbps.  I'm going to be using dialup IP for the demo,
perhaps using the Telebit multiplexing IP router, so my throughput
in some scenarios will exceed 9600 bps and I want to make sure
that there are no bottlenecks that will prevent me from showing
off that throughput while connected to a remote 3270 host.  If someone
is willing to give me access to a barebones PROFS account for a week
or so, please send me some mail.  

Also, if anyone has suggestions for things to show off during the demo,
I'm all ears.  I'm hoping (praying) that FTP Software's Windows
product will handle multiple IP connections via PPP so that I can
be doing multiple Telnet sessions, an FTP session, and mail all at
the same time.  I want to see some eyes bulging during this demo :)

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

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 01:57:57 GMT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Packet driver over NDIS

In article <27269@hydra.gatech.EDU>, ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:
> I've been experimenting lately with the packet->NDIS converter from 
> FTP Software.  I cannot seem to get the converter bound to the NDIS
> driver; netbind.exe just hangs my machine.  One machine can load the
> modules in and initialize the ethernet card, but no binding can take
> place.   Another machine with a different (3Com 3c523) ethernet board
> cannot get initialized (using the elnkmc.dos file dated April 9 at
> FTP's site).   I would appreciate any pointers on putting the pieces
> together in the right order; I feel I'm extremely close to a solution.
> Has anyone successfully used this combination?
> -- 
> 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
===================
Eric,
	I'd suggest you try the next iteration of the dis_pkt routine, version
1.6, which can be found on my VMS VAX netlab.usu.edu 129.123.1.11 in
directory [anonymous.netwatch] as file  dis_pkt.asm (a uuencoded archive).
The top of the .asm file shows example config.sys and protocol.ini files.
	Joe D.

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 05:42:46 GMT
From:      sfalken@mondo.engin.umich.edu (Steve Falkenburg)
To:        comp.sys.mac.comm,comp.sys.mac.misc,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Even _Newer_ XferIt Mac FTP Client Available

Version 1.3.1 has just been released (I feel like I just
released System 6.0.0 yesterday...)

This one is finally compatible with VMS (yay!).  The delimiter
character must be set to nothing "" for VMS transfers to work.

Get Tree now works _much_ better.  It barely worked at all, I
found out today, and is now fixed.

Other fixes include support for continuation responses from
FTP servers (###-) and much better error handling and reporting
(even with notification manager).

As Bernie said, make sure you have a copy of MacTCP in your
Control Panels folder if you are running System 7!

As always, it's on mondo.engin.umich.edu anonymous ftp.
This will probably be the last minor update I announce,
as it's getting tiresome.  From now on, just check
mondo.engin.umich.edu to see if the version # has
changed.

-steve falkenburg (hoping to release fewer versions of XferIt/week)

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 12:34:33 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   SNMP Discussion Group

There is a mailing list snmp@nisc.nyser.net which is dedicated to the 
discussion of SNMP and its application.  It is fairly active, with a number
of well-known and highly competent people participating...

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714-6066	
----------------------------------------------------------------------
"Never underestimate the bandwidth of a station wagon load of magnetic
 tapes screaming down the interstate!"			

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 12:49:38 GMT
From:      schoff@uu.psi.com (Martin Schoffstall)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: Let's create comp.protocols.netmanagement

Since PSI is currently mastering the snmp mailing list on UUPSI we'll
be happy to gateway a SNMP subgroup between USENET and email.  Just
let us know if and when.

Marty
----------

>Yes!  We have a local newsgroup here into which we dump anything
>coming in off the snmp or oim mail exploder.  It would be great
>to have a public newsgroup of the same sort with wider distribution.

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 20:30:34 GMT
From:      bsimpson@VELA.ACS.OAKLAND.EDU (Bill Simpson)
To:        comp.protocols.tcp-ip
Subject:   Re: call for discussion of usenet newsgroup 'comp.protocols.ppp'.

Too complicated.  What about comp.protocols.serial, and gateway to/from
the ietf-ppp list?

Bill_Simpson@um.cc.umich.edu
    bsimpson@vela.acs.oakland.edu

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      27 Apr 91 23:45:35 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Does FTP Define A C Level Protocol?

In article <41713@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Does the FTP definition include a C level protocol?

The FTP definition defines the bytes on the wire, not at the C or user
level.  Although it's a non-trivial protocol, there is nothing stopping
you from implementing it however you wish.  RFC959 is the basic defining
document, although a look at RFC1123's FTP section is in order first.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 00:23:37 GMT
From:      brian@NAPA.TELEBIT.COM (Brian Lloyd)
To:        comp.protocols.tcp-ip
Subject:   call for discussion of usenet newsgroup 'comp.protocols.ppp'.

I am not sure that ietf-ppp should go away.  There needs to be a
place where implementors can go to talk where the S/N ratio remains
high.

Brian

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 07:31:21 GMT
From:      carson@darwin.ntu.edu.au
To:        comp.protocols.tcp-ip
Subject:   RE> KA9Q source Ftp Site

In article <1991Apr26.190244.1832@nevada.edu>, sivesh@nevada.edu (SIVESH PRADHAAN) writes:
> Hi,
> 
> 	I am trying to get source for KA9Q (router) software to run on a
> unix machine (convex/ibm rs/6000). Can anyone tell me where to look up
> for the source code?
> 
> 	Help !!!
> 
> 	Thanks in advance.

Try THUMPER.BELLCORE.COM and you may be in luck.
-- 


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

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 15:26:38 GMT
From:      emanuele@overlf.UUCP (Mark A. Emanuele)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q Source - FTP Site for

In article <1991Apr26.190244.1832@nevada.edu>, sivesh@nevada.edu (SIVESH PRADHAAN) writes:
> 	I am trying to get source for KA9Q (router) software to run on a
> unix machine (convex/ibm rs/6000). Can anyone tell me where to look up
> for the source code?



Try thumper.bellcore.com



-


-- 
Mark A. Emanuele
V.P. Engineering  Overleaf, Inc.
218 Summit Ave   Fords, NJ 08863
(908) 738-8486                           emanuele@overlf.UUCP

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 17:55:01 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

mark@alias.com (Mark Andrews) writes:

>Unfortunately, the bit order is machine and compiler dependent.

This is true, in a sense.

Bu this ...

>On little endian machines, the bit fields are assigned least significant bit
>first (right to left),
 
>On big endian machines, the bit fields are also assigned least significant
>bit first, but this time the bit fields are assigned left to right:

Is simply wrong, or perhaps inaccurate.  Except on those processors
that have "extract/insert bitfield" instructions, the order in which
bitfields are placed in a byte (or whatever) is purely compiler
dependant - on a little endian host you could assign bit fields either
way, on a big endian host you could assign bit fields either way.

Even with a host with bitfield instructions, the compiler could do
it either way (the bit numbers of the fields will be constant,
whether the compiler omits instructions to extract bits 0-3 or
4-7 when fetching the ip_v field is pretty much irrelevant to
anything - except the expectations of the author of the code).

The ifdef's in the BSD source are just a latent bug waiting to bite
someone who isn't very careful porting the code to a new compiler.
(It just happens to work out right on the compilers the code is
normally compiled with).

>In which order are the bits transmitted such that the integrity of the
>data is not compromised, independent of the endian order.

It depends entirely on the medium over which the data is being sent,
and only on that - on serial (point to point) wires, sync or async,
and on ethernet (ISO 8802/3) the least significant bit is sent
first, on rings the most significant bit is sent first, if you
happen to have an 8 bit parallel bus, then all the bits are sent
simultaneously..., but as long as all the hardware understands this
the most significant bit of a received byte will be the most
significant bit of the transmitted byte, so once the hardware is
designed & built correctly you never need to worry about this.

On the other hand, you do need to worry about the order of the bytes
wrt their interpretation as multi-byte objects (int's etc), and
thw way that the compiler lays out storage in structs, including bits
for bit fields.  Anyone attempting to use struct definitions to
represent network packet formats must have intimate knowledge of the
way the compiler works - and should the compiler decide to change
from one version to another, and the network code breaks because
of that, its a bug in the net code - not the compiler.

kre

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 18:53:27 GMT
From:      alan@CURTA.CC.COLUMBIA.EDU (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: Parallel routers running proxy-arp

To concur about proxy-arp.  SunOS and IBM VM TCP/IP arp implementations
are broken.  They never age out.  We had tried this set up.  Our fix on
the unix side is to have a cron job that runs every 5 minutes or so and
explicity flush the arp cache.
/a

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 21:22:23 GMT
From:      db@argon.Eng.Sun.COM (David Brownell)
To:        comp.protocols.tcp-ip
Subject:   Re: Request For Info On Dynamically Acquiring IP Addresses At Boot

> Can someone give me a reference to any research or commercial products
> that attempt to solve the problems of 1) allowing a PC or workstation
> to dynamically acquire an IP address at boot time, and 2) making it
> easier to install IP on a PC or workstation (i.e., an attempt to make
> things in general more dynamic so that each client doesn't have so
> much static information hard-coded into it at install time).

Well, the Sun386i is the first commercial product that I heard of that
did this.  That was back in 1988; I think they're off the price list
now.  A design requirement for the product was that, on cooperating
networks, unsophisticated users be able to unbox the workstation and be
reading their mail, on a new user account, 15 minutes after it was
physically cabled together ... and it worked!  Clearly, one of the big
parts of that process was setting up IP addressing and naming.  (Though
the marketing said otherwise, this part was independant of the rest.)

There were three phases.  First was characterizing the network to figure
out what kind of installation procedure was required.  (For those of you
that know the 386i, it wasn't an engineer that decided to require using
YP on all networks!!)  Second  (if dynamic installation was required) was
acquisition of a "transient" IP address.  These were unnamed, and were
liable to be reallocated after a longish time period; just what you get
if you pick an address manually, but guaranteed to be on the right subnet
and not otherwise in use.  The third step of dynamic installation was
persistent allocation of resources such as a hostname, configuration of
any diskless boot resources, and so on.

That process couldn't really be done without new protocols.  There are
lookup protocols, such as RARP/TFTP/BOOTPARAMS and BOOTP/TFTP, which
distribute configuration information that's already been manually set up,
but no standard protocols to reject installation or generate/select and
store configuration information.  (Such protocols might be used either
by an administrator with a GUI tool, or by a new workstation seeking to
install itself ... the difference could be purely what kind of policy the
site put in place.)  There is an IETF working group (DHCWG) to address some
of these problems, but I don't know their status.

It's sort of perplexing to me to see that nothing else along those lines
has become available.  I don't think the problem is really technical;
there are no unsolved problems beyond protocols getting defined and used.
I suspect that IP networking just hasn't (yet?) reached the kind of mass
market where real simplicity of operation is obligatory.  For now, most
sites seem to be happy with solutions requiring administrative involvment
on every aspect of network (re)configuration.

- Dave Brownell

--
"The traffic started getting rough; the chicken had to cross.  If not
for the plumage of its peerless tail the chicken would be lost.  The
chicken would be lost!" -- Gilligan

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      28 Apr 91 23:30:56 GMT
From:      chip@osh3.OSHA.GOV (Chip Yamasaki)
To:        comp.protocols.tcp-ip
Subject:   IP explanation please

I would like to have IP access to some of the many "anon FTP" sites, but
I don't have TCP/IP.  I suppose I could get SCO's TCP/IP, but how
exactly do you connect.  I thought the TCP inferred Ethernet.

I know there is such a thing as SL/IP, and PPP, but if you have those
who do you connect to and how?

Do I need an Internet address to use even SL/IP?

Can I get everything I need in the BSD sources on UUNET?

Can the BSD sources be ported to SCO Unix Sys V 3.2.2?

What questions am I forgetting to ask?

Why is there air?

Thanks!
-- 
--
Charles "Chip" Yamasaki
chip@oshcomm.osha.gov

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 00:02:18 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Does FTP Define A C Level Protocol?

The FTP specification defines only the protocol. In general, Internet
protocol specifications define the actual protocol, and sometimes list
requirements of an API for the protocol, but don't actually specify
the API. Most FTP implementations jumble together the actual protocol
implementation, the API to FTP (if there's even one) and the interface
to the OS.

The only specific API for FTP that I know of is for an FTP library
that I wrote for FTP Software a long time back. It's specified in the
documentation for FTP (Software)'s dev kit, which includes the
library. I think you can buy the dev kit manuals separately if you
want. I know FTP Software considers the API to be non-proprietary.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 00:33:08 GMT
From:      romkey@ASYLUM.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   re: Byte and bit order within packet headers

It's true. In the portable UDP stack which Epilogue sells, I
originally had defined the header length and IP version numbers at
bitfields but finally took them out because we found that that
bitfield ordering was really compiler dependent instead of processor
dependent. I replaced our bitfields with appropriate masking
operations to avoid the problem.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	voice/fax: 415 594-1141

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 08:10:37 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   The ftp site of the Sun TI-RPC?


Hi netlanders,
        Recently, Sun has annnounced the availablity of Trasnport-Independent
RPC (TI-RPC) in Internet. Could somebosdy
 tell me where is the available
ftp sites?
        Thanks a lot.

- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 13:01:33 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   ypbind proxy


can one run a ypbind 'proxy' on net 1 that replies on behalf of a NIS
server on net 2? (dont ask why:-)

thanks

jon 

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 13:15:16 GMT
From:      shari@GATEWAY.MITRE.ORG (Shari Galitzer)
To:        comp.protocols.tcp-ip
Subject:   multiple IP addresses

I am trying to get multiple GATEDs to run
on a single host to simulate multiple routers
on a single host.

My initial problem is getting multiple IP addresses 
on a single ethernet (qe0) port.  I've tried ifconfiging
2 times with different addresses and the host locks up.

Does anybody know if a single ethernet port can have
two addresses in the same family?  If so, how or if not,
at what point is the capability prohibited?

In addition, has anyone tried running multiple GATEDs
and is able to provide some helpful insight.

Thank you for your attention and I appreciate any
help you are able to provide.

Shari Galitzer
MITRE Corp.

shari@gateway.mitre.org
(703) 883-6229

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 13:35:09 GMT
From:      kovar@biostat.harvard.edu (David C. Kovar)
To:        comp.protocols.tcp-ip
Subject:   Product announcement - a serious problem?


  Someone at Harvard brought this to my attention. Offhand, it seems like
a good way to beat the Internet to death in one move. Like flushing all
the toilets at DEC and watching the plumbing explode. I don't know
exactly how they implemented it, but the parallel approach and the decending
search of a tree approach sounds like they're going to start at the top of
the domain name servers and work they're way down, hitting each server
below a node with a new request. Anyone want to guess at how many nodes
one request would touch, and how much traffic would be generated?

  There also might be a legal side to this, but that's a lot more fuzzy.
I suspect that the research networks would not take kindly to someone
making money by loading down their links, but then again, these guys
are just selling a tool, not a network based service.

-David Kovar

------- Forwarded Message

Subject: 	NetFind, whitepages service for the Internet
From: 		xcaret@csn.org (Xcaret Research)
Newsgroups: 	comp.newprod
Organization: 	Colorado SuperNet Inc.

NetFind, from Xcaret Research, Inc., is a whitepages service for the 
Internet.  Given a person's name and location or organization, NetFind 
returns their Internet electronic mail (email) address.  NetFind 
differs from other whitepages facilities by offering fast and up to 
date service from your own machine.  

NetFind runs from the UNIX command line.  To find John Smith at 
Bigstate University, you just type:

        % netfind smith bigstate

NetFind returns the email address.  Its that simple.

NetFind operates on a Sun3 or Sun4 computer running SunOS 4.0 or 
later with access to the Internet.  Uses only 4MB of disk space.  
Since NetFind runs from the command line, you can use NetFind from 
any remote terminal, Mac or PC that accesses a Sun.

NetFind uses a unique method to actively search the Internet for 
your target.  It does not attempt to keep a database of users across 
the Internet; that would be quite large and constantly out of date.  
Instead, NetFind uses the natural database of the Internet itself: it 
sends multiple parallel requests across the Internet  to machines 
where it suspects the target may reside.  NetFind queries these 
machines for the name you provide as well as for leads on other 
machines nearby.  NetFind in turn searches these discovered 
machines and so on down the hierarchy until the address is found or 
there are no more machines to search.  The whole process is 
surprisingly fast, because NetFind sends searches out in parallel.  

NetFind uses a reference file for domains and a location index.  They 
take up about 3MB.  The first file is a partial list of Internet 
domains.  NetFind uses this list to prime its search.  The list is by 
no means all of the computers it can search.  Rather, it will use the 
information obtained from querying those machines to further its 
search.

The second file is an index of location words.  When you say:

                % netfind smith bigstate

NetFind looks in this index for "bigstate".  Then it resolves the 
information it sees with specific machines in the domain file and 
begins its search.  So, the whole process goes from location word to 
index to domain file and then in parallel searches throughout the 
Internet.

The name can be either a last name or a username. The location 
words are generally geographical or organizational (i.e., switzerland 
or sun) and can be combined to narrow the search  
(i.e., netfind smith bigstate university ).

NetFind is sold with a single user license for $159.  Please call for
educational discounts and site licensing.   You may order by phone, e-
mail or postal mail (include P.O. number, check or credit card).
Please specify your domain name, Sun3 or Sun4, and  the format
(electronic, floppy, 60MB, or 150MB tape).  We don't charge for
floppies, but cartridge tapes are an additional $30 to cover cost.

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


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

-David C. Kovar
	Consultant				ARPA: kovar@biostat.harvard.edu
	Eclectic Associates			BITNET: corwin@harvarda.bitnet
	Ma Bell: 617-643-3373			MacNET: DKovar

         "It is easier to get forgiveness than permission."

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 13:50:26 GMT
From:      bob@MORNINGSTAR.COM (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Does FTP Define A C Level Protocol?


   From: Will@cup.portal.com (Will E Estes)
   Date: 26 Apr 91 22:30:29 GMT

   Does the FTP definition include a C level protocol?  ... How is the
   calling interface FTP currently defined,

The FTP protocol spec describes octets flying over a TCP connection,
which is routed by IP.  It doesn't care what language you use, nor
specifically how you persuade the octets to fly.

   and where can I read about this definition?

FTP is defined in RFC959.  It is clarified and somewhat expanded in
RFC1123 section 4, which also specifies a user interface but not a
programmer's interface.

Your operating system may provide library calls to manipulate TCP
sockets, which may give you what you want.  Look in the documentation
provided by your software vendor.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 16:40:41 GMT
From:      rpc@hpcndaw.CND.HP.COM (Ron Poppen-Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: SCO's TCP/IP:  "out of streams resources"

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

Run the "crash" command. This lets you look at a bunch of system information,
run the "strstat" command under crash. This will tell you the number of times
each size message block has been allocated and has failed an allocation request.
Then edit /etc/conf/cf.d/stune (or run the /etc/conf/cf.d/configure comand)
to up the number of steams message blocks for the size(s) that crash
said failed.

Hope this helps.


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

Ron Poppen-Chambers
rpc@hpcnd.cnd.hp.com

Advice is like most things that are free, you get what you pay for. (me)

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 16:58:40 GMT
From:      rpc@hpcndaw.CND.HP.COM (Ron Poppen-Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP UDP port

> 
>   In the RFC 1157 section 4 "Protocol Specification", it
> states "A protocol entity receives messages at UDP port
> 161 on the host ....".
> 
> Here are the questions:
> 
> (1) Does the statement implies that a Network management
>     station must receive SNMP message (other than traps)
>     on UDP port 161?
>    (1.1) If (1) is yes, then NMS and the agent cannot
>          both reside on the hosts (e.g.workstation)?
> 

No to (1). The management station should only receive traps and responses
to requests. This can be done on a port other than 161.

> (2) Is it a protocol violation to receive messages on any
>     other UDP ports (other than traps on 162)?

I believe that an object manager/agent would be in violation if it did this.


> (3) In practice, could we assign any unreserved port to
>     the source port of the outgoing get_request message
>     (with destination port 161)?  Should we expect to receive
>     a get_response on the same port that we assigned to
>     the outgoing get_request? In this case is the statement
>     quoted from RFC 1157 violated?

I believe this is the prefered method. The response should be sent to the
port that sent the request, but I don't believe that this is explictly 
stated in the RFC.


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

Ron Poppen-Chambers
rpc@hpcnd.cnd.hp.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 17:01:26 GMT
From:      lear@turbo.bio.net (Eliot)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...

Host security is nice, and should be practiced.  Try implementing it
on 20,000 Macs.
-- 
Eliot Lear
[lear@turbo.bio.net]

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 18:22:34 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: yet more slide locks.

In article <9104241431.AA08259@ww.msc.edu> djl@MSC.EDU (Dennis Longar) writes:
>->Speaking of slide lock connectors 

(...)

My favorite solution is getting plastic D-15 insulation displacement
connectors from INMAC (or some such place) and a roll of 15-conductor 
ribbon cable. Cut a 3-4'' piece of cable, attach a male and a female
IDC connector on either end, and put it between the drop cable and 
the AUI connector. The friction from the plastic shell is enough to
keep the connectors in place, provided the drop cable is not hanging
from its connector. Keep the ribbon cable as short as possible.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 18:43:00 GMT
From:      jchen@flash.bellcore.com (Jason Chen)
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking SNMP Agent Tests

In article <810018@hpcndm.CND.HP.COM> wil@hpcndm.CND.HP.COM (Wilson E Brumley) writes:
>Does any know where I might get a test (or set of tests) for an SNMP
>agent?  Have any of the standards groups developed such tests?

There is an article in Network World (4/22/91) on this topic. This
article provides test results of SNMP agent implementations on bridges.
An quite interesting article.

I called the author's company for more information. They said that
they were also doing similar tests for routers. Reports would be
available in September, and cost about $3k a piece.


C. Jason Chen 
jchen@ctt.bellcore.com

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 19:45:09 GMT
From:      nreadwin@micrognosis.co.uk (Neil Readwin)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers


In article <9104252242.AA28673@taipan.coral.com>, greene@coral.com
(Jeremy Greene) writes:
|> The bottom line is that you only have to worry about bit order if
|> you're wokring at the MAC layer.

Or reading IEEE documents that specify everything in a counter-intuitive
bit ordering :-\

 Phone: +44 71 528 8282  E-mail: nreadwin@micrognosis.co.uk
 Quote: Everything is a cause for sorrow that my mind or body has made

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 20:55:08 GMT
From:      G.Eustace@massey.ac.nz (Glen Eustace)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...

Our solution to the host security situation would involve 2 major
components.  1 Our intended firewall machine, and 2 our Cisco router.
 The Cisco can be setup to only allow certain kinds of IP connections
to and/or from hosts that match specific conditions.

Our intention had been to provide all of our other hosts with a
version of telnet and ftp etc. that connected internally to the
firewall machine and then had it connect to the outside world via the
cisco.  As has already been posted, the problem is the software.  We
need a client front end for the various utilities, telnet, ftp etc.
and a server that could run on the firewall machine.

e.g.

     Client ------------> Firewall Host -------> Cisco -----> Internet

The Cisco would be setup to only allow outgoing telnet and ftp from
the Firewall Host.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Software Manager | EMail: G.Eustace@massey.ac.nz
 Computer Centre,  Massey University,  Palmerston North,  New Zealand
Phone: +64 63 69099 x7440, Fax: +64 63 505 607,       Timezone: GMT-12

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 20:55:29 GMT
From:      blu@millipore.com (Brian Utterback)
To:        comp.protocols.tcp-ip
Subject:   Need ethernet address to Vendor mapping.

Is there a reasonably complete list of the ethernet address blocks assigned 
to vendors?  I have a list that is somewhat out of date and only has about
half of the ethernet addresses observable on our internal network.

If there is no such archive, then perhaps some kind soul can identify the
following ethernet blocks for me:

00:00:81
00:80:d3
01:00:81
08:00:01
09:00:2b
09:00:65
09:00:77
09:00:07
09:00:09
ab:00:00
ab:00:04
-- 
Brian Utterback, Millipore Corporation, 75G Wiggins Ave., Bedford Ma. 01730
Work:617-275-9200x8245, Home:603-891-2536
INTERNET:: blu@millipore.millipore.com
UUCP:: {samsung,cg-atla,merk,wang,bu-tyng}!millipore!blu

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 20:59:19 GMT
From:      droms@SOL.BUCKNELL.EDU (Ralph E. Droms)
To:        comp.protocols.tcp-ip
Subject:   Re: Product announcement - a serious problem?

Xcaret does not depend solely on a descending tree search of DNS; it
uses a collection of heuristics to determine where to start searching
and then may elect to extend its search through DNS.

The work on which Xcaret is based is described in:

Michael Schwartz and Panagiotis G. Tsirigotis, "Experience with a
Semantically Cognizant Internet White Pages Directory Tool", Journal
of Internetworking: Research and Experience 2, 1 (March, 1991).

- Ralph Droms                 Computer Science Department
  droms@bucknell.edu          323 Dana Engineering
                              Bucknell University
  (717) 524-1145              Lewisburg, PA 17837

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 22:35:47 GMT
From:      lance@motcsd.csd.mot.com (lance.norskog)
To:        comp.protocols.tcp-ip
Subject:   Re: Is the DNS "working"?

This thread reminds me of an idea I head awhile back: a DNS MIB.
You ask a particular host, "make this DNS request via your normal method,
and send me back the results".  The point being, that every morning at
3AM you can do a spot check on all your hosts and make sure that they
can see their local servers, their main servers, and can get out on
the internet.  SNMP is the natural avenue for doing this check.

Lance Norskog

Ever notice that UDP is only used on the Internet for infrastructure?
Except for NFS, which should use TCP anyway?

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      29 Apr 91 22:40:35 GMT
From:      lance@motcsd.csd.mot.com (lance.norskog)
To:        comp.protocols.tcp-ip
Subject:   Re: Byte and bit order within packet headers

mark@alias.com (Mark Andrews) writes:

>I have a question concerning concering the byte and bit order of fields
>within packet headers. Many of the RFCS (including RFC1060) state rules
>about the byte (octet) order:
> [ use of C bit fields elided ]

The C programming language is missing a lot of useful features;
paradoxically, bit fields should never have been added.  In
particular, they should not be used for expressing the movement
of binary data between machines.  BSD TCP/IP shouldn't have used
bit fields to begin with, and should be rewritten to get rid of
them.  Sorry, I can't volunteer.  You should quit trying to 
use them, and rewrite your code to remove them.

Lance Norskog

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 01:06:39 GMT
From:      ron@Eyring.COM (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

In article <1991Apr23.172533.20781@athena.mit.edu> jstahlhu@athena.mit.edu (Julie Kozaczka Stahlhut) writes:

>Who invented those slide latches, anyway?  I'd like to meet this person,
>maybe shake his or her throat ..... :-(

His name is Rich Seifert.  He wrote an article for the January 1991 issue
of "Byte" called "Ethernet: Ten Years After".  In the article he discusses
what he and the other members of the original Ethernet design group
would change if they could do it over again.  He says "Personally, I would
have saved every Ethernet user a lot of grief by not specifying the dreaded
slide-latch connector... We really had good intentions.  I was fed up
with the RS-232C connectors that fell off because the tiny screw driver
necessary to tighten them down was never handy.  I just didn't realize
that the side latch was so flimsy and unreliable until it was too late.
Ethernet installers around the world must curse me every day."

Now you know the name to curse :^)

You can e-curse him at seifert@asylum.sf.ca.us
-- 
Ron Holt	ron@Eyring.COM  uunet!lanai!ron
Eyring Inc.	+1 801-375-2434 x434

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 01:39:28 GMT
From:      heimlich@watson.ibm.com (Steve Heimlich)
To:        comp.protocols.tcp-ip
Subject:   Re: Product announcement - a serious problem?

A description of this product seems to appear in the March 91 issue of
Internetworking Research and Experience, pp 23-50.  The article is
"Experience with a Semantically Cognizant Internet White Pages Directory
Tool," Michael F. Schwartz and Panagiotis G. Tsirigotis (U. of Colorado
at Boulder).  I believe this paper describes what was announced.

Steve

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 13:21:34 GMT
From:      tom@magnus.acs.ohio-state.edu (Tom Easterday)
To:        comp.protocols.tcp-ip
Subject:   Re: Setting up a Firewall system, proxy-ftp and proxy-telnet, ...

In article <1991Apr29.205508.23094@massey.ac.nz> G.Eustace@massey.ac.nz (Glen Eustace) writes:
>...stuff deleted... 
>Our intention had been to provide all of our other hosts with a
>version of telnet and ftp etc. that connected internally to the
>firewall machine and then had it connect to the outside world via the
>cisco.  As has already been posted, the problem is the software.  We
>need a client front end for the various utilities, telnet, ftp etc.
>and a server that could run on the firewall machine.
>
AT&T uses such a system to connect their corporate net to the internet.
They have a machine that runs a proxy telnet, ftp and also does mail.
They have not released the code that I know of, but then I have never asked.  

It works reasonably well from what I have seen.  I am working on some 
network statistics stuff with AT&T folks in NJ and they pick up data every
day from a machine on the local campus here through the firewall machine.
I don't know if they have ported the proxy client to every type of machine
internal to AT&T (like Mac's for instance) but I have seen it work from Suns.

You could try the following contact:

@whois att.com
AT&T Bell Laboratories (ATT-DOM)
   6200 East Broad Street
   Columbus, OH 43213

   Domain Name: ATT.COM

   Technical Contact, Zone Contact:
      Judge, Joseph  (JTJ11)  Joseph.T.Judge@ATT.COM
      (614) 860-7119
 

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 13:44:00 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: An informal survey [slide-locks]

In article <1991Apr30.010639.1288@Eyring.COM>, ron@Eyring.COM (Ron Holt) writes:
> His name is Rich Seifert. ....  I was fed up
> with the RS-232C connectors that fell off because the tiny screw driver
> necessary to tighten them down was never handy.

Amen!  While it's now obvious to everyone that the slide latch doesn't work
well, I have the suspicion that many of its critics haven't used RS-232
very much.  For those of us who've fought with missing screwdrivers,
inconsistent use of male vs. female connectors, protruding nuts bumping
into each other, gender benders, strange and wondrous uses of RTS and CTS,
and disagreements about the True Meaning of DSR and CD, the Ethernet
spec is a marvel of consistency.  They were certainly an experiment worth
trying.

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 14:32:06 GMT
From:      arena@goethe.UUCP (mike arena)
To:        comp.protocols.tcp-ip,comp.unix.misc,comp.unix.admin
Subject:   Connecting to the Internet

I am tyring to find information on how to connect to the Internet.  I have
an application from the NIC for an Inetrnet address but they have no
information on HOW to do it.

I have information on how to connect to NearNet (?).  It will cost $7000/year
and $7450 initially for the hardware (9600 baud DDS leased line).
Admittedly, this will provide the services we want but it is expensive.

Are there other organizations that provide Internet access in the Boston area?
If so, are the charges comparable to the above?

Any information would be appreciated.

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 15:16:00 GMT
From:      LIANE%SBU.UFRGS.ANRS.BR@UICVM.UIC.EDU
To:        comp.protocols.tcp-ip
Subject:   Wolongong e-mail address

Does any one has the Wolongong e-mail. I would like to ask someone about TCP/IP
and NFS products line.
Thanks in advenace for any help.
Liane Tarouco
University Federal of Rio Grande do Sul
Porto Alegre - RS - Brazil

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 16:30:58 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip
Subject:   Looking dfor a book on SNMP ????????

Hi,

Can anyone point me towards a good book or parer on SNMP ?

thanks

John Bourke								 O-O
Systems Support,			<bourkej@ul.ie>			  | 
Information Technology Department,	Phone: +353 61 333644 x2008	# _ #
University Of Limerick, Ireland.	FAX:   +353 61 330316		 ###

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 17:24:18 GMT
From:      brad@opaque.UUCP (Bradley Yearwood)
To:        comp.protocols.tcp-ip
Subject:   Re: yet more slide locks.

From article <1991Apr29.182234.4726@cs.columbia.edu>, by ji@cs.columbia.edu (John Ioannidis):
> My favorite solution is getting plastic D-15 insulation displacement
> connectors from INMAC (or some such place) and a roll of 15-conductor 
> ribbon cable. ...

I've been using similar ribbon cable stubs for several months now.  They
have completely eliminated Ethernet cabling as a source of network problems
on our Sun servers.

Brad Yearwood   {uunet, pyramid}!optilink!brad              Petaluma, CA

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 17:34:39 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]


    You can e-curse him at seifert@asylum.sf.ca.us

He said he's sorry, and he can't go back in time and fix it, so I suggest
that flames be directed to /dev/null, or the IEEE/ISO.  They're the current
owner of the standard, and they seem quite willing to issue addendums long
after the initial standard came out...

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

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 18:21:09 GMT
From:      ron@lanai.UUCP (Ron Holt)
To:        comp.protocols.tcp-ip
Subject:   Re:  An informal survey [slide-locks]

James B. Van Bokkelen writes:
> 
>>     You can e-curse him at seifert@asylum.sf.ca.us
> 
> He said he's sorry, and he can't go back in time and fix it, so I suggest
> that flames be directed to /dev/null, or the IEEE/ISO.  They're the current
> owner of the standard, and they seem quite willing to issue addendums long
> after the initial standard came out...
> 
> James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
> FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Yes, I realize this.  Perhaps I should have added a smiley face after
the last line of my message.  I thought it was clear from my quote that
the problem is recognized and it's not something that can be changed now.
Byte magazine mentioned his email address for reference and so did I in
my message.  I think most people would realize it would be rather pointless
to flame anybody now about this issue.  My only reason for posting my
message was to share with others some interesting insights into Ethernet
from Seifert's article.

Ron Holt	ron@Eyring.COM  uunet!lanai!ron
Eyring Inc.	+1 801-375-2434 x434

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 18:28:51 GMT
From:      tester@cmcl2.nyu.edu (L Testerville)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Re: Telnet From Xterm To Host Is Dropped By Host Immediately


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

  Many thanks to:

  Bob Sutterfield	bob@morningstar.com
  Bob Williams		bobw@cac.washington.edu
  Ari Rabinowitz	ari@bear.com

  for their suggestions and advice.

   \\Lee
thx1138@nyu.edu

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 18:57:06 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Request For Info On Dynamically Acquiring IP Addresses At Boot


    Well, the Sun386i is the first commercial product that I heard of that
    did this.  That was back in 1988; I think they're off the price list
    now.  A design requirement for the product was that, on cooperating
    networks, unsophisticated users be able to unbox the workstation and be
    reading their mail, on a new user account, 15 minutes after it was
    physically cabled together ... and it worked!  ....

We own a single 386i, but not a 'co-operating' net, and never before or
since have we had such a vale of tears for the systems people.  If you limit
the scope of the problem, you can come up with an essentially proprietary
solution.  General solutions aren't so easy, as anyone who's ever installed
a MAC-layer bridge connecting two previously happy Appletalk user communities
can tell you.

    It's sort of perplexing to me to see that nothing else along those lines
    has become available.  I don't think the problem is really technical;
    there are no unsolved problems beyond protocols getting defined and used.
    I suspect that IP networking just hasn't (yet?) reached the kind of mass
    market where real simplicity of operation is obligatory.  For now, most
    sites seem to be happy with solutions requiring administrative involvment
    on every aspect of network (re)configuration.

There is lots of customer demand, but defining an interoperable, scalable
solution to Dynamic Host Configuration is still at least partly a research
issue (yes, I know of the broadcast name-claim schemes, but they don't
scale, and all-knowing servers have to be duplicated, and the duplicates
have to be kept in synchronization...).

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

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 19:23:36 GMT
From:      rauscher@remus.rutgers.edu (Rich Rauscher)
To:        comp.protocols.tcp-ip
Subject:   active tcp ports and process id's

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

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

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 19:39:07 GMT
From:      mock@watt.support.Corp.Sun.COM (Joseph Mocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Packet driver over NDIS


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

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


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

-- Joe
--
------------------------------------------------------------------------------
Joe Mocker//USAC//PC-NFS Support :: mock@Corp.Sun.COM :: Sun Microsystems Inc.

  :: there's still lofty dreams  ::  meager desires  ::  still sillyness ::  

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 19:56:52 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re: Thin wire or twisted pair?

Doug Rob (doug@psy.uwa.oz.au) writes:

"Just to give you an example. I heard of a firm that got 3 floors
of a new building in Perth wired up recently. Two thin wire segments
on each floor and thick wire segment between floors. No connectors
terminators, delni, desta etc because as yet the don't have a computer
system. The cost for this $A7,000.

They also had 8 pair, PDS (unshielded twisted pair) to 100 outlets
with rj45 connectors back to a distrib board put in at the
same time, cost $A48,000. To actually get a computer network
will need a 10baseT hub etc as you know.
Since they don't have a network yet I don't know that the final
cost of each scenario would be."

Although one might question the costs, let's also point out that the above
comparison is definitely apples and oranges.  Why?  
 Two thinwire segments = 60 machines, including the required bridge or
(*ugh*) repeaters. You probably meant 8-conductor, or 4 pair, times 100
gives 100 data *and* 100 phone outlets.  If you want, you can even make it
200 data outlets.

Cost of making it a network:
Thinwire: (2) bridges, plus 3 sets of terminators. And transceivers.
UTP     : Hub

Cost of installing machines 1-59:
Thinwire: Labor and material to cut, reterminate, and place the thinwire
 segment, plus network downtime.
UTP: 1/100th hub cost plus plugging a jumper into the wall.

Cost of installing machines 60+:
Thinwire: ???? {new bridge/repeater}, new cable, etc.
UTP: 1/100th hub cost plus plugging a jumper into the wall.

-----------
I believe thinwire can be cost effective in limited settings, but not in a
larger arena (unless you want to saddle your successor with the problems.)
Cheers,
-------------------------------------------------------------------------------
 Willis F. Marti		Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
 	---Not an official document of Texas A&M---

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 20:58:50 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   SEND et al in the SMTP mail spec


I was wondering, does anybody know what implementations of SMTP
support the following commands:
	SEND FROM:
	SOML FROM:
	SAML FROM:

I know that MRC's TOPS-20 Mailer does, and the ITS and WAITS mailers
do.  Are there any others?

Warner
-- 
Warner Losh		imp@Solbourne.COM
Does this mean we can't use your phone?

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      30 Apr 91 23:19:29 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron)
To:        comp.protocols.tcp-ip
Subject:   Re: SEND et al in the SMTP mail spec

In article <1991Apr30.205850.16457@solbourne.com>, imp@solbourne.com 
(Warner Losh) writes...
# 
#I was wondering, does anybody know what implementations of SMTP
#support the following commands:
#	SEND FROM:
#	SOML FROM:
#	SAML FROM:
# 
#I know that MRC's TOPS-20 Mailer does, and the ITS and WAITS mailers
#do.  Are there any others?

	TGV Inc.s MultiNet TCP/IP for VMS supports these.
	You can probably get more info from sales@tgv.com...
#-- 
#Warner Losh		imp@Solbourne.COM

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

END OF DOCUMENT