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