The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for November 1990 (380 messages, 202265 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/11.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 Nov 90 01:26:38 GMT
From:      netcom!cmilono@apple.com  (Carlo Milono)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP over X.25
I am involved in an overseas agreement where Intel-based UNIX platforms
will be used in a distributed RDBMS environment.  There is a domestic
X.25 network (GE) in place, with UUCP traffic and H/TPAD access to the
various hosts.  The problem is that the cost of hooking up the international
sites with private links to the X.25 (perhaps via X.75 gateways) is not
economically feasible.

My plan was to take advantage of the TCP/IP that is present in each of the
nodes and route it over X.25...this has been done and works just fine.

Since I cannot have private X.25 overseas, I was contemplating using SLIP
to dial *into* a PAD and hence, route the info...this would be FTP'ing
files only, perhaps bi-directionally; this would limit the initiator to
the dial-in site....

Has anyone done anything similar?  HELP!---


-- 
+--------------------------------------------------------------------------+
|                   Carlo Milono                                           |
|    Personal:    netcom!cmilono@apple.com   or   apple!netcom!cmilono     |
|"Sometimes I think the surest sign that intelligent life exists elsewhere |
| in the universe is that none of it has tried to contact us." B.Watterson |
+--------------------------------------------------------------------------+
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 08:08:14 GMT
From:      royce@scoraz.resp-sci.arizona.edu (Royce Robbins)
To:        comp.sys.mac.comm,comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   TCP/IP over AppleTalk for Apple IIgs????

Title says it all: Is there such a thing as a package that will let my 
Apple IIgs do TCP/IP over AppleTalk (like MacTCP + stuff) or even over
ethernet?

Any pointers would be appreciated.
					--Royce Robbins


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Royce Robbins                         INTERNET: royce@resp-sci.arizona.edu
Div Resp Sciences                          FAX: (602) 626-4884
UofArizona                               PHONE: (602) 626-5022
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 14:16:11 GMT
From:      eru!hagbard!sunic!dkuug!vaxc!vax87!dalk@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Printers for Ultrix
We want to connect our printers from a Ultrix machine through some
terminalservers using TCP/IP ( CS/200). But we do not know how to
do it. Can anyone help me - then please E-mail.
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 19:11:20 GMT
From:      usc!elroy.jpl.nasa.gov!jarthur!bridge2!api!gpz@ucsd.edu  (G. Paul Ziemba)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem with Xmodem and 3Com terminal server
BILLW@MATHOM.CISCO.COM (William Chops Westfield) writes:

>Even when transferring text files, XMODEM needs a clear 8-bit path to
>accomadate its block counts and checksum.  By definition, telnet is a
>7 bit protocol, and you must negotiate "binary" mode to get an 8-bit
>path.  The terminal server may be refusing binary mode negotiations,
>may just do binary incorrectly, or may just need configured differently.

Unfortunately, I did not read the original query, so I'm guessing that
the original poster (someone @z.nsf.gov) is trying to establish an 8-bit
path from a 3com terminal server. This can be done...the following settings
are needed:

fcf=n flow-control-from disabled
fct=n flow-control-to   disabled
bra=ig break-action	ignore
ecmc=d escape-cmd-char	disabled

depending on the comserver software version, you may also need to set

xb=on  transmit binary	enabled
lbra=l local-break-action listen (so you can break the connection locally)


If that doesn't answer the original question, well, then, never mind :-)

 ~!paul
--
Paul Ziemba  api!gpz  gpz@ESD.3com.com  408.764.5390   OS/2: just say no.

"How much char could a char star star if char star could star char?"
(quote stolen from mspercy@clemson.clemson.edu)
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 19:21:31 GMT
From:      agate!shelby!unixhub!slacvm!ago@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP-NFS Lan for Macs/PCs/Unix boxes - Opinions wanted

I'm currently planning a LAN for the Electronics Department
at the Stanford Linear Accelerator Center. The media is going
to be Ethernet, and the protocols will be TCP/IP and NFS.
As we have to support a vriety of machines, things start to
get hairy. The platforms to be supported in a first phase are
Macs, PCs, UNIX workstations, and Apple LaserWriters.

Now, how do you get all these bozos to talk to each other? I
suppose a lot of people had to deal with a similar problem,
so I don't want to reinvent the wheel. Although searching quite
intenseley, I wasn't able to find write-ups addressing the
different facets of the problem. As I suppose that this subject
interests a certain number of people, I describe the solutions
I'm thinking about, and would like to hear comments/suggestions/
caveats, etc. I will post a summary under comp.dcom.lans as soon
as a compilation is done. Of course, you can post your comments
also directly on the net if you think a larger amount of people
can directly take advantage of them.

   The number of machines on the net will be around 50-100, with
a majority being PCs. During the first phase, only one file server
(SparcStation) will be installed. The Macs will be running Pathway
NFS client from Wollongong, and the PCs PC-NFS (or maybe a similar
product from Wollongong or ftp software). On the Mac, TN3270 will
be used for remote mainframe logon; no product has been identified
yet on the PC side.

   Printing seems to be more of a problem. We'd like to attach the
printer(s) directly to the net, not to a server. As the interface on
the printer side is LocalTalk, a converter is needed. Moreover, the
PCs and Suns don't speak PAP (the Apple Printing Protocol), and some
of their output is non-PostScript. How to access the printer? One
solution seems to be the Cayman GatorBox running GatorPrint. With
the lpr feature of the NFS client packages, it should be possible
to access the printer(s) through the GatorBox. Only disadvantage:
LocalTalk cables have to be run to the printer(s). Another solution
seems to be to run a few software packages on the server (CAP,
Transript and UAB), but this looks much less straightforward and
prone to failure.

   Comments would be appreciated in the following areas:

- Do you see a problem with this scheme? Any better solutions?
- Has anybody used Wollongong's PathWay Client NFS for Mac? Experience?
- What about alternatives to PC-NFS? Has anybody used WIN/TCP for
  DOS, PathWay Client NFS for DOS (Wollongong), PC/TCP (ftp software),
  or similar packages?
- What about the coexistence of the packages with Windows 3.0?
- Printer access through these packages (+ GatorBox)?
- Recommendations for Ethernet cards for Mac and PC?
- Experience with the GatorBox and GatorPrint?

Well, I hope this starts some interesting discussions on the net.
I'm looking forward to hearing different opinions, so feel free
to contact me. Posting of a summary will be done as soon as
possible under comp.dcom.lans, as mentioned before.

                                    Romain C. Agostini
                              Stanford Linear Accelerator Center

Disclaimer: the views and opinions expressed in this document are
my own, and do not necessarily reflect those of SLAC or Stanford
University.
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 22:12:43 GMT
From:      rochester!rocksanne!sma@cu-arpa.cs.cornell.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Reliable Datagram ??? Protocols

We have been doing some work on a reliable multicast transport protocol,
the "Multicast Transport Protocol".  MTP (or Empty Pea) attempts to satisfy
two of the goals discussed recently - 1) fast, reliable multicasting at the
transport level, and 2) agreement on order and delivery of "messages" built
on top of the transport data.

The transport layer is a NAK-based protocol that utilizes the multicast
capability of the lower layers (e.g. IP and Ethernet).  It provides reliable
delivery of messages, which are uninterpreted sequences of bytes terminated
by a end-of-message marker.  The ordering and agreement protocol uses a
token-based scheme to grant sending rights to producers of messages, to
guarentee that a given message will either be accepted by all processes or
not accepted by any, and to guarentee that all processes agree on the order
in which the messages will be processed.

Alan Freier at Apple and Keith Marzullo at Cornell have written a technical
report on MTP available from Cornell.  Ask marzullo@cs.cornell.edu for
information on getting a copy.

Cheers,
    Susie Armstrong
    Xerox Webster Research Center
    armstrong.wbst128@xerox.com
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Nov 90 22:29:49 GMT
From:      agate!shelby!neon!jackson@ucbvax.Berkeley.EDU  (Robert D. Jackson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Source Code Search
I'm searching for vendors that sell TCP/IP source code.  I have found two:
Wollongong and Interactive Systems.  I've been able to experiment a little 
with binaries from Wollongong (AT&T 6386, Unix System V, Rel 3.2.1) and 
have gotten a few comments from others that have used it.  I have not been 
able to locate anyone that has had experience with the Interactive software.

If you have had experience with the TCP/IP software and/or support from
either of these vendors, good or bad, please drop me a line.

If you know of another place I should look for TCP/IP source code, please 
let me know.

Thanks in advance,

-- 
Bob Jackson
jackson@neon.stanford.edu
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 03:07:13 GMT
From:      munnari.oz.au!uniwa!aldetec!smenda@uunet.uu.net  (Greg Smenda)
To:        tcp-ip@nic.ddn.mil
Subject:   tcpip network problems

We are running a TCP/IP network that is displaying some funny characteristics.
The basic setup is  a motorola Delta 1147 system
connected to MVME147 processor board running pSOS+ real time operating system
and pNA (it's tcp-ip module).

The pNA side acts as a server, with sockets being created in SOCK_STREAM mode. 

Our delta machine is doing a blocked read on the opened socket, yet
after a burst of data has commenced, some reads are only partially completing -
i.e 200 bytes of a 500 byte packet is returned, and the remaining 300 bytes
must be 'mopped-up' in the next read. The real crunch is that our data 
transfer seems to grind to a halt, with mopup reads required on nearly every
unit of data that is transferred from the pSOS system. Also the time taken to
actually read a complete packet goes way down the gurgler when these mopup
reads are required. 

Running a similar data transfer between 2 delta machines results 
in similar problems, although the dreaded time-lag in mopping up doesn't 
appear to be present.

Typically, a burst of data may be 5000 514-byte packets, sent at a rate of
5-20 a second ... Degradation can been seen from as early as the 20th packet.
(The test between the 2 delta machines was transferring at a faster rate,
allowing for time-sharing etc)


I've tried using 'nettrace', which returns streams of information, most that 
does not concern the connection of interest. However, messages are rapidly
sent to the console while this program is running, giving the diagnostic
message  'if37x_rx: trace packet dropped - canput failed'. Some packets of
interest that nettrace does report concerning our link, have a TCP flag value
of RESET, where can I get info on what this means? Are there other utilities
that may assist a novice networker in monitoring a specific connection,
particularly being able to identify data that has arrived but not been read,
and reporting any 'out-of-the-ordinary' retries/errors in the data transfer
for that connection. (If not, what about information on structures,
routines that I could use to monitor the socket from a program ??)

-- 
__________________________________________________________________________
Greg Smenda           Internet :  smenda@aldetec.oz.au
                        ACSnet :  smenda@aldetec.oz
                        Voice  :  +61-9-4451888   0800 - 1730 WST
System Administrator           :  +61-9-3859521   otherwise
Aldetec Pty Ltd.  
        - Fishy fishy fishy fish, it would go where ever I did go -
__________________________________________________________________________
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Nov 90 08:36:23 EST
From:      BDK@UNB.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Configuring a Sun to use DNS
As it comes from the factory SunOS 4.1 requires the use of NIS in
order to use the DNS. When we complained to SUN they provided a
fix that they said would do the job. Since we were novices with SUNs at
the time we decided to stick with standard things rather than modify
the system. So contact your SUN technical support person.
Brian Kaye
University of New Brunswick

On  Fri, 2 Nov 90 05:47:31 GMT  Samuel Lam <sdd.hp.com!zaphod.mps.
ohio-state.edu!van-bc!skl@UCSD.EDU> writes:

> Could someone please tell me what is the easiest way to get a NIS-less
> Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name
> lookups?
>
> Adding a /etc/resolv.conf file didn't do it.  It just changed how
> nslookup behaves, but nothing else.
>
> Thanks in advance for any pointers.
>
> ....Sam
> --
> Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.
> ca!skl
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 05:47:31 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!skl@ucsd.edu  (Samuel Lam)
To:        tcp-ip@nic.ddn.mil
Subject:   Configuring a Sun to use DNS
Could someone please tell me what is the easiest way to get a NIS-less
Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name
lookups?

Adding a /etc/resolv.conf file didn't do it.  It just changed how
nslookup behaves, but nothing else.

Thanks in advance for any pointers.

...Sam
-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 13:41:42 GMT
From:      encore!mperlman@husc6.harvard.edu  (Mark Perlman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem with Xmodem and 3Com terminal server
In article <9010312149.AA07742@z.nsf.gov> mmorse@Z.NSF.GOV ("Michael H. Morse") writes:
>	...
>I suspect this has something to do with parity, since the ASCII
>characters transmitted by Xmodem, and received by the PC are
>identical.  Has anybody run into a similar problem? Any information on
>how telnet reacts when raw mode is selected would be appreciated.

Mike:

I had a similar problem with uucp through a CMC Terminal Server.  I had
written a "reverse telnet" program to set a permanent circuit from the
server to the host.  To make a long story short, I found out that
typically, telnet uses 7-bit mode, however, it is an option that is
negotiable.  It may be that Ultrix may default to 8-bit mode and the
3Com terminal server may default to 7-bit.  The 3Com TS may not support
8-bit mode?  I not sure about that.

Hope that helps.

+----------------------------------------------------------------------+
|                            Mark R. Perlman                           |
| Independent Consultant                          301-206-2016         |
| 14014 Oakpointe Dr.                             mperlman@encore.com  |
| Laurel, MD  20707                               uunet!gould!mperlman |
+----------------------------------------------------------------------+
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 01:09:37 PST (Sat)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        jackson@neon.stanford.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Source Code Search
A third vendor of TCP/IP source code is Epilogue Technology. We
announced a portable TCP product at Interop. Email me for more
information.

Many people use the Berkeley code as a start. It's an excellent
protocol engine; its main drawback is that it really really wants to
live inside a UNIX kernel. It often takes many man-months to port
properly. You can find it on uunet.uu.net for anonymous FTP.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Nov 90 17:41:45 PRT
From:      CHIS%PTEARN.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@NIC.DDN.MIL
Unsubcribe me !!!
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 19:26:12 GMT
From:      CHIS@PTEARN.BITNET
To:        comp.protocols.tcp-ip
Subject:   (none)

Unsubcribe me !!!

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 20:23:12 GMT
From:      attcan!telly!evan@uunet.uu.net  (Evan Leibovitch)
To:        tcp-ip@nic.ddn.mil
Subject:   Info needed on Beame & Whiteside TCP/IP & NFS
Title says it. I heard a consultant recommend this company to a client
and know little or nothing about them. Any comments or suggestions are
welcome. Please mail replies.


Thank you.
-- 
Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
evan@telly.on.ca / uunet!attcan!telly!evan / moderator, rec.arts.erotica
           ...quoth the Raven, "Eat My Shorts!" -- Bart
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 20:45:26 GMT
From:      usc!elroy.jpl.nasa.gov!aero!aerospace.aero.org@ucsd.edu  (Charles T. Wolverton)
To:        tcp-ip@nic.ddn.mil
Subject:   X.400 over TCP/IP
We would like to use an IP internetwork as an intermediary between
two OSI networks for the purpose of X.400 E-mail exchange. The
following kludge uses Wollongong products and appears
(conceptually) to work:

                      -------      -------
                      | MHS |      | MHS |
                      | --- |      | --- |
-------               | ULS |      | ULS |               -------
|X400 |   ---------   |w/RFC|      |w/RFC|   ---------   |X400 |
|MTAs |   |  TSB  |   |1006 |      |1006 |   |  TSB  |   |MTAs |
| ON  |   |-------|   |-----|      |-----|   |-------|   | ON  |
| TP4 |   |LLS|TCP|   | TCP |      | TCP |   |TCP|LLS|   | TP4 |
-------   ---------   -------      -------   ---------   -------
  +        +    +        +            +        +    +       +
  +        +    +        +            +        +    +       +
++++++++++++    ++++++++++            ++++++++++    ++++++++++++
   OSI #1       TCP/IP #1+            +TCP/IP #2       OSI #2
                         +            +
                         ++++++++++++++
                         TCP/IP internet

Each OSI/TCP #N logical pair is physically one network. The
Wollongong components are:

TCP-based MTA: WIN/MHS, WIN/ULS (using the transport switch in RFC1006
		"position"), WIN/TCP

Transport bridge: WIN/TSB, WIN/LLS

Altho shown logically separated, hopefully each MHS/ULS/LLS/TCP set would run
on one machine.

The assumptions leading to the kludge:

i.  The WIN/ULS transport switch is static, not dynamic -> a simple
dual stack ULS-over-LLS+TCP wont work -> need the TSB

ii.  The TSB needs a true destination host address, not another TSB
-> need the two TCP-based MTAs (MHS/ULS/TCP)

Questions:

i.   Is there a more straightforward way to do this??? (with
commercial products - no ISODE, "you can easily hack the blah, blah
code", etc. - we're buyers, not developers)

ii.  If not, are the above assumptions correct?? Should the kludge
work?? Has anyone tried it (or something similar and, hopefully,
simpler)??

Many thanks for any help. Also, apologies if this isn't the best
list for the question.

-chas
-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 20:52:16 GMT
From:      sdd.hp.com!samsung!umich!vela!srodawa@ucsd.edu  (Ron Srodawa)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem with Xmodem and 3Com terminal server
Another thing to watch out for with 3COM terminal servers is the setting
for Net AScii.  It can be either UseLF or UseNul.  Flip it and see if
it fixes things.  (This changes whether a CR si followed by a NUL or
by a LF character on the net.  Some systems don't care.  Others go
bonkers if the setting is wrong.)

-- 
| Ronald J. Srodawa               | Internet: srodawa@unix.secs.oakland.edu |
| School of Engineering and CS    | UUCP:     srodawa@egrunix.UUCP          |
| Oakland University              | Voice:    (313) 370-2247                |
| Rochester, Michigan  48309-4401 |                                         |
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Nov 90 22:31:51 GMT
From:      icarus.eng.ohio-state.edu!kaul@tut.cis.ohio-state.edu  (Rich Kaul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Configuring a Sun to use DNS
In article <39@van-bc.wimsey.bc.ca> Samuel Lam writes:
   Could someone please tell me what is the easiest way to get a NIS-less
   Sun (SunOS 4.1) to use the DNS instead of /etc/hosts for host name
   lookups?

Ah, something I just enabled on my Sun.  Here's a previous posting
that may be helpful.  "It worked for me."

-rich

>From earle@POSEUR.JPL.NASA.GOV Mon May 21 09:58:30 1990
From: earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
Newsgroups: osu.sys.sun.managers
Subject: Revised posting on how to create libc_resolv.so under SunOS 4.1
Date: 19 May 90 03:59:57 GMT
Distribution: osu
Organization: Sun-Managers

Evan Wetstone's posting to Sun-Spots about libc+resolv under 4.1 has reminded
me to repost a slightly revised version of the instructions.  This is prompted
by 3 things:
(1) The original, virgin /usr/lib/shlib.etc/README file has an oversight in it;
    The original mentions that 2 files in the archive library need to be
    renamed after they are extracted, because the names are truncated at 16
    characters.  This is true for the Sun-3 and Sun-3x, but on Sun-4's and
    Sun-4c's (SPARCstation-1's, 1+'s, and presumably SLC's), there is an
    additional library module whose name is also truncated.  This is corrected.

(2) Several people complained to me that my instructions, being placed as an
    addendum rather than in line with the rest of the instructions, were thus
    unneccessarily confusing, and could even (if misinterpreted) cause someone
    to build a libc that would not work.

(3) I accidentally included my .signature file at the end of the posting,
    and then told everyone to append the rest of my message to their README
    files, thus immortalizing my .signature in everybody's README (^:  I
    humbly apologize ...

So, without further ado, here is the revised version of the file
/usr/lib/shlib.etc/README.  I recommend backing up the original, nuke my
previous version (the one that Evan re-posted), and insert this in its place.

	- Greg Earle			| "This is Kraft.  It uses a blue box.
	  Sun Microsystems, Inc.	|  This is Stouffer's.  It uses red.
	  JPL on-site Software Support	|  The choice is yours."
	  sun!poseur!earle		| Pretty damn convincing argument, eh?

----------------  >8  Cut here - /usr/lib/shlib.etc/README  8<  ---------------

This is a procedure you can use to substitute or add 
a module in your shared libc C library. 

Note! If you are interested in a System V libc, please substitute
	libc_pic.a for libcs5_pic.a in step 3, 
	libc.so.x.y.z for libcs5.so.x.y.z in step 8.

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

1. Become super user
	% su

2. Make a temporary directory
	# mkdir tmp

3. Change to the "tmp" directory just made, extract the pic .o from 
   libc_pic.a and rm the file __.SYMDEF. The reason you need to do 
   the 2 (or 3) "mv" commands is because "ar" truncated filenames over 
   16 characters.
	# cd tmp
	# ar x ../libc_pic.a
	# rm __.SYMDEF
	# mv rpc_dtablesize. rpc_dtablesize.o
	# mv rpc_commondata. rpc_commondata.o
   If on a Sun-4, perform this additional `mv' command:
	# mv xccs_multibyte. xccs_multibyte.o

Here are some extra instructions for building a shared libc.so that uses the
resolver for hostname/addr resolution:

3a. Extract the contents of libc_pic.a and /usr/lib/libresolv.a into the
    tmp directory:
	# ar x /usr/lib/libresolv.a

    The libresolv.a contains object modules that are position independant, so
    they can be added to the libc_pic modules.

    *Note*  If you have your own copy of the resolver library sources,
    (perhaps from a post-4.8 BIND distribution) you can compile each of these
    modules yourself using `cc -pic' and the resulting object modules *should*
    be usable in this schema as well.  To test that the custom resolver
    modules will be usable, cd to the directory containing the custom resolver
    sources and object modules and perform this test:

	# ld -assert pure-text *.o

    If `ld' issues no complaints, then you can assume that the object modules
    are safe to use.

3b. Remove the old routine to do the hostname/addr resolution:
	# rm gethostent.o

3c. Remove the libresolv module that contains `strncasecmp' (which is now
    in the main C library, so it is redundant):
	# rm strcasecmp.o

3d. As mentioned in step 5 below, edit the file `lorder-sparc' in the ..
    directory.  Remove the reference to `gethostent.o' and add the
    references to the resolver library routines by applying this patch:

	*** lorder-sparc.orig	Thu Feb  8 05:27:46 1990
	--- lorder-sparc	Mon Apr  9 12:58:59 1990
	***************
	*** 150,154 ****
	  getwd.o
	  getnetgrent.o
	! gethostent.o
	  ypxdr.o
	  ttyname.o
	--- 150,161 ----
	  getwd.o
	  getnetgrent.o
	! gethostnamadr.o
	! sethostent.o
	! res_query.o
	! res_mkquery.o
	! res_send.o
	! res_debug.o
	! res_comp.o
	! res_init.o
	  ypxdr.o
	  ttyname.o

3e. Continue on, from steps 6 to 9 (i.e., skip steps 4 and 5 immediately below).

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

4. Replace or add the .o that you wanted by doing a copy. Please
   note here that you are advised to create your object with
   the following compiler option, i.e "cc -c -pic yourprogram.c" to make
   it shareable.
	# cp your.o .

5. If you add a new module then you need to do this step.
   You need to edit the file "lorder-sparc" and add the name of the file
   you have copied from step 4 at the end of this file. 
	# vi ../lorder-sparc

6. 	# cd ..

7. 	# make libc.so

8. Now you should have some libc.so.x.y.z built in the current directory.
   It is recommended that you tested out this library at this point 
   before installing it. You can do so by setting the environment
   LD_LIBRARY_PATH  to the current directory for example:
   	# setenv LD_LIBRARY_PATH `pwd`
	# your_favorite_test_cmd
   Once you are satisfied that the new library worked, you can proceed
   to install it with the following commands:
	# cp libc.so.x.y.z /usr/lib
	# ldconfig
	# unsetenv LD_LIBRARY_PATH

9. You are now running with the new library. You can verify this by
   doing a trace command of let's say "date".
	# trace date
   The output should informed you that the new library is being used.
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 02:10:35 GMT
From:      usc!samsung!olivea!tymix!cirrusl!sunstorm!dhesi@ucsd.edu  (Rahul Dhesi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In <1990Oct29.205244.2051@supernet.haus.com> cluther@supernet.haus.com
(Clay Luther) writes:

>Internet will not be cheap until it drops to say, $100/month, or less.

I fail to see why it should be any more than about $1.50 per month,
plus communications costs.  You don't need $100/month for storing a
password entry.  The only significant cost should be for
communications.

While we're on the subject, the whole idea of requiring some sort of
leased line for Internet access is all wrong.  In this age of
Trailblazers, low-volume access to a network shouldn't need to cost
more than $30/hour after hours plus $1.50 per month for maintaining the
account.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi
A pointer is not an address.  It is a way of finding an address. -- me
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 02:16:42 GMT
From:      hpda!hpcupt1!hpindwa!lmg@ucbvax.Berkeley.EDU  (Lisa Gullicksen)
To:        tcp-ip@nic.ddn.mil
Subject:   HPCIGETVAR error -- HELP!!!
Background:
We encountered a problem in integration testing of SNMP/XL.  The
test system is a 925 running the test build Z.22.12 of the OS.
The program under test is written in C.
The problem occurs when we execute an snmpget from a UX machine
to query the system.sysDescr.0 MIB object.

The Problem:
The error occurs when the HPCIGETVAR intrinsic is called. The return
value of the status parameter is:

hpcigetvar returned info = -8106 subsys = 166.
The code that gets invoked, along with the parameter declarations, follows:
--------------------------------------------------------------------
hpe_status status_c;
char keyvalue1[200];
int  keyvalue2;

printf ("about to call hpcigetvar for HPCPUNAME.\n");
hpcigetvar ("HPCPUNAME$", &status_c, 2, keyvalue1,
	     11, &keyvalue2);
printf ("hpcigetvar returned info = %d subsys = %d.\n",
		      status_c.half.info, status_c.half.subsys);
-------------------------------------------------------------------
Questions:
What is the error -8106? Why is it that this call works when linked with
the test driver but not with the module with which it is being integrated?
Within the integrated module, hpcigetver is called twice. The first time
it works. The second time it doesn't.  The second invocation is the
one that comes from the newly integrated code (linked with the main
program as an RL).  We've checked that the test driver and the actual
code are built in the same manner with the same capabilities, execution
level and priv level (xleast=2;privlev=2;cap=ph,ds,mr,pm,ia,ba).

Any help will be greatly appreciated!

Lisa Gullicksen 1-447-2499, lmg@hpindzl
Brian McCracken 1-447-3478, bhm@hpda   
IND
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 02:53:25 GMT
From:      usc!jarthur!bridge2!mbt@ucsd.edu  (Brad Turner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem with Xmodem and 3Com terminal server
mmorse@Z.NSF.GOV ("Michael H. Morse") writes:

>I am having a problem getting Xmodem to work between a Sun workstation
>and a PC running a terminal emulator.

>The PC uses a modem and a dial-up line to communicate, but it cannot
>get to the workstation directly because the workstation has no serial
>ports.  Instead, the PC logs on to some other host, and then uses
>telnet to get to the workstation.

>We have a 3Com terminal server that is normally used in this situation,
>but we've found that Xmodem does not work (the PC nacks everything it
>gets) in this configuration.  However, if the PC logs onto one of our
>Ultrix hosts, and in effect uses it for a terminal server to telnet to
>the workstation, Xmodem works fine.  Subsequent tests have absolved the
>terminal emulator (on the PC) and the xmodem program on the
>workstation, leaving suspicion around the telnet implementation
>on the terminal server.

>I suspect this has something to do with parity, since the ASCII
>characters transmitted by Xmodem, and received by the PC are
>identical.  Has anybody run into a similar problem? Any information on
>how telnet reacts when raw mode is selected would be appreciated.

>Thanks in advance.

>--Mike

>-- 

>Michael Morse                           Internet: mmorse@note.nsf.gov
>National Science Foundation               BITNET: mmorse@NSF
>                                       Telephone: (202) 357-7659
>                                             FAX: (202) 357-7663

Mike,
   From your description above it sounds like you have the following
topology.
                                      Ethernet
                                           |
                                           |
               Phone                       |
    PC--Modem1=========Modem2---TermServer-|
               Line                        |
                                           |
                                           |--WorkStation
                                           |

If this is your topology then you should set up the termnial server parameters
as follows for the duration of the Xmodem transfer:

  FlowControlTo=none
  FlowControlFrom=none
  BreakAction=(EscDTM)
  ECMChar=disable

You can create a macro on the terminal server to do this and another macro to
restore the parameters after the transfer. By default the terminal server
attempts to negotiate a binary connection so the connection is 8-bits wide.
It has been a while since I worked in tech support so let me know if this
doesn't work (I'm winging it from memory.) I know that this can work since
I've configured it and had it running in the past (Xmodem through our CS that
is.)

-brad-
-- 
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner |5400 Bayfront Plaza |Mktg.Engr.(408) 764-5261| I speak for myself
3Com Corp.  |Santa Clara CA,95052|mbt@bridge2.ESD.3Com.Com| NOT for my employer
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 03:02:00 GMT
From:      KCPENG@TWNCTU01.BITNET
To:        comp.protocols.tcp-ip
Subject:   annoying n/w problems

Hi netter,

   There exist some problems in our network, though not(?) severe but indeed
annoying. The net consists of tens of various machine: Vaxs, Suns, HPs,
RS6000s, X-terminals... Some observable phenomenons follow:
   . the Sun 4/370 console keeps printing the message a period of time -
     'le0 : No carrier - transceiver cable problem?'
     of course, it can still do network functions. Other Suns SSs just have
     no such annoyance.
   . there are 3 workstations, say A, B and C, networked together.
        (O) ftp A to B
        (O) ftp B to C
        (X) ftp A to C
     A, B = Sun, C = RS600. (B,C) and (A) are on two different repeter ports.
   . another 2 hosts, say D and E, connected.
        (O) telnet D to E
        (X) telnet E to D
        (X) telnet D to D
     these two nodes are not on the same repeter port. I've re-invoked the
     inetd of D, still in vain. (It seems D can telnet 'out' sometimes before)

What I'm concerned are,
1) what's the causes? repeater? cable? others?
2) any utility to monitor the network problems, like re-transmission rate?
   or you have to put some command, like netstat, in cron table and run it
   periodically, then do statistics yourself? if so, how do I suppose to know
   the 'correct'(tolerable) value in all these statistical values?
3) some friend mentioned to me a product called 'cable scanner'. is it helpful
   to the above problems?

Any clue is highly, highly welcome.

Regards,
Kai-Chih Peng,
kcpeng@twnctu01.bitnet

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 07:27:22 GMT
From:      mcb@presto.ig.com  (Michael C. Berch)
To:        tcp-ip@nic.ddn.mil
Subject:   Cost of Internet access
In the referenced article, dhesi%cirrusl@oliveb.ATC.olivetti.com 
(Rahul Dhesi) writes:
> While we're on the subject, the whole idea of requiring some sort of
> leased line for Internet access is all wrong.  In this age of
> Trailblazers, low-volume access to a network shouldn't need to cost
> more than $30/hour after hours plus $1.50 per month for maintaining the
> account.

Uhhh, $30/hour?  That's about $21,000 per month, isn't it?  Even
assuming you typo'd "$30" for "$3" that would be $2,100/month which is
still pretty high.  Unless you meant some sort of access that would
only be a few hours per day, which misses the main advantage of
Internet access in the first place, which is real-time access to a
large set of distributed resources.  As an Internet user I can sit at
my workstation during business hours and log in to remote accounts,
FTP files to and from arbitrary locations all over the world, and send
and receive mail that arrives in seconds or minutes. 

Dial-up SLIP or PPP on an after-hours batched basis can't offer those
services and do not, to my mind, provide much of an advantage over
dial-up UUCP.  "Real" Internet access, to me, means real-time access.

--
Michael C. Berch  
mcb@presto.ig.com / uunet!presto.ig.com!mcb / ames!bionet!mcb
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 14:49:07 GMT
From:      bywater!acheron!clarke@uunet.uu.net  (Ed Clarke/10240000)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
From article <2650@cirrusl.UUCP>, by dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi):
- While we're on the subject, the whole idea of requiring some sort of
- leased line for Internet access is all wrong.  In this age of
- Trailblazers, low-volume access to a network shouldn't need to cost
- more than $30/hour after hours plus $1.50 per month for maintaining the
- account.

PSInet charges $250/month, flat fee using local phone numbers.  There are
no additional charges for packet or connect time.  If you think that you
will use internet access more than eight hours at your $30/hr, then you
have access right now.  Call 1.800.82PSI82 (blech!) to get more info.  
They support PPP (RFC 1171 asynch), SLIP (RFC 1055) and X.25/IP.

I just got the add yesterday ...
-- 
               | "Pain, n.  An uncomfortable frame of mind that may have
Ed Clarke      |  a physical basis in something that is being done to the
acheron!clarke |  body, or may be purely mental, caused by the good fortune
               |  of another." - Ambrose Bierce
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      3 Nov 90 16:26:07 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@ucsd.edu  (Tim Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP Packages via Anonymous ftp?
What SNMP packages are available via anonymous ftp--and from where?

Thanks.
-- 
cc:Mail		Tim K. Evans at ~OSS
UUCP 		...!{rutgers|ames|uunet}!mimsy!woodb!tkevans
INTERNET	tkevans%woodb@mimsy.umd.edu   PHONE:  (301) 965-3286
US MAIL		6401 Security Blvd, 2-Q-2 Operations, Baltimore, MD  21235	
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Nov 90 4:17:07 EST
From:      "Robert J. Reschly Jr." <reschly@BRL.MIL>
To:        Ian Heavens <ian@spider.co.uk>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: ttcp

      Ian,

  Sorry for the delay, but I wanted to ping Mike Muuss to confirm my
understanding.  The code for ttcp.c has been placed in the Public Domain,
so you can fold, spindle, multilate, and resell to your heart's content.
I modified our sources to include an explicit Public Domain comment and
updated the anonymous FTP copy on FTP.BRL.MIL (aka VGR.BRL.MIL,
26.2.0.29, 128.64.4.4).  Enjoy.

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

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

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Sat, 3 Nov 90 11:02 U
From:      <KCPENG%TWNCTU01.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   annoying n/w problems
Hi netter,

   There exist some problems in our network, though not(?) severe but indeed
annoying. The net consists of tens of various machine: Vaxs, Suns, HPs,
RS6000s, X-terminals... Some observable phenomenons follow:
   . the Sun 4/370 console keeps printing the message a period of time -
     'le0 : No carrier - transceiver cable problem?'
     of course, it can still do network functions. Other Suns SSs just have
     no such annoyance.
   . there are 3 workstations, say A, B and C, networked together.
        (O) ftp A to B
        (O) ftp B to C
        (X) ftp A to C
     A, B = Sun, C = RS600. (B,C) and (A) are on two different repeter ports.
   . another 2 hosts, say D and E, connected.
        (O) telnet D to E
        (X) telnet E to D
        (X) telnet D to D
     these two nodes are not on the same repeter port. I've re-invoked the
     inetd of D, still in vain. (It seems D can telnet 'out' sometimes before)

What I'm concerned are,
1) what's the causes? repeater? cable? others?
2) any utility to monitor the network problems, like re-transmission rate?
   or you have to put some command, like netstat, in cron table and run it
   periodically, then do statistics yourself? if so, how do I suppose to know
   the 'correct'(tolerable) value in all these statistical values?
3) some friend mentioned to me a product called 'cable scanner'. is it helpful
   to the above problems?

Any clue is highly, highly welcome.

Regards,
Kai-Chih Peng,
kcpeng@twnctu01.bitnet
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Nov 90 12:26:50 CST
From:      pdurrant@ub.d.umn.edu (Paul Durrant)
To:        TCP-IP-L@VMD.CSO.UIUC.EDU
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: your mail
> 
> Unsubcribe me !!!
> 
UNSUBSCRIBE me, too!

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 06:52:58 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Router scorecard 1.7


                              CAVEATS
                              -------

    The following scorecard tries to compare various  multi-protocol
routers.   The  current  scorecard  mainly  contains information for
cisco and  Wellfleet but  any other vendor is welcome  to  send me a
complete set of  manuals for their  equipment so that  I can analyze
and update the scorecard.

    The fact of  the matter is  that certain features  and "gotchas"
only appear when testing the actual equipment.  I hope that the user
population of multi-protocol routers  will assist me in  making this
scorecard as comprehensive as possible so that people who follow  do
not have to go through what I have gone through.

    It was  difficult to  decide whether  to include  future release
notes  in  this  scorecard.   I  trust  the  user  population in the
Internet to take each promise for a "future feature" with a grain of
salt  and  to  keep  watch  on  the  vendors that indeed they follow
through with their  promises.  All too  often vendors state  certain
features will be available in a certain release and sometimes  their
deadlines slip.   It is  advised that  people should  not base their
decisions on the future release notes. [That was a long caveat].

    If you  have comments,  suggestions, additions,  or subtractions
or corrections, please send them to:

HANK@VM.TAU.AC.IL   or   HANK@TAUNIVM.BITNET    (but not to both!)

    The  scorecard will  be updated on a monthly basis.  This report
may be freely reproduced as long as nothing is altered or removed.

    If you read this report  and are not connected to  the Internet,
you can send your comments to:

Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

    [The above employer has nothing to do with this scorecard so  if
something bothers you about it, I take full responsibility.]

                          END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box.  I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
                  Comparison of Multiprotocol Routers
                           Henry Nussbacher
                            November 1990
                             Version 1.7


                       +--------------+--------------+---------------+
 Multiprotocol         | cisco AGS+   | Wellfleet LN | Proteon p4200 |
 Router                | Rel. 8.1(14) | Rel. 5.40    | Rel. 8.3      |
                       +--------------+--------------+---------------+
 1. General            |              |              |               |
    - # of slots       | 9            | 4            | 7             |
    - Processor        | 30Mhz 68020  | 32MHz 68030  | ??Mhz 68020   |
    - Memory           | 4Mbyte       | 4Mbyte       | 2Mbyte        |
    - Updates via      | ROM, TFTP    | diskette,TFTP| diskette,TFTP |
    - Speed of bus     | 530Mb/sec (a)| 320Mb/sec    | 160Mb/sec     |
    - Boot from        |              |              |               |
      - ROM            | Yes          | No           | No            |
      - Net-boot       |              |              |               |
        - IP           | Yes          | Rel 5.60     | Yes           |
        - Decnet (MOP) | No           | No           | No            |
      - Diskette       | No           | Yes          | No            |
      - Another router | Yes          | Rel 5.60     | No            |
    - Volatile changes | Yes  (b)     | No           | Yes   (h)     |
    - CPU statistics   | Yes  (c)     | No           | Yes           |
    - Memory stats     | Yes          | Yes          | Yes           |
    - Ease of install  | Very easy    | menu driven  |               |
    - Documentation    | Difficult    | Skimpy       | Clear, orderly|
    - Autorestart (d)  | Yes          | Yes          | Yes           |
    - Restart for      |              |              |               |
      config changes   | No           | Yes          | Yes           |
    - Watchdog timer   | Yes          | Yes          | Yes           |
    - Reboot time  (e) | 29 sec  (f)  |  60 sec  (j) | 32 sec (i)    |
    - Power-up time (g)| 29 sec       | 120 sec  (j) | 32 sec (i)    |

 Notes:
 a. Speed of old AGS bus is 160Mb.
 b. Volatile changes represents the ability of the router to accept a
    configuration change that is dynamic that only affects the current
    running system and once the system is rebooted, the change
    disappears.
 c. CPU statistics refers to the ability of the router to provide
    a monitoring facility to see what the CPU is doing and how often
    it is doing it.
 d. Autorestart in the event of a power failure.
 e. Reboot time refers to the amount of elapsed time needed to
    perform a logical restart (reboot) from the fastest available
    media.
 f. cisco timings are for older AGS system.
 g. Power-up time refers to the amount of elapsed time needed from
    the time of a power failure and recovery until the router is up and
    operational.
 h. Only available for DECnet and OSPF, and only for a subset of
    available parameters.
 i. Booting via Proteon's Intergrated Boot Device, with running
    diagnostics.
 j. Timings include CPU and I/O module diagnostics run at power-up.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       | 7x10Mb        |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 4x10Mb       | No            |
    - 4Mb Token Ring   | 3x4Mb    (i) | 4x4Mb        | 7x4Mb         |
    - 16Mb Token Ring  | Rel 8.2  (j) | 4x16Mb       | No            |
    - RS232            | 24x64kb      | 16x64kb      | 14x64kb       |
    - RS449            | 12x64kb      | 16x6Mb       | 14x64kb       |
    - V.35             | 12x64kb      | 16x6Mb       | 14x64kb       |
    - X.21             | ??           | 16x6Mb       | ??            |
    - T1 (1.544Mb)     |              |              |               |
      - Serial         | 12           | 8            | 14            |
      - Framed         | ??           | 8            | ??            |
    - CEPT DS1 (2Mb)   |              |              |               |
      - Serial         | 12           | 8            | 12            |
      - Framed         | ??           | 8            | ??            |
    - FDDI             | 2x100Mb   (l)| 1x100Mb      | 2x100Mb       |
      - DAS (Dual)  (e)| Yes          | Yes          | Yes           |
      - SAS (Single)   | Yes          | No           | Yes           |
    - Ultranet         | Rel 8.2   (k)| No           | ??            |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          | 255           |
    - Card types  (g)  | 6E, 1E2S,    | 2E, 1E1S, 1T,| 1E, 2S, 4S,   |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  | 1TR, .5F  (m) |
                       | 1TR, 1F   (h)| 1TR2S, 4S,   |               |
                       |              | 1TR, 2TR2S   |               |
                       |              | 1TR1S, 2T, 2C|               |

 Notes:
 a. Each interface subsection represents the maximum number of LANs
    or WANS that can be configured for that particular subsection.
    It is possible to "mix and match" various subsections by reducing
    the upper limit.
 b. Thin Ethernet refers to a standard BNC connector available directly
    on the router.
 e. Dual is also known as Type A and Single is also known as Type B.
 f. Depends on memory limitations.
 g. Card types: E: Ethernet     S: Serial/Synchronous line
                TR: Token-Ring  F: FDDI
                T: Framed T1    C: Framed CEPT (2.048Mbs)
 h. The 6E and 1F cards are for the faster cBus only.
 i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
 j. To be supported in later release of Version 8.2.
 k. Ultranet support will be in a later release of 8.2 but will
    only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
 l. 4x100Mb as of Rel 8.2.
 m. Proteon's FDDI is a 2 card set.

 3. Interface part II  |              |              |               |
    - Frame Relay (a)  | Rel 8.2      | Rel 6.0      | No            |
    - Ethernet         |              |              |               |
      encapsulation    |              |              |               |
      - Standard v2.0  | Yes          | Yes          | Yes           |
      - IEEE 802.3     | Yes          | Yes          | Yes           |
      - SNAP 802.2     |              |              |               |
        (RFC1042)      | Yes          | Yes          | No            |
    - Serial           |              |              |               |
      encapsulation    |              |              |               |
      - HDLC           | Yes          | Yes          | Yes           |
      - LAPB           | Yes          | Yes          | No            |
      - PPP (RFC1134)  | Yes          | No           | No            |
      - DDCMP          | No           | No           | No            |
      - X.25           |              |              |               |
        - SVC          | Yes          | Yes          | Yes           |
        - PVC          | Yes          | Yes          | Yes           |
    - Encryption   (b) | Pulse-time   | No           | No            |
    - Filtering by     |              |              |               |
      source/dest      | Yes          | Yes          | Yes           |

Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
   encrypting devices on various interfaces or circuits.
c. For CLNP only.

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          | Yes           |
    - ARP  (RFC826)    | Yes          | Yes          | Yes           |
    - RARP (RFC903)    | Yes          | No           | No            |
    - BOOTP (RFC951)   | Yes          | Rel 5.60     | No            |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          | Yes           |
    - ICMP             | Yes          | Yes          | Yes           |
    - Name-server      | Yes          | No           | No            |
    - Accounting       | Yes          | No           | No            |
    - MTU              | Yes          | Yes          | No            |
    - Security - IPSO  | Yes          | No           | No            |
    - Static routing   | Yes          | Yes          | Yes           |
    - Source routing   | Yes          | Yes          | Yes           |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          | Yes           |
      - TCP            | Yes          | Yes          | No            |
      - UDP            | Yes          | Yes          | No            |
      - ICMP           | Yes          | No           | No            |
      - by protocol (b)| Yes   (a)    | Yes          | No            |
    - Routing protocols|              |              | No            |
      - RIP (RFC1058)  | Yes          | Yes          | Yes           |
      - EGP (RFC904)   | Yes          | Yes          | Yes           |
      - BGP (RFC1105)  | Yes          | No           | No            |
      - Proprietary    | IGRP         | eRIP         | No            |
      - Filtering      | Yes          | Rel 5.60     | Yes           |
      - Default routes | Yes          | Yes          | Yes           |
      - OSPF           | Rel 9.0      | Rel 5.60     | Yes           |

 Notes:
 a. Can be done but is difficult and requires advanced knowledge of the
    specific protocols.
 b. Filtering by protocol can also be viewed as filtering by port
    number.

 5. DECNET             |              |              |               |
    - Phase IV Router  | Yes          | Yes          | Yes           |
    - Area Router      | Yes          | Yes          | Yes           |
    - Phase IV+   (a)  | Rel 8.2      | No           | No            |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      | No           | No            |
    - Phase V          | Yes     (b)  | No           | Yes     (b)   |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           | No            |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          | Yes           |
      - area-max-hops  | Yes          | Yes          | Yes           |
      - max-address    | Yes          | Yes          | Yes           |
      - max-area       | Yes          | Yes          | Yes           |
      - max-cost       | Yes          | Yes          | Yes           |
      - max-hops       | Yes          | Yes          | Yes           |
      - max-visits     | Yes          | Yes          | Yes           |
      - router-priority| Yes          | Yes          | Yes    (e)    |
      - hello-timer    | Yes          | Yes          | Yes           |
      - routing-timer  | Yes          | Yes          | Yes           |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           | Yes           |
      - by protocol    | No           | No           | No            |
      - by object      | No           | No           | No            |
      - routing        | Yes    (d)   | No           | Yes    (d)    |
    - MOP              | Bridged      | Bridged      | Yes    (f)    |
    - Static routing   | No           | No           | No            |
    - Max routing table| 1023         | 1023         | 1023          |
    - Max # of broad.  |              |              |               |
      router adjencency| 32           | 128          | ??            |

 Notes:
 a. Phase IV+ refers to path-split capability.  This means "normal" and
    not "interim".  Normal allows out-of-sequence packets to arrive.
    Interim does not allow out-of-sequence packets to arrive.
 b. cisco claims that it's ISO CLNS support is compatible with Decnet
    Phase V.
 c. Address Translation Gateway is the ability to connect two separate
    Decnet networks with overlapping addresses.
 d. It is not possible to filter out of area addresses.  It is only
    possible to filter an entire area or addresses within one's area.
 e. On a per circuit basis, as required by DECnet specs.
 f. MOP System ID.

 6. Bridging           |              |              |               |
    - Local bridging   | Yes          | Yes          | No            |
      - LAVC      (a)  | Yes          | Yes          | No            |
    - Remote bridging  | Yes   (b)    | Yes          | No            |
    - Transparent      |              |              |               |
      - Learning       | Yes          | Yes          | No            |
      - Spanning tree  |              |              |               |
        (IEEE 802.1)   | Yes          | Yes          | No            |
    - Priority    (c)  | Rel 8.2      | Yes   (h)    | No            |
    - Filtering        |              |              |               |
      - Multicast      | Yes          | Yes          | No            |
      - Protocol       | Yes          | Yes          | No            |
      - Source/dest    | Yes          | Yes   (g)    | No            |
      - Masking   (d)  | No           | No           | No            |
    - Load sharing     | Yes   (e)    | Yes          | No            |
    - Token Ring       |              |              |               |
      - Source route   | Yes          | Yes          | Yes           |
      - Multi-ring (f) | Yes          | Yes          | No            |

 Notes
 a. LAVC refers to the ability to act as a local bridge between two Vax
    clusters using the DEC LAVC protocol.
 b. cisco does not support bridging over X.25 or LAPB.
 c. Priority refers to the ability to assign a priority to a specific
    protocol so that that protocol is sent faster than any other
    protocol over a specific circuit/interface.
 d. Masking refers to the ability to specify some pattern string to be
    matched within the packet, so that the user can specify almost any
    filter.
 e. cisco load sharing (balancing) is on a per-node basis and not on
    a per packet basis.  That means that over 2 parallel serial lines
    the cisco will automatically allocate 50% of the learned Ethernet
    addresses to one line and the other 50% to the other line.
 f. Multi-ring refers to bridging between multiple Token Ring networks
    (all hosts must understand RIF).
 g. Wellfleet can only filter on destination address and not on source
    address.
 h. Priority can be implemented using circuit groups.

 7. Other protocols    |              |              |               |
    (ability to route) |              |              |               |
    - XNS              | Yes  (a)     | Yes          | Yes           |
      - UB derivitive  | Yes          | Yes          | Yes           |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          | Yes           |
      - Phase 2        | Rel 8.2      | Yes          | No            |
      - Tokentalk      | Rel 8.2      | Yes          | No            |
      - Ethertalk      | Yes          | Yes          | Yes           |
      - Localtalk      | No           | No           | No            |
      - RTMP           | Yes          | Yes          | Yes           |
      - AARP           | Yes          | Yes          | Yes           |
      - NBP            | Yes          | Yes          | Yes           |
      - EP             | Yes          | Yes          | Yes           |
      - ATP      (c)   | Yes          | No           | Yes           |
      - ZIP            | Yes          | Yes          | Yes           |
      - DDP            | Yes          | Yes          | Yes           |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           | Yes           |
      - ISO 9542 ES-IS | Yes          | No           | Yes           |
    - Apollo Domain    | Yes          | No           | Yes           |
    - Novell IPX       | Yes  (a)     | Yes          | Yes           |
    - Banyan Vines     | Rel 8.2      | No           | No            |
    - X.25             | Yes          | Yes          | Yes           |
      - bridging       | Rel 9.0      | Yes          | No            |
      - routing        | Yes          | Yes          | Yes           |
      - switching      | Yes          | Yes          | No            |
    - Security         | Yes  (b)     | Rel 5.60     | No            |

 Notes:
 a. With cisco equipment, if there are both Ethernet and Token Ring
    interfaces, then DECnet cannot be run simultaneously with either
    Novell IPX or XNS.  This restriction will be removed in Release 8.2.
 b. cisco provides filtering/permitting/denying certain packets
    only for IPX, XNS and Appletalk in the section listed above.
 c. Not required for correct operation of a Phase II router.

 8. Management         |              |              |               |
    - Central managed  | Yes          | Yes          | Yes           |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3, Sparc | 80286 AT      |
      - External       |              |              |               |
        software (b)   | No      (c)  | No           | No            |
      - X netmap       | Yes          | Yes          | Yes           |
        - Telnet to    |              |              |               |
          device  (d)  | Yes          | Yes          | Yes           |
      - X interactive  |              |              |               |
        performance    | Yes          | Yes          | Yes           |
      - History stats  | Yes          | Yes          | No            |
      - Report writer  | Yes     (c)  | No           | No            |
      - Alerts    (e)  | No           | No           | No            |
      - User defined   |              |              |               |
        extensions (m) | Yes          | Yes          | No            |
    - Usage stats      | Yes          | Yes  (f)     | Yes           |
    - Direct MIB access| No           | Yes          | No            |
    - PING             | Yes          | Yes  (g)     | No            |
    - Traceroute       | Yes          | No           | No            |
    - Telnet           | Yes     (h)  | Yes  (i)     | Yes (n)       |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      | No            |
    - NICE        (j)  | No           | No           | No            |
    - Decnet connect   | No           | No           | No            |
    - Passwords (k)    | Yes          | Yes          | Yes           |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          | Yes           |

 Notes:
 b. External software refers to the need to have some external
    software package available in order to run SNMP monitoring.
 c. cisco requires the Sybase database system in order to run their
    NMS software.  This package is bundled with their NMS.
 d. Ability to click on an icon on the X-11 network map and open
    a telnet connection to the device in question.
 e. Alerts refers to the ability to define a preset limit for a
    specific MIB variable at which point the SNMP monitoring software
    will present a window on top of the network map informing the
    network operator of the problem.
 f. Wellfleet interactive usage statistics are only for (ISO model)
    level 2.  Upper level statistics (such as RIP, UDP, TCP, Decnet
    HELLO, ARP) are not available.
 g. Wellfleet PING command stops after first failure and waits for
    user response.  This makes it very hard to check the total
    percentage of line failures over a short period of time.
 h. cisco is limited to 5 incoming Telnet sessions but has no
    limitation on outgoing Telnet sessions.
 i. Wellfleet Telnet is limited to one incoming and one outgoing
    session.
 j. NICE refers to the ability of the router to accept "SET EXECUTOR"
    as well as initiate a "SET EXECUTOR" to a remote host.
 k. Passwords refers to the ability to limit certain configuration and
    customization options only to those users who supply a password.
 l. cisco command is not an EXEC command but actually requires a
    configuration change to disable a line.
 m. The ability for the NMS software to add other vendor MIBs to their
    database, in order to manage these particular hardware units.
 n. Proteon is limited to 2 incoming and no outgoing sessions.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          | Yes           |
    - LAN              | Yes          | Yes          | Yes           |
    - Link             | Yes          | Yes          | Yes           |
    - Decnet           | Yes          | Yes          | Yes           |
    - Tcp/Ip           | Yes          | Yes          | Yes           |
    - Event log        | Yes          | Yes          | Yes           |
      - Network Logging| Yes          | Yes          | ??            |
      - Local Storage  | No           | Yes          | ??            |
    - Environmentals   | Yes          | No           | No            |

 Notes:
 a. Environmentals refers to the monitoring of variables such as
    fan, power supply, memory, temperature, etc.

 10. Performance  (a)  |              |              |               |
    - Router forward   | 4494         | 4494         | 1493          |
    - Router filter    | 4494         | 4494         | 1248          |
    - Bridge forward   | 4494         | 4494         | N/A           |
    - Bridge filter    | 4494         | 4494         | N/A           |
    - LAT compression  | Yes          | No           | No            |

 Notes:
 a. Performance based on 256 byte IP packets, between separate
    interface cards, with no packet loss.  Numbers listed are in
    packets per second.  Numbers based on Bradner report #3, Harvard
    University, Oct 1990.

 11. Survivability     |              |              |               |
    - alternate power  |              |              |               |
      supply           | No           | Yes   (d)    | No            |
    - standby line  (a)| No           | No           | No            |
    - fault tolerant(b)| No           | No           | No            |
    - field tolerant(c)| No           | No           | No            |
    - broadcast storms | Yes          | Yes          | Yes           |

 Notes:
 a. Standby line refers to the ability to define a line that is to be a
    hot standby, in the event that the primary line goes down.  The
    software switches all traffic automatically to the backup line.
 b. Fault tolerant refers to having redundent systems that are normally
    in standby mode, and that are only called into active mode in the
    event that the primary system fails.  Various systems are the power
    supply, the fan, the bus, the controller cards, etc.
 c. Field tolerant refers to the ability to withstand harsh elements
    and conditions out in the "field."
 d. Alternate power supply only available in large Concentrator model.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Sun, 04 Nov 90 08:52:58 O
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        cisco@spot.colorado.edu, wellfleet-l@nstn.ns.ca, tcp-ip@nic.ddn.mil, ripe@mcsun.EU.NET, p4200@devvax.tn.cornell.edu
Subject:   Router scorecard 1.7
                              CAVEATS
                              -------

    The following scorecard tries to compare various  multi-protocol
routers.   The  current  scorecard  mainly  contains information for
cisco and  Wellfleet but  any other vendor is welcome  to  send me a
complete set of  manuals for their  equipment so that  I can analyze
and update the scorecard.

    The fact of  the matter is  that certain features  and "gotchas"
only appear when testing the actual equipment.  I hope that the user
population of multi-protocol routers  will assist me in  making this
scorecard as comprehensive as possible so that people who follow  do
not have to go through what I have gone through.

    It was  difficult to  decide whether  to include  future release
notes  in  this  scorecard.   I  trust  the  user  population in the
Internet to take each promise for a "future feature" with a grain of
salt  and  to  keep  watch  on  the  vendors that indeed they follow
through with their  promises.  All too  often vendors state  certain
features will be available in a certain release and sometimes  their
deadlines slip.   It is  advised that  people should  not base their
decisions on the future release notes. [That was a long caveat].

    If you  have comments,  suggestions, additions,  or subtractions
or corrections, please send them to:

HANK@VM.TAU.AC.IL   or   HANK@TAUNIVM.BITNET    (but not to both!)

    The  scorecard will  be updated on a monthly basis.  This report
may be freely reproduced as long as nothing is altered or removed.

    If you read this report  and are not connected to  the Internet,
you can send your comments to:

Hank Nussbacher
Computer Center
Tel Aviv University
Ramat Aviv
Israel

    [The above employer has nothing to do with this scorecard so  if
something bothers you about it, I take full responsibility.]

                          END OF CAVEATS
--------------------------------------------------------------------
V1.6 update: Various vendors have been in contact with me but after
expressing interest in having an entry for their machine they disappear.
Other vendors have tried to change the particular hardware box that
is being compared to another box.  I hope that vendors will participate
in keeping this scorecard up-to-date.
--------------------------------------------------------------------
Distribution:
cisco@spot.colorado.edu
wellfleet@nstn.ns.ca
tcpip@nic.ddn.mil
ripe@mcsun.eu.net
p4200@devvax.tn.cornell.edu
Usenet: comp.dcom.lans
--------------------------------------------------------------------
                  Comparison of Multiprotocol Routers
                           Henry Nussbacher
                            November 1990
                             Version 1.7


                       +--------------+--------------+---------------+
 Multiprotocol         | cisco AGS+   | Wellfleet LN | Proteon p4200 |
 Router                | Rel. 8.1(14) | Rel. 5.40    | Rel. 8.3      |
                       +--------------+--------------+---------------+
 1. General            |              |              |               |
    - # of slots       | 9            | 4            | 7             |
    - Processor        | 30Mhz 68020  | 32MHz 68030  | ??Mhz 68020   |
    - Memory           | 4Mbyte       | 4Mbyte       | 2Mbyte        |
    - Updates via      | ROM, TFTP    | diskette,TFTP| diskette,TFTP |
    - Speed of bus     | 530Mb/sec (a)| 320Mb/sec    | 160Mb/sec     |
    - Boot from        |              |              |               |
      - ROM            | Yes          | No           | No            |
      - Net-boot       |              |              |               |
        - IP           | Yes          | Rel 5.60     | Yes           |
        - Decnet (MOP) | No           | No           | No            |
      - Diskette       | No           | Yes          | No            |
      - Another router | Yes          | Rel 5.60     | No            |
    - Volatile changes | Yes  (b)     | No           | Yes   (h)     |
    - CPU statistics   | Yes  (c)     | No           | Yes           |
    - Memory stats     | Yes          | Yes          | Yes           |
    - Ease of install  | Very easy    | menu driven  |               |
    - Documentation    | Difficult    | Skimpy       | Clear, orderly|
    - Autorestart (d)  | Yes          | Yes          | Yes           |
    - Restart for      |              |              |               |
      config changes   | No           | Yes          | Yes           |
    - Watchdog timer   | Yes          | Yes          | Yes           |
    - Reboot time  (e) | 29 sec  (f)  |  60 sec  (j) | 32 sec (i)    |
    - Power-up time (g)| 29 sec       | 120 sec  (j) | 32 sec (i)    |

 Notes:
 a. Speed of old AGS bus is 160Mb.
 b. Volatile changes represents the ability of the router to accept a
    configuration change that is dynamic that only affects the current
    running system and once the system is rebooted, the change
    disappears.
 c. CPU statistics refers to the ability of the router to provide
    a monitoring facility to see what the CPU is doing and how often
    it is doing it.
 d. Autorestart in the event of a power failure.
 e. Reboot time refers to the amount of elapsed time needed to
    perform a logical restart (reboot) from the fastest available
    media.
 f. cisco timings are for older AGS system.
 g. Power-up time refers to the amount of elapsed time needed from
    the time of a power failure and recovery until the router is up and
    operational.
 h. Only available for DECnet and OSPF, and only for a subset of
    available parameters.
 i. Booting via Proteon's Intergrated Boot Device, with running
    diagnostics.
 j. Timings include CPU and I/O module diagnostics run at power-up.

 2. Interfaces   (a)   |              |              |               |
    - Ethernet         |              |              |               |
      (802.3 10Base5)  | 24x10Mb      | 8x10Mb       | 7x10Mb        |
    - Thin Ethernet (b)|              |              |               |
      (802.3 10Base2)  | No           | 4x10Mb       | No            |
    - 4Mb Token Ring   | 3x4Mb    (i) | 4x4Mb        | 7x4Mb         |
    - 16Mb Token Ring  | Rel 8.2  (j) | 4x16Mb       | No            |
    - RS232            | 24x64kb      | 16x64kb      | 14x64kb       |
    - RS449            | 12x64kb      | 16x6Mb       | 14x64kb       |
    - V.35             | 12x64kb      | 16x6Mb       | 14x64kb       |
    - X.21             | ??           | 16x6Mb       | ??            |
    - T1 (1.544Mb)     |              |              |               |
      - Serial         | 12           | 8            | 14            |
      - Framed         | ??           | 8            | ??            |
    - CEPT DS1 (2Mb)   |              |              |               |
      - Serial         | 12           | 8            | 12            |
      - Framed         | ??           | 8            | ??            |
    - FDDI             | 2x100Mb   (l)| 1x100Mb      | 2x100Mb       |
      - DAS (Dual)  (e)| Yes          | Yes          | Yes           |
      - SAS (Single)   | Yes          | No           | Yes           |
    - Ultranet         | Rel 8.2   (k)| No           | ??            |
    - X.25             |              |              |               |
      - Max # of VCs   | Unlimited (f)| 254          | 255           |
    - Card types  (g)  | 6E, 1E2S,    | 2E, 1E1S, 1T,| 1E, 2S, 4S,   |
      per slot         | 2E2S, 4S,    | 1E2S, 2E2S,  | 1TR, .5F  (m) |
                       | 1TR, 1F   (h)| 1TR2S, 4S,   |               |
                       |              | 1TR, 2TR2S   |               |
                       |              | 1TR1S, 2T, 2C|               |

 Notes:
 a. Each interface subsection represents the maximum number of LANs
    or WANS that can be configured for that particular subsection.
    It is possible to "mix and match" various subsections by reducing
    the upper limit.
 b. Thin Ethernet refers to a standard BNC connector available directly
    on the router.
 e. Dual is also known as Type A and Single is also known as Type B.
 f. Depends on memory limitations.
 g. Card types: E: Ethernet     S: Serial/Synchronous line
                TR: Token-Ring  F: FDDI
                T: Framed T1    C: Framed CEPT (2.048Mbs)
 h. The 6E and 1F cards are for the faster cBus only.
 i. The AGS can take 4 Token Rings while the AGS+ can only take 3.
 j. To be supported in later release of Version 8.2.
 k. Ultranet support will be in a later release of 8.2 but will
    only support a 125Mb full-duplex connection to Ultranet's 1Gb LAN.
 l. 4x100Mb as of Rel 8.2.
 m. Proteon's FDDI is a 2 card set.

 3. Interface part II  |              |              |               |
    - Frame Relay (a)  | Rel 8.2      | Rel 6.0      | No            |
    - Ethernet         |              |              |               |
      encapsulation    |              |              |               |
      - Standard v2.0  | Yes          | Yes          | Yes           |
      - IEEE 802.3     | Yes          | Yes          | Yes           |
      - SNAP 802.2     |              |              |               |
        (RFC1042)      | Yes          | Yes          | No            |
    - Serial           |              |              |               |
      encapsulation    |              |              |               |
      - HDLC           | Yes          | Yes          | Yes           |
      - LAPB           | Yes          | Yes          | No            |
      - PPP (RFC1134)  | Yes          | No           | No            |
      - DDCMP          | No           | No           | No            |
      - X.25           |              |              |               |
        - SVC          | Yes          | Yes          | Yes           |
        - PVC          | Yes          | Yes          | Yes           |
    - Encryption   (b) | Pulse-time   | No           | No            |
    - Filtering by     |              |              |               |
      source/dest      | Yes          | Yes          | Yes           |

Notes:
a. CCITT standards Q.931 (Frame Relay) and I.122 (Lap-D)
b. Encryption refers to the ability of the router to compensate for
   encrypting devices on various interfaces or circuits.
c. For CLNP only.

 4. IP                 |              |              |               |
    - Subnetting       |              |              |               |
      (RFC950)         | Yes          | Yes          | Yes           |
    - ARP  (RFC826)    | Yes          | Yes          | Yes           |
    - RARP (RFC903)    | Yes          | No           | No            |
    - BOOTP (RFC951)   | Yes          | Rel 5.60     | No            |
    - proxy ARP        |              |              |               |
      (RFC1027)        | Yes          | Yes          | Yes           |
    - ICMP             | Yes          | Yes          | Yes           |
    - Name-server      | Yes          | No           | No            |
    - Accounting       | Yes          | No           | No            |
    - MTU              | Yes          | Yes          | No            |
    - Security - IPSO  | Yes          | No           | No            |
    - Static routing   | Yes          | Yes          | Yes           |
    - Source routing   | Yes          | Yes          | Yes           |
    - Filters          |              |              |               |
      - source/dest    | Yes          | Yes          | Yes           |
      - TCP            | Yes          | Yes          | No            |
      - UDP            | Yes          | Yes          | No            |
      - ICMP           | Yes          | No           | No            |
      - by protocol (b)| Yes   (a)    | Yes          | No            |
    - Routing protocols|              |              | No            |
      - RIP (RFC1058)  | Yes          | Yes          | Yes           |
      - EGP (RFC904)   | Yes          | Yes          | Yes           |
      - BGP (RFC1105)  | Yes          | No           | No            |
      - Proprietary    | IGRP         | eRIP         | No            |
      - Filtering      | Yes          | Rel 5.60     | Yes           |
      - Default routes | Yes          | Yes          | Yes           |
      - OSPF           | Rel 9.0      | Rel 5.60     | Yes           |

 Notes:
 a. Can be done but is difficult and requires advanced knowledge of the
    specific protocols.
 b. Filtering by protocol can also be viewed as filtering by port
    number.

 5. DECNET             |              |              |               |
    - Phase IV Router  | Yes          | Yes          | Yes           |
    - Area Router      | Yes          | Yes          | Yes           |
    - Phase IV+   (a)  | Rel 8.2      | No           | No            |
    - Phase IV-V       |              |              |               |
      Transitional gty | Rel 8.2      | No           | No            |
    - Phase V          | Yes     (b)  | No           | Yes     (b)   |
    - Address xlation  |              |              |               |
      gateway     (c)  | Yes          | No           | No            |
    - NCP              |              |              |               |
      - area-max-cost  | Yes          | Yes          | Yes           |
      - area-max-hops  | Yes          | Yes          | Yes           |
      - max-address    | Yes          | Yes          | Yes           |
      - max-area       | Yes          | Yes          | Yes           |
      - max-cost       | Yes          | Yes          | Yes           |
      - max-hops       | Yes          | Yes          | Yes           |
      - max-visits     | Yes          | Yes          | Yes           |
      - router-priority| Yes          | Yes          | Yes    (e)    |
      - hello-timer    | Yes          | Yes          | Yes           |
      - routing-timer  | Yes          | Yes          | Yes           |
    - Filtering        |              |              |               |
      - source/dest    | Yes          | No           | Yes           |
      - by protocol    | No           | No           | No            |
      - by object      | No           | No           | No            |
      - routing        | Yes    (d)   | No           | Yes    (d)    |
    - MOP              | Bridged      | Bridged      | Yes    (f)    |
    - Static routing   | No           | No           | No            |
    - Max routing table| 1023         | 1023         | 1023          |
    - Max # of broad.  |              |              |               |
      router adjencency| 32           | 128          | ??            |

 Notes:
 a. Phase IV+ refers to path-split capability.  This means "normal" and
    not "interim".  Normal allows out-of-sequence packets to arrive.
    Interim does not allow out-of-sequence packets to arrive.
 b. cisco claims that it's ISO CLNS support is compatible with Decnet
    Phase V.
 c. Address Translation Gateway is the ability to connect two separate
    Decnet networks with overlapping addresses.
 d. It is not possible to filter out of area addresses.  It is only
    possible to filter an entire area or addresses within one's area.
 e. On a per circuit basis, as required by DECnet specs.
 f. MOP System ID.

 6. Bridging           |              |              |               |
    - Local bridging   | Yes          | Yes          | No            |
      - LAVC      (a)  | Yes          | Yes          | No            |
    - Remote bridging  | Yes   (b)    | Yes          | No            |
    - Transparent      |              |              |               |
      - Learning       | Yes          | Yes          | No            |
      - Spanning tree  |              |              |               |
        (IEEE 802.1)   | Yes          | Yes          | No            |
    - Priority    (c)  | Rel 8.2      | Yes   (h)    | No            |
    - Filtering        |              |              |               |
      - Multicast      | Yes          | Yes          | No            |
      - Protocol       | Yes          | Yes          | No            |
      - Source/dest    | Yes          | Yes   (g)    | No            |
      - Masking   (d)  | No           | No           | No            |
    - Load sharing     | Yes   (e)    | Yes          | No            |
    - Token Ring       |              |              |               |
      - Source route   | Yes          | Yes          | Yes           |
      - Multi-ring (f) | Yes          | Yes          | No            |

 Notes
 a. LAVC refers to the ability to act as a local bridge between two Vax
    clusters using the DEC LAVC protocol.
 b. cisco does not support bridging over X.25 or LAPB.
 c. Priority refers to the ability to assign a priority to a specific
    protocol so that that protocol is sent faster than any other
    protocol over a specific circuit/interface.
 d. Masking refers to the ability to specify some pattern string to be
    matched within the packet, so that the user can specify almost any
    filter.
 e. cisco load sharing (balancing) is on a per-node basis and not on
    a per packet basis.  That means that over 2 parallel serial lines
    the cisco will automatically allocate 50% of the learned Ethernet
    addresses to one line and the other 50% to the other line.
 f. Multi-ring refers to bridging between multiple Token Ring networks
    (all hosts must understand RIF).
 g. Wellfleet can only filter on destination address and not on source
    address.
 h. Priority can be implemented using circuit groups.

 7. Other protocols    |              |              |               |
    (ability to route) |              |              |               |
    - XNS              | Yes  (a)     | Yes          | Yes           |
      - UB derivitive  | Yes          | Yes          | Yes           |
    - Appletalk        |              |              |               |
      - Phase 1        | Yes          | Yes          | Yes           |
      - Phase 2        | Rel 8.2      | Yes          | No            |
      - Tokentalk      | Rel 8.2      | Yes          | No            |
      - Ethertalk      | Yes          | Yes          | Yes           |
      - Localtalk      | No           | No           | No            |
      - RTMP           | Yes          | Yes          | Yes           |
      - AARP           | Yes          | Yes          | Yes           |
      - NBP            | Yes          | Yes          | Yes           |
      - EP             | Yes          | Yes          | Yes           |
      - ATP      (c)   | Yes          | No           | Yes           |
      - ZIP            | Yes          | Yes          | Yes           |
      - DDP            | Yes          | Yes          | Yes           |
    - ISO              |              |              |               |
      - ISO 8473 CLNP  | Yes          | No           | Yes           |
      - ISO 9542 ES-IS | Yes          | No           | Yes           |
    - Apollo Domain    | Yes          | No           | Yes           |
    - Novell IPX       | Yes  (a)     | Yes          | Yes           |
    - Banyan Vines     | Rel 8.2      | No           | No            |
    - X.25             | Yes          | Yes          | Yes           |
      - bridging       | Rel 9.0      | Yes          | No            |
      - routing        | Yes          | Yes          | Yes           |
      - switching      | Yes          | Yes          | No            |
    - Security         | Yes  (b)     | Rel 5.60     | No            |

 Notes:
 a. With cisco equipment, if there are both Ethernet and Token Ring
    interfaces, then DECnet cannot be run simultaneously with either
    Novell IPX or XNS.  This restriction will be removed in Release 8.2.
 b. cisco provides filtering/permitting/denying certain packets
    only for IPX, XNS and Appletalk in the section listed above.
 c. Not required for correct operation of a Phase II router.

 8. Management         |              |              |               |
    - Central managed  | Yes          | Yes          | Yes           |
    - SNMP             |              |              |               |
      - Platform       | Sun 3, Sparc | Sun 3, Sparc | 80286 AT      |
      - External       |              |              |               |
        software (b)   | No      (c)  | No           | No            |
      - X netmap       | Yes          | Yes          | Yes           |
        - Telnet to    |              |              |               |
          device  (d)  | Yes          | Yes          | Yes           |
      - X interactive  |              |              |               |
        performance    | Yes          | Yes          | Yes           |
      - History stats  | Yes          | Yes          | No            |
      - Report writer  | Yes     (c)  | No           | No            |
      - Alerts    (e)  | No           | No           | No            |
      - User defined   |              |              |               |
        extensions (m) | Yes          | Yes          | No            |
    - Usage stats      | Yes          | Yes  (f)     | Yes           |
    - Direct MIB access| No           | Yes          | No            |
    - PING             | Yes          | Yes  (g)     | No            |
    - Traceroute       | Yes          | No           | No            |
    - Telnet           | Yes     (h)  | Yes  (i)     | Yes (n)       |
    - MOP Remote Cons. | Rel. 8.2     | Bridged      | No            |
    - NICE        (j)  | No           | No           | No            |
    - Decnet connect   | No           | No           | No            |
    - Passwords (k)    | Yes          | Yes          | Yes           |
    - Disable lines    |              |              |               |
      dynamically      | Yes     (l)  | Yes          | Yes           |

 Notes:
 b. External software refers to the need to have some external
    software package available in order to run SNMP monitoring.
 c. cisco requires the Sybase database system in order to run their
    NMS software.  This package is bundled with their NMS.
 d. Ability to click on an icon on the X-11 network map and open
    a telnet connection to the device in question.
 e. Alerts refers to the ability to define a preset limit for a
    specific MIB variable at which point the SNMP monitoring software
    will present a window on top of the network map informing the
    network operator of the problem.
 f. Wellfleet interactive usage statistics are only for (ISO model)
    level 2.  Upper level statistics (such as RIP, UDP, TCP, Decnet
    HELLO, ARP) are not available.
 g. Wellfleet PING command stops after first failure and waits for
    user response.  This makes it very hard to check the total
    percentage of line failures over a short period of time.
 h. cisco is limited to 5 incoming Telnet sessions but has no
    limitation on outgoing Telnet sessions.
 i. Wellfleet Telnet is limited to one incoming and one outgoing
    session.
 j. NICE refers to the ability of the router to accept "SET EXECUTOR"
    as well as initiate a "SET EXECUTOR" to a remote host.
 k. Passwords refers to the ability to limit certain configuration and
    customization options only to those users who supply a password.
 l. cisco command is not an EXEC command but actually requires a
    configuration change to disable a line.
 m. The ability for the NMS software to add other vendor MIBs to their
    database, in order to manage these particular hardware units.
 n. Proteon is limited to 2 incoming and no outgoing sessions.

 9. Debugging &        |              |              |               |
     Monitoring        |              |              |               |
    - Data-Link Layer  | Yes          | Yes          | Yes           |
    - LAN              | Yes          | Yes          | Yes           |
    - Link             | Yes          | Yes          | Yes           |
    - Decnet           | Yes          | Yes          | Yes           |
    - Tcp/Ip           | Yes          | Yes          | Yes           |
    - Event log        | Yes          | Yes          | Yes           |
      - Network Logging| Yes          | Yes          | ??            |
      - Local Storage  | No           | Yes          | ??            |
    - Environmentals   | Yes          | No           | No            |

 Notes:
 a. Environmentals refers to the monitoring of variables such as
    fan, power supply, memory, temperature, etc.

 10. Performance  (a)  |              |              |               |
    - Router forward   | 4494         | 4494         | 1493          |
    - Router filter    | 4494         | 4494         | 1248          |
    - Bridge forward   | 4494         | 4494         | N/A           |
    - Bridge filter    | 4494         | 4494         | N/A           |
    - LAT compression  | Yes          | No           | No            |

 Notes:
 a. Performance based on 256 byte IP packets, between separate
    interface cards, with no packet loss.  Numbers listed are in
    packets per second.  Numbers based on Bradner report #3, Harvard
    University, Oct 1990.

 11. Survivability     |              |              |               |
    - alternate power  |              |              |               |
      supply           | No           | Yes   (d)    | No            |
    - standby line  (a)| No           | No           | No            |
    - fault tolerant(b)| No           | No           | No            |
    - field tolerant(c)| No           | No           | No            |
    - broadcast storms | Yes          | Yes          | Yes           |

 Notes:
 a. Standby line refers to the ability to define a line that is to be a
    hot standby, in the event that the primary line goes down.  The
    software switches all traffic automatically to the backup line.
 b. Fault tolerant refers to having redundent systems that are normally
    in standby mode, and that are only called into active mode in the
    event that the primary system fails.  Various systems are the power
    supply, the fan, the bus, the controller cards, etc.
 c. Field tolerant refers to the ability to withstand harsh elements
    and conditions out in the "field."
 d. Alternate power supply only available in large Concentrator model.
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 13:38:28 GMT
From:      tiamat!chromc!dynasys!jessea@uunet.uu.net  (Jesse W. Asher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal - what should we do?
In article <1990Oct28.220432.521@ddsw1.MCS.COM>, karl@mcs.MCS.COM (Karl Denninger) wrote the following:
>This is a call to action by all interested parties.
>
>There is wind of a proposal stirring in Washington that would place the 
>NSFNet backbone, and eventually the entire government-run part of the 
>Internet, into the hands of IBM.

Is there anything besides calling our elected officials that we can do?
Anyone else we should write to?  Should we have an overall plan of attack?
I know the modem line surcharge that was proposed a while back was hacked
because of the coordinated outpouring of indignation.  Let's do the same
thing with this crap.  Most of us think its a bad idea so let's stop saying
it's a bad idea and do something about it.  Ideas anyone?
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Nov 90 14:57 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Tim Evans <swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!oss670!tkevans@ucsd.edu>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   RE: SNMP Packages via Anonymous ftp?
>What SNMP packages are available via anonymous ftp--and from where?

(I apologize to the list for sounding like a broken record, but...)

Check RFC 1147.  It describes, and tells how to get, many free and
commercial products for managing TCP/IP internets.  In particular, it
tells how to get CMU's SNMP and MIT's SNMP via anonymous FTP.

- Bob Stine
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 18:22:00 GMT
From:      usc!cs.utexas.edu!sun-barr!newstop!texsun!netdev!alex@ucsd.edu  (Alex Huppenthal)
To:        tcp-ip@nic.ddn.mil
Subject:   Public Domain PPP Available?

  Looking for PPP freely-available software. Please respond by E-mail.
  
 -Alex

--
alex@netdev.comsys.com			Communication Systems Research
{cs.utexas.edu}!texsun!netdev!alex      Dallas, Texas 75252
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 21:56:31 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!athene!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
On 3 Nov 90 07:27:22 GMT, mcb@presto.ig.com (Michael C. Berch) said:

	[ ... on cheaper Internet access ... ]

mcb> Unless you meant some sort of access that would only be a few hours
mcb> per day, which misses the main advantage of Internet access in the
mcb> first place, which is real-time access to a large set of
mcb> distributed resources.  As an Internet user I can sit at my
mcb> workstation during business hours and log in to remote accounts,
mcb> FTP files to and from arbitrary locations all over the world, and
mcb> send and receive mail that arrives in seconds or minutes.

All these goodies COST MONEY. If you are the one signing the cheques and
you are given an option between instant service during business hours at
3X and evenings at X, maybe you think more than three times about the choice.

mcb> Dial-up SLIP or PPP on an after-hours batched basis can't offer those
mcb> services and do not, to my mind, provide much of an advantage over
mcb> dial-up UUCP.  "Real" Internet access, to me, means real-time access.

Note that dialup IP connections are indeed non batched -- it is
applications that would be batched, waiting for the IP connection to be
established. Just like sendmail does today wih SMTP.

The difference between dialup IP and dialup UUCP is that UUCP can only
be offline, while IP can also be online. The difference between dialup
IP and direct link IP is that dialup IP does not give continuous access,
but only on request. It is up to you do delay the request or not.

So the issue is not batched vs. online, but continuous vs. on demand.

Once we all have ISDN and IP over ISDN we will all have continuous IP at
the same price as dialup IP; for now, dedicated lines offering
continuous Internet connectivity are expensive...
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Nov 90 08:17:53 -0600
From:      David Borman <dab@berserkly.cray.com>
To:        BILLW@mathom.cisco.com, mmorse@z.nsf.gov
Cc:        tcp-ip@NSF.GOV
Subject:   Re: Problem with Xmodem and 3Com terminal server
> Also, some telnet implementations ignore the "7-bit" definition, and
> routinely send 8 bit data anyway.  This is useful, but means that a
> telnet terminal server strictly adhering to the standard might not work
> as well as one with a more flexible interpretation.  The Hosts Requirement
> document was carefully worded to allow 8-bit transmission, as long as
> you were doing actual "parity".
      ^^^^^^^^^^
> Bill Westfield

That should have been "were NOT doing"...

I assume that Bill just made a typeo.  Everyone should be aware that
the Hosts Requirement document was carefully worded to allow 8-bit
transmission while in Telnet NVT mode, but we were very explicit
that the eighth bit is NOT a "parity" bit, and any implementation that
transmits 7-bit data with the eighth bit as a parity bit is broken.

			-David Borman, dab@cray.com
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 22:47:07 GMT
From:      prism!prism.gatech.EDU!ce1zzes@gatech.edu  (Eric Sheppard)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet question
I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file.
I've set an environment variable CONFIGTEL to point to this file (as 
mentioned in the docs), but the programs still can't find it.  Is the
environment variable different?

Eric 
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Nov 90 22:53:24 GMT
From:      prism!prism.gatech.EDU!ce1zzes@gatech.edu  (Eric Sheppard)
To:        tcp-ip@nic.ddn.mil
Subject:   Mail for PC with Ethernet?
What are the various packages available that can process (send and receive)
mail on the PC platform?  I'm hooked up to the Ethernet with a 3C503 card,
and I'm currently using packet drivers with it.  I've experimented with 
MUSH a bit, but I couldn't get it to work; probably missing some important
pieces.  What is out there?

Eric
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Nov 90 09:47:31 -0500
From:      aggarwal@nisc.jvnc.net (Vikas Aggarwal)
To:        icarus.eng.ohio-state.edu!kaul@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Configuring a Sun to use DNS
>  3c. Remove the libresolv module that contains `strncasecmp' (which is now
>      in the main C library, so it is redundant):
>  	# rm strcasecmp.o

The present 4.8.3 bind distribution also has some other "strxxx"
routines- any problems if these are also included in the shared
library ? (these routines are not present in the Sun libresolv
or in the libc provided).

I allude to the following routines provided with the bind 4.8.3
distribution:

	herror.o
	mktemp.o
	strerror.o
	strpbrk.o


-vikas

  vikas@nisc.jvnc.net					(609) 258-2403
--------------------------------------------------------------------------
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Nov 90 12:27:10 -0500
From:      aggarwal@nisc.jvnc.net (Vikas Aggarwal)
To:        tcp-ip@nic.ddn.mil
Subject:   SENDMAIL configuration

I have spent enough time trying to figure it out for myself, and
now I want to know if there is an easier way...

I am trying to set up sendmail on our Sun 4, and I have the latest
version of bind and sendmail (with MX kludge, etc, etc) running.

I have a host, call it "A.FOO.NET", and I wanted that mail addresses
of the form "user@foo.net" be accepted by the mailer on A.FOO.NET.

I set up an MX record for FOO.NET which points to A.FOO.NET so
that mail destined for "user@foo.net" gets to this host atleast.
My problem lies in the A.FOO.NET mailer accepting the fact that
mail addressed to "user@foo.net" actually implies itself.

I am using the standard Berkeley config files, and finally got
the whole thing to work by adding ruleset 8 where I replaced
an occurrence of "@DOMAIN" with "@host.domain".

I have bounced mail of berkley.edu (a.k.a ucbvax.berkeley.edu)
and noticed that that mailer does not do any replacement stuff.
I would prefer to do something like that.

Can I create a name server entry where "A.FOO.NET" is a CNAME
for "FOO.NET" - then the resolver routines will automagically
replace the FOO.NET with A.FOO.NET - but maybe my nameserver
will choke...

Any ideas / suggestions (postmaster@berkeley.edu ....?!!) ??


-vikas

  vikas@nisc.jvnc.net					(609) 258-2403
--------------------------------------------------------------------------
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      Mon 5 Nov 90 12:41:43-PST
From:      William Chops Westfield <BILLW@mathom.cisco.com>
To:        dab@berserkly.cray.com
Cc:        mmorse@z.nsf.gov, tcp-ip@NSF.GOV
Subject:   Re: Problem with Xmodem and 3Com terminal server
    From: David Borman <dab@berserkly.cray.com>
    > you were doing actual "parity".
	  ^^^^^^^^^^
    > Bill Westfield

    That should have been "were NOT doing"...


oops.  It was a typo, and Dave is exactly correct.

Sorry
BillW
-------
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Nov 90 13:21:45 -0500
From:      jcurran@SH.CS.NET
To:        tcp-ip@nic.ddn.mil
Cc:        jcurran@SH.CS.NET
Subject:   Re: Cost of Internet access
Dialup IP services are quite inexpensive, and if set up with care will
give all the advantages of a dedicated circuit only with an occasional
30 second delay (those times when the line must be brought up.)

Yes, dedicated circuits are very nice.  But if it takes a dial-up line 
to get some companies on the Internet, then so be it.

/John
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Nov 90 15:55:08 PST
From:      wrs!yuba!hwajin@uunet.UU.NET (Hwa Jin Bae)
To:        jackson@neon.stanford.edu, uunet!asylum.sf.ca.us!romkey@uunet.UU.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Source Code Search
>Many people use the Berkeley code as a start. It's an excellent
>protocol engine; its main drawback is that it really really wants to
>live inside a UNIX kernel. It often takes many man-months to port
>properly. You can find it on uunet.uu.net for anonymous FTP.

berkeley code is actually pretty portable.  it's really not that hard
to port berkeley code to non-unix environment.  you need to write a set
of compatible routines -- spl*(), splx() can be emulated using semaphores,
timeout() can be emulated in most operating systems that support 
watchdog timers of some sort, sleep() (kernel version) can be done
via a semaphore or mailbox, wakeup() the same way, perror() and panic()
are trivial, cluster mbuf can be emulated if you change the mbuf structure
slightly even on systems that lack virtual memory, etc.   i'm speaking
from my experience... your mileage may vary.

hwajin
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 08:12:57 GMT
From:      uupsi!sunic!lth.se!newsuser@nyu.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA Telnet question
In article <16367@hydra.gatech.EDU> ce1zzes@prism.gatech.EDU (Eric Sheppard) writes:
>I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file.
>I've set an environment variable CONFIGTEL to point to this file (as 
>mentioned in the docs), but the programs still can't find it.  Is the
>environment variable different?
>
I have a .bat file containing the line:
d:\ncsa\telbin -h d:\ncsa\config.tel %1 %2 %3 %4 %5

( I don't remember why it looks like this - it was some time ago since I
installed it.)
The version inquestion is 2.2DSb, but don't take the version letters too
seriously; it's been modified for use with Swedish national characters.
The basic program is the same though...



-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      05 Nov 90 15:29:27 EST
From:      Christopher Allen (SIBU Special Systems) <Allen@Relay.Prime.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted: IP directly over HDLC
Hi,
     We have an opportunity here to productize a capability of doing
IP over serial lines.  The way I've prototyped this is to encapsulate
IP datagrams directly into HDLC framing (ISO 3309), without any of the
"upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff.

     We were wondering if there are any implementations out there that are
also able to do this.  Both Wellfleet and cisco boxes come to mind, but are
there any other implementations that can do this in a non-proprietary manner?

     Note: I am aware of PPP and am not interested in implementing it as a
solution at this time.

     Please email me directly; I will post a summary if enough interest.

-Chris Allen
 allen@relay.prime.com
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 11:25:00 GMT
From:      CBAD33@UCVAX.ULSTER.AC.UK
To:        comp.protocols.tcp-ip
Subject:   help

Could you please help me.  I am trying to gather addresses of companies/
academic institutions who are involved with Wide Area Distribution of
Geographic Information.  This would involve the capture of aerial photographs,
digitizing the image, and transferring the resultant material from location to
location, based on requirements.  Thus, workstations would exist at key
sites around the Area, displaying the information to users who access it for
particular applications (line maps with data superimposed showing drainage/
telephone cables/elecdtrical ducts), maybe even the location of medical
facilities on a town/city map, which would be of interest to planners etc.
The obvious problem to the communications engineer, is how to best provide a
communications infrastructure to service such a facility at many locations.
The problem is compounded by the time scales and class of data being
transferred.  A user requesting a raster image of a node of a particular line
map will want to see the hotel/hospital/golf course that has been highlighted
by the mouse, so the amount of information required to satisfy the query is
suddenly increased many fold.  The time scale is such that one does not want
the user to have to wait minutes while this image is transferred from a server
located somewhere.

What I would like is any clues as to who is involved in this area, that
includes companies/universities/real=life commercial/research institutions etc.

I can assure you that any information will only be used for research purposes.

I would require the e.mail addresses or postal addresses of the places
concerned.  Please direct your replies to my e.mail address.
Thanks for your time


Dr Gerard Parr
Department of Applied Computing
Institute of InformAtics
University of Ulster
Derry

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Nov 90  11:25 GMT
From:      CBAD33%UCVAX.ULSTER.AC.UK@pucc.PRINCETON.EDU
To:        TCP-IP@NIC.DDN.MIL
Subject:   help
Could you please help me.  I am trying to gather addresses of companies/
academic institutions who are involved with Wide Area Distribution of
Geographic Information.  This would involve the capture of aerial photographs,
digitizing the image, and transferring the resultant material from location to
location, based on requirements.  Thus, workstations would exist at key
sites around the Area, displaying the information to users who access it for
particular applications (line maps with data superimposed showing drainage/
telephone cables/elecdtrical ducts), maybe even the location of medical
facilities on a town/city map, which would be of interest to planners etc.
The obvious problem to the communications engineer, is how to best provide a
communications infrastructure to service such a facility at many locations.
The problem is compounded by the time scales and class of data being
transferred.  A user requesting a raster image of a node of a particular line
map will want to see the hotel/hospital/golf course that has been highlighted
by the mouse, so the amount of information required to satisfy the query is
suddenly increased many fold.  The time scale is such that one does not want
the user to have to wait minutes while this image is transferred from a server
located somewhere.

What I would like is any clues as to who is involved in this area, that
includes companies/universities/real=life commercial/research institutions etc.

I can assure you that any information will only be used for research purposes.

I would require the e.mail addresses or postal addresses of the places
concerned.  Please direct your replies to my e.mail address.
Thanks for your time


Dr Gerard Parr
Department of Applied Computing
Institute of InformAtics
University of Ulster
Derry
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 17:42:39 GMT
From:      bourkej@ul.ie
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   MultiLan vs Wollongong for VAX/VMS ?????

Can anyone compare the relative merits of TGV MultiLan and the Wollongong
offering for VMX/VMS ?

I'm told MultiLan is the bees knees, but does Wollongong live up to it ?


John Bourke								 O-O
<bourkej@ul.ie>								  | 
Information Technology Department,					# _ #
University Of Limerick, Ireland.					 ###

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 18:21:45 GMT
From:      jcurran@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   Re: Cost of Internet access

Dialup IP services are quite inexpensive, and if set up with care will
give all the advantages of a dedicated circuit only with an occasional
30 second delay (those times when the line must be brought up.)

Yes, dedicated circuits are very nice.  But if it takes a dial-up line 
to get some companies on the Internet, then so be it.

/John

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 18:50:18 GMT
From:      van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!GHOLAN@ucbvax.Berkeley.EDU  (Geoffrey Holan)
To:        tcp-ip@nic.ddn.mil
Subject:   pc-routers
Three quick questions:
1. Has anyone converted ka9q to Microsoft c from turbo ?
2. Has anyone put snmp into ka9q ?
3. Does anyone know where I could find CMU's pcrouter with snmp
   support?
                thanks in advance.
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 19:06:37 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   LPD for the Mac?

I guess this is THE lpd everyone likes and that can be FTPed from some place.
What I am looking for is one that would operate as a background process
under MacTCP and print via the Mac print spooler on Appletalk Laserwriter.
Or any functionally equivalent solution.
Or a MacIntosh oriented TCP/IP mailing list as a better place to ask.
I have connected Appletalk to Ethernet with the (excellent) PCROUTE.

Many thanks in advance.

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

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 20:29:27 GMT
From:      Allen@RELAY.PRIME.COM (Christopher Allen, SIBU Special Systems)
To:        comp.protocols.tcp-ip
Subject:   Wanted: IP directly over HDLC

Hi,
     We have an opportunity here to productize a capability of doing
IP over serial lines.  The way I've prototyped this is to encapsulate
IP datagrams directly into HDLC framing (ISO 3309), without any of the
"upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff.

     We were wondering if there are any implementations out there that are
also able to do this.  Both Wellfleet and cisco boxes come to mind, but are
there any other implementations that can do this in a non-proprietary manner?

     Note: I am aware of PPP and am not interested in implementing it as a
solution at this time.

     Please email me directly; I will post a summary if enough interest.

-Chris Allen
 allen@relay.prime.com

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 21:42:19 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!usenet@ucsd.edu  (Brian Wolfe)
To:        tcp-ip@nic.ddn.mil
Subject:   Cheap (or Free) TCP-IP summary

Here is the summary of Cheap TCP-IP implementations for VAX/VMS:

I receieved about 15 responses pointing me towards CMU/TEK TCP-IP,
a few people thought that it was painful to get working and that
they thought Multinet was cheaper in terms of their time. Several
people recommended CMU/TEK as a very solid alternative to Wollengong,
TGV et al, although they thought that CMU didn't scale well on a large 
machine.

For this price I'm going to try it and see how things go, if it 
doesn't do exactly what we need at least we should be able to do something  
until we can budget the money for a commercial TCP.

Here is a typical response...
-------------------------------------------------------------------
CMU/TEK TCP-IP  This is a full-blown implementation, including Telnet,
FTP, SMTP support, LPR and Finger.  It is very stable and well-supported.


Order from:
Karen Heilman, CMU (412) 268-5896  karen.heilman@andrew.cmu.edu

There is a mailing list, cmu-tek-tcp@andrew.cmu.edu, that you can
subscribe to (cmu-tek-tcp-request@andrew.cmu.edu)


--
-------------------------------------------------------------------------
Brian Wolfe                    Internet: baw@terminator.cc.umich.edu
Systems Analyst                UUCP:     {rutgers,uunet}!sharkey!hfhrv!brian
Henry Ford Hospital 	       Voice:    (313)-876-7461
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Nov 90 20:06:37 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   LPD for the Mac?
I guess this is THE lpd everyone likes and that can be FTPed from some place.
What I am looking for is one that would operate as a background process
under MacTCP and print via the Mac print spooler on Appletalk Laserwriter.
Or any functionally equivalent solution.
Or a MacIntosh oriented TCP/IP mailing list as a better place to ask.
I have connected Appletalk to Ethernet with the (excellent) PCROUTE.

Many thanks in advance.

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
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 21:53:58 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!caen!umich!terminator!usenet@ucsd.edu  (Brian Wolfe)
To:        tcp-ip@nic.ddn.mil
Subject:   Berkeley Socket Libraries for Macintosh?
Does anyone know if there is a Berkeley sockets API
(for TCP-IP) available for the Macintosh? The people I've spoken 
to at Wollengong have said that they will have such a product    
in about 6 months.

regards,

Brian



--
Brian Wolfe                    Internet: brian@rpslmc.edu
Rush Medical Center            Voice:    (312)-942-5781
Chicago, IL 60612 	       FAX:      (312)-942-2114 
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 22:29:14 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!halley!news@ucsd.edu  (usenet news)
To:        tcp-ip@nic.ddn.mil
Subject:   X.25 Host Interface Specification?
Where might I obtain a copy of the following document?

    "Defense Data Network X.25 Host Interface Specification"

Your help is greatly appreciated.

Phil Webster        (Keep trying if halley bounces mail.  It's flakey)
(cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com)
 ^Preferred                                   ^Most reliable (?)
-----------------------------------------------------------------------
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Nov 90 23:45:10 GMT
From:      arc!chet@apple.com  (Chet Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   How do you use Dial-up SLIP?
It appears SLIP was designed for people who want to extend their IP
universe from work to home. I'm sure that it works fairly well for
this. But now organizations can use it to connect with the Internet.
The logistics of using it for this seem awkward. Would those who are
making use of this service kindly tell me how they make it work?

Here's how I suppose it works:

User dials up the network service provider using tip, and logs in with
a name and password. 

In another window, you run "slip-attach" to configure the interface.

Then you do your ftp, or whatever.

Then you kill the slip-attach process with -HUP and somehow get the
modem to hang up.

There are several things wrong with this picture. 

1. Am I supposed to tell all our users our login name and password on
our providers equipment? Seems like a security risk to me.

2. Who pays the phone bill when a user forgets to hang up after a
session?

[ A/UX 2.0 - specific ]
3. Based on my very limited experimentation, killing slip-attach (or
whatever it's called) on the Mac sometimes leaves grunge around so that it
cannot be run again without rebooting the machine.

It seems to me, because of these things, that it would be more than
worth it to use a leased line for SLIP access, unless someone can tell
me of some effective workarounds...

Thanks...

Chet
--
Chet Wood                       ~                         (408)727-3357 X269
   chet@Advansoft.Com    .  Advansoft Research Corporation
     arc!chet@apple.COM    .      4301 Great America Parkway, 6th floor
            apple!arc!chet   .            Santa Clara, CA 95054, USA
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 00:36:52 GMT
From:      bacchus.pa.dec.com!mogul@decuac.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for utility to monitor RIP packets
In article <775@casbah.acns.nwu.edu> matt@acns.nwu.edu writes:
>I am looking for a UNIX utility that will listen for all the RIP
>packets on a network and display their contents.  I am essentially
>trying to duplicate the output of a cisco router with RIP debugging
>turned on.  The output looks something like:
>
>Received RIP update from xxx.xxx.xxx.xxx:
>  network yyy.yyy.yyy.yyy in n hops
>  network zzz.zzz.zzz.zzz in m hops
>  ...

The "tcpdump" program (from the folks at LBL) decodes RIP packets,
among others.  A new version of tcpdump is being tested at the moment;
it now includes support for Ultrix systems and 4.3BSD, as well as the
SunOS support it has always had.  No, I don't know when the latest
version will be available, but you probably shouldn't bother to
write your own.

The output format is a little different, but otherwise you should
get all the information you want.  For example:
16:34:07.612 16.1.16.252.520 > 16.1.31.255.520: rip-resp 25:
    16.183.1.0(8) 16.10.0.1(3) 16.10.16.3(9) 16.10.0.4(3) 16.10.16.4(3)
    16.10.16.5(5) 16.10.16.6(4) 16.10.16.8(3) 16.4.16.12(5) 16.10.16.13(4)
    16.10.16.14(8) 16.10.16.16(3) 16.10.16.17(8) 16.10.16.18(8)
    16.10.16.20(3) 16.4.16.22(5) 16.4.16.23(5) 16.10.16.23(4)
    16.10.16.24(5) 16.10.16.25(5) 16.10.16.26(5) 16.36.192.0(7)
    16.68.192.0(7) 16.26.192.0(7) 16.153.192.0(7)

-Jeff
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Nov 90 10:02:32 -0500
From:      barns@gateway.mitre.org
To:        halley!phil@cs.utexas.edu
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: X.25 Host Interface Specification?
This document is available through the Defense Technical Information
Center as accession number ADA 137427.  You must be registered with
DTIC to get documents from them, and you must be a government contractor
or potential contractor or other specifically authorized type of entity
to get registered.  Most medium or large companies that do business
with DOD are already registered, usually via their library or marketing
organization.  The payment mechanism runs through NTIS and DTIC will
give you information on setting up a deposit account with NTIS.

Since this document has an ADA number, you can probably get the document
directly from NTIS.  NTIS usually costs more than DTIC, but they are
often a little quicker (potentially overnight if you don't mind paying
about four times as much).  For normal NTIS orders, call them at
(703) 487-4650.  For rush orders, call (800) 336-4700 or (703) 487-4700.

This document is almost 7 years old and is somewhat behind the times.
A revision is somewhere in the works.  Implementations built to this
spec will still work, but some areas of possible interest such as
support of GOSIP protocols are not discussed in it.  I think I am on
the hook to draft the DDN OSI Subscriber Interface document.  Feel free
to send me questions and comments.  I'll try to respond if I am able,
or will try to identify an appropriate contact in DCA or wherever.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 10:01:37 PST (Tue)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        wrs!yuba!hwajin@uunet.uu.net
Cc:        jackson@neon.stanford.edu, tcp-ip@nic.ddn.mil
Subject:   TCP/IP Source Code Search
Well, my experience from watching many people port the Berkeley code
is that it's a four to six month effort to get it working.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 04:35:59 GMT
From:      att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@ucbvax.Berkeley.EDU  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Definitive TCP, IP, UDP
If I wanted the definitive word on what TCP is, for example, I imagine I could
slog through the list of RFCs and figure out what obsoletes what, print out
all the ones that seem relevant and scratch my head.  Is there a document out
there (say an RFC in preparation) that describes exactly how all parts of the
protocol work (RTT calculations, options, etc.)? How about for IP and UDP?

-Johnny TCP
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 05:36:33 GMT
From:      amdcad!brahms!ching@ucbvax.Berkeley.EDU  (Mike Ching)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
In article <9010311729.AA07194@braden.isi.edu> braden@VENERA.ISI.EDU writes:
>I would like to suggest that IBM-bashing, no matter how enjoyable a 
>pastime for some, is not an appropriate use of this mailing list.
>Besides, it is very BORING.
>
>Bob Braden

But the bashing is not unwarranted. Prodigy (owned by IBM and Sears Roebuck)
cancelled membership of people who protested new per-message fees by con-
tacting advertisers. Complaining to advertisers was considered harassment.
Is IBM a company you want administering your network?

Mike Ching

Disclaimer: My opinions do not represent those of my employer.
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Nov 90 12:10:14 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   PPP and VJ's Header Compression for SUNs

Does anyone know where I can get the necessary sources to add PPP and
hopefully VJ's Header Compression to SUN 3's and 4's??  Or are we still
stuck with slip even when something better has been devised??

Any pointers??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 08:53:17 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net  (Daniel Huber)
To:        tcp-ip@nic.ddn.mil
Subject:   3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
I'm searching for a TELNET client software which emulates IBM 3270.

I know there is a PD tn3270 package somewhere in an archive.
I'm also able to get it, but before I ask somebody to download it for me,
I have some questions.
I try to connect our CAD environment (based on HP9000/3xx, 835) and the
engineering environment (based on Sun) to our AS/400 (OS/400). 
IBM's AS/400 has a TCP/IP solution which supports FTP, TELNET etc.
The TELNET server (also the client) on the IBM only supports ASCII
streams, 3270 or 5250. For our applications we need at least the 3270
emulation.
As I understand, the TELNET client must support 3270 emulation. In fact,
the AS/400 expect a 3270 controller (I'm not sure about this) so the 
client has to simulate that. 
The user himself use his terminal as a 3270 terminal (with a quite
different keyboard :-)  ).

Questions:

	- Does tn3270 have all this features I need ?
	- Is there another product available (as tn3270) ?
	- Is tn3270 usefull (speed, performance, keyboardmapping...) ?
	- Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ?
	- Does tn3270 work with X-Windows(Openlook and Motif), Sunview
	  and ASCII Terminals ?
	- Is tn3270 also usefull over 9600 Baud Modem ? 
	  (Terminal->modem->UNIX->tcpip->AS/400)
	- Native language support ?


Thanks for all answers. (Do I get any ?)    :-)


Daniel

-- 
Daniel Huber		Tel.	+41 31 52 96 64
Ascom Autelca		Fax.	+41 31 52 53 01
CH-3073 Guemligen	email:	dhuber@autelca.ascom.ch
Switzerland		uucp:	uunet!mcsun!chx400!hslrswi!aut!dhuber
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Nov 90 16:35:47 EST
From:      THIER@ORCAD2.dnet.ge.com
To:        tcp-ip@nic.ddn.mil
Subject:   Determining Socket Status

	I am implementing a UDP/TCP/IP communication software package 
for a small network of SPARCStation 1+'s running 4.1 and Motorola
MVME147 boards running VADSWorks. Message receive tasks are to be
kicked off using the asynchronous I/O mechanism.

	My approach is to utilize SIGIO to alert the receive processing
to socket activity, and then use SELECT and the associated mask
manipulation macros to identify the active sockets. What I haven't
figured out is how to determine the cause of a given SIGIO. Sun 
documentation states that the signal is posted upon state changes to
the socket. Fair enough, but how does one go about determining
which change (e.g, connection establishment/disestablishment, data
available in receive queue, etc.) has occurred? SELECT, I assume,
flags data availability, but a look at the socket state #defines 
(SS_NODREF, etc.) tells me that I need more than that to safely 
multiplex sockets. Is there a socket (or file) status call that I'm
missing? Thanks in advance.


John Thier
GE DSD
Pittsfield MA
thier@orcad2.dnet.ge.com

 	


-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Nov 90 23:47:10 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   PPP for Sun OS....
>CSLIP and SLIP sources for Sun 3 & 4 systems are available from
>uunet and several other systems.  As of Interop, I have not seen
>or heard of a WORKING PPP for SunOS.  Good Luck!
>
>===============================================================================
>Cerafin E. Castillo                       ||      //\\  ||\\  ||

We have had one for the better part of a year now and it does work. The
problem with it is that it is written to run on top of the lower layer
drivers provided as part of Sun's INR package and thus it's difficult to
distribute. We have no problem distributing it and we even have an
independent lower layer driver that will work on Sun's. But we're not
willing to support it....

					Torben
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 13:55:08 GMT
From:      AYYOUB@TRMETU.BITNET (Ayyoub)
To:        comp.protocols.tcp-ip
Subject:   Re: Industrial Computing Society - Call for Papers

Dear Mr. OZGIT

I have posted the article to metu.campus.news group today at 14:00.
Most probably you got the draft for October's CCNEWS from ISIK. Pls
let me know as soon as you finish reviewing it. Pls know that we are
a little late, so I would like to submitt to Matbaa asap.

Regards
Ayyoub

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 14:19:50 GMT
From:      AYYOUB@TRMETU.BITNET (Ayyoub)
To:        comp.protocols.tcp-ip
Subject:   Re: Industrial Computing Society - Call for Papers

Sorry the last mail was sent by mistake.
Ayyoub

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 15:07:29 GMT
From:      world!bzs@uunet.uu.net  (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Definitive TCP, IP, UDP

>If I wanted the definitive word on what TCP is, for example, I imagine I could
>slog through the list of RFCs and figure out what obsoletes what, print out
>all the ones that seem relevant and scratch my head.  Is there a document out
>there (say an RFC in preparation) that describes exactly how all parts of the
>protocol work (RTT calculations, options, etc.)? How about for IP and UDP?

Sounds like you want Doug Comer's textbook, "Internetworking with
TCP/IP", Prentice-Hall. Should be available at any college bookstore.

-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Tue 6 Nov 90 23:57:33-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        Allen@Relay.Prime.COM
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Wanted: IP directly over HDLC
     We have an opportunity here to productize a capability of doing IP
    over serial lines.  The way I've prototyped this is to encapsulate IP
    datagrams directly into HDLC framing (ISO 3309), without any of the
    "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff.

Indeed, this is what almost all of the major router vendors do.  PPP is
also like this except that there is a potential of doing millions of lines
of code to support all the random option negotiation.


    We were wondering if there are any implementations out there that are
    also able to do this.  Both Wellfleet and cisco boxes come to mind,
    but are there any other implementations that can do this in a
    non-proprietary manner?

As far as I know, wellfleet and cisco "hdlc" encapsulations are only
"proprietary" in that no one else does them - they aren't big secrets.
(Ill enclose a description of cisco's spec later in this message...)


    Note: I am aware of PPP and am not interested in implementing it as a
    solution at this time.

Why not?  I would think that this would be a good idea, especially if
you leave out the negotiation of the millions of options.  A "minimal
subset" (refuse all options) of PPP is not difficult, and even a format
equivilent to PPP with not option negotiation supported at all (eg only
the PPP wire format) probably has a better interoperability future than
anything else...

Bill Westfield
cisco Systems.


                        cisco Serial Line Encapsulation
                        -------------------------------

cisco's default encapsulation on synchronous serial lines uses HDLC framing,
with packet contents defined as follows:

The first ("address") octet is set to 0x0F for unicast packets and 0x8F
for broadcast packets. Broadcast just means that the higher-level protocol
thought this was a broadcast packet; cisco doesn't support multidrop
HDLC at this time.

The second ("control") octet is always 0.

The next two octets are a 16-bit protocol code, sent most-significant-first.
These codes are usually Ethernet type codes. cisco has added some codes to
support packet types that don't appear on Ethernets. The current list of codes
is as follows:

        TYPE_PUP                0x0200  PUP
        TYPE_XNS                0x0600  XNS
        TYPE_IP10MB             0x0800  IP
        TYPE_CHAOS              0x0804  Chaos
        TYPE_IEEE_SPANNING      0x4242  DSAP/SSAP for IEEE bridge spanning prot.
        TYPE_DECNET             0x6003  DECnet phase IV
        TYPE_BRIDGE             0x6558  Bridged Ethernet/802.3 packet
        TYPE_APOLLO             0x8019  Apollo domain
        TYPE_REVERSE_ARP        0x8035  cisco SLARP (not real reverse ARP!)
        TYPE_DEC_SPANNING       0x8038  DEC bridge spanning tree protocol
        TYPE_ETHERTALK          0x809b  Apple EtherTalk
        TYPE_AARP               0x80f3  Appletalk ARP
        TYPE_NOVELL1            0x8137  Novell IPX
        TYPE_CLNS               0xFEFE  ISO CLNP/ISO ES-IS DSAP/SSAP

This list is shared between serial and Ethernet encapsulations. Not all
these codes will necessarily appear on serial lines. This list will probably
be extended as cisco adds support for more protocols.

Bytes after this are higher-level protocol data. These normally look the
same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
MAC headers; no other packets do.

Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers to
as SLARP. SLARP has two functions: dynamic IP address determination and
serial line keepalive.

The serial line model supported by SLARP assumes that each serial line is
a separate IP subnet, and that one end of the line is host number 1, while
the other end is host number 2. The SLARP address resolution protocol allows
system A to request that system B tell system A system B's IP address,
along with the IP netmask to be used on the network. It does this by sending
a SLARP address resolution request packet, to which system B responds with a
SLARP address resolution reply packet. System A then attempts to determine its
own IP address based on the address of system B. If the host portion of system
B's address is 1, system A will use 2 for the host portion of its own IP
address. Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than 1 or 2,
system A assumes that system B is unable to provide it with an address via
SLARP.

For the SLARP keepalive protocol, each system sends the other a keepalive
packet at a user-configurable interval. The default interval is 10 seconds.
Both systems must use the same interval to ensure reliable operation.
Each system assigns sequence numbers to the keepalive packets it sends,
starting with zero, independent of the other system. These sequence numbers
are included in the keepalive packets sent to the other system. Also included
in each keepalive packet is the sequence number of the last keepalive packet
_received_ from the other system, as assigned by the other system. This number
is called the returned sequence number. Each system keeps track of the last
returned sequence number it has received. Immediately before sending a keepalive
packet, it compares the sequence number of the packet it is about to send with
the returned sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line to have failed, and
will route no further higher-level data across it until an acceptable keepalive
response is received.

There is interaction between the SLARP address resolution protocol and the
SLARP keepalive protocol. When one end of a serial line receives a SLARP
address resolution request packet, it assumes that the other end has restarted
its serial interface and reset its keepalive sequence numbers. In addition
to responding to the address resolution request, it will act as if the
other end had sent it a keepalive packet with a sequence number of zero,
and a returned sequence number the same as the returned sequence number
of the last real keepalive packet it received from the other end.

The following is a C definition for the SLARP packet. The "long" and "ulong"
types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit
number, high octet sent first.

        struct slarp {
            long code;          /* SLARP packet type code */
        union sl {              /* followed by one of: */
            struct {                    /* Address resolution functions */
                ulong address;          /* Address of system sending this pkt */
                ulong mask;             /* IP subnet mask for this line */
                ushort unused;          /* Unused: contents undefined */
            } add;              /* -- or -- */
            struct {                    /* Keepalive probing functions */
                ulong mysequence;       /* Outgoing sequence number */
                ulong yoursequence;     /* Returned sequence number */
                ushort reliability;     /* Reserved: set to FFFF */
            } chk;
          } t;
        };

Note that the data storage for t.add is overlayed on the data storage for
t.chk. The whole SLARP packet consists of a 32-bit type code, followed by
two 32-bit quantities and one 16-bit quantity. The overall length of the
SLARP packet is 14 octets. The "code" field is used to identify the packet's
SLARP type. Legal values for the "code" field are as follows:

        SLARP_REQUEST   0       Address resolution request
        SLARP_REPLY     1       Address resolution reply
        SLARP_LINECHECK 2       Line keepalive

For address resolution request packets, the "address" and "mask" fields are
set to zero, and the contents of the "unused" field field are undefined. For
address resolution reply packets, the "address" field contains the IP address
of the _replying_ system, and the "mask" field contains the IP subnet mask
to be used. The contents of the "unused" field are undefined.

For keepalive packets, the "mysequence" field contains the sequence number
of the packet and the "yoursequence" field contains the returned sequence
number, which is the sequence number of the last keepalive packet the sending
system has gotten from the receiving system. The "reliability" field is
reserved for future use, and _must_ be set to FFFF hexadecimal.
-------
-------
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Nov 90 14:05:52 TUR
From:      Ayyoub <AYYOUB%TRMETU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Industrial Computing Society - Call for Papers
Dear Mr. OZGIT

I have posted the article to metu.campus.news group today at 14:00.
Most probably you got the draft for October's CCNEWS from ISIK. Pls
let me know as soon as you finish reviewing it. Pls know that we are
a little late, so I would like to submitt to Matbaa asap.

Regards
Ayyoub
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Tue, 06 Nov 90 14:17:50 TUR
From:      Ayyoub <AYYOUB%TRMETU.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Industrial Computing Society - Call for Papers
Sorry the last mail was sent by mistake.
Ayyoub
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 16:20:54 GMT
From:      usc!samsung!b-tech!zeeff@ucsd.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you use Dial-up SLIP?
> stuff about dial-up slip

>1. Am I supposed to tell all our users our login name and password on
>our providers equipment? Seems like a security risk to me.
>
>2. Who pays the phone bill when a user forgets to hang up after a
>session?

All you need is a little program to detect the need for an outgoing 
connection, dial up and establish the connection, and then drop it 
when there is not traffic for some period.  It's not hard (I've done 
it).  




-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 17:10:14 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   PPP and VJ's Header Compression for SUNs


Does anyone know where I can get the necessary sources to add PPP and
hopefully VJ's Header Compression to SUN 3's and 4's??  Or are we still
stuck with slip even when something better has been devised??

Any pointers??

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

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

Well while you are waiting for theirs, give Novell a call they have been
selling such a beast for the last 2-3 years.  They call it TCPort, yeah I
know it looks like TCP - ort, what an ort is I don't know.  But given a call
and take a look at it.  It should be compatable with their TCP/IP stack and
with Apple's MacTCP.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 19:44:32 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LPD for the Mac?
In article <9011060338.AA11437@ucbvax.Berkeley.EDU>,
PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) writes:
> I guess this is THE lpd everyone likes and that can be FTPed from some place.
> What I am looking for is one that would operate as a background process
> under MacTCP and print via the Mac print spooler on Appletalk Laserwriter.
> Or any functionally equivalent solution.
> Or a MacIntosh oriented TCP/IP mailing list as a better place to ask.
> I have connected Appletalk to Ethernet with the (excellent) PCROUTE.
> 
> Many thanks in advance.
> 

If you just want to be able to use MacTCP and print on AppleTalk at the sametime,
you don't need a lpd.?.?  Just set the printer to AppleTalk within Chooser,
and set MacTCP to be running on your ethernet card.  There isn't much else
to it.

Now if you want to print from a UNIX box to the LaserWriter hanging off of
AppleTalk, that's a different story.

This list, so far, is about the best place to talk about TCP/IP and the Macintosh,
the only other list you could try is comp.sys.mac.comm.

Hope this helps.
--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 20:55:01 GMT
From:      jcurran@SH.CS.NET (John Curran)
To:        comp.protocols.tcp-ip
Subject:   UDP Checksumming of IP addresses

I'm sure I've overlooked something, and could use a push..
 
Why does UDP (when used with checksumming enabled) create a pseudo-header 
that contains both the port numbers and the source and destination IP 
addresses?  Isn't it already protected from address changes by the datagram
checksum?

/John

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Nov 90 20:55:01 GMT
From:      John Curran <jcurran@SH.CS.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   UDP Checksumming of IP addresses
I'm sure I've overlooked something, and could use a push..
 
Why does UDP (when used with checksumming enabled) create a pseudo-header 
that contains both the port numbers and the source and destination IP 
addresses?  Isn't it already protected from address changes by the datagram
checksum?

/John
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Nov 90 21:02:59 GMT
From:      portal!cup.portal.com!cec@apple.com  (Cerafin E Castillo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP and VJ's Header Compression for SUNs

CSLIP and SLIP sources for Sun 3 & 4 systems are available from
uunet and several other systems.  As of Interop, I have not seen
or heard of a WORKING PPP for SunOS.  Good Luck!

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

                      "...No hay mal que por bien no venga..."
===============================================================================
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 09:58:36 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net  (Daniel Huber)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
    IBM's AS/400 has a TCP/IP solution which supports FTP, TELNET etc.
    The TELNET server (also the client) on the IBM only supports ASCII
    streams, 3270 or 5250. For our applications we need at least the 3270
    emulation.

I have heard rumors about the "TN5250" support being developed, but no
standard has been published and for the moment it must be viewed as IBM
proprietary (anyone from IBM want to comment or publish?).

            - Does tn3270 have all this features I need ?
            - Is tn3270 usefull (speed, performance, keyboardmapping...) ?

That's hard to say: TN3270 does its best to make the terminal on your desk
into a 327x device connected to the mainframe via co-ax.  How well it
succeeds depends on how well your terminal can be mapped to the specific
model of 327x your application expects.  A PC with the proper display adapter
can do quite well for all kinds of 3278, and some varieties of 3279.  3179G
is possible, too (talk to Mitek for that).  Minshall's Unix TN3270 has a much
harder job, in that it doesn't have a directly-addressable display and has to
use curses and a keyboard-remapping scheme to transform random asynch Ascii
terminals.  Basic 3278-2 isn't too bad, but things like screen painting tend
to be slow...

            - Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ?

Don't know, even about our own DOS product.  I haven't yet heard of an
AS/400 on the Internet that we could test against (any volunteers?).
Either there would have to be something on the AS/400 which translated a
5250 data stram into a 3270 data stream, or you'd need AS/400 applications
which understood 3270s.

            - Does tn3270 work with X-Windows(Openlook and Motif), Sunview
              and ASCII Terminals ?

The curses output can be sent to a terminal emulator running in a window.
It won't be too quick, but it works.  I don't know of anyone who has re-hacked
it to bypass curses and the emulator, but it could certainly be done, at the
cost of marrying it to a particular environment.

            - Is tn3270 also usefull over 9600 Baud Modem ?
              (Terminal->modem->UNIX->tcpip->AS/400)

I've used it that way.  Reading or writing the whole screen will be slow,
so watch out for applications for which this is a way of life...

            - Native language support ?

Our DOS product has a user-loadable Ascii-EBCDIC translation table, and
the screen and keyboard can be re-mapped.  Minshall's original version
would have to be customized in the source.  I don't know what other
vendors have done.

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

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 11:53:26 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        bkc@omnigate.clarkson.edu, portal!cup.portal.com!cec@apple.com
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  PPP and VJ's Header Compression for SUNs
Brad, I presume yours is an asynchronous implementation? Ours is purely
synchronous.....

					Torben
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 07:40:04 EST
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@UCBVAX.BERKELEY.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Definitive TCP, IP, UDP
 > From tcp-ip-RELAY@NIC.DDN.MIL Tue Nov  6 18:26:40 1990
 > From: att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!zweig@ucbvax.Berkeley.EDU  (Johnny Zweig)
 > Organization: U of Illinois, Dept. of Computer Science, Systems Research Group
 > Subject: Definitive TCP, IP, UDP
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > If I wanted the definitive word on what TCP is, for example, I imagine I could
 > slog through the list of RFCs and figure out what obsoletes what, print out
 > all the ones that seem relevant and scratch my head.  Is there a document out
 > there (say an RFC in preparation) that describes exactly how all parts of the
 > protocol work (RTT calculations, options, etc.)? How about for IP and UDP?
 > 
 > -Johnny TCP
 > 

Johnny TCP,

You might wish to start with the host requirements RFCs - 1122/23(?).
                  ^^^^^
                  
Frank Kastenholz
Racal Interlan

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 02:41:18 GMT
From:      bu.edu!wang!fitz@uunet.uu.net  (Tom Fitzgerald)
To:        tcp-ip@nic.ddn.mil
Subject:   Any experiences with PCroute 2.0?
We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP
routing package - has anyone else had any experiences with it?

From the looks of it, it seems like a great package for setting up a
router, quickly, in a low-traffic situation.  The main disadvantage
seems to be that you need turbo-assembler to build it, and rebuilding
it is necessary to reconfigure the interface hardware.  But it handles
plain routing, SLIP, proxy-arping and RIP, and it runs on a machine
that you can buy for $800 these days.

In fact, I'm kinda surprised it isn't used all over the place....

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 10:49:14 PST
From:      rxk@ain.ESD.3Com.COM (Rajeev Kochhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problem with Xmodem and 3Com terminal server
mmorse@Z.NSF.GOV ("Michael H. Morse") writes:

>I am having a problem getting Xmodem to work between a Sun workstation
>and a PC running a terminal emulator.

>The PC uses a modem and a dial-up line to communicate, but it cannot
>get to the workstation directly because the workstation has no serial
>ports.  Instead, the PC logs on to some other host, and then uses
>telnet to get to the workstation.

>We have a 3Com terminal server that is normally used in this situation,
>but we've found that Xmodem does not work (the PC nacks everything it
>gets) in this configuration.  However, if the PC logs onto one of our
>Ultrix hosts, and in effect uses it for a terminal server to telnet to
>the workstation, Xmodem works fine.  Subsequent tests have absolved the
>terminal emulator (on the PC) and the xmodem program on the
>workstation, leaving suspicion around the telnet implementation
>on the terminal server.

>I suspect this has something to do with parity, since the ASCII
>characters transmitted by Xmodem, and received by the PC are
>identical.  Has anybody run into a similar problem? Any information on
>how telnet reacts when raw mode is selected would be appreciated.

>Thanks in advance.

>--Mike

>-- 

>Michael Morse                           Internet: mmorse@note.nsf.gov
>National Science Foundation               BITNET: mmorse@NSF
>                                       Telephone: (202) 357-7659
>                                             FAX: (202) 357-7663

The dicussion following the above posting raised a few points about the 3Com
terminal server which I want to clarify.

The server does support 8-bit (binary transmission) mode in Telnet. The server
can initiate negotiation for 8-bit transmission any time during a session.
When the server initiates a connection it negotiates 8-bit mode based on the
setting of the XmitBinary (can be ON or OFF) parameter. Default value is off.
When the terminal server is the server side of a connection it negotiates
8-bit mode by default.

The server has a parameter called NetAscii which determines the character
sequence transmitted when a <CR> is seen at the terminal port. Can be
configured to transmit <CR><LF> or <CR><NULL>. However, in 8-bit mode,
no extra characters are added to the data stream (i.e. NetAscii is ignored).

For a completely transparent session the terminal parameters should be set
as following:

XmitBinary = ON
FlowControlTo = none
FlowControlFrom = none
ECMChar = disable
BreakChar = disable
DataBits = 8
Parity = None

Hope this helps,

-Rajeev Kochhar
 3Com

Disclaimer: Comments reflect my own understanding and opinion.  
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Nov 90 13:04:39 -0500
From:      George Williams <gwilliam@SH.CS.NET>
To:        John Curran <jcurran@SH.CS.NET>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: UDP Checksumming of IP addresses
I'm sure I've overlooked something, and could use a push..

Why does UDP (when used with checksumming enabled) create a pseudo-he
ader
that contains both the port numbers and the source and destination IP

addresses?  Isn't it already protected from address changes by the da
tagram
checksum?

/John


>Not an expert, but my best-guess-protocol-based response would be for possible fragmentation.
>If I were writing a similar protocol...would take into account the data link level transmission
>medium below IP.
 
>Sounds like the above scheme allows for just that. A datagram is so logically, right. There is
>nothing to say it has to stay physically intact....during transit. What's the real deal wizards out there ?


 George Williams



-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 05:12:25 GMT
From:      jon@bloom-beacon.mit.edu  (Jon A. Rochlis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Berkeley Socket Libraries for Macintosh?
When I ported Kerberos to the Mac I built a primitive socket library
on top of MacTCP.  You can get the "alpha" Kerberos distribution
including the socket library via anonymous ftp from
athena-dist.mit.edu ... retrieve the file pub/kerberos/README.mac for
intructions and export restrictions.

If you don't want to deal with Kerberos, you can get just the socket
library (plus a couple of other bsd compatibility routines) via
anonymous ftp from net-dist.mit.edu as jon/bsd-mac-compat.sit.Hqx ...

Please send any fixes or comments to me.

		-- Jon Rochlis (jon@mit.edu)
		   MIT Network Services
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 11:36:50 CST
From:      santa@hemlock.cray.com (Dave Sadler)
To:        tcp-ip@nic.ddn.mil
Cc:        M.Cutts@uk.cray.com
Subject:   TCP/IP for UNISYS 1100/OS?
Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be
appreciated.

Thanks,   Dave Sadler (santa@cray.com)
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 11:11:58 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        Cerafin E Castillo <portal!cup.portal.com!cec@apple.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  PPP and VJ's Header Compression for SUNs
You can get a version of PPP for Sun OS 4.* (using streams) via anonymous
ftp from
	omnigate.clarkson.edu:/pub/sun/ppp.tar.Z

This distribution is for non-commercial use.

It was generated on a Sun 386i running 4.0.1, hence some of the include file
requirements have changed. If you have trouble installing it, drop me a line
and I'll send you some comments from others who have gone through and
determined what changes are required.

This version does VJ TCP header compression.


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

ps. By non-commercial I mean, not to be integrated into another product, nor
bundled for resale. If you are a commercial org and need to use it in house to
connect things togother, thats ok.

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Wed,  7 Nov 90 14:38:45 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP and VJ's Header Compression for SUNs
There IS a PPP available for SunOS which supports VJ compression.  You
can get it from Brad Clements, bkc@omnigate.clarkson.edu.

Drew
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 07:25:09 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP Source Code Search
In article <9011061001.AA27908@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes:
>Well, my experience from watching many people port the Berkeley code
>is that it's a four to six month effort to get it working.

Speaking as someone who has just spent a few months porting the berkeley
code to a simple microprossesor environment (no virtual memory, no this,
no that...), I have to agree ... IT DOES! (:-))


-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 16:38:34 PST
From:      braden@venera.isi.edu
To:        gwilliam@sh.cs.net, jcurran@sh.cs.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP Checksumming of IP addresses
There are two answers, one historical and the other architectural.

Historically, the early versions of TCP/IP followed the original
Cerk&Kahn paper in having a single protocol.  Only later (version 4)
was it split into an IP and a Transport layer.  When it was split,
the addressing information was split between the two layers.  But
who wants to change the checksum definition...?

The architectural justification was that the transport layer should be
able to verify the integrity of its addressing information no matter
what lower-layer protocol it runs over.  "Don't trust ANYBODY".  The
TCP and UDP specs say, "This gives protection against misrouted
segments".  Actually, all it probably gives you is protection
against software bugs.

Bob Braden
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 16:11:58 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  PPP and VJ's Header Compression for SUNs

You can get a version of PPP for Sun OS 4.* (using streams) via anonymous
ftp from
	omnigate.clarkson.edu:/pub/sun/ppp.tar.Z

This distribution is for non-commercial use.

It was generated on a Sun 386i running 4.0.1, hence some of the include file
requirements have changed. If you have trouble installing it, drop me a line
and I'll send you some comments from others who have gone through and
determined what changes are required.

This version does VJ TCP header compression.


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

ps. By non-commercial I mean, not to be integrated into another product, nor
bundled for resale. If you are a commercial org and need to use it in house to
connect things togother, thats ok.

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Nov 90 01:05 PST
From:      Denis DeLaRoca (213) 825-4580        <CSP1DWD@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Re:  PPP and VJ's Header Compression for SUNs
Sometime ago Karl Fox from Morning Start Technologies had actually
made the changes necessary to have Brad Clements' PPP code compile
and run on Sun platforms other than the 386i... I had the changes from
Karl but my Sun's hard disk broke down. Karl may be reached at

         <Karl@MorningStar.Com

-- Denis
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 17:57:35 GMT
From:      sci34hub!gary@uunet.uu.net  (Gary Heston)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SENDMAIL configuration
In article <9011051727.AA16922@nisc.jvnc.net> aggarwal@NISC.JVNC.NET (Vikas Aggarwal) writes:
> [ typical tale of sendmail woe deleted ]

>Any ideas / suggestions (postmaster@berkeley.edu ....?!!) ??

Yes. I fought with sendmail configuration for a long time, and never 
succeeded in getting it running just the way I wanted to. 

Then, I pulled smail3.14 off uunet, and had it installed and running 
right in about three days. I'm happy, the users are happy, the mail
is getting thru....   HIGHLY recommended.

The only thing to watch are the log and error files in /usr/spool/smail,
which can get large if you don't clean them out every week. 

-- 
Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or
My opinions, not theirs.  SCI Systems, Inc.     gary@sci34hub.sci.com
  The sysadmin sees all, knows all, and doesn't tell the boss who's
  updating their resumes....  This .sig Copyright G. L. Heston, 1990
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 18:04:39 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP Checksumming of IP addresses

I'm sure I've overlooked something, and could use a push..

Why does UDP (when used with checksumming enabled) create a pseudo-he
ader
that contains both the port numbers and the source and destination IP

addresses?  Isn't it already protected from address changes by the da
tagram
checksum?

/John


>Not an expert, but my best-guess-protocol-based response would be for possible fragmentation.
>If I were writing a similar protocol...would take into account the data link level transmission
>medium below IP.
 
>Sounds like the above scheme allows for just that. A datagram is so logically, right. There is
>nothing to say it has to stay physically intact....during transit. What's the real deal wizards out there ?


 George Williams

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 19:16:09 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you use Dial-up SLIP?
In article <CHET.90Nov5154510@commanche.Advansoft.COM> chet@Advansoft.COM (Chet Wood) writes:
>It seems to me, because of these things, that it would be more than
>worth it to use a leased line for SLIP access...

Leased lines are better than dialup connections; there is no doubt about
that.  However, they also are significantly expensive, can sometimes be hard
to get, and generally require explicit budget justification rather than
getting a "free ride" on existing hardware and existing phone bills.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 19:23:05 GMT
From:      cs!samadams.princeton.edu@princeton.edu  (Tom Reingold)
To:        tcp-ip@nic.ddn.mil
Subject:   looking for SLIP for System V Release 3
I am interested in learning who sells versions of SLIP for System V
Release 3.  I have 3B2's and 386's.  Does each brand of SLIP depend on
a particular brand of TCP/IP?

Any information on any brands would be appreciated.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
	from windshield before starting ignition."
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 20:07:05 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Definitive TCP, IP, UDP
In article <BZS.90Nov6100729@world.std.com> bzs@world.std.com (Barry Shein) writes:
>>...  Is there a document out
>>there (say an RFC in preparation) that describes exactly how all parts of the
>>protocol work (RTT calculations, options, etc.)? How about for IP and UDP?
>
>Sounds like you want Doug Comer's textbook, "Internetworking with
>TCP/IP", Prentice-Hall. Should be available at any college bookstore.

Uh, Barry, had a hard night last night? :-)  Comer is a good textbook, but
it is not in any way, shape, or form the sort of reference manual that he
is asking for.  Too many things are alluded to but not discussed.  (I've
heard there is a second edition, which may have improved the situation,
but I'd still be surprised if it was what he's after.)  It doesn't even
discuss the details of closing a TCP connection, for example.

As far as I know, there is no substitute for wading through lots of RFCs.
The Host Requirements and Protocol Standards ones are the places to start.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Nov 90 20:58 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        David Doll <davidd@hitl.vrnet.washington.edu>, tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   SNMP Packages via Anonymous ftp?
>Simple question: what is RFC 1147? 

>David Doll

David,

Glad you asked. :-)

RFC 1147 is "A Network Management Tool Catalog."  It is a (by no means
comprehensive) list of free and commericial tools for managing TCP/IP internets
and the devices that they interconnect.

RFC 1147 is also FYI 2; the purpose of the FYI series of documents is to provide
general or practical information on the Internet.  As you might surmise from the
number, the FYI document series is rather new.

RFC 1147 was published in April of this year.  The IETF is currently working on
developing son-of-1147.  Anyone who would like to have his/her tool listed in
the next edition of the catalog, or anyone who would like to have an existing
catalog entry updated, should contact me, or drop a note to noctools@merit.edu. 
For various reasons, we require vendors to provide the draft entries of their
commercial products.

Regards,

Bob Stine
bstine@MCIMail.com

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 21:58:01 GMT
From:      usc!zaphod.mps.ohio-state.edu!think.com!barmar@ucsd.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP Checksumming of IP addresses
In article <9011070014.AA08334@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET (John Curran) writes:
>I'm sure I've overlooked something, and could use a push..
> 
>Why does UDP (when used with checksumming enabled) create a pseudo-header 
>that contains both the port numbers and the source and destination IP 
>addresses?  

The pseudo-header doesn't have port numbers in it.  It contains the
addresses, the protocol number (17 when used with IP as the network layer),
and the length.

>	     Isn't it already protected from address changes by the datagram
>checksum?

From RFC 768: "This information gives protection against misrouted
datagrams."  In other words, it's there to detect failure of the IP layer.
For instance, if the receiving host is single-homed and the datagram isn't
a broadcast, the destination IP address in the pseudo-header could be the
address of the interface rather than the address in the IP header, and
which will catch attempts by a broken IP layer to pass up packets intended
for another host (an IP layer might not check the destination address of
packets coming in through a point-to-point link, or it might not be
prepared for an interface being in promiscuous mode).

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      7 Nov 90 23:59:49 GMT
From:      usc!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!unger@ucsd.edu  (Tom Unger)
To:        tcp-ip@nic.ddn.mil
Subject:   Help with XModem over telnet
Reply-To: tom@citi.umich.edu (Tom Unger)
Distribution: usa
Organization: University of Washington, Seattle


I am trying to implement a file transfer over telnet.  On the unix side
I am running sz (as sx for XModem) and on the Mac side I'm runing the
software that I'm writing.  For the file transfer I negociate telnet
binary mode, in both directions.  The unix machine responds positivly,
for both directions.  (I think that sx also does what is necessary to
transmit binary data).

For downloads (unix to mac) I find that a NULL is inserted after every
CR.  I know that this is required for default operation but I expected
that in binary mode I would only have to watch for IACs.  Is the unix
implementation that I have wrong (a/ux 2.0) or does the CR NULL rull
apply even in binary mode?

I checked the RFCs but didn't see anything pertaining to how CR should
be handled in binary mode.

Please reply via mail to:

        unger@cdp.igc.orgTo UnMIT

Tom Unger
MITEM
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Nov 90 07:25:59 EST
From:      Rob Hudson <SSROB%ECUVM1.BITNET@ncsuvm.ncsu.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: TCP/IP for UNISYS 1100/OS?
On Wed, 7 Nov 90 11:36:50 CST Dave Sadler said:
>Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be
>appreciated.
>
>Thanks,   Dave Sadler (santa@cray.com)
Dave,
    There are one of 2 options for TCP/IP on Unisys 1100/2200 Mainframes.
If your host has a DCP there is a DCP Ethernet Line Module that requires
the following software: Comm Delivery 4,  TCP/IP Stack,  DCP Lan Platform.
If you want ftp smtp you will also need DDN-1100.  The other option is a
channel attached box call a Host Lan Controller (HLC).  This box requires
DDN-1100 also but not the other software.  Both of these options allow
connection to an Ethernet Segment.  If you have any further questions
please email me or give me a call.

=======================================================================
* Rob L. Hudson                ___   ___         SSROB@ECUVM1.BITNET  *
* Systems Programmer          |__   |     |  |   ( 919 ) 757 - 6401   *
* East Carolina University    |___  |___  |__|   Greenville, NC 27858 *
=======================================================================
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 08:05:19 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   Re: Any experiences with PCroute 2.0?

On Wed, 7 Nov 90 02:41:18 GMT Tom Fitzgerald said:
>We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP
>routing package - has anyone else had any experiences with it?

I have been using PCROUTE 2.0 (now 2.1 for just a fix to SLIP) for 6 months
without a glitch (or should I say with just one which was a power one
after which the PC wouldn't restart and no PCROUTE's fault).
3 days work (tests before production) for a router novice at that time.
It's got 2 Ethernet, 1 Appletalk and 2 SLIPs (SLIP not tried yet).
I didn't figure how to get to overload it. Our hosts would overload first.
It even helps big blue's static routing with its proxy-arp.
The doc is excellent. But it doesn't teach what is routing and RIP.
Practically, it doesn't even cost what you say: it's the occasion to
dust stranded PC's or reuse unwanted ones. Better use ATs for SLIP, though.
I didn't mind using the savings to buy TurboAsm (and TC++).

>In fact, I'm kinda surprised it isn't used all over the place....

So am I. Or is it and nobody cares to say?
We are hearing much about problems, don't we?
The only good reason we don't use more of it here is that it would be a good
reason not to buy more sophisticated hardware that some people feel proud of.

I wanted to make this reply public both in thanks to Vance and in reaction
to having read that PCROUTE is not supported. It doesn't need it. It works.
This note via tn3270 through it.

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

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Nov 90 16:30:39 -0500
From:      cws@ftp.com  (Cris Shuldiner)
To:        psuvm!cjs@psuvax1.cs.psu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
    Date: 8 Nov 90 16:45:31 GMT
    From: psuvm!cjs@psuvax1.cs.psu.edu
    Organization: Penn State University
    Subject: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
    To: tcp-ip@nic.ddn.mil
    
    I sure would like 3179G emulation in a TN3720.  Does anyone have an
    address or phone number for Mitek handy?
    

The number for Mitek is (214) 490-4090.  They are located in Carrollton, TX. 

    We are using FTP Software's TN3270 to telnet to an AS/400.  It works
    pretty good; I wish it (TN3270) supported color or at least extended
    attributes (like underscore).  The default 3270-to-5250 keyboard mapping
    (on the AS/400) is brain-damaged, but (somewhat) easily remedied with a
    user command.  Also, it only does 24 lines.  I also use FAL's telnet to
    log onto the AS/400.  Extended color and highlighting work.
    
Our TN program [in ver 2.05 which was released a couple of weeks ago]
does support extended attributes affecting color and highlighting.
It also supports 32x80, 43x80, and 27x132 screen sizes, if your video
card and monitor can handle them.

Cris Shuldiner						Product Support
cws@ftp.com						FTP Software, Inc.
--------------------------------------------------------------------------
"The pain of war can not exceed the woe of aftermath..."  - Led Zeppelin

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 08:52:50 GMT
From:      munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!manic!chris@uunet.uu.net  (Chris Clarkson)
To:        tcp-ip@nic.ddn.mil
Subject:   Adding a SLIP streams module to a 3b2 running WIN TCP/IP
I need to get SLIP up on a 3b2/400 & 3b2/600 running WIN TCP/IP and vanilla
3b2 System V.3 Unix. I can find plenty of Berkely SLIP examples but no
System V.3 examples. Can anyone point me towards articles, source or just give
me some general pointers on the complexity of what I'm contemplating?
Please reply by post.
-- 
Chris Clarkson					 	Tel:	61 8 410 1442
chris@manic.communica.oz.au				Fax:	61 8 410 1443
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 09:05:00 GMT
From:      CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   Re: Re:  PPP and VJ's Header Compression for SUNs

Sometime ago Karl Fox from Morning Start Technologies had actually
made the changes necessary to have Brad Clements' PPP code compile
and run on Sun platforms other than the 386i... I had the changes from
Karl but my Sun's hard disk broke down. Karl may be reached at

         <Karl@MorningStar.Com

-- Denis

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 09:50:42 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   TCP sockets driver, Desqview/X

Go to your bookshop and buy the IBM PC special issue of BYTE.
Detach the booklet from Quarterdeck and read it.
Full X support in the DESQview multitasking environment for MSDOS.
Seems amazing.
Just as striking to me is that it looks like (I have to check) Quarterdeck
have managed to multiplex the FTP Software socket driver between several
concurrent DOS applications.
More like TCP/IP wouldn't it?
This strengthens my opinion that PD software for DOS should detect and use
this socket API when present.

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

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Nov 90 09:05:19 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Any experiences with PCroute 2.0?
On Wed, 7 Nov 90 02:41:18 GMT Tom Fitzgerald said:
>We've started playing here with Vance Morrison's PCroute 2.0 TCP/IP
>routing package - has anyone else had any experiences with it?

I have been using PCROUTE 2.0 (now 2.1 for just a fix to SLIP) for 6 months
without a glitch (or should I say with just one which was a power one
after which the PC wouldn't restart and no PCROUTE's fault).
3 days work (tests before production) for a router novice at that time.
It's got 2 Ethernet, 1 Appletalk and 2 SLIPs (SLIP not tried yet).
I didn't figure how to get to overload it. Our hosts would overload first.
It even helps big blue's static routing with its proxy-arp.
The doc is excellent. But it doesn't teach what is routing and RIP.
Practically, it doesn't even cost what you say: it's the occasion to
dust stranded PC's or reuse unwanted ones. Better use ATs for SLIP, though.
I didn't mind using the savings to buy TurboAsm (and TC++).

>In fact, I'm kinda surprised it isn't used all over the place....

So am I. Or is it and nobody cares to say?
We are hearing much about problems, don't we?
The only good reason we don't use more of it here is that it would be a good
reason not to buy more sophisticated hardware that some people feel proud of.

I wanted to make this reply public both in thanks to Vance and in reaction
to having read that PCROUTE is not supported. It doesn't need it. It works.
This note via tn3270 through it.

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
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Nov 90 16:41 EST
From:      Dan <MORTON@fccc.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a way to send OOB data with  CMU-TEK TCP/IP?
I'm looking to notify a client program on a UNIX system that the server on a
VMS system is going to go away (I'm using the CMU TEK implementation of
TCP/IP).  I've read that a program will receive a SIGURG signal when it 
receives out-of-band data.  Does anyone know of a way to  send it using
CMU-TEK?  Given my VMS/UNIX combination, does anyone know of a simple way
to trigger a signal to  the UNIX side, failing the OOB approach?


--------------------------------------------------------------------------------
Return address: 
 
Dan Morton                         Voice:  215-728-3644
Fox Chase Cancer Center
7701 Burholme Avenue               Fax:    215-728-3574
Philadelphia, PA 19111
USA				   Net:    morton@fccc.edu
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 12:25:59 GMT
From:      SSROB@ECUVM1.BITNET (Rob Hudson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP for UNISYS 1100/OS?

On Wed, 7 Nov 90 11:36:50 CST Dave Sadler said:
>Is there a TCP/IP product for the UNISYS 1100 series OS? Any pointers would be
>appreciated.
>
>Thanks,   Dave Sadler (santa@cray.com)
Dave,
    There are one of 2 options for TCP/IP on Unisys 1100/2200 Mainframes.
If your host has a DCP there is a DCP Ethernet Line Module that requires
the following software: Comm Delivery 4,  TCP/IP Stack,  DCP Lan Platform.
If you want ftp smtp you will also need DDN-1100.  The other option is a
channel attached box call a Host Lan Controller (HLC).  This box requires
DDN-1100 also but not the other software.  Both of these options allow
connection to an Ethernet Segment.  If you have any further questions
please email me or give me a call.

=======================================================================
* Rob L. Hudson                ___   ___         SSROB@ECUVM1.BITNET  *
* Systems Programmer          |__   |     |  |   ( 919 ) 757 - 6401   *
* East Carolina University    |___  |___  |__|   Greenville, NC 27858 *
=======================================================================

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Nov 90 10:50:42 +0100
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        cutcp@omnigate.clarkson.edu, tcp-ip@nic.ddn.mil
Subject:   TCP sockets driver, Desqview/X
Go to your bookshop and buy the IBM PC special issue of BYTE.
Detach the booklet from Quarterdeck and read it.
Full X support in the DESQview multitasking environment for MSDOS.
Seems amazing.
Just as striking to me is that it looks like (I have to check) Quarterdeck
have managed to multiplex the FTP Software socket driver between several
concurrent DOS applications.
More like TCP/IP wouldn't it?
This strengthens my opinion that PD software for DOS should detect and use
this socket API when present.

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
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 12:35:53 GMT
From:      mcsun!ukc!keele!csd35@uunet.uu.net  (Jonathan Knight)
To:        tcp-ip@nic.ddn.mil
Subject:   Why do I need multiple host names for the same host?
Our dept has just re-arranged its ethernet into 2 seperate ethernets
with a sun 4 acting as the router.  It is the only host which has
more than one cable attached to it.

Following the manual we have put:
192.42.100.3    do loghost
192.82.242.1    doc_1

into our hosts table.  This causes problems as some of our diskless
stations need to be told to get their swap and root from 'doc'
and others need to get it from 'doc_1'.  This is caused by the fact
that they have no routing information at the point at which they want
to download vmunix.  Therefore the host they boot from must be on
their network.

I have two questions.

1)	When a host on the 192.82.242 network tries to talk to
	'doc' is the packet addressed to 192.42.100.3?  If not
	is this packet unpacked by doc?  If not does this packet
	actually get placed on the 192.42.100 network and re-read
	by doc?

2)	Is there a way to indicate to each host that doc is local
	on their ethernet?

The only solution I came up with was having multiple /etc/hosts, one
for each network with doc listed on that network.  This is inelegant as
we want to use YP (sorry - NIS) to distribute the known hosts to all
networks and we want to avoid multiple domains.

Any help will be gratefully received.
-- 
  ______    JANET :jonathan@uk.ac.keele.cs     Jonathan Knight,
    /       BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
   / _   __ other :jonathan@cs.keele.ac.uk     University of Keele, Keele,
(_/ (_) / / UUCP  :...!ukc!kl-cs!jonathan      Staffordshire.  ST5 5BG.  U.K.
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 14:13:38 GMT
From:      pasteur!agate!linus!nixbur!nixpbe!peun33!freiss@ucbvax.Berkeley.EDU  (the hacker)
To:        tcp-ip@nic.ddn.mil
Subject:   Multiple subnets on same cable

This might be a silly question, but it's been worrying me for some time.
What happens if different IP subnets live on the same ethernet cable?

I'm worried about excessive ICMP traffic (ICMP net_redirect packets);
I see some SGI workstations here react to some packets from a
different subnet with this ICMP message.

Could somebody tell me if this is a problem or what other
problems I haven't even thought of might arise?
Pointers to books, RFCs etc. on this subject are also welcome.

Thanks, Martin
--
 Martin Freiss       | internet:  freiss.pad@nixdorf.com
 SNI AG              | dnet: freiss.pad@nixdorf.de
 Dept. STO-NC 333    | Voice: +49 5251 14 6601
 D-4790 Paderborn    | fun: marvin%dg5kx@infodn.rmi.de
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 15:37:11 GMT
From:      pacbell.com!tandem!netcom!jbreeden@ucsd.edu  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: looking for SLIP for System V Release 3
In article <4299@rossignol.Princeton.EDU> tr@samadams.princeton.edu (Tom Reingold) writes:
>I am interested in learning who sells versions of SLIP for System V
>Release 3.  I have 3B2's and 386's.  Does each brand of SLIP depend on
>a particular brand of TCP/IP?
>

The AT&T/Wollongong tcp-ip that's available for SysV R4 (you need to rev your
3bs and 386s) includes SLIP (along with an snmp agent, ip over x.25 and 
other goodies).

I also understand that the AT&T/Wollongong tcp-ip for SysV R3 (win/386 R3.0)
has a slip module, AT&T just dosn't include it. You might try Wollongong
directly.

-- 
 John Robert Breeden, 
 netcom!jbreeden@apple.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden
 -------------------------------------------------------------------
 "The nice thing about standards is that you have so many to choose 
  from. If you don't like any of them, you just wait for next year's 
  model."
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 16:45:31 GMT
From:      psuvm!cjs@psuvax1.cs.psu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
In article <9011071458.AA25335@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen)
says:

>A PC with the proper display adapter
>can do quite well for all kinds of 3278, and some varieties of 3279.  3179G
>is possible, too (talk to Mitek for that).

I sure would like 3179G emulation in a TN3720.  Does anyone have an
address or phone number for Mitek handy?

>            - Does tn3270 work with AS/400 TCP/IP (not only with VM/CMS) ?
>Don't know, even about our own DOS product.  I haven't yet heard of an
>AS/400 on the Internet that we could test against (any volunteers?).

We are using FTP Software's TN3270 to telnet to an AS/400.  It works
pretty good; I wish it (TN3270) supported color or at least extended
attributes (like underscore).  The default 3270-to-5250 keyboard mapping
(on the AS/400) is brain-damaged, but (somewhat) easily remedied with a
user command.  Also, it only does 24 lines.  I also use FAL's telnet to
log onto the AS/400.  Extended color and highlighting work.

Because of the weirdness in remapping the 3270->5250 keys, I wish I had a
TN3720 that allowed its keyboard remapping to define more than one 3270
key to be transmitted with one PC key.  The 5250 has 24 PF keys plus more
than the usual 3270 attention keys: help, page up (roll down) and page
down (roll up), some some functions have to be mapped to dual 3270
attention keys (PA1+PFx or PA2+PFx).  A TN5250 would be nice for this
reason.
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 17:26:40 GMT
From:      van-bc!robinson@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Source Code Search
In article <9011052355.AA28967@yuba.WRS.COM> hwajin@yuba.UUCP (Hwa Jin Bae) writes:
>>Many people use the Berkeley code as a start. It's an excellent
>>protocol engine; its main drawback is that it really really wants to
>>live inside a UNIX kernel. It often takes many man-months to port
>>properly. You can find it on uunet.uu.net for anonymous FTP.
>
>berkeley code is actually pretty portable.  it's really not that hard
>to port berkeley code to non-unix environment.  you need to write a set
>of compatible routines -- spl*(), splx() can be emulated using semaphores,
>timeout() can be emulated in most operating systems that support 
>watchdog timers of some sort, sleep() (kernel version) can be done
>via a semaphore or mailbox, wakeup() the same way, perror() and panic()
>are trivial, cluster mbuf can be emulated if you change the mbuf structure
>slightly even on systems that lack virtual memory, etc.   i'm speaking
>from my experience... your mileage may vary.

One possible problem is the use of non-int bit fields in the tcp and ip
header structures. Pre-ANSI C requires only that unsigned int bit fields be
supported by a compiler and ANSI C requires only (*I believe*) signed or
unsigned bit fields be supported. Thus, if your compiler does not support,
say, unsigned char bit fields, which are indeed used in the BSD code, you
will have to do a bit of work to work around this problem. If you are
unlucky, as I was, your compiler will *not* complain, but merely generate
incorrect code.

You will also run into a number of annoying problems if the sizes of ints
and pointers on your target machine are greater than 32 bits, since there
are several coding practices employed that assume 32 bit pointers and ints.
-- 
Jim Robinson
{uunet,ubc-cs}!van-bc!mdivax1!robinson
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 18:02:22 GMT
From:      agate!shelby!morrow.stanford.edu!Valinor.Stanford.EDU!vaf@ucbvax.Berkeley.EDU  (Vince Fuller)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you use Dial-up SLIP?
In article <1990Nov7.191609.19972@zoo.toronto.edu>,
henry@zoo.toronto.edu (Henry Spencer) writes:
|> In article <CHET.90Nov5154510@commanche.Advansoft.COM>
chet@Advansoft.COM (Chet Wood) writes:
|> >It seems to me, because of these things, that it would be more than
|> >worth it to use a leased line for SLIP access...
|> 
|> Leased lines are better than dialup connections; there is no doubt
about
|> that.  However, they also are significantly expensive, can sometimes
be hard
|> to get, and generally require explicit budget justification rather
than
|> getting a "free ride" on existing hardware and existing phone bills.
|> -- 
|> "I don't *want* to be normal!"         | Henry Spencer at U of
Toronto Zoology
|> "Not to worry."                        |  henry@zoo.toronto.edu  
utzoo!henry

The above statement may or may not be true, depending on the nature of
the local telephone service where you are located. In the Bay Area, for
example, you can't get a business line with unlimited local dailing -
everything is measured rate. For this reason, it will be cheaper to
lease a dedicated 9.6KB line if you plan on using for more than a very
small amount (like an hour a day or thereabouts). In additione, 56KB ADN
("advanced digital network") circuits are not much more expensive than
9.6KB leased lines, though they are not quite as ubiquitous as 9.6KB
lines. Of course, there are other capital costs associated with a leased
line connection which are not present when getting "a free ride on
existing hardware" (but a "free ride on existing phone bills" is much
harder to hide if  you have measured service...)

	Vince Fuller, Stanford University/BARRNet
 
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Nov 90 22:35:20 GMT
From:      usc!zaphod.mps.ohio-state.edu!mips!wdl1.wdl.fac.com!wdl51!wrl@ucsd.edu  (Bill Lewandowski)
To:        tcp-ip@nic.ddn.mil
Subject:   Annex Terminal Server
Hi,
I have an annex terminal server. It works great on our
local network. But, when I try and use it towards the
internet, I get the destination unreachables. The netstat -r
on the annex shows that there are routes to some of our cisco
gateways. Even though the default route is not to our
internet gateway, it should follow the icmp redirects.

Anyone have any advise for me (besides throwing it away).
We have a large meeting here next week and I would like to use
it to allow people to access their home machines over the Internet.
I have tried to tell it the correct default gateway with no
results.

Thanks,
(Mail answers directly to me).


-- 
Bill Lewandowski		LORAL Western Development Labs
(408) 473-4362			Internet: wrl@wdl1.wdl.fac.com
FAX: (408) 473-7926		UUCP: wdl1!wrl
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Nov 90 08:46:33 -0500
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        tcp-ip@sri-nic.arpa
Subject:   SLIP weirdness

Often when running SLIP over modem home to work, SLIP will
go down even though the modem stays up.  When this happens,
I simply restart SLIP, and even my rlogins stay up.

Does anyone know why SLIP does this, or what diagnostics
SLIP has so I can find out myself?

PT

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Nov 90 09:51:57 EST
From:      Bob Stratton <dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil>
To:        munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!manic!chris@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Adding a SLIP streams module to a 3b2 running WIN TCP/IP

>I need to get SLIP up on a 3b2/400 & 3b2/600 running WIN TCP/IP and vanilla
>3b2 System V.3 Unix. I can find plenty of Berkely SLIP examples but no
>System V.3 examples. Can anyone point me towards articles, source or just give
>me some general pointers on the complexity of what I'm contemplating?

I'm working on the same issue, although I'm leaning toward PPP. If I
get it ported, I'd be glad to send you a copy/mods to the BSD code,
etc. If you do it first, PLEASE tell me what you did...

The AT&T Enhanced TCP/IP WIN/3B has pretty good Berkeley compatibility
routines in it as delivered. The real issue is one of linking the
module into the Sys V kernel. I haven't tried this yet. I have seen
SLIP implementations that seem to run as a user (as opposed to kernel)
process, and if at all possible, I'm going to try to bring one of
these up first, as I expect it'll be considerably easier.

Thanks...

Bob Stratton 		| dsc3rjs@nmdsc20.nmdsc.nnmc.navy.mil [DDN/Internet]
NAVMEDATASERVCEN	| dsc3rjs@vmnmdsc		      [BITNET]
(Innova Comms. / AT&T)	| 295-3503 [AV]    +1 301 295 3322    [PSTNet]
Disclaimer: The above opinions are mine alone - Who else would want them?
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 05:10:25 GMT
From:      bu.edu!rpi!clarkson!nelson%image.soe.clarkson.edu@bloom-beacon.mit.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Status of, and mailing list for Clarkson packet drivers
Hi.  This is just a note to keep you all up to date on the packet
drivers, and to announce the creation of a mailing list for packet
driver issues.  I should also mention that it's the Clarkson
*collection* of packet drivers, but that doesn't fit very well on the
subject line.

The mailing list:

To subscribe to the mailing list, send an automated add request to
listserv@sun.soe.clarkson.edu.  Send a one line mail message whose
sole contents are "add drivers".  To get off the list, send "delete
drivers".  To send mail to a human (in case of trouble), send mail to
drivers-request@sun.soe.clarkson.edu.  To post to the list, send mail
to drivers@sun.soe.clarkson.edu.

The 7.x release:

  o The -w switch seems to cause problems, although I can't see why.
  o The Tiara and NE2000 packet drivers do not work with the -n switch.
    The fix is trivial but requires reassembling those drivers.
  o 3c523.com and 3c523_5.com are both broken.  I have a replacement that
    seems to work.  Ask me for it.
  o The wd8003e driver seems to be unreliable.  You may wish to drop back
    to the 6.x version, available in sun.soe.clarkson.edu:pub/packet-drivers/
    pktd6_0.arc.
  o I've seen the ni6510 driver head south.  I haven't determined if it's the
    transmitter or receiver.  It doesn't crash, it just stops sending (or
    receiving).

Donations:

Since the 7.x release, we've received donations of Ethernet equipment
from Hewlett-Packard (including an Ethertwist hub), Cabletron, D-Link,
and Digital Equipment Corporation.  Thanks to all of them, their
support is appreciated and encouraging.  Please remember to tell your
Ethernet equipment vendor that you're using the packet drivers.
Otherwise, they have no way to know that the packet drivers "butter
their side of the bread".

The 8.x release (no date yet):

  o If anyone has any bug fixes or new drivers, please tell us about them,
    so that they may be included.
  o We have several new drivers: 3Com 3c507, D-Link DE-600, and
    Ungermann-Bass ubnicps2.
  o Everex has a Clarkson-derived packet driver for their SpeedLink-16
    that they distribute without source.  They promised to send us the
    source, but we haven't gotten it yet.
  o The new 3c507 driver sometimes goes deaf.  This is unacceptable
    and must be fixed before the driver is released.  Hopefully this
    is just a problem with the 3c507, and not a problem with the 82586
    generic driver.
  o We have two new drivers in the works, an HP Ethertwist, and a DEPCA.
  o Someone is working on a Mylex driver.
  o I am working on "genericizing" the 8390 drivers, similar to the way the
    82586 drivers use a common file.  This serves two purposes, one
    to include the wd8003e high performance code in all 8390 drivers, and the
    other to write the Ethertwist driver.
  o I will include Jochen Kornitzky's changes that let a packet be upcalled
    to multiple protocol stacks.  This is of great use to those running
    Novell who wish to run a packet spy, such as Netwatch or FTP's Lanwatch.
    Anyone thinking about using it to run two stacks of the same protocol
    should get more sleep, he says at midnight.  :-)

Useful projects I don't see myself finding the time for:

  o A real but small program written in C that uses the packet driver, with
    source code for study and modification.
  o A program or programs that exercise the packet drivers.  For example,
    a ping client that loops through all possible packet sizes would be
    handy.  Perhaps the PC-IP ping client could be modified to do this?
  o Genericize the three LANCE-based drivers, the ni6510, the nti16, and
    the (unreleased) isolink.
  o Write an article on the packet drivers for a PC programmer's magazine
    such a Programmer's Journal, or suchlike.

-russ
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Nov 90 14:55:38 -0400
From:      doucette@px1.stfx.ca (Gary Doucette)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP - SLIP over Dialup

I am interested in setting up slip for dialup access.

Where should I start.

Gary Doucette
Network/Unix System Manager
Saint Francis Xavier University
Antigonish, Nova Scotia CANADA

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 12:13:17 GMT
From:      spang@nbivax.nbi.dk (Karsten Spang)
To:        comp.os.vms,vmsnet.misc,comp.protocols.tcp-ip
Subject:   TCP/IP print server running under VMS and UCX


    Hello

I have a VAX/VMS system running DEC's TCP/IP implementation UCX.

I need to have a print server process running on the VAX accept print files
from an Apollo over TCP/IP and print them on a printer connected to the VAX.

I probably need more than one print server, printing to different queues 
and/or forms, so it should be possible to
  1) Run several print server processes on one machine
  2) Specify the queue and form for each server process

Does anybody know about a (public domain or commercially available) print
server that fullfills these requirements?

Please answer by e-mail, as I don't read this newsgroup regularly.

                         Thanks in advance,
                           Karsten
--------------------------------------------------------------------------------
InterNet:       spang@nbivax.nbi.dk (nbivax=129.142.100.3) Karsten Spang
NORDUNET/HEPnet:NBIVAX::SPANG       (NBIVAX=21.601=22105)  Midtflxjene 22, 2tv
VAXPSI MAIL:    (0)238301032352::SPANG                     DK-2700 Brxnshxj
Phone: +45 31 28 03 24                                     Denmark

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 16:56:55 GMT
From:      sdd.hp.com!wuarchive!cs.utexas.edu!halley!news@ucsd.edu  (usenet news)
To:        tcp-ip@nic.ddn.mil
Subject:   Simple Book
I need information on the publisher of Marshall Rose's recent book on
SNMP entitiled, I believe,
"The Simple Book".

Thanks,

Phil Webster        (Keep trying if halley bounces mail.  It's flakey)
(cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com)
 ^Preferred                                   ^Most reliable (?)
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 17:09:47 GMT
From:      tcora@PICA.ARMY.MIL (Tom Coradeschi)
To:        comp.protocols.tcp-ip
Subject:   SLIP Advantages?

I've been reading a bit about SLIP, and have a few questions. What are the
real advantages of SLIP, over serial connections. I have a 9600bps dialin
connection, via broadband cable, to the host I'm mailing this from. What do
I gain by going to SLIP, which would make it worthwhile to broach the
subject with the powers that be here. Please email your comments (as I
cannot easily read USENET), and I'll summarize for the net.

tom coradeschi    <+>    tcora@pica.army.mil    <+>    tcora@dacth01.bitnet

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 18:33:37 GMT
From:      mintaka!olivea!orc!bu.edu!buit13!kwe@bloom-beacon.mit.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple subnets on same cable
>What happens if different IP subnets live on the same ethernet cable?

	This question comes up often and bears mention occasionally.
Don't forget that what happens with subnets depends on who is looking
and how they are configured.

	If you subnet your (eg) Class B with eight bit subnet masks
and you don't want (can't have) variable length subnets, then subnet
layering looks attractive for configuring your routers.

	But your hosts can see things differently than their routers.
If you layer subnets, you may set the subnet mask on these layered
subnet hosts to be the network mask.  They will then ARP for all
members of their (subnetted) net and communicate directly to all their
directly attached neighbors with no extra hops, failure points or
extra traffic and the routers will answer for off-net members of the
subnetted net, if your routers are set to proxy ARP.

	It works for 4.2BSD and it works well for layered subnets.
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 18:41:17 GMT
From:      psuvm!jhl1@psuvax1.cs.psu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   DECnet encapsulation in TCP-IP
We're interested in encapsulating DECnet within a TCP-IP package.  We
are looking primarily for a software solution, although hardware
solutions would be considered.  If anyone knows of such a product.
please e-mail at the following address.

JEFF@PSUPEN.PSU.EDU

Thanks,
Jeffrey H. Lynn
Penn State College of Agriculture
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Nov 90 18:41:49 PRT
From:      CHIS%PTEARN.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@NIC.DDN.MIL
Please,

unsubcribe me.
                      Ana Violante
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 18:52:30 GMT
From:      mips!wdl1.wdl.fac.com!wdl51!wrl@apple.com  (Bill Lewandowski)
To:        tcp-ip@nic.ddn.mil
Subject:   ANNEX (FIXED)
Hi,
Thanks to all who replied. There were two problems.

1. I needed to have a /erpcd/bfs/gateways file
that specified a default gateway.

2. (This one I don't understand) The problem turned
out to be our cisco gateway security filters.

We have them set to allow tcp in only to ports 1023 & above.
(Standard set up). While using the debug icmp I could see that
we were sending out 'destination unreachables'. I added a filter
to allow any host to talk to our annex (any port) and it works.

I guess the annex does not set up its tcp connections to use
ports 1023 & above like normal systems (at least ones I'm
used to).

Thanks again to all the answers.

Bill.........

 
-- 
Bill Lewandowski		LORAL Western Development Labs
(408) 473-4362			Internet: wrl@wdl1.wdl.fac.com
FAX: (408) 473-7926		UUCP: wdl1!wrl
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 19:39:49 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Steven Eubanks)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SMB/NETBIOS/RFC1001/RFC1002 server  product

	I am interested in examining NETBIOS/SMB servers for both *NIX
and VMS-based platforms.  I'm aware of one company call Syntax Systems
having a product in this area.  Are there others?  Company names and phone
numbers would be appreciated as well as any experiences with this type of
product (good and/or bad).


Thanks in advance!

Steve
--
Steven W. Eubanks,  EDS/LIMS			NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-8498					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 20:16:54 GMT
From:      julius.cs.uiuc.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sccsi.com!sugar!ficc!peter@apple.com  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
In article <9011061147.AA20765@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET writes:
> Dialup IP services are quite inexpensive, and if set up with care will
> give all the advantages of a dedicated circuit only with an occasional
> 30 second delay (those times when the line must be brought up.)

Um, won't this cause problems with SMTP? What does SMTP do when the
destination is only available for brief periods, or should you handle
your mail via an MX?
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com 
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 21:13:31 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)

      - Does tn3270 work with X-Windows(Openlook and Motif), Sunview
        and ASCII Terminals ?

   The curses output can be sent to a terminal emulator running in a
   window.

Alternatively, get expo.lcs.mit.edu:contrib/x3270-1.2.tar.Z, Jeff
Sparkes' X port of Robert Viduya's 3270tool.
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 22:19:38 GMT
From:      ceco!jon@uunet.uu.net  (Jon Castle)
To:        tcp-ip@nic.ddn.mil
Subject:   Problem with Xmodem and Micom terminal server (was Re: Problem with Xmodem and 3Com terminal server)

In article <9011071849.AA21432@ain.ESD.3Com.COM> rxk@ain.ESD.3Com.COM (Rajeev Kochhar) writes:
}mmorse@Z.NSF.GOV ("Michael H. Morse") writes:
}
}>I am having a problem getting Xmodem to work between a Sun workstation
}>and a PC running a terminal emulator.
}
}>The PC uses a modem and a dial-up line to communicate, but it cannot
}>get to the workstation directly because the workstation has no serial
}>ports.  Instead, the PC logs on to some other host, and then uses
}>telnet to get to the workstation.
}
}>I suspect this has something to do with parity, since the ASCII
{>characters transmitted by Xmodem, and received by the PC are
{>identical.  Has anybody run into a similar problem? Any information on
{>how telnet reacts when raw mode is selected would be appreciated.
{
{For a completely transparent session the terminal parameters should be set
{as following:
{
{XmitBinary = ON
{FlowControlTo = none
{FlowControlFrom = none
{ECMChar = disable
{BreakChar = disable
{DataBits = 8
{Parity = None
{

I have exactly the same problem only this is with a Micom terminal server 
(the InstaGate1500).  I dial up from home to a modem at work through the
terminal server, and then connect to a Sun.  I tried seting up similar 
settings in the Micom InstaGate1500, but to no avail.  I must be missing
something.  Does anyone have a Micom specific solution to this problem?
Thanks.

Jon Castle                      jon@ceco.com
Commonwealth Edison Co.         (312)294-2824
Chicago, IL
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 22:23:13 GMT
From:      rpcfod@uarthur.UUCP (Robert Patt-Corner)
To:        comp.protocols.misc,news.software.nntp,comp.protocols.tcp-ip
Subject:   NNTP (Network News Transfer Protocol) Query

Our organization is looking to implement netnews -- we're at the beginning,
where things can be started well or badly.

I'm convinced we should implement NNTP (network news transfer protocol)
and encourage users to use nntp front ends, such as the NetNews reader 
for the Mac done by Harry Chesley.

This is a request for some help in:

1.	Finding the appropriate newsgroup to start a discussion?  It's
	not at all clear to me where NNTP discussions go.

2.	Investigating the two big barriers that NNTP faces here:

	a.	How can you charge back to support a service whose main
		virtue is that it does not require a user account to use?

	b.	What front ends for NNTP are available for boxes other
		than Mac's, especially DOS boxes.

3.	Finding Harry Chesley's email address?

Please respond by mail ... I'll move the thread appropriately.

Thanks -

Robert

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Nov 90 23:44:09 GMT
From:      sdcc6!jclark@ucsd.edu  (John Clark)
To:        tcp-ip@nic.ddn.mil
Subject:   ETHERNET Packet TYPES

I need to know where to find the registered ethernet types
which can occur in the ethernet packet type field. The standard
'/usr/include/..." type files have what the local unix machine
is capable of understanding but leave no clue as to what else
one may expect when one is monitoring raw packets from the net.
-- 

John Clark
jclark@ucsd.edu
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 01:52:30 GMT
From:      CHIS@PTEARN.BITNET
To:        comp.protocols.tcp-ip
Subject:   (none)

Please,

unsubcribe me.
                      Ana Violante

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Nov 90 9:41:29 PDT
From:      salzman@nms.hls.com (Mike Salzman)
To:        xxseub@osprey.lerc.nasa.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SMB/NETBIOS/RFC1001/RFC1002 server  product
Steve,

There is a company in the Seattle area,  called Interconnections
who developed the IPX stack and server for VMS.  That product
is primarily sold by Novell, as Novell for VMS.

They had plans to branch out into the LAN MAN area with SMB
services at some point.  I last talked to them in 88.

Anyway, they may be reached at (206) 881-5773 voice, or
(206) 867-5022 fax.  
Address:
	InterConnections Inc.
	14711 N.E. 29th Place, Suite 100
	Bellevue, Wa 98007

-------------------- salzman@hls.com ----------------------
Michael M. Salzman  Voice (415) 966-7479  Fax (415)960-3738	
Hughes Lan Systems  1225 Charleston Road   Mt View Ca 94043 
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Nov 90 11:17:49 -0500
From:      jcurran@SH.CS.NET
To:        Peter da Silva <julius.cs.uiuc.edu!ficc!peter@apple.com>
Cc:        tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET
Subject:   Re: Cost of Internet access
Regarding dialup IP services, Peter da Silva writes:
> Um, won't this cause problems with SMTP? What does SMTP do when the
> destination is only available for brief periods, or should you handle
> your mail via an MX?

As long your implementation automatically brings up the circuit when there
is a packet queued (at either end), the application layer can not distinguish
dialup IP services from dedicated.  SMTP simply gets a long delay on the 
initial connection.

/John
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 05:55:14 GMT
From:      mintaka!olivea!oliveb!pyramid!cbmvax!grr@bloom-beacon.mit.edu  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
> We're interested in encapsulating DECnet within a TCP-IP package.  We
> are looking primarily for a software solution...

I believe TGV multinet can handle this...

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      Sat, 10 Nov 90 19:38:22 -0800
From:      Einar Stefferud <stef@ICS.UCI.EDU>
To:        halley!phil@cs.utexas.edu
Cc:        webster_phil@tandem.COM, tcp-ip@nic.ddn.MIL Einar Stefferud <stef@ICS.UCI.EDU>
Subject:   Re: Simple Book
> Date:    09 Nov 90 16:56:55 +0000 
> Subject: Simple Book
> From:    halley!phil@cs.utexas.edu
>To:      tcp-ip@nic.ddn.mil

> I need information on the publisher of Marshall Rose's recent book on
> SNMP entitiled, I believe,
> "The Simple Book".

> Thanks,

> Phil Webster        (Keep trying if halley bounces mail.  It's flakey)
> (cs.utexas.edu!halley!phil, phil@halley.uucp, webster_phil@tandem.com)
>  ^Preferred                                   ^Most reliable (?)

@book{Simple.Book,
	author	=	mtr,
	title	=	"{The Simple Book: An Introduction to Management of
			  TCP/IP-based internets}",
	publisher=	{Prentice-Hall},
	address	=	{Englewood Cliffs, New Jersey},
	series	=	{Prentice Hall Series in Innovative Computing},
	year	=	1990,
	note	=	{ISBN 0--13--812611--9}
    }
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 15:44:01 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!ra!emory!hubcap!ncrcae!ncr-sd!simasd!jadpc!jdeitch@ucsd.edu  (Jim Deitch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
In article <WA_6L.@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In article <9011061147.AA20765@ucbvax.Berkeley.EDU> jcurran@SH.CS.NET writes:
>> Dialup IP services are quite inexpensive, and if set up with care will
>> give all the advantages of a dedicated circuit only with an occasional
>> 30 second delay (those times when the line must be brought up.)
>
>Um, won't this cause problems with SMTP? What does SMTP do when the
>destination is only available for brief periods, or should you handle
>your mail via an MX?
>-- 
>Peter da Silva.   `-_-'
>+1 713 274 5180.   'U`
>peter@ferranti.com 

Not at all.  SMTP will just hold the message on queue until either
sendmail or whatever you are using to smtp with wakes up and tries
again to send it.  If it can't connect within about 3 days or so then
it is returned to the sender.  This is the way it works for both
directions.  Once you have the link up you can invoke sendmail -q to
run the queue and deliver what it can.

Jim



-- 

UUCP: nosc!jadpc!jdeitch
ARPA: jadpc!jdeitch@nosc.mil
INET: jdeitch@jadpc.cts.com
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 16:17:49 GMT
From:      jcurran@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   Re: Cost of Internet access

Regarding dialup IP services, Peter da Silva writes:
> Um, won't this cause problems with SMTP? What does SMTP do when the
> destination is only available for brief periods, or should you handle
> your mail via an MX?

As long your implementation automatically brings up the circuit when there
is a packet queued (at either end), the application layer can not distinguish
dialup IP services from dedicated.  SMTP simply gets a long delay on the 
initial connection.

/John

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 17:51:14 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ETHERNET Packet TYPESREAD/NEW/FOLLOWUP
In article <14048@sdcc6.ucsd.edu>, jclark@sdcc6.ucsd.edu (John Clark) writes:
> 
> I need to know where to find the registered ethernet types
> which can occur in the ethernet packet type field. The standard
> '/usr/include/..." type files have what the local unix machine
> is capable of understanding but leave no clue as to what else
> one may expect when one is monitoring raw packets from the net.

See RFC1060. It is available from NIC.DDN.MIL. 
FTP NIC.DDN.MIL
ftp> Login anonymous
Password: your-user-name
ftp> cd rfc: (The ":" is CRITICAL!)
ftp> get rfc1060.txt
ftp> quit

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

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 20:09:42 GMT
From:      sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino@decwrl.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   humanitarian request


Dear NetFolks,

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

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

Please send your card to:

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


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

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

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

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

PS - I apologize for the possible redundancy of posting this net-wide. I
     hope everyone can understand the necessity/urgency of the situation.
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Nov 90 23:06:36 GMT
From:      world!bzs@decwrl.dec.com  (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access

>As long your implementation automatically brings up the circuit when there
>is a packet queued (at either end), the application layer can not distinguish
>dialup IP services from dedicated.  SMTP simply gets a long delay on the 
>initial connection.

That doesn't quite answer Peter's message. What about some random host
out there with mail for you? He tries to connect, gets a timeout since
you're not dialed in at the moment, and re-queues. Chances are slim
that you'll be dialed in when he happens to retry unless you're dialed
in a lot.

Of course, if the other host will also dial you then that's a
solution. But I'm pretty sure (due to voice network charges and the
service relationship usually implied) this is not the model most
people are thinking of, they are effectively a leaf node and dial a
centralized host providing the SLIP service to them.

One has to either use MX records so the centralized host accepts and
forwards the mail (the easiest solution), or use something like POP.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 02:53:10 GMT
From:      stan!marvin!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
Someone write:
>>As long your implementation automatically brings up the circuit when there
>>is a packet queued (at either end), the application layer can not distinguish
>>dialup IP services from dedicated.  SMTP simply gets a long delay on the 
>>initial connection.

But most systems time out if they don't get a connection after 30
seconds or so.  When I dial in to work from home, it takes at least
that long to make the connection.  Since a mailer will requeue to try
later (anywhere from 10 minutes to a day depending on the mailer%),
the line may well have disconnected by then to save charges.

In article <BZS.90Nov10150636@world.std.com> bzs@world.std.com (Barry Shein) writes:
>Of course, if the other host will also dial you then that's a
>solution. But I'm pretty sure (due to voice network charges and the
>service relationship usually implied) this is not the model most
>people are thinking of, they are effectively a leaf node and dial a
>centralized host providing the SLIP service to them.

However, SMTP doesn't work this way in practice.  Sure, there is a
command that tells the mail daemon on a remote machine to send mail
down the line, but it isn't widely implemented.  Unless my machine can
connect to your machine, the mail usually doesn't go out.

>One has to either use MX records so the centralized host accepts and
>forwards the mail (the easiest solution), or use something like POP.

This sounds like a good idea.  But if you are going to do dialup
already, why not just use uucp mail?  It is simpler to setup than
arranging slip lines.

The whole idea of dialup access is good, if it can be done "fast" and
on demand.  TCP connection would show the line is still in use, but
how do you work out things like UDP packets?  There is no "connection"
data or state associated with them.

Warner
--
%Mailers -- Sendmail is one mailer that is on the Internet.  There are
others that don't behave the same way that sendmail does, but are not
the less just as standard conforming as sendmail.
--
Warner Losh		imp@Solbourne.COM
How does someone declare moral bankruptcy?
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 09:35:00 EST
From:      "VSDEC::SHERMAN" <sherman%vsdec.decnet@nusc.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?
Hi.

I've had/seen an intermittent problem over the last 8 years, and
I have yet to bump into anybody who can explain why I see this
problem, or what it is. 

I'll be connected to some computer via modem doing my normal work
when suddenly I'll get about 60 uppercase Us on my screen.  From
then on, everything I type gets echoed on my CRT but I get no
responses back from the computer that I'm connected to.  I've
tried typing commands that would effect things on the computer
that I'm dialed up to so that when I sign back on again I could
tell if it was seeing what I typed, but the commands were never
acted upon.  But the modem is still off-hook and got a carrier-
detect. 

I've seen the mysterious UUUUUUUs using different terminals and
terminal emulators, when using different modems, when dialed up
not only to different computers, but also different sites across
the country.

Does anybody there know what this is?  I only happens perhaps 3
or 4 times a year, but it's always very annoying and extremely
puzzling. 

Bill

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Sun, 11 Nov 90  13:49:29 EST
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Why do mysterious UUUUUUUUUUUUs sometimes dance on my, screen?
This is rather off the subject of TCP/IP.  Perhaps further discussion
should be moved to Info-Modems Digest.

There was a bug in the original Bell 212 modem that managed to make its
way into some compatible modems.  The modem would erroneously enter
remote digital loop.  On one end this appeared as a continuous stream
of Us and on the other as a hung connection.  The bug was fixed in
later versions of the 212.  The bypass was to disable remote digital
loop.  At NIH we were early users of the 212 and worked with AT&T (Bell
Labs, as I recall) to assist them in tracking down the cause of the
problem.

Roger Fajman                                   Telephone:  +1 301 402 1246
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 14:35:00 GMT
From:      sherman%vsdec.decnet@NUSC.NAVY.MIL ("VSDEC::SHERMAN")
To:        comp.protocols.tcp-ip
Subject:   Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?

Hi.

I've had/seen an intermittent problem over the last 8 years, and
I have yet to bump into anybody who can explain why I see this
problem, or what it is. 

I'll be connected to some computer via modem doing my normal work
when suddenly I'll get about 60 uppercase Us on my screen.  From
then on, everything I type gets echoed on my CRT but I get no
responses back from the computer that I'm connected to.  I've
tried typing commands that would effect things on the computer
that I'm dialed up to so that when I sign back on again I could
tell if it was seeing what I typed, but the commands were never
acted upon.  But the modem is still off-hook and got a carrier-
detect. 

I've seen the mysterious UUUUUUUs using different terminals and
terminal emulators, when using different modems, when dialed up
not only to different computers, but also different sites across
the country.

Does anybody there know what this is?  I only happens perhaps 3
or 4 times a year, but it's always very annoying and extremely
puzzling. 

Bill

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 17:08:58 GMT
From:      paul@uxc.cso.uiuc.edu  (Paul Pomes - UofIllinois CSO)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?
sherman%vsdec.decnet@NUSC.NAVY.MIL ("VSDEC::SHERMAN") writes:

>Hi.
>
>I've had/seen an intermittent problem over the last 8 years, and
>I have yet to bump into anybody who can explain why I see this
>problem, or what it is. 
>
>I'll be connected to some computer via modem doing my normal work
>when suddenly I'll get about 60 uppercase Us on my screen.  From
>then on, everything I type gets echoed on my CRT but I get no
>responses back from the computer that I'm connected to.

Some line noise is triggering the remote modem to go into a test mode and/or
loopback.  Upper case 'U' characters have an alternating 1-0 bit pattern
useful for testing BER, etc.  The fix is to disable remote toggling of test
mode.

/pbp
--
         Paul Pomes

UUCP: {att,iuvax,uunet}!uiucuxc!paul   Internet, BITNET: paul@uxc.cso.uiuc.edu
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801-2910
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 17:33:58 GMT
From:      usc!zaphod.mps.ohio-state.edu!ub!palter@ucsd.edu  (Bill Palter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
In article <90312.114531CJS@psuvm.psu.edu> CJS@psuvm.psu.edu writes:
>In article <9011071458.AA25335@ftp.com>, jbvb@FTP.COM (James B. Van Bokkelen)
>says:
>We are using FTP Software's TN3270 to telnet to an AS/400.  It works
>pretty good; I wish it (TN3270) supported color or at least extended
>attributes (like underscore).  The default 3270-to-5250 keyboard mapping
>(on the AS/400) is brain-damaged, but (somewhat) easily remedied with a
>user command.  Also, it only does 24 lines.  I also use FAL's telnet to
>log onto the AS/400.  Extended color and highlighting work.
>
>Because of the weirdness in remapping the 3270->5250 keys, I wish I had a
>TN3720 that allowed its keyboard remapping to define more than one 3270
>key to be transmitted with one PC key.  The 5250 has 24 PF keys plus more
>than the usual 3270 attention keys: help, page up (roll down) and page
>down (roll up), some some functions have to be mapped to dual 3270
>attention keys (PA1+PFx or PA2+PFx).  A TN5250 would be nice for this
>reason.

	Can anyone point me to an IBM manual that describes a 5250 manual,
or a list of differences it has from a 3270.

	I have just finished implementing a new tn3270 and I am thinking about 
doing 3179-G or 5250 emulation as well. 

Bill Palter
Palter@twg.com
The Wollongong Group
2010 Corporate Ridge Drive
McLean VA. 22102
(703) 847-4570
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Nov 90 19:42:28 GMT
From:      world!bzs@decwrl.dec.com  (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?

In ASCII "U" is hex 55 or, in binary, your message is 01010101010101010101

Perhaps that's a clue.
-- 
        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 08:10:19 -0500
From:      jcurran@SH.CS.NET
To:        Warner Losh <stan!marvin!imp@boulder.colorado.edu>
Cc:        tcp-ip@nic.ddn.mil, jcurran@SH.CS.NET
Subject:   Re: Cost of Internet access
> This sounds like a good idea.  But if you are going to do dialup
> already, why not just use uucp mail?  It is simpler to setup than
> arranging slip lines.
> 
> The whole idea of dialup access is good, if it can be done "fast" and
> on demand.  TCP connection would show the line is still in use, but
> how do you work out things like UDP packets?  There is no "connection"
> data or state associated with them.
>
> Warner

Dialup IP provides a general transport service for mail, ftp, telnet, etc.
Many people are using dialup IP with automatic initiation for this reason 
and it works quite well.  Certainly a little care has to be used when setting
up mail and DNS [kids, don't try this at home..], but it's worth it for those
sites who can't afford the cost of a dedicated circuit.  

This line of conversation started regarding the high cost of connecting to the 
Internet; it's important to show there are alternatives to the direct line.

/John 
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 00:56:03 GMT
From:      usc!samsung!munnari.oz.au!bruce!gdwb.oz.au!csb@apple.com  (Craig Bishop)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 TELNET client (tn3270 ?) and AS/400 TELNET server (TCP/IP)
CJS@psuvm.psu.edu writes:
>Because of the weirdness in remapping the 3270->5250 keys, I wish I had a
>TN3720 that allowed its keyboard remapping to define more than one 3270
>key to be transmitted with one PC key.  The 5250 has 24 PF keys plus more
>than the usual 3270 attention keys: help, page up (roll down) and page
>down (roll up), some some functions have to be mapped to dual 3270
>attention keys (PA1+PFx or PA2+PFx).  A TN5250 would be nice for this
>reason.

I also would like TN5250. But even better would be an implementation
"x3270" which was "x5250". Anyone out there dong this?
--
Craig Bishop			Geelong & District Water Board
Phone: +61 52 262506		61-67 Ryrie St Geelong
Fax:   +61 52 218236		Victoria 3220 Australia
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 09:19:26 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   dial-up IP questions

There were a couple of questions about dial-up IP behavior that I'd like
to respond to (by the way, all this stuff was covered in a paper on dial-up
IP that Leo Lanzillo and I gave at the 1989 Winter USENIX).

Connection set up time:

    Someone pointed out that many TCPs limit their open timeout to 30 seconds,
which means dialing a link has to be done in less than 30 seconds.  This is
a known problem -- it turns out that you often find that dial-up IP connects
the link just as your SYN times out (recall that 30 seconds includes delays
before you get to the dial-up gateway, so even a dial-up IP that can connect,
in say, 15 seconds, often loses).   However Host Requirements now require
TCPs to have a much longer timeout, so if your TCP still does 30 seconds,
beat up on your vendor.

SMTP:

    There was a question about j-random host trying to SMTP to your system
which is behind a dial-up IP link.  If the link can be brought up at any time,
then assuming your TCP is HRRFC conformant, no problem.  However, some
sites limit the times their link can be brought up to minimize phone costs
(e.g. only at evening and weekend rates).  In these situations, people use
MX records to forward their mail to a particular machine, and then have a
program that tickles the remote mailer to deliver to them.  (This is NOT
done using TURN; rather the final destination machine telnets to a special
port, which causes the SMTP daemon to start up -- this avoids the security
problems of TURN).

Craig
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 09:00:02 PST
From:      postel@venera.isi.edu
To:        jclark@ucsd.edu, sdcc6!jclark@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  ETHERNET Packet TYPES

John Clark:

See page 35 of RFC-1060.

--jon.

	Date: 9 Nov 90 23:44:09 GMT
	From: sdcc6!jclark@ucsd.edu  (John Clark)
	Subject: ETHERNET Packet TYPES
	To: tcp-ip@nic.ddn.mil

	I need to know where to find the registered ethernet types
	which can occur in the ethernet packet type field. The standard
	'/usr/include/..." type files have what the local unix machine
	is capable of understanding but leave no clue as to what else
	one may expect when one is monitoring raw packets from the net.

	John Clark
	jclark@ucsd.edu

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 01:23:21 GMT
From:      att!emory!utkcs2!eljazzar@ucbvax.Berkeley.EDU  (Mohamad El Jazzar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA Telnet question
>I can't seem to get Telnet, FTP, or TN3270 to find my config.tel file.
>I've set an environment variable CONFIGTEL to point to this file (as 
>mentioned in the docs), but the programs still can't find it.  Is the
>environment variable different?
>
>Eric 

Try this:

  SET CONFIG.TEL=path-to-your-config.tel  (not CONFIGTEL)

It seems that this is a bug (feature?) in NCSA Telnet.

Mohamad
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 07:58:19 CST
From:      Dave Bergum <bergum@cim-tune.Honeywell.COM>
To:        "VSDEC::SHERMAN" <sherman%vsdec.decnet@nusc.navy.mil>
Cc:        "tcp-ip" <tcp-ip@nic.ddn.mil>, bergum@cim-tune.Honeywell.COM
Subject:   Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?
>  Date: 11 Nov 90 09:35:00 EST
>  From: "VSDEC::SHERMAN" <sherman%vsdec.decnet@nusc.navy.mil>
>  Subject: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?
>  To: "tcp-ip" <tcp-ip@nic.ddn.mil>
>  
>  Hi.
>  
>  I've had/seen an intermittent problem over the last 8 years, and
>  I have yet to bump into anybody who can explain why I see this
>  problem, or what it is. 
>  
>  I'll be connected to some computer via modem doing my normal work
>  when suddenly I'll get about 60 uppercase Us on my screen.  From
>  then on, everything I type gets echoed on my CRT but I get no
>  responses back from the computer that I'm connected to.  I've
>  tried typing commands that would effect things on the computer
>  that I'm dialed up to so that when I sign back on again I could
>  tell if it was seeing what I typed, but the commands were never
>  acted upon.  But the modem is still off-hook and got a carrier-
>  detect. 
>  
>  I've seen the mysterious UUUUUUUs using different terminals and
>  terminal emulators, when using different modems, when dialed up
>  not only to different computers, but also different sites across
>  the country.
>  
>  Does anybody there know what this is?  I only happens perhaps 3
>  or 4 times a year, but it's always very annoying and extremely
>  puzzling. 

You'll probably get a million responses to this...your modem is going
into remote digital loopback test mode with the modem at the other end.
 Occassionally you will get a burst of noise which looks to the modem
at the other end to be the escape sequence to put it into remote
digital loopback test mode.  In this mode a continuous stream of test
data is sent and compared with the known values.  This is a test used
to evaluate the connection between the modems.  There are configuration
straps in most modems that allow you do enable/disable the RDL test
mode from line commands.  Normally when a modem is put into RDL, its
local interface goes into analog loop test mode.  Sometimes you can get
it out of test mode by
putting your own modem into RDL and then setting it back to normal
mode.  Sometimes that just drops the line.

      A
-----/|\---------------------------------------+
-   / | \   Bergum@CIM-VAX.Honeywell.COM       |
-  /__|__\  Dave Bergum [MN26-3190]            |
-  t--'--/   2701 4-th Ave. S., Mpls, MN 55408 |
-~~~~~~~~~~  (612)870-5839                     |
-----------------------------------------------+
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 11:28:07 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        world!bzs@decwrl.dec.com  (Barry Shein)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
    One has to either use MX records so the centralized host accepts and
    forwards the mail (the easiest solution), or use something like POP.
    -- 
            -Barry Shein

And thus my posting a while ago asserting that "the time has come for
distributed mail protocols".  The SMTP outbound queue is not the best
place to hold messages while you wait for intermittent connectivity.
POP or PCMAIL or IMAP are a tremendous improvement.

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

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 08:38:49 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net  (Daniel Huber)
To:        tcp-ip@nic.ddn.mil
Subject:   PPP over ..... Does it work ? (HP)
Question to somebody with experience: Will that work?

I'd like to connect two UNIX computers (HP9000/835 and HP9000/375, both
with HP-UX 7.0) over a serial link.

HP distributes PPP on a tape (X.25 software, fileset NETINET i think)
for the 800 series. About 300 series, I don't know. Anybody knows ?

The way of connection:

		835 			HP9000/835S, name "aut"
		^
		|		
		v
		serial line, 19200Bd 	<30m, probably only 9600Bd
		^
		|			
		v
		asynchron to synchron 	needed for multiplexer
		^			(only able to mux synchron)
		|			<2m
		v
		multiplexer		19200Bd -> AS/400 to 5394 (sync)
		^			19200Bd -> PPP
		|			 9600Bd -> 6150 connection
		v
		64kB/s modem	\
		^
		|		  >	~3km, digital link
		v
		64kB/s modem	/
		^
		|
		v
		multiplexer		19200Bd -> 5394 to AS/400 (sync)
		^			19200Bd -> PPP
		|			 9600Bd -> 6150 connection
		v
		synchron to asynchron	needed for multiplexer
		^			(only able to mux synchron)
		|
		v
		serial line, 19200Bd 	<4m, probably only 9600Bd
		^
		|
		v
		375			HP9000/375, name "oscad1"

I want to start the connection at boot time.
Programms running over this link: r-programms, telnet, ftp...

What's happen if one machine goes down?
Is this connection transparent to users? (if routing is correct)
Is this connection usefull? (performance etc.)
Is NFS possible?  ;-)  

And the most important question: 
Does it work ?

What would I need, to connect the two computers over a synchron line?

Thanks for any responses.

Daniel



-- 
Daniel Huber		Tel.	+41 31 52 96 64
Ascom Autelca		Fax.	+41 31 52 53 01
CH-3073 Guemligen	email:	dhuber@autelca.ascom.ch
Switzerland		uucp:	uunet!mcsun!chx400!hslrswi!aut!dhuber
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 08:47:29 GMT
From:      cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!ab4@rutgers.edu  (Andrew M. Boardman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why do mysterious UUUUUUUUUUUUs sometimes dance on my screen?
There was a an exhaustive discussion of this a while ago, in, I believe,
comp.dcom.telecom.  I seem to remember that this was caused by modems
trying to resync -- they would send alternating 1's and 0's until they
got back on speaking terms.

/a
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 10:00:29 GMT
From:      eru!hagbard!sunic!mcsun!ukc!mucs!logitek!martino@bloom-beacon.mit.edu  (Martin O'Nions)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple subnets on same cable
freiss@nixdorf.de (the hacker) writes:


>This might be a silly question, but it's been worrying me for some time.
>What happens if different IP subnets live on the same ethernet cable?

>I'm worried about excessive ICMP traffic (ICMP net_redirect packets);
>I see some SGI workstations here react to some packets from a
>different subnet with this ICMP message.

>Could somebody tell me if this is a problem or what other
>problems I haven't even thought of might arise?
>Pointers to books, RFCs etc. on this subject are also welcome.

Observe caution! RFC950 adds a couple of new ICMP types, including one
to allow determination of subnet mask for this segment. This specifically
states that a host may request the active subnet mask EVEN IF IT DOES NOT
KNOW ITS OWN IP ADDRESS (IP 0.0.0.0 (!?**@!)). Therefore, even though it
it is (hopefully) unlikely to occur, this section of the specification
could cause prob's if someone chose to implement the RFC in this detail.

(P.S. If anyone has any info. which updates/obsoletes/contradicts this,
don't flame me - mail me!)

--
+------------------------------------------------+-----------------------+
| I've got a little black book with my poems in, |     Martin O'Nions    |
| I've got a bag with a toothbrush and a comb in,| Logitek Group Support |
| When I'm a good dog they sometimes throw me a  | martino@logitek.co.uk |
| bone in           (Roger Waters - The Wall)    |      0257 426 644     |
+------------------------------------------------+-----------------------+
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 13:10:19 GMT
From:      jcurran@SH.CS.NET
To:        comp.protocols.tcp-ip
Subject:   Re: Cost of Internet access

> This sounds like a good idea.  But if you are going to do dialup
> already, why not just use uucp mail?  It is simpler to setup than
> arranging slip lines.
> 
> The whole idea of dialup access is good, if it can be done "fast" and
> on demand.  TCP connection would show the line is still in use, but
> how do you work out things like UDP packets?  There is no "connection"
> data or state associated with them.
>
> Warner

Dialup IP provides a general transport service for mail, ftp, telnet, etc.
Many people are using dialup IP with automatic initiation for this reason 
and it works quite well.  Certainly a little care has to be used when setting
up mail and DNS [kids, don't try this at home..], but it's worth it for those
sites who can't afford the cost of a dedicated circuit.  

This line of conversation started regarding the high cost of connecting to the 
Internet; it's important to show there are alternatives to the direct line.

/John 

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 14:19:26 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   dial-up IP questions


There were a couple of questions about dial-up IP behavior that I'd like
to respond to (by the way, all this stuff was covered in a paper on dial-up
IP that Leo Lanzillo and I gave at the 1989 Winter USENIX).

Connection set up time:

    Someone pointed out that many TCPs limit their open timeout to 30 seconds,
which means dialing a link has to be done in less than 30 seconds.  This is
a known problem -- it turns out that you often find that dial-up IP connects
the link just as your SYN times out (recall that 30 seconds includes delays
before you get to the dial-up gateway, so even a dial-up IP that can connect,
in say, 15 seconds, often loses).   However Host Requirements now require
TCPs to have a much longer timeout, so if your TCP still does 30 seconds,
beat up on your vendor.

SMTP:

    There was a question about j-random host trying to SMTP to your system
which is behind a dial-up IP link.  If the link can be brought up at any time,
then assuming your TCP is HRRFC conformant, no problem.  However, some
sites limit the times their link can be brought up to minimize phone costs
(e.g. only at evening and weekend rates).  In these situations, people use
MX records to forward their mail to a particular machine, and then have a
program that tickles the remote mailer to deliver to them.  (This is NOT
done using TURN; rather the final destination machine telnets to a special
port, which causes the SMTP daemon to start up -- this avoids the security
problems of TURN).

Craig

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Nov 90 14:20 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: SNMP Packages via Anonymous ftp?
>I'd love to see RFC 1147 - is there a site I can send mail to to get
>a copy via their info-server?

Yes.  Send an empty email message to service@nic.ddn.mil.  For the ASCII version
of the RFC, use SUBJECT line

     RFC 1147

For the postscript version (which I recommend, if you have a postscript
printer), use SUBJECT line

     RFC 1147.PS

For more info on the NIC document server, use SUBJECT line

     HELP

Regards,

Bob Stine
Applied Cybernetics, Inc.

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 16:46:04 GMT
From:      sdroppers@pbs.org
To:        comp.unix.ultrix,comp.protocols.tcp-ip,comp.sys.pyramid
Subject:   SL/IP on Ultrix 4.0 or Pyramid

I have SL/IP software for genric VAX and SUN.   Does anyone have any experience
puttin SL/IP on RISC machines?  I am looking for pointers especially for
DEC 5400 (Ultrix 4.0) and AT&T 7020 (Pyramid OSx).

Will what I have work in this environment?

Jarom


-------------------------------------------------------------------------------
  *Not paid for and/or endorsed by National Political Resources Incorporated.

(UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jhagen) 

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 17:18:15 GMT
From:      ingea@IFI.UIO.NO (Inge Arnesen)
To:        comp.protocols.tcp-ip
Subject:   LPD and RFC 1179

While going through RFC 1179 (thanks to L.J. McLaughlin for writing it!),
I've stumbled across a few points I need some help with:

1) In section 3.1 in RFC1179, it says:
   "The source port must be in the range 721 to 731 inclusive."

   I've looked through a two different implementations, and I cannot find
   any reference to specific client port numbers, expect that they must be
   in the reserved range (below 1024). RFC1060 does not list these port
   numbers as reserved for LPD client. Is this number range reserved for
   LPD ? Are checks made by different LPD's to verify client source number?

2) In section 6.3 in 1179, it says:
   "The total number of bytes in the stream may be sent as the first operand,
   otherwise the field should be cleared to 0"
   Note: The receive data file command.

   Once again I've looked at source code and done some testing, and I cannot
   understand the perpose of setting the "number of bytes" field to zero.
   If this this field is cleared, the LPD server part assumes that the data
   file has a zero length (as far as I can see from the BSD source and some
   other implementations).

   Are there implementations around that allow the client side to specify
   zero data file length to mean unknown length ? In that case, how does
   the server side know when the whole data file has been transfered ?
   If the file is pure ASCII it poses no problem, since the terminating
   NULL char can act as an EOF marker, but what about non-ASCII files ?


Inge (BoB)  { ingea@ifi.uio.no }
=========================================================================
==   Inge Arnesen, University of Oslo, Norway.                         ==
==                                                                     ==

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Nov 90 22:44:05 GMT
From:      steve@grian.cps.altadena.ca.us (Steve Mitchell)
To:        comp.dcom.lans,comp.windows.ms,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   need to synchronize PC to Sun over TCP/IP

I'm running a PClone/386 diskless using Excelan TCP/IP and Beame &
Whiteside NFS over an Ethernet.  Quite often when attempting to save a
file my word processor complains that someone has modified a file it
is editing.  I've been told by Carl Beame (our NFS vendor) the problem
is that the clocks on the PClone and the Sun fileserver are out of
synch.  Since both clocks drift, and at different rates, I'm looking
for a program which can be run by the PClone at boot to query the Sun
for its time, and then set the local clock accordingly.  Is there such
a program?  Is there a public domain version?  If so, where can it be
found?

Please email any replies, as I can't cover all these groups very
often.

Thanks to all for your help.
-- 
		-  Steve Mitchell	steve@cps.altadena.ca.us
					grian!steve@elroy.jpl.nasa.gov
					ames!elroy!grian!steve
"God is licht, an in him there is nae mirkness ava." -- 1 John 1:5

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 00:22:37 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: humanitarian request
In article <26685.273c1836@kuhub.cc.ukans.edu> decwrl.dec.com!sdd.hp.com!caen!kuhub.cc.ukans.edu!petrino@ucsd.edu writes:
>
>
>Dear NetFolks,
>
>We would appreciate your responding to the request of Craig Shergold who
>is a seven year old boy with an inoperable tumor on his brain.
>
>He has not been given a very long time to live and it is Craig's ambition
>to enter the Guiness Book of World Records for the largest number of get
>well cards ever received by an individual.
>                              
>----------------------------------------------------------------------
>       Jack Petrino (DRAGON)        int: PETRINO@KUHUB.CC.UKANS.EDU         
>       Systems Testing              bit:     PETRINO@UKANVAX
>       University of Kansas         vox:      (913)864-0443          
>       Computer Center              fax:      (913)864-0485    
>-----------------------------------------------------------------------
>
>PS - I apologize for the possible redundancy of posting this net-wide. I
>     hope everyone can understand the necessity/urgency of the situation.

NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO!

This situation is not urgent. This drivel has been circulating for
over a year. Craig Shergold, the Guiness Book of World Records, the
hospital, the post office and many others have been pleading for
people to STOP sending cards.

If I see this one more time, I'm going to devote the rest of my life
to developing a /dev/cattleprod that works through a network
connection.

However, there is a FAX number :-)

The *only* reason I am posting at all is to try to convince people to
remove this dreck from any and all computer storage media. A blowtorch
might be appropriate. PLEASE DO NOT PASS THIS ANY FURTHER!


Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: sun!suntan!tots!tep
Tactical and Training Systems Division  |
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 00:45:29 GMT
From:      apple.com!fair@apple.com  (Erik E. Fair)
To:        tcp-ip@nic.ddn.mil
Subject:   Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET
I am in the market for a device that will do two things:

1. Accept X.25 calls and then allow outbound connections to TELNET
	servers on an Internet.

2. Accept inbound TCP connections, and then allow outbound X.25 calls
	to destinations on an X.25 network.

In effect, I want a protocol coverter for remote login protocols.
It would also be nice to be able to restrict who can use this network
resource through some kind of access control and/or password mechanism.

I'd like the TCP implementation to behave well on the Internet, although
the majority of time it will be used for local ethernet connections. 

I'd like the X.25 implementation to be as completely configurable as
possible, given the rather wide variations in X.25 service providers
in the U.S.

I have two promising candidates so far:

	the cisco Systems Protocol Converter
	the Datability Vista VCP-1000

This posting is to request information from the assembled multitudes
of the network:

1. If any of you have purchased either or both of the above named
	devices, I'd love to hear accolades, curses, etc. relating to
	your experiences with them.

2. Who have I missed? Are there other products which might fill my
	need in this area?

Thanks for your time & trouble,

	Erik E. Fair	apple!fair	fair@apple.com
-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Nov 90 14:23:57 -0500
From:      mrf@ftp.com
To:        sdcc6!jclark@ucsd.edu  (John Clark)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: ETHERNET Packet TYPES
    From: sdcc6!jclark@ucsd.edu  (John Clark)
    Organization: University of California, San Diego
    Subject: ETHERNET Packet TYPES
    
    I need to know where to find the registered ethernet types
    which can occur in the ethernet packet type field. The standard
    '/usr/include/..." type files have what the local unix machine
    is capable of understanding but leave no clue as to what else
    one may expect when one is monitoring raw packets from the net.
    
    John Clark
    jclark@ucsd.edu

This information can be found in RFC 1060 (Assigned Numbers).  This
RFC (and others) is available for anonymous FTP from the NIC (at
nic.ddn.mil).

Margaret Forsythe	Technical Support	FTP Software, Inc.
(617) 246-0900 		FAX: (617) 245-7943	E-mail:  mrf@ftp.com

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Nov 90 14:59:48 EST
From:      cliff@alpha.eng.wayne.edu (Cliff Stallings)
To:        tcp-ip@NIC.DDN.MIL
Cc:        cliff@wsu-eng.eng.wayne.edu
Subject:   removal from the users group
Please remove me from this users group...
 
Thank you...
 
Cliff Stallings


cliff@wsu-eng.eng.wayne.edu
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 13:46:58 GMT
From:      hvoslef@ifi.uio.no (Hvoslef)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.misc
Subject:   PD NFS client for read/write of remote files ?

I am looking for a public domain source doing the NFS client
side. I only need a very stripped version doing reads/writes of 
remote files.

The size of the resulting binary is important, as I have limited
RAM. I am also using a hand-crafted real-time monitor which
happens to have a few unix-like kernel calls.

Do I have to jump on the NFS license wagon or can anybody help me ?

-------------------------
hvoslef@ifi.uio.no

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 14:35:19 GMT
From:      snorkelwacker!ira.uka.de!fauern!tumuc!guug!ecrc!dave@bloom-beacon.mit.edu  (Dave Morton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Cost of Internet access
In article <9011101731.AA20352@ucbvax.Berkeley.EDU>, jcurran@SH.CS.NET writes:
|>Regarding dialup IP services, Peter da Silva writes:
|>> Um, won't this cause problems with SMTP? What does SMTP do when the
|>> destination is only available for brief periods, or should you handle
|>> your mail via an MX?
|>
|>As long your implementation automatically brings up the circuit when there
|>is a packet queued (at either end), the application layer can not distinguish
|>dialup IP services from dedicated.  SMTP simply gets a long delay on the 
|>initial connection.
|>
|>/John
           
This is exactly how tund appears to work on X.25 links. If you're on a
fixed cost X.25 net like the WiN then that's ok, if you're on a fee per
packet X.25 net then you might end up paying even though the other site
has established the call. Tund, for example, re-establishes it from your
side. We ran into this situation recently - it can be expensive....

Dave Morton,
European Computer Research Centre		Tel. + (49) 89-92699-139
Arabellastr 17, 8000 Munich 81. Germany.	Fax. + (49) 89-92699-170
E-mail:	dave@ecrc.de
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 14:46:21 GMT
From:      encore!mperlman@husc6.harvard.edu  (Mark Perlman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple subnets on same cable
In article <martino.658404029@krypton> martino@logitek.co.uk (Martin O'Nions) writes:
>freiss@nixdorf.de (the hacker) writes:
>
>
>>This might be a silly question, but it's been worrying me for some time.
>>What happens if different IP subnets live on the same ethernet cable?
>
>>I'm worried about excessive ICMP traffic (ICMP net_redirect packets);
>>I see some SGI workstations here react to some packets from a
>>different subnet with this ICMP message.
>
>>Could somebody tell me if this is a problem or what other
>>problems I haven't even thought of might arise?
>>Pointers to books, RFCs etc. on this subject are also welcome.

I may have missed some of the previous posting in response, however,
I'll put in my 2 cents for free.

You can "turn off" subnetting by specifying a metric of 0 (zero) when
you use the route command.  E.G.:
    route add <some_subnet_address> <some_host_address_in_your_subnet> 0

You also need to consider broadcasting addresses on this
multi-subnetted physical network.  A broadcast address of xx.xx.xx.255
says "all hosts on subnet xx.xx.xx.0", whereas, a broadcast address of
255.255.255.255 says "all hosts an my local network".  It requires some
forethought on your part to assure a working broadcasts.

I would reccommend getting your hands on Charles Hedrick's paper,
"Introduction to Administration of an Internet-based Local Network", 3
October 1988.

Hope this was useful.

+----------------------------------------------------------------------+
|                            Mark R. Perlman                           |
| Independent Consultant                          301-206-2016         |
| 14014 Oakpointe Dr.                             mperlman@encore.com  |
| Laurel, MD  20707                               uunet!gould!mperlman |
+----------------------------------------------------------------------+
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 16:32:32 GMT
From:      mcsun!cernvax!chx400!hslrswi!aut!dhuber@uunet.uu.net  (Daniel Huber)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How do you use Dial-up SLIP?
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:

>All you need is a little program to detect the need for an outgoing 
>connection, dial up and establish the connection, and then drop it 
>when there is not traffic for some period.  It's not hard (I've done 
>it).  

If I "ping" the machine on the other side of the outgoing connection
(connection not yet established), does this work too?



-- 
Daniel Huber		Tel.	+41 31 52 96 64
Ascom Autelca		Fax.	+41 31 52 53 01
CH-3073 Guemligen	email:	dhuber@autelca.ascom.ch
Switzerland		uucp:	uunet!mcsun!chx400!hslrswi!aut!dhuber
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 16:58:07 GMT
From:      unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU  (Ruth Milner)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP/streams problems
We have a Sun 3/260, running 4.0.3, which runs SLIP and has been running into
problems with streams allocation. Usually this just consists of SLIP making
"slip_output can't allocb" complaints, but today it spilled over into general 
terminal usage. The root of the problem is that we are running out of the 
larger streams buffers (excuse me if I haven't got the terminology correct; 
I don't know very much about streams internals). The number of NBLK512/1024/
2048/4096 has already been increased once from the pathetically low values 
they had originally, but it made no noticeable difference to SLIP. 

Today we started seeing problems with the terminal driver being unable to
allocate streams buffers. "cat" was unable to output files over about 1K
directly to the screen (no problem with redirection to disk or any other
command). The output from "netstat -m" is as follows: 

372/448 mbufs in use:
    19 mbufs allocated to data
    12 mbufs allocated to packet headers
    103 mbufs allocated to socket structures
    137 mbufs allocated to protocol control blocks
    94 mbufs allocated to routing table entries
    2 mbufs allocated to socket names and addresses
    5 mbufs allocated to interface addresses
0/32 mapped pages in use
88 Kbytes allocated to network (52% in use)
0 requests for memory denied

streams allocation:
                                         cumulative  allocation
                      current   maximum       total    failures
streams                    22        23         157           0
queues                     80        84         621           0
mblks                     140       176      215604           0

total dblks               140       176      215604       90715
size    4 dblks             0        20       78588           0
size   16 dblks             3        22       32774           0
size   64 dblks             0        34       98291           0
size  128 dblks            52        55        2850           0
size  256 dblks             1        11        2089           0
size  512 dblks            28        28         267       11794
size 1024 dblks            28        28         689       45369
size 2048 dblks            28        28          56       33530
size 4096 dblks             0         0           0          22
 
As you can see, the problem is definitely in the streams area, not with
memory buffers or anything like that. Normally when this problem shows up,
the number of allocation failures is an order of magnitude lower than this.

So far all we have been able to do to cure this problem is reboot. Our
version of SLIP is up-to-date. Does anyone have any idea what's going on,
and/or how to fix it? It looks to me as though SLIP (or something, but it's
the likeliest possibility) is allocating buffers and not letting go of them
properly afterwards.

Thank you very much.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Nov 90 18:08:33 +0000
From:      Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   refile +archive


does anyone know of a third level to the mh mail interface program -
refileing and folder +'ing to an archive - this would be jolly handy

plus

why, oh pray, has no-one done a level up from the folders 
folder +../bboards

or some such...so we get (x)mh integrated support in a uniform way for
e-mail & bboards...

answers in a P2 envelope...:-)

btw - is there a good bboard for discusion of mailsystem&bboard UA
programs

thanks

jon 
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 02:16 PST
From:      Denis DeLaRoca (213) 825-4580        <CSP1DWD@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: CUTCP/CUTE
This question is more appropiately placed in the
cutcp@omnigate.clarkson.edu discussion list.

Try setting splay=no in your config.tel file. Splay compression is
a feature that Brad Clements, cutcp's author, was playing with in
connection with Header Compression (the VJC parm which must also be
set to no).

-- Denis
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 19:10:54 GMT
From:      wuccrc!dworkin!christos@louie.udel.edu  (Chris Papadopoulos)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for probes for TCP/IP
Let me first introduce myself. I am Christos Papadopoulos, a graduate
student at Washington Univ working with Guru Parulkar. I am interested
in remote visualization. I plan to implement an application which we
think has characteristics typical of visualization applications and
distribute it across our campus network using TCP/IP. Then tap in the
protocols at different levels and take various measurements to
identify where the bottlenecks are (if any).  

The application we picked is "Display of cell trajectories in 3D
using Optical Sectioning Microscopy". This uses an optical microscope
equipped with a CCD camera to collect images of planes in an organism.
The big advantage of this method is that there is no physical slicing
involved, thus the organism does not have to be killed. The CCD camera
has variable pixel resolution of up to 1000 by 1000, at 4096 graylevels.
The volumetric data will be in the range of 10-20 MBytes per image. To
trace the trajectories of cells several images need to be collected to
construct a short animation. There is a number of steps that need to be
performed before the data can be rendered. These include elimination of
noise due to the point spread function of the lens, edge enhancement,
image segmentation and various geometric transformations.

After distributing the application we would like to monitor the
communication and take measurements on protocol overhead. The
communication model we think may be appropriate is as follows:

              TCPq     Networkq         Networkq    TCPq
--------      ----|      ----|           ----|      ----|      ----------
|Sender|----->  |||----->  |||---------->  |||----->  |||----->|Receiver|
--------      ----|      ----| Ethernet  ----|      ----|      ----------

    The measurements we would like to take include:
    	(i)	Dynamic queue length at the various queues
    	(ii)	Various delays a packet experiences

The question I want to ask is the following:

Are there probe and measurement utility programs which will allow us
to take these measurements without any kernel modifications? 

	Thanks in advance,

Christos.
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 19:20:32 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!news.cs.indiana.edu!news!german@ucsd.edu  (Chad W. German)
To:        tcp-ip@nic.ddn.mil
Subject:   CUTCP/CUTE
is release D.  I'm using the software with Netware 286.  I unarchived
it with the Zoo utilities and configured the config.tel file.  When
I fire up the program it recognizes by card and puts me in server mode.
I have no problems with the software BUT I get a message:

Server mode, press ESC to exit or Alt-A to begin a session
Configfile: Warning, this version not compiled with Splay Compression
             Support

Can anyone advise me on this error message??????

Thanks in advance for all info.    
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 20:56:23 GMT
From:      LA.TIS.COM!gds@apple.com  (Greg Skinner)
To:        tcp-ip@nic.ddn.mil
Subject:   ftp between IBM's secure xenix and SunOS 4.1
If anyone out there has experienced any kind of trouble with bogus IP
options issued by IBM's secure xenix during ftp's with SunOS 4.1
machines (or for that matter, any other machines) please let me know
by email.

--gregbo
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Nov 90 23:36:08 GMT
From:      usc!coh!rzelman@ucsd.edu  (R. Zelman)
To:        tcp-ip@nic.ddn.mil
Subject:   Macintosh & TCP/IP

Does anyone know of good TCP/IP software for the MAC?  In our lab
we have a number of online instruments connected to various systems
(DECstation 2100's, SUN Sparc station, Compaq 386) that we wish to
connect to a Macintosh 2 via ethernet.  The Dec's are running
ULTRIX.  The Mac will have a CD Rom read/write optical drive to
store the data from the instruments.  What would be a suitable
ethernet board to install in the Mac and what is the best software
to purchase?  Also, any ideas as to software and hardware to
connect the Compaq 386?  Please email to me direct.  Thanks in
advance.

Ron Zelman                  Internet: rzelman%coh@usc.edu
City of Hope
Duarte, CA
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 09:44:14 PST
From:      postel@venera.isi.edu
To:        LA.TIS.COM!gds@apple.com, tcp-ip@nic.ddn.mil
Subject:   Re:  ftp between IBM's secure xenix and SunOS 4.1

Greg:

Maybe you mean Datagrams with protocol type = 91 (in the field where TCP = 6)?
This is called LARP from Locus computing.  Everyone should feel free to give
Locus a very hard time about not documenting this in an RFC.

--jon.

	From tcp-ip-RELAY@NIC.DDN.MIL Wed Nov 14 03:38:31 1990
	Date: 13 Nov 90 20:56:23 GMT
	From: LA.TIS.COM!gds@apple.com  (Greg Skinner)
	Subject: ftp between IBM's secure xenix and SunOS 4.1
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil

	If anyone out there has experienced any kind of trouble with bogus IP
	options issued by IBM's secure xenix during ftp's with SunOS 4.1
	machines (or for that matter, any other machines) please let me know
	by email.

	--gregbo

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 02:00:52 GMT
From:      jk3n+@andrew.cmu.edu  (John Stephen Kalucki)
To:        tcp-ip@nic.ddn.mil
Subject:   IP Router-Where to Start?

I'm thinking about implementing an IP router, but I have no idea where
to start. I've browsed through the RFC index and a few RFC's themselves,
but there doesn't appear to be anything directly related to routers.

I'm looking basically for 4 things:
1) Related RFC's
2) Books and other text that might help
3) Public Domain implementations, hopefully source, to test mine with
4) Advice

Thanks.

		-John Kalucki
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 12:34:25 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        tcp-ip@nic.ddn.mil
Subject:   PPP software....
My apologies in case I'm abusing this list. But in response to a recent
note about a version of PPP we developed, I got so many requests for it
that I'm not about to respond individually.

I've made our version of PPP available for anonymous FTP. It's available
on

uhccux.uhcc.Hawaii.Edu

in directory

misc/ppp.tar.Z

It's freely available to anyone who wants it. Subject to the requirement that
you send bug reports/fixes back.

It currently depends on Sun's INR software for a lower layer synch driver for
the 85C30 which Sun uses for on-board serial ports. Roll your own if you
like. We have one of our own too, but it's in a pretty poor state.

					Torben
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 16:02:51 -0800
From:      Brian Gray RC <gray@george.arc.nasa.gov>
To:        tcp-ip@nic.ddn.mil
Subject:   mailing list

Please remove me from this mailing list:

Brian Gray
gray@yorktown.arc.nasa.gov
NASA Ames Research Center
415-604-5013

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 08:50:57 EST
From:      David T. Miller <dtm@ulana.mitre.org>
To:        LA.TIS.COM!gds@apple.com (Greg Skinner)
Cc:        tcp-ip@nic.ddn.mil, dtm@mbunix.mitre.org
Subject:   Re: ftp between IBM's secure xenix and SunOS 4.1

>If anyone out there has experienced any kind of trouble with bogus IP
>options issued by IBM's secure xenix during ftp's with SunOS 4.1
>machines (or for that matter, any other machines) please let me know
>by email.
>
>--gregbo

We discovered that our Sun's (SunOS 4.1) crash instantly when
attempting an FTP to a secure xenix host.  The secure xenix sends
fixed length IP headers - 32 octets - 12 bytes of padded zeroes
with no options. I have no idea why, but it causes the Suns to
immediately reboot, and as the Sun is trying to reboot, the xenix
machine begins retransmitting its last packet causing the Sun to
begin rebooting again.  This continues until you reboot the xenix
machine.  We contacted Sun and have received to patches which
corrected the problem on the Sun end.  I'm still not sure about
the xenix 32 octet IP headers.

The patches from Sun are #s:  100077-02 and 100149-01.  Sun will
mail these out to you if you report the problem.  Our contact
was Arlene at Sun Support (415) 336-6034.

Dave Miller
dtm@mitre.org
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 03:54:29 GMT
From:      cert!netnews.upenn.edu!scotty.dccs.upenn.edu!kehoe@lll-winken.llnl.gov  (Brendan Kehoe)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP between a Sun & SCO

 Hi there .. a friend of mine & I have been trying to devise a way for
him to use SLIP to telnet over to my machine over a V.32 modem. I've
got the stuff for my Sun (SS1 under SunOS 4.1). What we need to know
is what it would take on his end (SCO Xenix on a 386) to make this
happen. Would he have to fork out the $$ to get the TCP/IP
implementation for SCO? (I'm not a Xenix expert; Suns are my bag.)
 Thanks!


Brendan Kehoe | brendan@cs.widener.edu [ It's here, but it won't resolve yet ]
For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu
  "The latest polls indicate you're in danger of losing touch with the
	     common man."   "Oh DEAR ... heaven forfend!"
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 13:18:55 -0500
From:      George Williams <gwilliam@SH.CS.NET>
To:        "Erik E. Fair" <apple.com!fair@apple.com>
Cc:        tcp-ip@nic.ddn.mil, gwilliam@SH.CS.NET
Subject:   Re: Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET

In response to this portion of your query:

........

	the cisco Systems Protocol Converter
	the Datability Vista VCP-1000

This posting is to request information from the assembled multitudes
of the network:

1. If any of you have purchased either or both of the above named
	devices, I'd love to hear accolades, curses, etc. relating to
	your experiences with them.

2. Who have I missed? Are there other products which might fill my
	need in this area?


>>>  I believe xni-list@cs.net is the mailing list for additional info.

>>> () Third party (b)router people have jumped on the bandwagon with board
>>>    and standalone router solutions to IP/x.25 that are based on RFC877.
>>>
>>>   - Sun is one you didn't mention above. (RFC877 compliant)
>>> 
>>>   - Cisco is another as noted.           (RFC877 ditto   )
    
>>> () Cursory research I did in this area regarding interoperabilty between
>>>    cisco and the SUNLINK product resulted in following input (from cisco)
>>>    and observations to date:

>>> The above information left
>>> one to ask:

         1) Is your IP over X.25 based on this RFC (877)?
         > Yes. 

         2) Will cisco routers talk to this SUN product and if so what has been
            the user feedback, if any?
            > Yes; we have customers doing this. Indeed, we will talk to any
            >  machine that is RFC877 compliant.
            > The feedback is "rather quiet" because it generally works 
            > (unfortunately, feedback is often only received when there
            > is a problem!) 

         3) Do you even recommend trying this or is it known there is no
            compatibility between the two router products ?
            > Yes -- you should be able to do this.

            --Joel
>>>  Thanks to jpbion@cisco.com for above !

>>> () Marketing people from cisco however do not take an official "supported"
>>>   position for the above. They do say they will talk to "anything" that is
>>>   DDN X25 compliant,however.

>>> () CSNET work is in progress to bring up a SUN to CISCO connection of two
      ( international and domestic ) PDNs. It appears to be working with most
      of the problems technical administration ( being worked on ) of VC
      utilitazion.

>>>  BTW, there is a known problem with the sunlink product not clearing called
     "hung" VC's. This I think is being worked on.

  Good Luck,

  George Williams
  Technical Staff CSNET CIC 




-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 06:01:01 GMT
From:      pacbell.com!tandem!mytardis!narayan@ucsd.edu  (Narayan Mohanram)
To:        tcp-ip@nic.ddn.mil
Subject:   Any RFC for IP over ISDN?
I am looking for info if there is any RFC for IP over ISDN. If there is
not one, are there any implementations out there??

Thanks in advance for info.

Narayan Mohanaram

-- 
E-Mail:  narayan@mram.sunnyvale.ca.us	   ************************************
Phone:	 408-738-4165			   *   Lifes a reach, then you Jibe   *
USnail:	 908 W. Olive, Sunnyvale, CA 94086 ************************************
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 14:22:32 EST
From:      David Rankin <drankin%westford.ccur.com@RELAY.CS.NET>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Mail list madness!!!!!

Hello,

After being on the list for over a year, I have seen many
requests from people wanting to get off of the mailing list.
Usually these request are met with a less than constructive
reply, along the lines of "Don't clutter up the mailing list
with silly mail!".

May I suggest that someone please post the procedure so that
these poor souls (and the rest of us) can have some peace?

David
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 10:16:00 GMT
From:      CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   Re: CUTCP/CUTE

This question is more appropiately placed in the
cutcp@omnigate.clarkson.edu discussion list.

Try setting splay=no in your config.tel file. Splay compression is
a feature that Brad Clements, cutcp's author, was playing with in
connection with Header Compression (the VJC parm which must also be
set to no).

-- Denis

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 11:09:56 GMT
From:      lrb@rrivax.rri.uwo.ca (Lance R. Bailey)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: MultiLan vs Wollongong for VAX/VMS ?????

In article <9611.2735a48f@ul.ie>, bourkej@ul.ie writes...
>Can anyone compare the relative merits of TGV MultiLan and the Wollongong
>offering for VMX/VMS ?
>I'm told MultiLan is the bees knees, but does Wollongong live up to it ?

i use wollongong, and have tested multinet, i did not move to multinet because
of a certain functionality i needed. when i mailed to ken adelman about this,
he had a fix within a day.

1)
for functionality i think you will have people argue both sides.

2)
most of the net software i see is based on multinet, but more and more are
getting wollongong ports (like the news reader i use)

3)
for support, well.... the above example shows multinet, email a complaint
and they act immediatly. i have complained about wollongong support before
and the last time i did so, california phoned me to discuss the matter.
I later got some EXCELLENT support in installing the secure ftp product,
_however_ of the THREE modification requests i have sent in on their product,
i received:
    three electronic acknowledgements of receipt
    only two paper acknowledgements of receipt
"acknowledgement of receipt" is nothing more than "we got it, when it is
resolved one way or the other, you will hear from us. bye."

now, one of these mod. req. i labelled URGENT with a note that it adversely
affects software which we use on top of the ftpd.exe program -- software
that is integral to the running of our operation.  in the last month i
essentially have sat on my hands waiting for the wollongong god to grin upon
me.

to be fair, wollongong _does_ support many more platforms, so their
resource people are stretched across many platforms.


Lance R. Bailey, Systems Manager 
================================   box: Robarts Research Institute
email: lrb@rri.uwo.ca                   Clinical Trials Resources Group
  fax: 519.663.3789                     P.O. Box 5015, 100 Perth Dr.
  vox: 519.663.3787 ext. 4108           London, Canada N6A 5K8

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Nov 90 14:04 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Chris Papadopoulos <wuccrc!dworkin!christos@louie.udel.edu>
Cc:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: Looking for probes for TCP/IP
>... I plan to implement an application which we think has characteristics
>typical of visualization applications ...[t]hen tap in the protocols at
>different levels and take various measurements to identify where the
>bottlenecks are (if any).  
> ...
>    The measurements we would like to take include:
>       (i)     Dynamic queue length at the various queues
>       (ii)    Various delays a packet experiences
> ...
>
>Are there probe and measurement utility programs which will allow us
>to take these measurements without any kernel modifications? 

Christos,

You might check RFC 1147, "A Network Management Tool Catalog," for a list of
several tools.  Unfortunately, to the best of my recollection, the only tools
capable of monitoring actual queue lengths require some (well-documented) kernel
mods.  I could be wrong about this.  My gut feeling, however, is that getting
the queue lengths will require some special instrumentation, which in turn will
require kernel mods.

At any rate, I recommend that you take a look at the catalog entry describing
NETMON and iptrace, developed by Allison Mankin, of MITRE.  NETMON is
essentially kernel instrumentation for BSD-UNIX.  You might conclude that
avoiding mods to the kernel is not a hard-and-fast requirement.

For background on TCP/IP, I'd also recommend that you read RFC 1122,
"Requirements for Internet hosts -- communication layers."

- Bob Stine


-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 17:54:28 GMT
From:      chytil@vlsivie.tuwien.ac.at (Chytil Georg)
To:        comp.protocols.tcp-ip,comp.sys.apollo,comp.protocols.tcp-ip.domains
Subject:   bind 4.8.3. installation problems : help appreciated !

I'm currently in the frustrating process of installing bind 4.8.3 from
ucbarpa.berkeley.edu on an Apollo DN3500 running Domain/OS 10.2.0.5, more
or less BSD4.3 .

After some minor hacks (thanks, Apollonians !) it finally compiled fine, and
I'm now stuck in a runtime-problem :

When configuring itself through getnetconf() named tries to open a socket
on the net-interface (ok) and then on the local-loopback too --- and then
fails with an 'Can't assign requested adress' . Sigh.
While named's code is very readable as far as the how is concerned, I'm not
always sure about the 'why' (Well, this may also be due to my inexperience, but 
I'm not that daring to admit this ).

Why is the check_for_local_loopback situated _after_ the opensocket() in the
code ?
Why should local loopback interfere with the physical interface ?
	(Why can't I join the happy and drunk VMS-guys in the pub at 4pm sharp
	 1/2:-( 1/2;-) ).

some debugging-information follows :

Upon coming up named announces to syslog :

Nov 13 17:11:55 walter named[287]: restarted
Nov 13 17:11:55 walter named[287]: bind(dfd 6, 127.0.0.1[53]): Can't assign requested address

/usr/tmp/named.run shows :

Debug turned ON, Level 1000
Version = named 4.8.3 Wed Nov  7 19:07:03 MST 1990
	chytil@vlsivie://vlsivie/users/chytil/named/named.new/named
	bootfile = /etc/named.boot
dqp->dq_addr 128.130.40.5 d_dfd 5
dqp->dq_addr 127.0.0.1 d_dfd 6


point of failure is the call to bind() in opensocket -- should I add 
REUSE_ADDR (sp?) to socket-options or is this left out with purpose ?

			Thanx for Your help

					Georg

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 18:18:55 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote login protocol conversion, X.25/X.29 <=> TCP/TELNET


In response to this portion of your query:

........

	the cisco Systems Protocol Converter
	the Datability Vista VCP-1000

This posting is to request information from the assembled multitudes
of the network:

1. If any of you have purchased either or both of the above named
	devices, I'd love to hear accolades, curses, etc. relating to
	your experiences with them.

2. Who have I missed? Are there other products which might fill my
	need in this area?


>>>  I believe xni-list@cs.net is the mailing list for additional info.
 
>>> () Third party (b)router people have jumped on the bandwagon with board
>>>    and standalone router solutions to IP/x.25 that are based on RFC877.
>>>
>>>   - Sun is one you didn't mention above. (RFC877 compliant)
>>> 
>>>   - Cisco is another as noted.           (RFC877 ditto   )
 
>>> () Cursory research I did in this area regarding interoperabilty between
>>>    cisco and the SUNLINK product resulted in following input (from cisco)
>>>    and observations to date:
 
>>> The above information left
>>> one to ask:

         1) Is your IP over X.25 based on this RFC (877)?
         > Yes. 

         2) Will cisco routers talk to this SUN product and if so what has been
            the user feedback, if any?
            > Yes; we have customers doing this. Indeed, we will talk to any
            >  machine that is RFC877 compliant.
            > The feedback is "rather quiet" because it generally works 
            > (unfortunately, feedback is often only received when there
            > is a problem!) 

         3) Do you even recommend trying this or is it known there is no
            compatibility between the two router products ?
            > Yes -- you should be able to do this.

            --Joel
>>>  Thanks to jpbion@cisco.com for above !
 
>>> () Marketing people from cisco however do not take an official "supported"
>>>   position for the above. They do say they will talk to "anything" that is
>>>   DDN X25 compliant,however.
 
>>> () CSNET work is in progress to bring up a SUN to CISCO connection of two
      ( international and domestic ) PDNs. It appears to be working with most
      of the problems technical administration ( being worked on ) of VC
      utilitazion.

>>>  BTW, there is a known problem with the sunlink product not clearing called
     "hung" VC's. This I think is being worked on.

  Good Luck,

  George Williams
  Technical Staff CSNET CIC 

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 21:00:30 GMT
From:      smb@purdue.edu  (Scott M. Ballew)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why do I need multiple host names for the same host?
In article <705@keele.keele.ac.uk> csd35@seq1.keele.ac.uk (Jonathan Knight) writes:
>I have two questions.
>
>1)	When a host on the 192.82.242 network tries to talk to
>	'doc' is the packet addressed to 192.42.100.3? If not
>	is this packet unpacked by doc?  If not does this packet
>	actually get placed on the 192.42.100 network and re-read
>	by doc?

Ok, first it will send it to 192.42.100.3 since this is the only
translation for the name doc.  Doc will recognize it as its own and
process it correctly (it does NOT go back out on the other net).  If
it were sent out on the other net, it is not guaranteed that doc could
read it back in (some ethernet interfaces hear themselves talking,
others do not).

>2)	Is there a way to indicate to each host that doc is local
>	on their ethernet?

We do the following with our gateways:
128.10.2.8      gwen gwen-en 
128.10.3.8      gwen gwen-xinu

(I have deleted the fully qualified domain names).  This seems to keep
everyone who does not run DNS (a rapidly shrinking number) happy.  I
don't know about booting, however, since we generally do not make a
file server a gateway.

Running a nameserver is probably a better bet but you may have reasons
not to do so.

Scott Ballew
Cypress Network Operations Center
Purdue University Department of Computer Sciences
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Nov 90 11:07:34 -0800
From:      "Philip Almquist" <almquist@jessica.stanford.edu>
To:        jk3n+@andrew.cmu.edu (John Stephen Kalucki)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Router-Where to Start?
John,
> I'm thinking about implementing an IP router, but I have no idea where
> to start. I've browsed through the RFC index and a few RFC's themselves,
> but there doesn't appear to be anything directly related to routers.
> 
> I'm looking basically for 4 things:
> 1) Related RFC's
	There are a lot of of relevant RFCs.  In addition to the router
standard (RFC1009) that Jon Postel mentioned, there are several RFCs on
the network layer (791, 792, 922, 950, 1112, 1122).  And of course
there ARP, all of the IP over mumble networks RFCs, routing protocols,
SNMP, ...

	There is also a draft successor to RFC1009 which is available
via anonymous FTP from NIC.DDN.MIL.  Its name is:

	internet-drafts:draft-ietf-rreq-iprouters-00.txt

> 2) Books and other text that might help
	Various good books, such as Comer's, provide a reasonably good
introduction to TCP/IP.  None that I know of teach nearly all of the
things you'd need to know to implement a router.

> 3) Public Domain implementations, hopefully source, to test mine with
	PCROUTE, KA9Q, and Berkeley UNIX are all reasonably easy to
obtain, though I don't have details for any of them on the tip of my
fingers.  Additionally, various universities (MIT, CMU, Stanford, and
probably others) have developed routers whose code is likely to be
available if you can figure out who at those institutions has the
authority to give it to you.

	One caveat, however: most if not all of the above are not fully
compliant with RFC1009.

> 4) Advice
	Don't underestimate the effort involved in building a router
from scratch.  You're talking man-years of effort to build even a
minimally reasonable one.
						Philip
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Nov 90 22:58:42 GMT
From:      news@apple.com  (John Veizades)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Macintosh & TCP/IP

This is a list of applications that run over MacTCP, Apple implementation
of the TCP/IP protocols.  The list is as complete as I could make it.  If
anyone has addition to the list please drop me a line.

John Veizades...
MacTCP Engineering Manager
Apple Computer, Inc.

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

Terminal Emulators and File Transfer Tools
	SUMac/IP 4.0 - Stanford University
	NCSA Telnet - University of Illinois
	tn3270 - Brown University
	Net/One MacUWS - Ungermann Bass
	TCP/Connect II - Intercon
	HyperFTP - Cornell University
	TGraph - Grafpoint
	PacerLink - Pacer Software, Inc.
	Mac Samson - Stanford University

Mail Tools
	POPStack - University of Minnesota
	MacMH 4.0 - Stanford University
	BeaverGate - University of Toronto
	Mews - University of Tasmania
	GatorMail - Cayman
	Mail*LInk - StarNine
	TCP/Connect II - Intercon
	NetNews - Apple Computer, Inc.
	MacPost - Lund University, Sweden
	IMap - Stanford University

X Servers
	MacX - Apple Computer, Inc.
	eXcedos - White Pines Software

Programming Libraries
	Stanford Streams - Stanford University
	Sockets - Novell
	Sockets - University of Toronto
	MacTCP XCMDS - Apple Computer, Inc.
	MacWorkstation Tool - University of Michigan

Databases
	Wingz - Informix
	Oracle
	Sybase

NFS
	The Wollongong Group
	InterCon
	GatorBox - Cayman

Gateways (Hardware and Software)
	GatorBox - Cayman
	FastPath - Shiva
	MultiGate - NRC
	Cornell
	Ungermann Bass
	The Wollongong Group
	MultiGate - Webster

Comm Toolbox
	TCPack - Advanced Software Concepts
	Pacer's CommToolbox interface

Miscellaneous
	MacNix - List
	Mathematica - Wolfram Research Inc.
	SNMP Agent - CMU - Excel based
	MacTCP API in A/UX - Apple

--
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 90 00:36:13 GMT
From:      munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!maree@THEORY.TN.CORNELL.EDU  (Maree Hegarty)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: bind 4.8.3. installation problems : help appreciated !
In article <1994@tuvie> chytil@vlsivie.tuwien.ac.at (Chytil Georg) writes:
>I'm currently in the frustrating process of installing bind 4.8.3 from
>ucbarpa.berkeley.edu on an Apollo DN3500 running Domain/OS 10.2.0.5, more
>or less BSD4.3 .

Talking about BIND 4.8.3...

I haven't seen much discussion about this release since Dave Curry sent an
article about 4.8.3 and SunOS 4.1 to sun-nets in early September.  I also
recall reading somewhere that BIND 4.8.2 wasn't actually official yet:-)
Can anyone tell me what's the official release?  What's the opinion about
BIND4.8.3?  What enhancements does it have over 4.8.2?

Maree.

--
------------------------------------------------------------------
Maree Hegarty	 	maree@uqcspe.cs.uq.oz.au 
Computer Science, University of Queensland, 4072, Australia
Ph: +61 7 377 4270	Fax: +61 7 371 0783
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Nov 90 09:06:22 PST
From:      postel@venera.isi.edu
To:        jk3n+@andrew.cmu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  IP Router-Where to Start?
Hi.

Start with RFC-1009, and also get involved with the "router requirements
working group" of the IETF.

--jon.

	From tcp-ip-RELAY@NIC.DDN.MIL Wed Nov 14 20:53:27 1990
	Date: 14 Nov 90 02:00:52 GMT
	From: jk3n+@andrew.cmu.edu  (John Stephen Kalucki)
	Subject: IP Router-Where to Start?
	Sender: tcp-ip-relay@nic.ddn.mil
	To: tcp-ip@nic.ddn.mil


	I'm thinking about implementing an IP router, but I have no idea where
	to start. I've browsed through the RFC index and a few RFC's themselves
	but there doesn't appear to be anything directly related to routers.

	I'm looking basically for 4 things:
	1) Related RFC's
	2) Books and other text that might help
	3) Public Domain implementations, hopefully source, to test mine with
	4) Advice

	Thanks.

			-John Kalucki
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 90 10:49:11 PST (Thu)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        tcp-ip@nic.ddn.mil
Subject:   Ruby tape from "Oddball Uses of the Internet" at Interop
I used a 5 minute clip from a tape called Ruby 2 during the "Oddball
Uses of the Internet" panel at Interop (this is the one where the main
character, Ruby, stays at a motel of the future full of talking
appliances). After the panel several people asked me where to get the
tapes, and I couldn't answer.

They're published by a company called ZBS Foundation. You can reach
them at
	ZBS Foundation
	RR #1 Box 1201
	Fort Edward, NY 12828
	800-662-3345

They have a catalog of their tapes.

Sorry that I didn't have this info at the show; I hope this reaches
some of the people who wanted to know.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
"Karma means getting caught. The secret to creating karma is getting even
 without getting caught." - Rodant Kapoor in RUBY 3
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 90 05:58:50 GMT
From:      simasd!jadpc!jdeitch@nosc.mil  (Jim Deitch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP between a Sun & SCO
In article <32821@netnews.upenn.edu> kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) writes:
>
> Hi there .. a friend of mine & I have been trying to devise a way for
>him to use SLIP to telnet over to my machine over a V.32 modem. I've
>got the stuff for my Sun (SS1 under SunOS 4.1). What we need to know
>is what it would take on his end (SCO Xenix on a 386) to make this
>happen. Would he have to fork out the $$ to get the TCP/IP
>implementation for SCO? (I'm not a Xenix expert; Suns are my bag.)
> Thanks!
>
>
>Brendan Kehoe | brendan@cs.widener.edu [ It's here, but it won't resolve yet ]
>For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu
>  "The latest polls indicate you're in danger of losing touch with the
>	     common man."   "Oh DEAR ... heaven forfend!"

Not only for the TCP/IP but the Streams stuff as well.


-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.nosc.mil
UUCP:	    nosc!jadpc!jdeitch
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 00:15:19 EST
From:      Russ Nelson <nelson@sun.soe.clarkson.edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   At wits end with Xenix <--> SunOS Noninterop
Can anyone give me some hints as solve my problem with Xenix <--> SunOS
NONinteroperability?  I can always telnet between the two hosts, but when
I try to ftp between them, I get big troubles.  The transfer never gets
more than 100 KB through.  BUT, when I use KA9Q as a midpoint (do
SunOS to KA9Q to Xenix), it works just fine.  So clearly both systems
are capable of transferring tens of megabytes over a single TCP
connection.  They just can't talk to anyone else.

Now, I would look at the packets, but trpt says "tcp_debx=0", and the
manual claims this is an "other message which should be self explanatory."
Ha, programmers are such wags.

The really strange part is that the problems aren't seen when transferring
data *from* the Xenix system, it's when you try to transfer data *to* the
Xenix system.

There, I just went away and pushed 1.5 MB from the Xenix to the SunOS,
and I can't even get 40 KB from the SunOS to the Xenix.  Can someone
please tell me what to look at?  Oh, and please send me mail, as I
normally read this group via news, and news is what's NOT running on
the Xenix system.  All the news junkies at Clarkson are on my back
about it...

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      15 Nov 90 21:30:45 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Macintosh & TCP/IP
In article <11257@goofy.Apple.COM>, veizades@apple.com (John Veizades) writes:
> Comm Toolbox
> 	TCPack - Advanced Software Concepts
> 	Pacer's CommToolbox interface

Gack.  John, you missed our tool here.  :-)  InterCon has a tool as well,
that allows both Telnet negotiation and raw TCP, and is much smaller than
TCPack, I don't know about Pacer's, I haven't seen it.

--
Kurt Baumann                       InterCon Systems Corporation
703.709.9890                      Creators of fine TCP/IP products
703.709.9896 FAX               for the Macintosh.
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 00:56:06 GMT
From:      comp.vuw.ac.nz!badger!mark@uunet.uu.net  (Mark Wright)
To:        tcp-ip@nic.ddn.mil
Subject:   IP address assignment at boot time - for PCs
We have a network of diskless PCs that boot from a server running novell. On
the same ethernet we have a tcp-ip network of unix workstations.

I am currently in the process of installing NCSA telnet over the Clarkson
packet drivers on these PCs.

I want the PCs to get their IP address from a server when they boot. I would
like the addresses to be assigned by the server as they are needed - e.g. a PC
may not always get the same IP address, rather it is allocated from a "pool"
of addresses upon request.

I seem to recall reading of software to do this - can anyone point me in the
right direction?

What are the drawbacks of this approach? We have more PCs then I would like to
configure RARP to handle, so I think it IS preferable. 

If I have to use RARP, can ultrix 3.1 ARP handle RARP requests - I can't find
any reference to it in TFM.

All pointers gratefully received.


-- 

 Mark Wright.                    Dept. of Survey and Land Information,NZ.
 email: mark@dosli.govt.nz       phone: 64 4 710-380 ext 8688
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 17:05:29 PST
From:      prue@venera.isi.edu
To:        guyton@rand.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet/NSFNet proposal to be run by IBM -- call to action!
>Fyi, our Los Nettos bill (T1) is $60k for 1st year, about $30k
>per year after that.  [initial estimates, we've been on for
>a couple years now and I've not gone back to check to see
>how accurate the estimates turned out]

Los Nettos has relatively short T1 lines and has had two favorable T1 line 
tariff changes since Los Nettos initially gave cost estimates.  The real
cost to members is quite a bit less.

Current estimates for membership are about $25k for intial equipment and
telco T1 installation plus about $15k per year for line costs.  This means it 
would cost about $40k for the first year.

Walt Prue
Los Nettos

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 14:34:09 EST
From:      Russ Nelson <nelson@sun.soe.clarkson.edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Diagnosis: Xenix <--> SunOS Noninterop
I said:

   I said:

      Can anyone give me some hints as solve my problem with Xenix <--> SunOS
      NONinteroperability?

   OR to make the window size smaller.  SCO doesn't make that easy,
   but I've got a call in on it, and hopefully they'll deign to tell
   me how I can properly configure my TCP/IP.

Hee hee.  Hackers 1, SCO 0.  I did a 'strings' on SCO's ifconfig
program.  Darned if it doesn't have an undocumented parameter,
onepacket.  "onepacket", "-onepacket" and "ioctl (set one-packet mode
params)".  What the heck, let's try it: "ifconfig 3comA0 onepacket".
Hey!  It works!

Summary: If you're using a 3c501 in your Xenix system, you must put it
in onepacket mode, otherwise you won't be able to talk to Suns.

Thanks to all who offered assistance.
-russ
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 10:43:45 GMT
From:      mcsun!hp4nl!nikhefh!a38@uunet.uu.net  (James Barr)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for Generic Pinger software
Hello,

I wondered if anyone knew of a program that could concurrently
ping multiple hosts or 'ping' using different protocols.  Or
failing this, give me some thoughts on how to construct one.

Thanks,
James Barr
-- 
James Barr                                        ...............       ......
+31 20-592-5104                                   ...........       ..........
James.Barr@nikhef.nl                              ......        ..............
NIKHEF, Kruislaan 409, 1009DB Amsterdam           ..        ..................
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 17:18:37 EST
From:      Pete Hickey <PETEHIC@ACADVM1.UOTTAWA.CA>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Why not use SO_KEEPALIVE?
Why not use keep-alives?

I'm no expert by any means, but in my opinion, it should be the
job of a specific server/application how long they want to wait
for their timeouts.  Some applications may decide that if nothing
came in from the socket for x seconds, they kill/close it.  The
application can decide on the time if and when it wants.  It should
not be the job of the lower levels of the protocol.

-Pete
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 16:44:48 GMT
From:      van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet@ucbvax.Berkeley.EDU  (Peter Whittaker)
To:        tcp-ip@nic.ddn.mil
Subject:   Why not use SO_KEEPALIVE?
Hello, I've been hearing bad things about SO_KEEPALIVE recently, but 
these "bad things" have amounted to nothing more than opinion - no one
has yet been able to give a substantive reason not to use it (with the 
possible exception of "no one uses it, so it has never been debugged, so it's
probably flakey, so don't use it" - a la Catch-22).

So, are there in fact substantive reasons not to use SO_KEEPALIVE?

(This matter arose from an application that uses SO_KEEPALIVE, naturally
enough, with apparent negative impact:  the server application gets killed
(KILL -9) but the TCP socket stays up, connected to the remote client,
with the server side sending ACK packets every now and again, just enough
of them to be annoying.  When we eventually want to restart the server, we
have to reboot or search and destroy all clients, because the address is in
use.  As a fix, we're going to use SO_REUSEADDR as well as SO_KEEPALIVE.
If there are substantive reasons not to use SO_KEEPALIVE, we'll recommend
that it be removed from the software).

Thanks,


--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 15:19:26 +0100
From:      jpk%slig.ucl.ac.be@CUNYVM.CUNY.EDU (J.P. Kuypers)
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Macintosh & TCP/IP
We know to :

Mail Tools
 TechMail - Massachusetts Institute of Technology (MIT Information Systems)
 MacPOP - NASA Ames Research Center
 Eudora - University of Illinois Board of Trustees (Steve Dorner)
 MailStop (an SMTP/POP2 mail-server) - University of Minnesota

J.P. Kuypers
Catholic University of Louvain
UCL - SRI
place des Sciences 4
B - 1348 Louvain la Neuve (Belgium)

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Nov 90 22:44:04 EST
From:      Michael A. Patton <MAP@lcs.mit.edu>
To:        pww@bnr.ca
Cc:        tcp-ip@nic.ddn.mil
Subject:   Warning: Keep-Alive considered harmful
Warning: Keep-Alive considered harmful!!!

   Date: 16 Nov 90 16:44:48 GMT
   From: van-bc!ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet@ucbvax.berkeley.edu  (Peter Whittaker)

(Boy, what a bogus address.  Good thing you put one in your signature.
You may not be able to help the enormous length, but could you try and
get your mail service to put YOU, not your daemon, in the header?)

   So, are there in fact substantive reasons not to use SO_KEEPALIVE?

Yes, indeed there are.  The implementation of keep-alives in the TCP
level is just WRONG.  Although the actual details are (usually) not a
strict violation of the spec, they do stretch it in interesting ways
and I have seen at least one implementation that would sometimes RESET
a connection in response to a keep-alive packet.

If you want the functionality that you think you get automagically by
setting this option, you should really think about the specifics more.
Think about what functionality you really want.  Do you just want it
to free up the socket or kill a server?  Why do you care?  Are you
attacking a symptom rather than the real problem?

Usually, the application needs much better control over how it really
works than just setting an option that causes it to crash if something
goes wrong.  You should think about the many effects that can
influence this (I'll list a few presently) and consider whether you
want these in your application domain.  Beware that you may only
intend to run your application in a limited context, but eventually
someone will try it over a different domain.  Please consider the
different cases before going for options like this.

One thing to consider is that there are links in the world where you
occasionally get only a packet every 5-10 minutes to actually go
through.  Do you want to forbid the use of your service over such a
link?  Just this morning I had a user complaint that they couldn't FTP
a file between two distant hosts.  The problem resolved to a link that
dropped out for several minutes every half hour or so, but the transfer
time for the file they wanted was 45 minutes.  When the link dropped
out, they would get punted because of keep-alives, then they had to
start over.  If only they weren't running keep-alives on the FTP
Server it would have worked, the person doing the transfer had enough
patience, if only the computer had.

Another thing to consider is that in any application with a person in
control, they are usually a better watch-dog timer than any program
you build.  This might suggest building some user-interface feature to
help.  The hash marks in some versions of FTP are one example.  Or you
might build the high-level timeout, but rather than punting the
operation, merely print out a message to the user explaining how they
could do it.

There are a few other general things to watch out for when building
any distributed system, these are a few related to the keep-alive
question.  Never predefine a timeout, it will eventually be too small.
As an example I have an FTP script that had a global timeout on a
transfer that caused it to quit and go on to the next.  I discovered
that for one combination of server and file, FIVE HOURS was not
enough, upping it to 10 got that file transferred (but wreaked havoc
with my other assumptions :-).

Well, there are several more things I could bring up, but I seem to
have rambled on for over a page already so I'll cut it short here.  I
hope this helps to answer your questions and give you some ideas as to
why keep-alive is considered harmful.  Hopefully it will point you in
a useful direction for developing what you really need as well.

            __
  /|  /|  /|  \         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. :-)
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 18:48:09 GMT
From:      ubc-cs!news-server.csri.toronto.edu!utgpu!utzoo!attcan!ncrcan!scocan!larryp@beaver.cs.washington.edu  (Larry Philps)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP Source Code Search
In article <1990Nov8.172640.13894@mdivax1.uucp> mdivax1!robinson (Jim Robinson) writes:
>
>One possible problem is the use of non-int bit fields in the tcp and ip
>header structures. Pre-ANSI C requires only that unsigned int bit fields be
>supported by a compiler and ANSI C requires only (*I believe*) signed or
>unsigned bit fields be supported. Thus, if your compiler does not support,
>say, unsigned char bit fields, which are indeed used in the BSD code, you
>will have to do a bit of work to work around this problem. If you are
>unlucky, as I was, your compiler will *not* complain, but merely generate
>incorrect code.
>
>You will also run into a number of annoying problems if the sizes of ints
>and pointers on your target machine are greater than 32 bits, since there
>are several coding practices employed that assume 32 bit pointers and ints.
>-- 
>Jim Robinson
>{uunet,ubc-cs}!van-bc!mdivax1!robinson

Hi Jim! That was a *fun* project wasn't it!  (The machine did not have a 16
bit data type, and could not do 16 bit arithmetic!)

Originally the compiler only supported int bitfields (8 bytes on that
machine), but the standard IP and TCP header structures are both 20 bytes.
This is not divisble by 8.  Since the machine enforced alignment, it was
impossible to reference both the IP and TCP headers of a packet without
moving things around.  We eventually had to change the compiler to support
short bitfields.

The BSD code also used an incredibly *portable* method of moving 16 bit
quantities around (ie. tcp options) via

	*(u_short *) cp = something.

which unfortunately did not work too well with our 32 bit u_shorts.

---
Larry Philps,	 SCO Canada, Inc (Formerly: HCR Corporation)
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM  or larryp%scocan@uunet.uu.net
UUCP:	 {uunet,utcsri,sco}!scocan!larryp
Phone:	 (416) 922-1937
Fax:	 (416) 922-8397
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 21:39:35 GMT
From:      mcsun!unido!ira.uka.de!rusux1!rusux1.rus.uni-stuttgart.de@uunet.uu.net  (Kurt Jaeger aka PI)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA-Telnet 2.3b7, IBM TR Cards & Mod.50's, Mod.80 as router ?
Hi !

Here comes a problem I don't know any cheap (in terms of money)
answer for:

The PC-pool of our math. dep. consists of a few (20?) Mod.50 PS/2
with IBM Token Ring cards and a file server Mod.80. The server
is connected to the Mod.50's with TR and with a ethernet card
to the campus LAN.

We want to provide all of the Mod.50's with IP-connectivity,
to connect to the rest of the LAN. Preferably we want to use
NCSA-Telnet (v2.3b7 aval.).

As far as I see, ncsa-telnet can make use of TR-cards.
So we would need some sort of router-sw for our Mod.80 ?
Where can we get some ? Should we use AIX for that purpose ?

The Mod.80 is a file server with some IBM-sw (dont know it
personally ;). Will it work in combination with IP ?
What about using PC-NFS afterwards/instead ?h

In case someone just knows a bit about it, please reply via
mail. I'll summarize if there's enough interest.
Comments like "forget it", "will never work" etc are
highly welcome, because it will give me some hint, too !

      aTdHvAaNnKcSe, PI
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      16 Nov 90 22:13:18 GMT
From:      thorin!tigger!bmh@mcnc.org  (Brad Hemminger)
To:        tcp-ip@nic.ddn.mil
Subject:   help with tcp/ip over high speed network...

We will be participating in a project that will require running some already
devleoped X Window System applications over a prototype high speed network.  It
appears that a good route for us is to get tcp/ip running over this network,
so that X and other network stuff falls out for free (?).
  What I'm looking for is information on what is required in order to get
tcp/ip running over an arbitrary network.  I.e. is the source public domain
and what parts would need changing?  Are their commercial companies
specialize in this?
  An alternative might be to just port X to run an alternative protocol. Any
suggestions on what protocol or how much work this would be?

  This would run on a sun sparc server type machine.


Thanks,
  Brad Hemminger
  bmh@rad.unc.edu
  Dept of Radiology
  (919) 966-2998
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 90 00:11:39 GMT
From:      envy!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why not use SO_KEEPALIVE?
In article <1990Nov16.164448.9918@bwdls61.bnr.ca>, pww@bwdls55.bnr.ca
(Peter Whittaker) writes:
|> So, are there in fact substantive reasons not to use SO_KEEPALIVE?

Yes.

|> the server application gets killed
|> (KILL -9) but the TCP socket stays up, connected to the remote
client,
|> with the server side sending ACK packets every now and again, just
enough
|> of them to be annoying.

This doesn't make sense. Under BSD UNIX, at least, when you kill a
process you automatically close its file descriptors and sockets. So
if an application has a TCP connection open, it will be closed.

The idea behind SO_KEEPALIVE is to "send ACK packets every now and
then".  (Actually, it sends one-byte data packets that are just before
the window, eliciting ACKs to indicate that the receiver is still
there.) The thinking is that you want to detect when the REMOTE end
has silently died.

But there are some big problems with TCP keepalives:

1. They can generate a lot of unnecessary network traffic. It is
perfectly legit for an application to hold open a TCP connection for
weeks or months without sending any traffic, since TCP connections
normally occupy no resources other than 100 bytes or so of RAM in each
end host.  But if you have them send pings to each other every 30
seconds, then your idle connections can cost you a bundle - especially
if your path includes an X.25 network that charges you by the packet.

2. They reduce robustness by closing connections unnecessarily when
there is a temporary network outage, since network outages are usually
indistinguishable from remote host failures. And if the TCP connection
is idle (which is the only time you be sending keepalives anyway) why
should you care if the network goes down momentarily during that time?
All that matters is that it be there when your application has some
real data to send, but by gratuitously closing the connection for him
you've made life for the application designer that much more
difficult. If the *application* wants to give up after some interval,
then *it* should make that decision, not TCP.

3. How do you set the keepalive interval? Remember that your TCP and
application will have to work over arbitrary Internet paths. Who's to
say that 30 seconds (or 1 minute or 1 hour) is a reasonable interval
between keepalives? What's reasonable today might be very unreasonable
tomorrow.

Phil
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 90 16:45:22 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!sigyn.idt.unit.no!ugle.unit.no!spurv.runit.sintef.no!he@ucsd.edu  (Havard Eidnes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Warning: Keep-Alive considered harmful
I agree that using TCP keepalives is a bad idea.  I just want to comment on
the specific example Michael A. Patton mentioned, making me able "with
Internet Hosts Requirements in hand" to point out one other area where
traditional implementations of TCP should be changed to improve robustness
in the case of temporary network failures.

In article <9011170344.AA20268@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>
>Just this morning I had a user complaint that they couldn't FTP
>a file between two distant hosts.  The problem resolved to a link that
>dropped out for several minutes every half hour or so, but the transfer
>time for the file they wanted was 45 minutes.  When the link dropped
>out, they would get punted because of keep-alives, then they had to
>start over.  If only they weren't running keep-alives on the FTP
>Server it would have worked, the person doing the transfer had enough
>patience, if only the computer had.

It is of course possible that this connection was blown away by the server
using TCP keepalives. However, one other possibility (perhaps more likely)
is that an intermediate gateway issued ICMP net unreachable messages while
the temporary network outage lasted.  Traditional implementations (including
the original BSD 4.3 version) of TCP blow away a live TCP connection when
they receive an ICMP net unreachable message. The Host Requirements state
that a host implementation of TCP MUST NOT do this (specifically: the ICMPs
net unreachable, host unreachable or source route failed should be
considered temporary failures and not permanent conditions). Some gateways
have the ability to turn off the sending of ICMP net unreachables, but this
is just a workaround for "broken" host implementations.

- Havard
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 90 20:01:24 GMT
From:      usc!phad.hsc.usc.edu!mcitron@ucsd.edu  (Mark Citron)
To:        tcp-ip@nic.ddn.mil
Subject:   3270 emulation for SCO tcp/ip

I posted this a while ago and got no responses but many requests for
any info I might receive so I am posting again.

Is there an IBM 3270 front end emulator for SCO tcp/ip for Unix?
We want to do a 3270 emulation with telnet.

Thanks for any help,
Mark Citron
mark@neurosci.usc.edi
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      17 Nov 90 21:46:49 GMT
From:      templon@copper.ucs.indiana.edu (jeffrey templon)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   WANTED: SLIP/Ethernet conversion help


Hello,

I have the problem of trying to use SLIP in an 'unsupported' environment.
The specific SLIP speaker is an AT&T 3b1 running the ka9q package, and
the network to which I'd like to connect is an ethernet full of machines
running various flavors of tcp/ip.  Purchasing some sort of bridge is not
an option unless it is VERY inexpensive.  Someone suggested that there
might be some way to have a program running on one of the ethernet-connected
computers which captured the incoming SLIP stuff from the serial (terminal)
line and spewed it out onto the ethernet.

It seems someone must have done this before or something similar.  Any
help or suggestions?  I don't have the time to write the program myself
(nor, probably the expertise.)  The machines which would be available to
host such a thing would be either VMS machines or unix machines.

Please reply to  templon@copper.ucs.indiana.edu
People wanting a summary are also welcome to reply.

					Jeff

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 09:40:05 GMT
From:      eru!hagbard!sunic!news.funet.fi!funic!santra!ngs!news@bloom-beacon.mit.edu  (Pekka Nikander)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP - SNA gateways -- information wanted

[This is a resending.  Apparently the earlier attempts to send this
did not reach the world.  If you see this TWICE, let me know.]

I am trying to put up an intelligent TCP/IP -- SNA gateway.
Preferably the gateway should support 
  TCP/IP + TN3270 --> LU2.0 + 3270      and
  TCP/IP + our own protocol --> LU6.2 + another own protocol
conversions.

I think the best solution would be an Unix machine with both TCP/IP
and SNA.  So, I am looking for information about any ready solutions
or about SNA software for IBM RS/6000, Sun, DecStation etc.  If you
have done something like this, PLEASE LET ME KNOW.

As usual, mail to me and I'll post a summary if enough interest.

--
Pekka Nikander                              Internet: pnr@ngs.fi -tai-
Finnish Unix systems User Group (FUUG)                Pekka.Nikander@ngs.fi
Helsinki Unixversity of Technology   
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Nov 90 22:17:13 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NCSA-Telnet 2.3b7, IBM TR Cards & Mod.50's, Mod.80 as router ?
The 'from' address was incredibly bogus (no username), so I'm posting...

If you want to use NCSA, you have to get the Clarkson Packet Driver collection
and use the "ibmtoken" driver.  This simulates Ethernet on 802.5, translating
the headers for NCSA.  It works for a while, but on the 17th different host
you try to connect to its "RIF caching" logic will come into conflict with
NCSA's ARP code and you won't be able to get through...

FTP Software, IBM, Wollongong and Beame & Whiteside all offer commercial
DOS TCP/IPs for 802.5.  All can use drivers that conform to IBM's "ASI"
spec (TOKREUI or the LAN Support Program), PC/TCP at least can use 802.5 NDIS
drivers as well.  Because the ASI or NDIS driver allows interface sharing,
you ought to be able to use TCP/IP concurrently with mounting remote volumes
on your server.

You will need a router of some sort.  Proteon, cisco and Wellfleet all offer
high-performace routers with 802.5 interfaces.  IBM and TWG will sell you
low-performance PC-based routers.  A Banyan VINES server can act as a router
between Ether and 802.5.  You can use a PC/RT (at least if it runs the
"academic 4.3" Unix).  If AIX supports routing, you could put that on
a PS/2 with two interfaces as well.  I don't know offhand if "PCRoute" can
hack 802.5, or if it is too simple to handle RIFs (for bridged rings).  I
don't believe KA9Q does 802.5.  Unless AIX can also act as a fileserver,
you will need to put it on another machine...
    
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Nov 90 22:17:31 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mcsun!hp4nl!nikhefh!a38@uunet.uu.net  (James Barr)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for Generic Pinger software
Jerry Saltzer at MIT was the first person do do something of this sort;
his used the MIT PCIP software as the lower layers, but I don't know if it
is included in any of the distributions.  We sell one (part of our "SNMP
Toolkit" offering for DOS PCs), you could write your own on our API.
Whether you'd be able to do it on any given OS depends on its offering an
adequate programmatic interface to ICMP; 4bsd unix lets you at the ICMP,
but I don't know if it can handle multiple simultaneous requests...

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

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 23:20:52 PST (Sun)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        jbvb@ftp.com
Cc:        mcsun!hp4nl!nikhefh!a38@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Request for Generic Pinger software
   Date: Sun, 18 Nov 90 22:17:31 -0500
   From: jbvb@ftp.com  (James B. Van Bokkelen)

   Jerry Saltzer at MIT was the first person do do something of this sort;
   his used the MIT PCIP software as the lower layers, but I don't know if it
   is included in any of the distributions.

It's the 'monitor' program in the last MIT release of PC/IP; it's in
all the later collections.
		- john romkey			Epilogue Technology
USENET/UUCP/Internet:  romkey@asylum.sf.ca.us	FAX: 415 594-1141
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 16:16:16 GMT
From:      mcsun!ukc!mucs!logitek!martino@uunet.uu.net  (Martin O'Nions)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SMB/NETBIOS/RFC1001/RFC1002 server product
xxseub@osprey (Steven Eubanks) writes:


>	I am interested in examining NETBIOS/SMB servers for both *NIX
>and VMS-based platforms.  I'm aware of one company call Syntax Systems
>having a product in this area.  Are there others?  Company names and phone
>numbers would be appreciated as well as any experiences with this type of
>product (good and/or bad).


>Thanks in advance!

>Steve

Hewlett Packard now, SCO for Q1 '91 (they tell me), and a number of others
for the near future have all committed to providing LM/X, running SMB/NB/TCP.

We have tried the existing SCO client in-house, talking to a 3Com 3+ Open
Lan Manager server over IP, and it seemed to work O.K......

On a general point, the number of PC LANS based around Lan Manager and
the Server Message Block scheme seems to vindicate the technique - the
testing time will be with the general availability of LM/X.

(No, this does not represent an official statement on behalf of and Logitek
Group company - I am to blame if anyone disagrees.)

--
+------------------------------------------------+-----------------------+
| I've got a little black book with my poems in, |     Martin O'Nions    |
| I've got a bag with a toothbrush and a comb in,| Logitek Group Support |
| When I'm a good dog they sometimes throw me a  | martino@logitek.co.uk |
| bone in           (Roger Waters - The Wall)    |      0257 426 644     |
+------------------------------------------------+-----------------------+
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 16:27:31 GMT
From:      bsu-cs!sam@iuvax.cs.indiana.edu  (B. Sam Blanchard)
To:        tcp-ip@nic.ddn.mil
Subject:   Request: SLIP on a Sequent S27 (info on SLIP in general)
I would like to implement SLIP on a Sequent S27 running Dynix.
Dynix is 4.2bsd with many 4.3bsd enhancements. (yes, Dynix is much more)

Sequent Support told me that kernel support was required and Sequent did not
support SLIP.  I do not have source.

I was told that adding 'options SLIP' might work.  There appears to be an
unsupported SLIP in Sequent's Dynix.  Can anyone refer me to documentation
on SLIP that would assist in using SLIP.  I have "no idea" how to try SLIP out
to see if anything works.
-- 
B. Sam Blanchard	UUCP:  <backbones>!{iuvax,pur-ee}!bsu-cs!sam
                    	ARPA:  sam@bsu-cs.bsu.edu
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 21:32:37 GMT
From:      rti!dg-rtp!bigben!bigben!philip@mcnc.org  (Philip Gladstone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Death on ICMP unreachable also harmful
Havard Eidnes writes:
> The Host Requirements state
> that a host implementation of TCP MUST NOT do this (specifically: the ICMPs
> net unreachable, host unreachable or source route failed should be
> considered temporary failures and not permanent conditions). Some gateways
> have the ability to turn off the sending of ICMP net unreachables, but this
> is just a workaround for "broken" host implementations.

I have found that most implementations of TCP/IP do not return
net/host unreachable messages even when they know that the path to the
net/host is not available. Is this due to the existence of the
'broken' implementations as mentioned above?

For example, on a lan which uses ARP, the host 'knows' that the remote
machine is not present when the ARP request times out. At this point,
it tends to drop the datagram. 

I would prefer to get back 'net unreachable' messages rather than the
ubiquitous 'timeout' message.

--
Philip Gladstone      
Development Lab Europe 
Data General, Cambridge
England.  +44 223-67600
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      18 Nov 90 21:59:10 GMT
From:      mcsun!ukc!slxsys!ibmpcug!robobar!ronald@uunet.uu.net  (Ronald S H Khoo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request: SLIP on a Sequent S27 (info on SLIP in general)
In article <12073@bsu-cs.bsu.edu> sam@bsu-cs.bsu.edu (B. Sam Blanchard) writes:

> I would like to implement SLIP on a Sequent S27 running Dynix.

> Sequent Support told me that kernel support was required and Sequent did not
> support SLIP.  I do not have source.

If you have a spare dusty PC XT or so and can fork out the $$ for a Western
Digital  ethernet card (or have a PC ethernet card supported by a packet
driver -- there are lots, but native support for the WD card will give you
better performance) you can do this with the aid of PC route 2.1
or any other router that supports SLIP:


	+-------------+  ethernet  +---------+  RS-232
	| sequent     +------------+ router  +----------> SLIP!
	+-------------+		   +---------+

The PC software is FREE by FTP from accuvax.nwu.edu under pub/pcroute.

This way, you will save your sequent from being hammered by the SLIP link
too.
-- 
ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Nov 90 7:59:01 CST
From:      "Capt E. Lee Hutchins" <hutch@ssmct62.ssc.af.mil>
To:        tcp-ip@nic.ddn.mil
Subject:   SCO TCP/IP and E-Mail Problems
Greetings!

I am running SCO Unix on a UNISYS PW2/800 otherwise known as the DoD Desktop
III computer.  I am having *LOTS* of problems configuring the mail system
so that it interacts properly with the other mail systems in use at my location.

	First of all, SCO states in its documentation, that it provides sendmail
but it does NOT support it. - I can see why, the "sendmail.cf" file has bugs in
it which prohibit receipt of mail by users from remote machines.  Any ideas on
this would be of lots of use because the alternative is "MMDF".

	MMDF is the supported mail system for SCO UNIX.  MMDF does not come 
with an ideal set of documentation.  (At least I
can't make heads or tails out of it).  If any one has some ideas on Docs for 
this system which are NOT in troff form I'd appreciate them.  Configuring MMDF
without real documentation is a real *&^%$!

	I can recieve mail from other UNIX platforms, but we have another 
mail system running which is based on 10NET, called "COURIER MAIL".  It has 
an "SMTP" gateway working and other UNIX boxes (AT&T 3B2 600G's) can 
receive and send mail fine.  My box on the other hand, does
not work with it.  The mail ends up in a queue on the "COURIER SERVER" and is 
never returned to me or the originator.  Anybody ever experienced this????  

	By the way my machine does not always accept:

	telnet machinename.domain 25

When tried manually from other hosts it often closes the connection before it
askes for the identification.  In fact it seems the more mail sent to my 
machine, the less I actually receive.  I am on *several* mailing lists and I
expected my mail volume to be much higher than it is.

	Finally, one other tidbit, I am running the latest version of "ELM" as
my front end to mail.

	If you could send responses directly to me I'd appreciate it.  I will
be more than happy to post a summary later on.


	thanx - in advance

	E. Lee Hutchins
	e-mail: hutch@ssmct62.ssc.af.mil
	mule train: SSC/SSMCT Bld 325
		    % Capt Hutchins
		    Gunter AFB, AL 36114
		    (205) 279-4555 
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Nov 90 09:40:15 EST
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        barmar@think.com, tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: Warning: Keep-Alive considered harmful
In article <1990Nov19.063111.21768@Think.COM> you write:
>Unfortunately, keep-alives are sometimes needed to work around deficiencies
>in application protocols.  For instance, there's no way for a server telnet
>to detect when the client host has crashed (it could send an IAC
>Are-You-There, but there's no standard for the response, so it would
>confuse the process receiving the input).

The server telnet could periodically send TELNET NOP commands (IAC NOP) to 
the client.  This should not cause any response to be generated, but will
poke the TCP re-transmission machinary to make sure that the connection is
intact.

louie
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 06:22:58 GMT
From:      ogicse!milton!mrc%Tomobiki-Cho.CAC.Washington.EDU@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   new IMAP distribution available


A new release of the IMAP2 multi-platform distributed e-mail system is
now available via anonymous FTP from FTPHOST.CAC.WASHINGTON.EDU (IP
address 128.95.112.1) as imap/imap.tar.Z.

Inside the imap.tar.Z distribution are three new servers, all of which
run under inetd.  These are: a complete rewrite of the IMAP2 server, a
POP2 server, and a POP3 server.  Additionally, the POP2/POP3 servers
are also IMAP clients, providing a POP->IMAP gateway to allow you to
leverage on your existing POP-based PC clients yet still use IMAPware.

Client programs include the NeXT MailManager and EasyMail programs,
the Macintosh MacMS program, and the Unix MS program.  We hope to have
a version of the Unix Pine program available for distribution in the
NeXT release.  A PC client (Pine or other) is planned for the 2nd
quarter of 1991 (= my boss has told me "enough waiting for someone
else to do it, *you* do it").

Both clients and servers use the same c-client library for mailbox
access, supporting local mailboxes in /usr/spool/mail and mail.txt
format as well as remote IMAP mailboxes in a transparent fashion.
Among other things, this ensures complete compatibility and
interoperability between POP, IMAP, and local mailbox access in this
release.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105  "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud         "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
  /|\    | |/\| _______  /  \ MRC@CAC.Washington.EDU  "Iie, boku ha nihonjin."
 / | \   | |__|  /   \  /    \ Lumchan ga suki ja!!   "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 06:31:11 GMT
From:      think.com!barmar@CS.YALE.EDU  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Warning: Keep-Alive considered harmful
Unfortunately, keep-alives are sometimes needed to work around deficiencies
in application protocols.  For instance, there's no way for a server telnet
to detect when the client host has crashed (it could send an IAC
Are-You-There, but there's no standard for the response, so it would
confuse the process receiving the input).

However, I think the common design of keep-alives is incorrect.  The
connection shouldn't be killed as a result of keep-alive timeouts.
Instead, the purpose of keep-alives should be to elicit RSTs from the other
host.  Timeouts can be due to any number of reasons, but a RST indicates
unambiguously that the connection is unusable, because the other end
rebooted or closed the connection itself (perhaps network problems
prevented the FIN from getting through).  If a host crashes, the keepalive
won't actually notice this until it comes back up, which is probably good
enough.

Yes, this will not catch all half-open connections.  If the host dies for
good, or crashes and is given a new address, the other hosts won't
automatically kill their connections to it.  But it's better to leave some
useless connections open than to close some useful connections.  Pinging
for RSTs is fail-safe.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Nov 90 16:33:59 PST
From:      braden@venera.isi.edu
To:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Cc:        iab@venera.isi.edu, iesg@venera.isi.edu
Subject:   IAB meeting minutes available

Minutes of the October 1990 IAB meeting are now available for anonymous
FTP from host venera.isi.edu with the pathname:

   pub/IABmins.oct90.txt
   

Bob Braden

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Nov 90 14:35 CST
From:      Armando Mac Beath <MACBEATH@UDLAPVMS.PUE.UDLAP.MX>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Request for Generic Pinger software
Date sent:  19-NOV-1990 14:33:20 
>
> 
>For VAX/VMS, there is NPRV -- IP Node/Protocol Reachability Verifier.  NPRV is a
>full-screen, keypad-oriented utility that runs under VAX/VMS.  It allows the
>user to quickly scan through a user-defined list of IP addresses (or domain
>names) and verify a node's reachability.  The node's reachability is determined
>by performing an ICMP echo, UDP echo and a TCP echo at alternating three second
>intervals.
> 
>NPRV runs under VAX/VMS V5.1+ and TGV Incorporated's MultiNet version 2.0.
>It can use any network interface supported by TGV Incorporated's MultiNet
>software.
> 
>NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV
>(128.55.128.30).  The distribution includes the following files:
> 
>               [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC     (ASCII text)
>               [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE     (binary)
>               [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA   (ASCII text)
> 
>Hope this helps.
> 
>Bob Stine

Bob, 
 This host have a anonymous disallowed :(
 Do you know how can get this package in another host or can you send me all
files !!!!!!!!


                                           Armando Mac Beath
                                            macbeath@udlapvms
                                            macbeath@udlapvms.pue.udlap.mx

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 11:02:08 GMT
From:      att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!solo!vaxb.acs.unt.edu!billy@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Internet library guide - additions requested
Hi,

I edit an Internet/THENET library guide (UNT's Accessing On-line Bibliographic
Databases).  I am working on the next version.  I would like anyone who is
aware of how to access a card catalog system over the Internet (that is not
listed below) to please send me mail directly with instructions on accessing
that system.  I will post a message to this newsgroup when I finish the update
explaining how to get a copy of the new  version.

The current version (July 90) is available via anonymus FTP on
VAXB.ACS.UNT.EDU.  The file name is LIBRARIES.TXT.  Numeric IP addresses are
list in LIBRARIES.ADR.

The libraries I currently have instructions for are:

Auburn, Auraria University, Boston Univ., Boulder Public Library, Brown,  Cal
Poly State, California State Univ, Case Western, CARL, Clemson, CMU, Colorado
School of the Mines, Columbia, Cornell, CWRU, Dartmouth, Deakin Univ., Denver
Pulbic Library, Denver University, Emory, Florida A&M, Florida Atlantic,
Florida State, Florida International, Harvard Univ, Indiana Univ., Kent State,
Lehigh, Luther College, MARMOT library (Colorado Western Slopes), Monterrey,
Mich State, Montegomery County (Rockville, MD), New Mexico St., New York Univ,
Northeastern, Northwestern, Ohio State, Penn State, Pikes Peak Library,
Princeton, Purdue, RPI, Rice, Rutgers, Sam Houston State University, SUNY
-Binghamton, Texas A&M, TWU, Univ of Cal, UC Berkeley, U of Central Florida, U
of Chicago., U of Colorado at Boulder, U of Delaware, U of Florida, U of Hawaii
at Honolulu, U of Hawaii at Manoa, U of Ill. Champaign/Urbana, U of Ill/Chic, U
of Kansas, U of Maine, U of Maryland, U of Michigan, U of Minnesota, U of
Missouri, U of Nebraska, UNLV,  U of New Mex., U of North Florida, U of North
Texas, U of Northern Colorado, Notre Dame, U of Oregon, U of Penn, U of Pitt, U
of South Florida, U of Tenn, U Tenn Memphis, U of UT Arlington, UT Austin, UT
Dallas, UT Health Science Center at San Antonio, UT Health Center at Tyler, U
of Toledo, U of Utah, U of Wash., U of West Florida, U of Wisconsin, U of
Wyoming, Vanderbilt, Victoria U Wel, Virginia Commonwealth, Virginia Tech, Wash
U at SL, Wayne State.

Also, I have instructions that I can not get to work for John Hopkins, UNC, 
Duke, NC State, Australian National University, and University of Konstanz.

Finally, if anyone knows the nodename (not numeric address) of the Virginia
Tech library (128.173.5.4), please let me know.

Thanks,

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX/Unix Systems Manager      THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Nov 90 15:02 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        James Barr <mcsun!hp4nl!nikhefh!a38@uunet.uu.net>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: Request for Generic Pinger software
>I wondered if anyone knew of a program that could concurrently
>ping multiple hosts or 'ping' using different protocols.

A cursory skim thru RFC 1147 shows 4 tools that might meet your requirements:

  1. Internet Rover,
  2. Map,
  3. netmon, and
  4. NPRV

Quoting liberally from the RFC....

Internet Rover is a prototype network monitor that uses multiple protocol
"modules" to test network functionality... Modules are included to test TELNET,
FTP, and SMTP.

The Internet Rover is known to run on Suns and IBM RTs.  It requires curses,
4.xBSD UNIX socket programming libraries, and BSD ping.

Full source for Internet Rover is available via anonymous FTP from  merit.edu
(35.1.1.42) in the ~ftp/pub/inetrover directory.  Source and executables are
public  domain  and  can  be freely  distributed for non-commercial use.
         
Map -- the Interactive Network Map -- draws a map of network connectivity and
allows interactive examination of information about various components including
whether hosts can be reached over the network.  Net components are pinged by use
of ICMP echo and, optionally, CHAOS status requests and SNMP "gets."

Map requires an X display for interactive display of the map, although
non-graphical interaction is available in non-display mode.  For hardcopy output
a PostScript or Tektronix 4692 printer is required.

Map runs under BSD UNIX or related OS.  IP/ICMP is required; CHAOS/STATUS and
SNMP can be used but are optional.  X-Windows is required for interactive
display of the map.

To obtain individual files or instructions on getting the full current release,
send a request to:

    MAP-Request@LCS.MIT.Edu.
               
Netmon is a DOS-based program that pings hosts on a monitored list at
user-specified intervals.  In addition, a user may optionally ping hosts not on
the list.  Netmon also performs domain lookups.  Furthermore, a user may build
and send a domain query to any desired DNS server.
Netmon requires the DOS operating system, and the PC/TCP Kernel by FTP Software,
Inc.

The BYU modified version is available for anonymous FTP from Dcsprod.byu.edu, in
directory "programs."  It can be freely distributed for non-commercial use.

For VAX/VMS, there is NPRV -- IP Node/Protocol Reachability Verifier.  NPRV is a
full-screen, keypad-oriented utility that runs under VAX/VMS.  It allows the
user to quickly scan through a user-defined list of IP addresses (or domain
names) and verify a node's reachability.  The node's reachability is determined
by performing an ICMP echo, UDP echo and a TCP echo at alternating three second
intervals.
               
NPRV runs under VAX/VMS V5.1+ and TGV Incorporated's MultiNet version 2.0.
It can use any network interface supported by TGV Incorporated's MultiNet
software.
 
NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV
(128.55.128.30).  The distribution includes the following files:

               [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC     (ASCII text)
               [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE     (binary)
               [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA   (ASCII text)

Hope this helps.

Bob Stine



-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 15:45:21 GMT
From:      mcsun!ukc!icdoc!syma!nickw@uunet.uu.net  (Nick Watkins)
To:        tcp-ip@nic.ddn.mil
Subject:   tftp needed for HP9000/835
We have an X terminal which needs to use trivial ftp to download the X binary
from an HP9000/835. tftp is not included in the TCP-IP software suite
provided with HP-UX (LAN 9000), has anybody got a suitable (source or
binary) version of tftp that we could have ?

Email to me, please.

Thanks,

Nick
-- 
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 16:22:45 GMT
From:      pasteur!dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucbvax.Berkeley.EDU  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Warning: Keep-Alive considered harmful
In article <1990Nov19.063111.21768@Think.COM> barmar@think.com (Barry Margolin) writes:
>Unfortunately, keep-alives are sometimes needed to work around deficiencies
>in application protocols.  For instance, there's no way for a server telnet
>to detect when the client host has crashed ...

I think this is a confusion of mechanism with policy.  A server telnet needs
a way to tell the TCP layer "ping the other end".  That is not the same as
having a wired-in policy that the TCP layer will ping the other end regularly
and break the connection if there is no response.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 20:01:53 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!polygen!rbraun@ucsd.edu  (Richard Braun)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
grr@cbmvax.commodore.com (George Robbins) writes:
>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
>> We're interested in encapsulating DECnet within a TCP-IP package.  We
>> are looking primarily for a software solution...
>
>I believe TGV multinet can handle this...

MultiNet is, IMHO, far and away the best TCP/IP package available for
VAX/VMS.  (This after reviewing products ranging from Process Software
to Fusion to Wollongong to...)  It's a Stanford-bred product written
in C with some TOPS-20'isms in it.

But I fail to understand the original question:  "encapsulating DECnet
within TCP/IP".  That just doesn't mean anything.  It could mean
buying a binary license to DECnet and one to TCP/IP and writing an
application which calls both.  Or it could mean buying a MultiNet
source license for $megabucks plus a TCI "CommUnity" DECnet source
license for $megabucks and integrating the two.  Or it could mean
going to DEC or Equinox or some other company and buying a LAT/TCP
terminal server to hook onto your Ethernet.  As you can see, you
can come up with solutions that cost anywhere from $3,000 to
$3,000,000.

What's the need, anyway?  And was it on VMS-only or does it have to be
platform-independent?

-rich
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      19 Nov 90 23:07:00 GMT
From:      rti!mozart!MVS.SAS.COM!SNODDI@mcnc.org  (Dale Ingold)
To:        tcp-ip@nic.ddn.mil
Subject:   Desperately Seeking MVS Netnews Reader
We are looking for any information on a news reader for MVS,
preferably(?) using NNTP across a TCP/IP link via IBM's TCP/IP product
for MVS.

------------------------------------------------------------------------
Dale Ingold                         Internet: snoddi@mvs.sas.com
SAS Institute Inc.                  Phone:    919-677-8000 x7603
SAS Campus Drive
Cary, NC  27513-2414
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 00:19:52 GMT
From:      rochester!rocksanne!sma@louie.udel.edu  (Susie Armstrong)
To:        tcp-ip@nic.ddn.mil
Subject:   NFS over TCP?
Hi,

A while back I posted (in the nfs group) looking for a user-space
public domain implementation for NFS, and received some good replies,
along with a suggestion that I be more specific about my reasons for
wanting such a beast.

What I'm really looking for is an NFS implementation over TCP
instead of UDP.  I'm aware of the BSD 4.3 Reno implementation -
unfortunately, I really need something to run on a Sun 4.

Any additional suggestions?

Cheers,
    Susie Armstrong
    Xerox Webster Research Center
    armstrong.wbst128@xerox.com
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 02:25:00 GMT
From:      rwmira01@ULKYVX.BITNET (NEWS_PERSONALNAME)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Looking for Info on TCP/IP packages (Novice here!)

I have some (what I hope are) simple questions about TCP/IP products.  But
before I get to that, here is my background and what I am attempting:

I know what telnet and ftp do and I know how to basically use them.  I know how
to manage a Unix file server for StarLAN (and can program in 'C') but I have
little expertise on the low-level networking.

We are using AT&T StarGROUP 3.2 on a Unix file server (intel 386) with AT&T
Unix Sys V R 3.2.2.  I have a StarServer E with Sys V R4 on order.  When we are
done, we will be on a 10BASE-T network with other Unix boxes, as well as our
VAX/VMS.  Within the next 6 months we hope to become a real internet site and
put our IBM Mainframe on Internet was well.

Now for my question(s).

I am looking for a Cheap (read free/public domain where applicable)
implementation of both TCP/IP and NFS.  My goals are:

1) Allow the StarGROUP PC Client to TELNET/FTP to our Unix File Server
2) Allow the StarGROUP PC Client to TELNET/FTP to any other TCP/IP host that
   I can reach.
3) Allow Macintosh's on the network to access the Unix file server as their
   file server (Apple tells me as long as NFS is on the Unix box their happy).
4) Allow the Unix server to be a TCP/IP host for the world
5) Multiple session via Windows 3.0
6) Possible Netnews at the PC desktop (low priority)
7) Mail at the desktop (if possible)

Over the weekend I acquired the binaries to NCSA/Telnet and I was able to FTP
between a couple of PCs today.  I couldn't get it to work with the Packet
Driver (AT&T.COM) for our network cards, but the Netbios version worked with
StarGROUP loaded but I got some weird data on the screen, but the files seemed
to transfer well.

What do I need to get TCP/IP on my unix box, preferably public domain?
Any advice in pulling this off would be of great help.

Please respond by E-Mail, although I will subscribe to these groups for the
next couple of weeks.

Thanks in advance
Rob Miracle
LAN consultant
University of Louisville
"Kill Wesley! Kill Wesley!"  -- Irate Star Trek:TNG Fans

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 03:16:19 GMT
From:      uhccux!munnari.oz.au!metro!solar.card.inpu.oz.au!brett@ames.arc.nasa.gov  (Brett Sealey)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SLIP driver for HP-UX 9000/360

The box is a HP-UX 9000 series 360, version 7

Any information about such a beast (When, where, how ...) would be much
appreciated.

Thanks,
	Brett.
______________________________________________________________________________
  __   __   ___ ____ ____
 /__) /__) /_    /    /				brett@solar.card.inpu.oz.au
/__) / \  /__   /    /					       Brett Sealey
______________________________________________________________________________
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Nov 90 8:28:30 EST
From:      Charles Lynn <clynn@BBN.COM>
To:        Barry Margolin <think.com!barmar@cs.yale.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Warning: Keep-Alive considered harmful
The old TOPS-20 TCP/IP used the RST method of probing for half-open
connections, by sending an unacceptable "SYN-ACK".
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 12:20:34 GMT
From:      templon@iuvax.cs.indiana.edu  (jeffrey templon)
To:        tcp-ip@nic.ddn.mil
Subject:   SUMMARY: SLIP/Ethernet conversion help

Hi net.folk:

	Here is a summary of what I found out.  I am posting since several
people asked for the summary.  Thanks to all who responded.

					Jeff

From <@ugw.utcs.utoronto.ca:kieffer@uncanet> Sun Nov 18 02:37:27 1990
From: kieffer%uncanet.bitnet@ugw.utcs.utoronto.ca (Rom Kieffer, TransCanada PipeLines)
Subject: slip routing

> Someone suggested that there
> might be some way to have a program running on one of the ethernet-connected
> computers which captured the incoming SLIP stuff from the serial (terminal)
> line and spewed it out onto the ethernet.
>


if you can dig up an old PC, then you can build your own bridge with PCRoute.
Its is a pd package that can route between SLIP and TCP/IP ethernets.
I cannot remember where it is housed for ftp, but a query to the ip community
would be propbably get you an address.
 rom


From vthrc%uqvax.cc.uq.oz.au@brolga.cc.uq.oz.au Sat Nov 17 22:19:01 1990
From: Danny Thomas <vthrc@uqvax.cc.uq.oz.au>
Subject: Re: WANTED: SLIP/Ethernet conversion help
Organization: VTHRC, University of Queensland


I think you could use Vance Morrison's PC-ROUTE or PC_BRIDGE from 
acns.nwu.edu, running on a PC with an ethernet card.
"What about SLIP Speeds?
PCRoute also supports up to 2 serial lines in addition to the other 
interfaces. These lines can operate at all the common baud rates up to 
19.2K. In PCRoute with a faster processor (10MHz XT or AT clone) can 
handle 38.4K or even 57.6K. Akll of this using the standard 8250 serial 
ports"
You'll need a copy of Borland's Turbo Assembler to compile the source 
after you specified the configuration, but I was very happy with the ease 
of installation (network novice speaking). Ours is used to link two (Mac) 
LocalTalk nets onto the university ethernet. It only handles TCP/IP but 
I've been very happy with it, but there may better solutions to you 
problem, I don't know.


From calford%psych.psy.uq.oz.au@vthrcmac.vthrc.uq.oz.au Sun Nov 18 15:55:44 1990
From: calford@psych.psy.uq.oz.au

Hmm, I think I forgot to mention PC-ROUTE takes over the machine and is 
intended to run as a dedicated router. It is a good use for any old PC you may 
have sitting around unused; it only needs a single floppy to boot from and 
128K RAM (certainly less than 256K), no hard disk, keyboard or video card. If 
you have to buy a PC, one from Jameco is recommended. I suppose if you only 
wanted occasional access you could run the software on one of the nearby PCs. 
You'd boot from a floppy with DOS and the configured PC-ROUTE, I don't think 
you'd have any problems with the ethernet also hosting the 3COM network as 
well as the machines you want to connect to with TCP/IP. Suggestion is to talk 
about it with your local network experts, perhaps after downloading the 
PC-ROUTE docs.

Let us know how you get on,
Danny Thomas.


From calford%psych.psy.uq.oz.au@vthrcmac.vthrc.uq.oz.au Sun Nov 18 16:35:39 1990
From: calford@psych.psy.uq.oz.au

Oops, another point I forgot to mention is PC-ROUTE only comes with drivers 
for Western Digital ethernet cards, i.e. WD8003E ethercard plus and 
corresponding starlan cards WD8003S & WD8003SH. This info is particularly 
significant if you're considering part-time use of an existing ethernetted PC, 
but still necessary if you're buying a card.


From nickless@elrond.cs.andrews.edu Sun Nov 18 21:19:54 1990
From: nickless@elrond.cs.andrews.edu (Bill Nickless)

If you have a terminal server connecting to the 3b1, you might check to
see if it will talk SLIP.  That's how we hooked up our 3b1, and in fact
one of the graduate students is working on integrating sendmail with ka9q.

If you have an el-cheapo IBM PC box floating around, you could put an 
inexpensive ethernet card into it for the network.

Many BSD-derived systems provide SLIP support.  Sometimes it's documented,
sometimes not.  If you have a Sun computer on your Ethernet it should
handle the application properly.  Various ftp sites have SLIP for the suns.

Hope this helps.
---
Bill Nickless     nickless@peter.cs.andrews.edu or nickless@flash.ras.anl.gov
                  (708) 972-7390 or (616) 927-0982

From: Mr. Antonio Querubin  <querubin@uhunix.uhcc.hawaii.edu>
Organization: University of Hawaii



Yes it should be possible to connect your 3b1 to the network via SLIP.  You'll
need to setup a SLIP port on one of your other machines (I believe Ultrix has
built-in SLIP capability and Ultrix-Connections for VMS does too) that is also
on your ethernet LAN.  The gateway host MAY need to have it's routing tables 
adjusted depeding on what you're running on it.  



From gjc@mitech.com Mon Nov 19 11:09:19 1990
Status: OR

> From: templon@copper.ucs.indiana.edu (jeffrey templon)
> Subject:WANTED: SLIP/Ethernet conversion help
> Date: 17 Nov 90 21:46:49 GMT
> Message-ID:<72608@iuvax.cs.indiana.edu>

> Hello,
> 
> I have the problem of trying to use SLIP in an 'unsupported' environment.
> The specific SLIP speaker is an AT&T 3b1 running the ka9q package, and
> the network to which I'd like to connect is an ethernet full of machines
> running various flavors of tcp/ip.  Purchasing some sort of bridge is not
> an option unless it is VERY inexpensive. 

You will probably get a few responses from people telling you about SLIP
drivers for SUN microsystems machines. I use one of those myself on
RILIAN.PARADIGM.COM (not yet registered).

But you should know that KA9Q also runs on IBM-PC clone machines. So
that would be one way to put together an inexpensive dedicated bridge
(there being reliability and flexibility advantages to dedicated bridges).

Northeastern University here in Boston MA runs KA9Q in this way.

-gjc
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 13:28:30 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Warning: Keep-Alive considered harmful

The old TOPS-20 TCP/IP used the RST method of probing for half-open
connections, by sending an unacceptable "SYN-ACK".

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 13:55:37 GMT
From:      eru!hagbard!sunic!news.funet.fi!kannel!Kimmo.Suominen@bloom-beacon.mit.edu  (Kimmo Suominen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SLIP driver for HP-UX 9000/360
>>>>> On 20 Nov 90 03:16:19 GMT, brett@solar.card.inpu.oz.au (Brett Sealey) said:

Brett> Any information about such a beast (When, where, how ...) would be much
Brett> appreciated.

Ask your local support for a free (!) distribution of SLIP.  It is
available for both the 800 and 300 series.  It is also UNSUPPORTED but
it should work.  I already got mine, but I yet need to install it.
--
Kim                      /  Internet: Kimmo.Suominen@lut.fi
"That's what I think."  /   Bitnet:   KIM@FINFILES
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 14:17:53 GMT
From:      tksjmi@sybil.cs.Buffalo.EDU (JoAnn Illuzzi)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.sys.mac.comm
Subject:   problems with NCSA Telnet 2.2 and EtherPortSE installer


 There is no comp.protocols.tcp-ip.mac, so excuse the cross postings...

 I have a couple of MacSEs that I cannot get working with NCSA Telnet 2.2.
 I am using EtherPortSEs in both the machines, I have release 2.5,
 rev B of the EtherPortSE installation disk.  The ethernet drivers install
 successfully, but when I invoke NCSA Telnet, I get a System ID of 12,
 and I have to restart the Mac. 

 Has anyone encountered this before and can give me some tips?
 thanks
 JoAnn Illuzzi
 University of Buffalo Technical Services
 716-636-3558

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 16:47:34 GMT
From:      psuvm!ysub!doug@psuvax1.cs.psu.edu  (Doug Sewell)
To:        tcp-ip@nic.ddn.mil
Subject:   tn3270 for sysv/twg tcp (NCR Tower) ?
We have a NCR Tower running System V with TWG tcp and sockets.

I attempted to compile 'vanilla' tn3270 with no luck - missing
includes, undefined symbols, etc.  Including twg_config.h didn't
seem to help (this was a few weeks ago, I don't remember what all
of the errors were).

Does anyone have a ftp-able version of tn3270 for System V/TWG ?

Thanks in advance, Doug
--
Doug Sewell, Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
E-mail: doug@ysub.bitnet, doug@ysub.ysu.edu, ...!uunet!ysub.ysu.edu!doug
You can believe me, because I never lie, and I'm always right (:
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 17:39:21 GMT
From:      mvb.saic.com!dayton.saic.com!fac2@ucsd.edu  (Earle Ake)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <897@fred.UUCP>, rbraun@polygen.uucp (Richard Braun) writes:
> grr@cbmvax.commodore.com (George Robbins) writes:
>>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
>>> We're interested in encapsulating DECnet within a TCP-IP package.  We
>>> are looking primarily for a software solution...
>>
>>I believe TGV multinet can handle this...
> 
> MultiNet is, IMHO, far and away the best TCP/IP package available for
> VAX/VMS.  (This after reviewing products ranging from Process Software
> to Fusion to Wollongong to...)  It's a Stanford-bred product written
> in C with some TOPS-20'isms in it.
> 
> But I fail to understand the original question:  "encapsulating DECnet
> within TCP/IP".  That just doesn't mean anything.

	I think what he means is sending DECnet packages inside of TCP/IP
packets.  I am using IP over DECnet right now.  My TCP/IP packets are
enclosed in DECnet packets, sent over our company DECnet and received by
a machine that 'unwraps' them and then sends them off to the Internet.

-- 
_____________________________________________________________________________
             ____ ____    ___
Earle Ake   /___ /___/ / /     Science Applications International Corporation
           ____//   / / /__                 Dayton, Ohio
-----------------------------------------------------------------------------
Internet: fac2@dayton.saic.com             uucp: dayvb!fac2
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 18:06:56 GMT
From:      cbmvax!grr@rutgers.edu  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes:
> grr@cbmvax.commodore.com (George Robbins) writes:
> >In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
> >> We're interested in encapsulating DECnet within a TCP-IP package.  We
> >> are looking primarily for a software solution...
> >
> >I believe TGV multinet can handle this...
> 
> But I fail to understand the original question:  "encapsulating DECnet
> within TCP/IP".  That just doesn't mean anything.  It could mean
> buying...

Usually enscapulation means that you have a network path that supports
only one protocol, such as a point-to-point DECnet link, over which you
would like to have packets for some other protocol such as TCP/IP pass
transparently.  This is pretty much the opposite of what a gateway does.

Wollengong, Multinet and probably countless others handle the case of
getting TCP through a VMS DECnet link, I assume that this person was
interested in doing the opposite, trying to get a transparent DECnet
link over an internet or other "TCP/IP" path.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 19:09:00 GMT
From:      csus.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!ut-emx!nic.the.net!don@ucdavis.ucdavis.edu  (Donald L. Nash)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <897@fred.UUCP>, rbraun@polygen.uucp (Richard Braun) writes:
>From: rbraun@polygen.uucp (Richard Braun)
>Subject: Re: DECnet encapsulation in TCP-IP
>Date: 19 Nov 90 20:01:53 GMT
>Organization: Polygen Corporation, Waltham, MA
>
>grr@cbmvax.commodore.com (George Robbins) writes:
>>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
>>> We're interested in encapsulating DECnet within a TCP-IP package.  We
>>> are looking primarily for a software solution...
>>
>>I believe TGV multinet can handle this...
>
>MultiNet is, IMHO, far and away the best TCP/IP package available for
>VAX/VMS.  (This after reviewing products ranging from Process Software
>to Fusion to Wollongong to...)  It's a Stanford-bred product written
>in C with some TOPS-20'isms in it.

I agree completely.  We use MultiNet extensively here, and I couldn't get along
without it.  TGV also does a good job with technical support as well.  But
anyway, back to the business at hand:

>But I fail to understand the original question:  "encapsulating DECnet
>within TCP/IP".  That just doesn't mean anything.

Perhaps a better way of saying this is "tunneling DECnet across an IP network". 
Here is an excerpt from the _MultiNet(tm)_System_Administrators'_Guide_ for
MultiNet Version 2.2.  This is the introductory paragraph for Chapter 5, found
on page 5-1:

A special DECnet device driver allows the MultiNet system manager to configure 
a DECnet line and circuit between two cooperating MultiNet systems across an
arbitrary IP network.  This special driver encapsulates DECnet packets in UDP
datagrams for transportation via the IP protocols, much like VAX/PSI
encapsulates DECnet packets in X.25 when doing Data Link Mapping.

This was quoted without permission, but I'm sure the nice folks at TGV won't
kill me for it.  Hopefully, they won't sue me for it either. :-)

I hope that clears the waters a bit.

				Donald L. Nash

				The University of Texas System
				Office of Telecommunication Services

Internet:  don@nic.the.net
THEnet:    THENIC::DON
BITNET:    DON@THENIC
PSI Mail:  311051200131::DON
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 19:35:16 GMT
From:      jk3n+@andrew.cmu.edu  (John Stephen Kalucki)
To:        tcp-ip@nic.ddn.mil
Subject:   SUMMARY:Router-Where to Start

A public thanks to all who sent replies to my request for information on
where to start researching an ip-router. Below are all of the replies:


From: oleary@sura.net (dave o'leary)
Date: Wed, 14 Nov 90 12:04:22 EST
To: jk3n+@andrew.cmu.edu
Subject: IP router implementation


Hi - 

If you are interested in producing a true, full blown IP router, my
advice is - don't.  Unless you are willing to devote many man-months
of your/your friend's/your employee's time.  

If you want basic functionality, i.e. RIP, read RFC 1058, and then
RFC1009 (old router requirements) and then get the draft router 
requirements document and read that.  

Proxy arp is important, especially in the CMU environment, however if
you are going to plug it into the real world you better talk to datacomm
etc. first.  (steve Waldbusser, walt wimer, tom holodnik).  Also Matt
Mathis can tell you a lot about proxy arp and how to do it right.

Basically it is a lot of work, and there are more important problems that
need to be solved beyond "yet another IP router"....

hav efun

					dave
##############################

Date: Wed, 14 Nov 90 11:12 PST
From: rls@osa.com (Rich Scott)
To: jk3n+@andrew.cmu.edu
Subject: Re: IP Router-Where to Start?


	John, take a look at GateD - it's a PD IP routing daemon for 
Berkeley-type Unix machines, and is very well done. It handles multiple
routing protocols (RIP, HELLO, EGP, BGP, and soon, OSPF), and is very
well done. You can ftp it from devvax.tn.cornell.edu. There is also a
"design notes" paper that talks about how it's designed to allow easy
updates for new routing protocols.

	As far as RFCs go, rfc1058 is very good reading for learning RIP,
and rfc1131 documents OSPF (the new replacement for RIP, and any other
Interior Gateway Protocols). Uunet.uu.net has all the rfc's and a rfc-index
in ~ftp/rfc.

	Finally, I highly recommend Douglas Comer's book "Internetworking
with TCP/IP" - it describes the various routinog protocols very well, and
is exceptionally well-written. Be sure to get the second edition - it
has the white cover (the 1st ed. has a black cover).

	-rich

---
rich scott						rich@rx7.osa.com
open systems architects					612 525-0000
minneapolis, mn

###################

To: jk3n+@andrew.cmu.edu (John Stephen Kalucki)
Cc: barns@gateway.mitre.org
Subject: Re: IP Router-Where to Start? 
Date: Wed, 14 Nov 90 15:37:13 -0500
From: barns@gateway.mitre.org

RFC-wise, start with RFC 1009 "Requirements for Internet Gateways"
and chase its references down.

A revision of 1009 is in work in the IETF Router Requirements
Working Group.  There is a draft of the current state of the new
document and it can be obtained through the normal Internet Drafts
distribution sites.  The specifics are attached below.  The preface
to the draft tells most of what you might want to know about the
working group's plans and objectives and how one can have an influence
on what is put into the document.  This draft also has an updated list
of references.  The problem with it is that several sizable chunks
have yet to be written.

Bill Barns
barns@gateway.mitre.org

########################

Date: Wed, 14 Nov 90 21:52 PST
From: Denis DeLaRoca 825-4580 <@BITNET.CC.CMU.EDU:CSP1DWD@OAC.UCLA.EDU> (213)
Subject: Re: IP Router-Where to Start?
To: jk3n+@ANDREW.CMU.EDU (John Stephen Kalucki)

Look at RFC-1009, it addresses the subject of routers directly, it
is 2-3 years old and a lot of things have happened since.
 
1009  Braden, R.T.; Postel, J.B.  Requirements for Internet gateways.  1987
      June; 55 p. (Format: TXT=128173 bytes)  (Obsoletes RFC 985)
 
For packages that can do routing and you can test with, there are many,
any BSD Unix host can do routing, look also at the PCROUTE, Ka9q,
the CMU tcp/ip package, etc.
 
-- Denis


#####################

To: jk3n+@andrew.cmu.edu (John Stephen Kalucki)
Cc: barns@gateway.mitre.org
Subject: Re: IP Router-Where to Start?
Date: Thu, 15 Nov 90 07:45:00 -0500
From: barns@gateway.mitre.org

Sorry, this got dropped from other message.  /Bill

------- Forwarded Message

Return-Path: <owner-ietf@venera.isi.edu>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
	id AA04720; Thu, 20 Sep 90 14:19:10 -0400
To: ietf@venera.isi.edu
Subject: ID ACTION: draft-ietf-rreq-iprouters-00.txt
Date: Thu, 20 Sep 90 10:04:32 -0400
From: mdavies@NRI.Reston.VA.US
Message-Id:  <9009201004.aa05617@NRI.NRI.Reston.VA.US>




A New Internet Draft is available from the on-line internet-drafts directories.

       Title    :  Requirements for Internet IP Routers
       Author(s):  Philip Almquist
       Filename :  draft-ietf-rreq-iprouters-00.txt


This draft attempts to define and discuss requirements for devices which
perform the network layer forwarding function of the Internet protocol suite.
The Internet community usually refers to such devices as "routers".  This
document is intended to provide guidance for vendors, implementors, and
purchasers of IP routers.

Internet-Drafts are available by anonymous_ftp.  Login with the username:
anonymous and password: guest.  After logging in, cd internet-drafts.
Type "get <filename>" with the filename above to retrieve the draft.

Internet-Drafts directories are located at:

NSF Network Service Center
    Address:  nnsc.nsf.net (192.31.103.6)

Defense Data Network NIC
    Address:  nic.ddn.mil (192.67.67.20)

Pacific Rim
    Address:  munnari.oz.au (128.250.1.21)

Europe
    Address:  nic.nordu.net (192.36.148.17)

Internet-Drafts are available by mail.  Send a message to SERVICE@nic.ddn.mil
with the subject:  SEND INTERNET-DRAFTS:draft-ietf-rreq-iprouters-00.txt

For questions, please mail to internet-drafts@nri.reston.va.us.


------- End of Forwarded Message

######################

Date: Thu, 15 Nov 90 08:53:10 PST
From: postel@venera.isi.edu
To: jk3n+@andrew.cmu.edu
Subject: Re:  IP Router-Where to Start?
Cc: tcp-ip@venera.isi.edu

Hi.

Start with RFC-1009, and also get involved with the "router requirements
working group" of the IETF.

--jon.

To: jk3n+@andrew.cmu.edu (John Stephen Kalucki)
Cc: tcp-ip@nic.ddn.mil
Subject: Re: IP Router-Where to Start? 
Date: Thu, 15 Nov 90 11:07:34 -0800
From: "Philip Almquist" <almquist@jessica.stanford.edu>

John,
> I'm thinking about implementing an IP router, but I have no idea where
> to start. I've browsed through the RFC index and a few RFC's themselves,
> but there doesn't appear to be anything directly related to routers.
> 
> I'm looking basically for 4 things:
> 1) Related RFC's
	There are a lot of of relevant RFCs.  In addition to the router
standard (RFC1009) that Jon Postel mentioned, there are several RFCs on
the network layer (791, 792, 922, 950, 1112, 1122).  And of course
there ARP, all of the IP over mumble networks RFCs, routing protocols,
SNMP, ...

	There is also a draft successor to RFC1009 which is available
via anonymous FTP from NIC.DDN.MIL.  Its name is:

	internet-drafts:draft-ietf-rreq-iprouters-00.txt

> 2) Books and other text that might help
	Various good books, such as Comer's, provide a reasonably good
introduction to TCP/IP.  None that I know of teach nearly all of the
things you'd need to know to implement a router.

> 3) Public Domain implementations, hopefully source, to test mine with
	PCROUTE, KA9Q, and Berkeley UNIX are all reasonably easy to
obtain, though I don't have details for any of them on the tip of my
fingers.  Additionally, various universities (MIT, CMU, Stanford, and
probably others) have developed routers whose code is likely to be
available if you can figure out who at those institutions has the
authority to give it to you.

	One caveat, however: most if not all of the above are not fully
compliant with RFC1009.

> 4) Advice
	Don't underestimate the effort involved in building a router
from scratch.  You're talking man-years of effort to build even a
minimally reasonable one.
						Philip
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 21:25:52 GMT
From:      unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU  (Ruth Milner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes:
>grr@cbmvax.commodore.com (George Robbins) writes:
>>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
>>> We're interested in encapsulating DECnet within a TCP-IP package.  We
>>> are looking primarily for a software solution...
>>
>>I believe TGV multinet can handle this...
>
>MultiNet is, IMHO, far and away the best TCP/IP package available for
>VAX/VMS.  
>
>But I fail to understand the original question:  "encapsulating DECnet
>within TCP/IP".  That just doesn't mean anything.  
>
[...]
>What's the need, anyway?  

Encapsulated DECnet is DECnet packets wrapped inside IP packets. To IP-only 
systems, the packets appear as normal TCP/IP and are routed accordingly. When 
they arrive at the destination (running MultiNet), the software strips off the
TCP/IP stuff, finds a DECnet packet inside, and hands it off to DECnet for
the real processing. As far as DECnet is concerned, a DECnet packet just came
off the net.

DECnet is very picky about nodes being "adjacent", i.e. directly reachable
through some line or another. Under normal circumstances you would have to 
have DECnet nodes every step of the way to reach a remote system.  With 
DECnet-over-IP, however, the IP-only node(s) in between are transparent
to DECnet, and even though the two nodes could be miles apart, they appear
to be adjacent. This can *enormously* simply configuring a wide-area DECnet,
especially if there are existing links which only run TCP/IP. It also reduces
the number of systems which must run DECnet; since most UNIX implementations
(at least as of a year ago) cannot do routing between networks, encapsulating 
DECnet within IP can save your hide if you find you need to talk to some 
(DECnet) system a few UNIX routers/gateways away.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 22:01:16 GMT
From:      usc!zaphod.mps.ohio-state.edu!ub!acsu.buffalo.edu@apple.com  (patrick k ferrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for sources of mh V6.x

The subject, as they say, says it all:  Anybody know where I can anonymously
ftp the sources for mh?  (Version 6.x would be nice)

Thanks,
Pat

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|   ____                                      |                               |
|  /\T B\   Patrick K. Ferrick / KA2AYK       |  If Helen's beauty could      |
| /  \E S\  ferrick@acsu.cc.buffalo.edu       |  launch 1000 ships, is one    |
| \  /   /  219 Computing Center              |  millihelen enough beauty     |
|  \/___/   State University of NY at Buffalo |  to launch one ship?????      |
|                                             |                               |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 22:04:28 GMT
From:      copper!hughes@iuvax.cs.indiana.edu  (larry hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <897@fred.UUCP> rbraun@fred.UUCP (Richard Braun) writes:
>grr@cbmvax.commodore.com (George Robbins) writes:
>>In article <90313.134117JHL1@psuvm.psu.edu> JHL1@psuvm.psu.edu writes:
>>> We're interested in encapsulating DECnet within a TCP-IP package.  We
>>> are looking primarily for a software solution...
>>
>>I believe TGV multinet can handle this...
>
>MultiNet is, IMHO, far and away the best TCP/IP package available for
>VAX/VMS.  (This after reviewing products ranging from Process Software
>to Fusion to Wollongong to...)  It's a Stanford-bred product written
>in C with some TOPS-20'isms in it.
>
>But I fail to understand the original question:  "encapsulating DECnet
>within TCP/IP".  That just doesn't mean anything.  It could mean
> [etc.]

DEC used to have a product called an "internet portal" which
enveloped TCP/IP within DECnet.  It was a hardware/software
solution consisting of an Ultrix workstation at both ends
(i.e. on two networks separated by a DECnet backbone) to handle
the enveloping/de-enveloping.

It's quite possible that they reversed this to envelope DECnet
withing TCP/IP...

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||        hughes@ucs.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...    ||
 \\==========================================================================//
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 22:29:53 GMT
From:      ucivax!jromine@ucbvax.Berkeley.EDU  (John Romine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for sources of mh V6.x
ferrick@acsu.buffalo.edu (patrick k ferrick) writes:
>The subject, as they say, says it all:  Anybody know where I can anonymously
>ftp the sources for mh?  (Version 6.x would be nice)

The short answer is ftp to ics.uci.edu:pub/mh and get mh-6.7.tar.Z.
--
John Romine
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      20 Nov 90 22:39:24 GMT
From:      nic.cerf.net!sss@ucsd.edu  (Marlene M. Eckert)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP Help

 
Hello.

My Task:
   Use a Sun 3/60 running Sun OS 4.1 to dial up to a regional net that
   connects to the Internet.

Proposed solution:
   Use SLIP to permit me to telnet, ftp, and mail my heart out.

Progress:
   I have SLIP installed and can start sliplogin. Netstat seems to see the
   connection, however I can't seem to ping any hosts.

Questions:
   1)  The README distributed with SLIP mentions a special tip for SLIP that
       was not available.  I am using Sun's standard version of tip to
       dial and establish the connection.  I then start sliplogin in a
       second Suntools window. I assume (because I can't find it in any
       documentation) that the window that is running tip can be closed
       to an icon, and that I should be able to telnet, etc. from any
       other window.  Is this correct or do I need another version of tip?

   2)  Obviously, I have not done this before.  I think changes must be
       necessary to my Sun's databases and routing table.  If so, what do I
       change?  There is a ton of stuff that the Unix documentation discusses
       (/etc/hosts, /etc/networks, /etc/gateways, routed, etc.).  Do I need to
       do anything special because the connection is not always up? I've tried
       experimenting (really hacking), now I'm askng the experts for help...

All help would be appretiated. Thanks in advance.

Please mail your responses directly to me at sss@cerf.net.  If there seems
to be interest I'll post a summary of the responses.
 
Michael Reznick
Structured Systems & Software (3S)
Phone: (714) 830-3777
Mail : sss@cerf.net 
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Nov 90 22:40 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Armando Mac Beath <MACBEATH@udlapvms.pue.udlap.mx>
Cc:        TCP IP <TCP-IP@nic.ddn.mil>
Subject:   Re: Request for Generic Pinger software
>>NPRV executables can be obtained by anonymous FTP from CCC.NMFECC.GOV
>>(128.55.128.30).  The distribution includes the following files:
>> 
>>               [ANONYMOUS.PROGRAMS.NPRV]NPRV.DOC     (ASCII text)
>>               [ANONYMOUS.PROGRAMS.NPRV]NPRV.EXE     (binary)
>>               [ANONYMOUS.PROGRAMS.NPRV]SAMPLE.IPA   (ASCII text)


> This host have a anonymous disallowed :(
> Do you know how can get this package in another host or can you send me all
> files !!!!!!!!

Rats!

Sorry, I don't have my own copy of the NPRV distribution.  Thanks for the
(unhappy) info.  I'll investigate.

- Bob Stine

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 90 18:07:16 GMT
From:      eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!dwight@bloom-beacon.mit.edu  (Dwight Ernest)
To:        tcp-ip@nic.ddn.mil
Subject:   Formation of the UK Internet Consortium

Formation of the UK Internet Consortium

London, 21 November 1990

Following years of mostly unfocused frustration about the lack of
clear direction in the UK networking community toward the creation
of a UK Internet, a group calling itself the UK Internet Consortium
has been formed in the last few weeks. The group intends to either
provide or to press for the timely and reasonable provision to UK
customers of a network with connections to continental and inter-
national Internets running the TCP/IP protocol suite.

Consortium members said that the emphasis would be on UK management,
UK-based service availability, reasonable prices, and cooperation
with other network providers. All agreed that in the current climate
of telecommunications deregulation, the time was ripe.

Founding consortium members included representatives from the
following UK firms: Unipalm Ltd., a Cambridge firm offering
TCP/IP-based communications software; The Independent, a quality
daily newspaper; Spider Systems Ltd., an Edinburgh-based company
offering networking equipment; the Desktop Connection, a Manchester-
based desktop publishing vendor and service provider; and
Specialix Ltd., who design and manufacture third-party communi-
cations equipment for the PC aftermarket. Both the Sun UK Users
Group and the IBM PC Users Group were also represented, as were
several private individuals with background and skills in computer
networking.

The consortium says it will be distributing a survey to gauge
market potential and emphasized that all consortium members had
signed an affidavit to the effect that responses would not be
misused. They said that all aspects of the Data Protection Act
would be strictly adhered to in the collection of responses.
Approximately 30,000 survey copies would be printed, and they
will be distributed through users groups mailings and company
promotional mailings.

Additionally, they said that surveys may be requested by sending
email to
	ip-interest@independent.uucp
or by posting a request to
	The UK Internet Consortium
	PO Box 360
	Harrow HA1 4LQ

They also mentioned that an electronic mailing list to facilitate
discussion of the issues has been created. They have asked for
subscription requests to be sent to
	ukipnet-request@independent.uucp

-30-

Please do not reply to the poster of this message, but to the
	ukipnet-request@independent.uucp
address instead.


-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
-- 
		--Dwight Ernest
			(reply to dwight%independent.uucp@ukc.ac.uk)
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 90 18:12:23 GMT
From:      snorkelwacker.mit.edu!usc!samsung!munnari.oz.au!murdu!viccol!timcc@bloom-beacon.mit.edu  (Tim Cook)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request: SLIP on a Sequent S27 (info on SLIP in general)
In article <12073@bsu-cs.bsu.edu>, sam@bsu-cs.bsu.edu (B. Sam Blanchard)
writes:
> I would like to implement SLIP on a Sequent S27 running Dynix.
> Dynix is 4.2bsd with many 4.3bsd enhancements. (yes, Dynix is much more)

There is a freely available implementation of SLIP available for DYNIX.  It
does need to be built into the kernel, but instructions are supplied on how
to do this, and you don't need DYNIX source code.  We have been using it
here for about 6 months, and it works fine, except it has crashed IP about
a dozen times, which I think is another symptom of the poor terminal
multiplexor drivers that are found on Sequents.  You may have better luck
than us, but we are going to start using a PC running PCroute soon.

You can find the source to this in networking/Dynix.sl.tar.Z in uunet's
anonymous FTP area, or send a message to info-sslip@riacs.edu for more
information.
--
The above message in no way represents the official opinion, policy or
standing of Victoria College, or the Computer Services department of
Victoria College.  If things come unstuck, they will disavow any knowledge
of my actions.  This item will self-destruct in five disk-accesses.
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      21 Nov 90 20:19:26 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!samsung!umich!sharkey!ionic!gm@ucsd.edu  (Greg Miller)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet's ECHO option

 I'm in the midst of writing my own tcp/ip implementation, and have been
caught up with what seems to be a problem - determining who exactly
does any echoing in a telnet session.

 I've read the RFC covering the telnet ECHO option (RFC 857), and thought
that I understood it.  This explanation is an oversimplification, but
shows the way I interpreted it:

 (There's no need to explain the need to respond to a "WILL/WONT" with a
  "DO/DONT" rather than the other-way-around; I'm fully aware of that, and
  make use of it.  I don't include it here for simplification.)

 (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo
each character I send to them.

 (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive
an echo for each character sent.

 Part (1) above seems to fit properly.  If I send the DO ECHO, the host
happily echos everything back to me.  However, part (2) doesn't seems to
always apply -

 On varied pieces of equipment, it does what I expect - a DONT/WONT pair
causes the host not to echo anything back.  However, whenever I try this
when I'm connected to a BSD machine, the host accepts my DONT ECHO,
replies with WONT ECHO, and then procedes to continue echoing anyways.

 What gives?  Am I interpreting things wrong?  Is this option incorrectly
implemented in some BSD revisions?

--
     +----------------------------------------------------------------+
     | A sign of mismanagement, over-    |  Greg Miller               |
     | complication and overall idiocy:  |  ..ames!sharkey!ionic!gm   |
     |                                   |  gm@ionic.uucp             |
     |      "Designed By Committee"      |                            |
     +----------------------------------------------------------------+
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 90 01:28:23 GMT
From:      bacchus.pa.dec.com!mogul@decuac.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: DECnet encapsulation in TCP-IP
In article <73306@iuvax.cs.indiana.edu> hughes@copper.ucs.indiana.edu (larry hughes) writes:
>DEC used to have a product called an "internet portal" which
>enveloped TCP/IP within DECnet.  It was a hardware/software
>solution consisting of an Ultrix workstation at both ends
>(i.e. on two networks separated by a DECnet backbone) to handle
>the enveloping/de-enveloping.

As far as I know, we still sell the Internet Portal.  Quite a few
are in use inside Digital.

>It's quite possible that they reversed this to envelope DECnet
>within TCP/IP...

Not that I know of.

-Jeff
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 90 03:07:36 GMT
From:      uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!nodecg!adrienne@ames.arc.nasa.gov  (adrienne byrd 4208172)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet option negotiation


For some time now we have been curious about what we think are called
"telnet options".  We are using NCSA Telnet 2.2 to talk to Xenix boxes with
Excelan's LAN WorkPlace package.  I've noticed that when running NCSA Telnet
I often get "telnet option 254 1" type messages.  

Further investigation in the Excelan manuals reveals that there is a 
"telnet command" 

	iac n1 n2 ...

where n1, n2 specifiy the decimal number of the command.  The manual gives
the example

	iac 254 1

as being the equivalent of telnet's DONT ECHO command.  

Could someone please post a list of these such numbers and what they mean in
telnetese?

Thank you in advance.

Adrienne Byrd
Network Computer Centre, Telecom Australia, WA
ACSNET: adrienne@telecomwa.oz
Internet: adrienne%telecomwa.oz@uunet.uu.net
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 90 03:10:41 GMT
From:      eru!hagbard!sunic!mcsun!tuvie!edvvie!eliza!schweigl@bloom-beacon.mit.edu  (Johnny Schweigl)
To:        tcp-ip@nic.ddn.mil
Subject:   need URGENT help with SCO UNIX TCP/IP - please
We are currently encountering a major problem with no idea how to solve it.
Machine configuration is as follows:

Hardware:
	COMPAQ Systempro
	two 386/33 CPU boards
	12 MB mem
	1.6 GB Disk, configured for data guarding
	3COM Etherlink II network adapter
	Adaptec SCSI controller 
	GIGATAPE DAT streamer
	SCO UNIPATH SDLC comms board
	Computone controller with 1 Async feature box attached

Software:
	SCO UNIX 3.2 Runtime
	TCP/IP 1.1.1 Runtime
	SCO (Corollary) MPX
	COMPAQ EISA supplement

Operating environment:
	Machine serves as time accounting system with industrial terminals
	connected via RS232. Users (>25) telnet from WANG VS (great, BTW)
	to SCO box, using accounting software.
	32 pty's are configured into the kernel (maximum allowed by TCP/IP).
	C2 security mode is relaxed (from sysadmsh).

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

RTFM: 
	SCO TCP/IP release notes predict this error if pty's and vty's are not
	correctly configured. Nope. As far as I can see I did it right. Simply
	followed the instructions in the manual.
	No further reference to this error in the complete runtime docs.
	Also, the TCP/IP manual says, that if streams ressources are insufficient,
	unpredictable errors.

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

Actions taken so far:
	Analyzed streams ressource usage with crash and strstat subcommand,
	reconfigured kernel. Should now be sufficient.
	Ran a brute force test with 32 concurrent telnets and some parallel 
	ftp's. Error did not occur. Next day, error occured 8 times. One day
	later 3 times, and so on ...

Problem:
	Angry users wanting to tear our heads off.
	So if you know any solution, or if this is a known error, corrected in
	release x.y.z pleeeaaase tell me.

Thanks in advance, 
 

-- 
This does not reflect the   | Johnny Schweigl
opinions of my employer.    | USENET: schweigl@edvvie.at
I am busy enough by talking | 
about my own ...            | EDVG  Vienna/Europe, Tel (+43 222) 59907-0
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Nov 1990 16:01:02 PST
From:      Ole J. Jacobsen <ole@csli.stanford.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: High-Speed Networking
Several articles on high speed networking appear in the October 1990
issue of ConneXions. There is an article on FDDI, one on SMDS (with
references to ATM and SONET), and one on Gigabit Networking. Also,
there is an article on ISDN, if you can call that "high speed"  :-)



Ole J Jacobsen, Editor & Publisher ConneXions--The Interoperability Report 
Interop, Inc., 480 San Antonio Road, Suite 100, Mountain View, CA 94040, USA
Phone: (415) 941-3399  FAX: (415) 949-1779  Email: ole@csli.stanford.edu
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 90 14:56:16 GMT
From:      eru!hagbard!sunic!mcsun!tuvie!acmis!joe@bloom-beacon.mit.edu  (Johannes Rupp)
To:        tcp-ip@nic.ddn.mil
Subject:   Interlan TCP/IP Novell Gateway SMTP Problem

We have a problem getting the SMTP mail connection running between our
INTERLAN TCP/IP Novell Gateway and any other computer running TCP/IP.

Our Novell configuration is as:

   Advanced Netware 286 V2.15
   Interlan TCP/IP gateway with the NP600G board installed
   Interlan TCP/IP gateway software V1.4

   The Interlan TCP/IP gateway is installed in the Novell server.


Our problem:

1.) Sending mails via SMTP from a UNIX host (also using TCP/IP) and an
   IBM host (again using TCP/IP via an IBM3172 controller) to the
   Novell server (via the Interlan TCP/IP gateway) works fine.

2.) Sending mails from a PC workstation in the Novell network using the
   Interlan MAILWS program (part of the Interlan TCP/IP gateway software
   distribution) to either the UNIX host or the IBM host fails.

   Watching the network traffic uncovers the following situation:

   
         Interlan TCP/IP gateway             UNIX host
       	   sends TCP/IP packet           sends TCP/IP packet
         =======================       ========================

        initiates a connection to
        UNIX host


				      220 acmis.cmis.co.at Sendmail ready at ...

        HELO *
             ^
             |
             |
             How can I change the Interlan TCP/IP gatway configuration
             to make the gateway sending out the actual TCP/IP gateway
             hostname instead of the '*' character?

-    In any mail received by the UNIX host the return address is always build up
     as 

              username@*

     I guess the '*' in the domain name instead of the host name comes from 
     the HELO * of above.


-    Sending mails to the IBM host is even impossible as the MAILSW program
     immediately returns with the messages:

         Trying to connect to dpcenter.cmis.co.at...
         Syntax Error. Start Domain with 'a'..'z' or 'A'..'Z'
         Connection to remote host failed.
         Mail saved in "SYS:MAIL/B70187\DEAD.LET"

     In this case it won't send no mail at all to the IBM host
     Also in this case the TCP/IP Interlan gatway sends a HELO *
     packet to the IBM host. The only difference is that the IBM
     implementation of TCP/IP refuses to accept the * instead of
     a hostname completely.



Sending mails between the IBM and UNIX hosts works in both directions.


My guess is that we have missed something during the installation of the
Interlan TCP/IP gateway software. What I would like to know is just what
we missed.

Any help is welcome.

Best regards,



Johannes


-- 
+------------------------------------------------------------------------+
| CMIS Austria                |      Voice:  (++43-222) 98 109  Ext. 110 |
| NIELSEN Austria             |      Voice:  (++43-222) 98 110  Ext. 110 |
| Moeringgasse 20             |      Fax:    (++43-222) 98 110 77        |
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      22 Nov 90 15:52:30 GMT
From:      eru!hagbard!sunic!mcsun!hp4nl!nikhefh!a20@bloom-beacon.mit.edu  (Marten Terpstra)
To:        tcp-ip@nic.ddn.mil
Subject:   high speed networking
Hi all,

Maybe this is not the most appropriate newsgroup but here goes.

I am looking for any information on high speed networking products and projects.
Possible names are :

FDDI, UltraNet, HIPPI, ATM, SONET and projects like AURORA, CASA, JPL, VISTA,
NECTAR.

Any pointers, hints are appreciated. Preferably technical descriptions.

Thanks,

Marten
--
Marten Terpstra                                  National Institute for Nuclear
Internet : terpstra@nikhef.nl 		                and High Energy Physics
Oldie-net: {....}mcsun!nikhefh!terpstra	      (NIKHEF-H), PO Box 41882, 1009 DB
Phone    : +31 20 592 5102                           Amsterdam, The Netherlands
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 02:37:18 GMT
From:      usc!samsung!munnari.oz.au!mel.dit.csiro.au!latcs1!wcc!tom@ucsd.edu  (Tom Evans)
To:        tcp-ip@nic.ddn.mil
Subject:   AMD LANCE - How to Tell Versions?
I need to write some code that will detect and warn of old versions of
the AMD AM7990 LANCE chip, particularly very old (1984) Rev A and Rev B 
versions.

Does anyone have any code examples that can do this, or knows of any
chip differences that can be detected from software? We've found that
AppleTalk Phase 2 won't run on Rev A and B chips - a problem to do
with Multicast address recognition. Loopback testing doesn't seem to
show it however (dammit!).

Please mail responses (as well/instead of posting - your choice).
Thanks.
========================
Tom Evans  tom@wcc.oz.au  
Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179
Victoria, Australia 61-3-764-1100  FAX ...764-1179
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 08:02:25 GMT
From:      eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun7!conti@bloom-beacon.mit.edu  (Giovanni Conti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option
In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes:
> 
>  (There's no need to explain the need to respond to a "WILL/WONT" with a
>   "DO/DONT" rather than the other-way-around; I'm fully aware of that, and
>   make use of it.  I don't include it here for simplification.)
> 
>  (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo
> each character I send to them.

I think there is a need to explain the WILL/WONT mechansim.
The ECHO is LOCAL. So if you ask your partner to do echo,
he will duplicate his output stream (from him to you) onto
his input stream. That means that a UNIX system doing Telnet echo
and sending you a "Username:" string will also read the same string
in its input stream. So obviously, the UNIX system never does Telnet
echo locally. On the other side, you (e.g. the terminal) are expected
to do some local echo of the keyboard input to the screen (echo
your input stream to your output stream). If the system does not
want you to do that (e.g. when you type the password), it tells
you DONT ECHO, which means "Just send me the characters, I will echo
back what I think is reasonable". In that case you do not
echo the characters locally on your screen.

If you ask the host to do ECHO, and assuming he answers WILL ECHO,
that means that when he sends you the string "Username:", telnet echoes
him a copy as if you've typed "Username:", leading to wrong behaviours.

So don't tell the host to do local echo (local to him) if you are
a Telnet Client (or unless you know exactly what you're doing).

> 
>  (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive
> an echo for each character sent.
> 

So this is wrong. But fortunately, according to your request, the BSD host
will not read in its input stream all the characters it sent to you.

>  Part (1) above seems to fit properly.  If I send the DO ECHO, the host
> happily echos everything back to me.  However, part (2) doesn't seems to
> always apply -
> 

The fact of echoing everything back to you means:

a) that you did not do local echo in the beginning (unless you received
   all duplicated characters. So there is an error in your Telnet
   implementation.

b) That the Application echo (e.g. the login deamon on a host) has
   NOTHING to do with your Telnet echo commands. In fact, the application
   running on top of telnet (e.g. csh) may echo back things, asking
   you first NOT to do local echo (so you receive a DONT ECHO from the host).

Good luck

Giovanni Conti
Ecole Polytechnique Federale de Lausanne
Laboratoire de Teleinformatique
EL-Ecublens
CH-1015 Lausanne
Switzerland
Tel   : +41 21 693.29.07
FAX   : +41 21 693.46.60
E-mail: conti@ltisun.epfl.ch
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Nov 90 11:15:15 GMT
From:      richards@hawk.nstn.ns.ca (Mark Richardson)
To:        tcp-ip@sri-nic.arpa
Subject:   Telnet, FTP, Mail and News for DOS

My boss recently tasked me with locating the *optimal* package that would
provide the following functionality to our customers on a dial-up basis:

                         - Telnet
                         - FTP
                         - Mail reader service (a la POP, PCMAIL, IMAP)
                         - News reader 

I realize that Telnet and FTP are no problem through dial-up; it is more of
a concern for the other two. We want to run this 'package' over either SLIP
or preferably a class 6 packet driver thus not neccesitating the use of a 
dedicated on-site server.

The customers machines are DOS machines, which precludes a wide variety of
choices.

If there is anyone out there who has had to solve a similar problem
or you think you have the answer (even if you sell the answer) please drop
me a note. Any help would be greatly appreciated (I should warn you that I
am rather new to networking, thus I may appear to be somewhat lacking in 
brain cells).

You can get me at the E-mail address below. If there is lots of interest,
I will be happy to summarize for the net.

Good Day, Eh

Mark

******************************************************************
*  Mark Richardson                        Software Kinetics Ltd  *
*  Project Engineer                       101 Ilsley Ave         *
*  E-mail - richards@hawk.nstn.ns.ca      Suite 5                *
*  Phone (902)468-3680                    Dartmouth N.S. Canada  *
*  Fax   (902)468-3679                    B3B 1S8                *
*                                                                *
*  If I should happen to be quoted, Software Kinetics Limted     *
*  will disavow any knowledge of my existance and I shall self   *
*  destruct ....... oh, I don't know .... maybe after lunch      *
*                                                                *
******************************************************************
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 14:53:58 GMT
From:      eru!hagbard!sunic!mcsun!ukc!stl!neil@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Reducing the risks when conencting to an internet

We are starting the planning process to connect our large internal network
to an internet. We wish to reduce the risk of unwanted external vistors
as far as possible, whilst allowing our internal users access to other
hosts.

One possibility is to acquire a device to sit between our backbone and
the outside world. This device would be programmable so that I could
authorise connections on a per host, per port, per direction basis.

So, for example I have network 128.199, I could have an authorisation
file like:-

# Source		Dest		Comment
# host.port		host.port

*.smtp			mymailgw.smtp	Mail service inbound
mymailgw.smtp		*.smtp		Mail service outbound
128.199.200.*.ftp	*.ftp		FTP
128.199.200.*.telnet	*.telnet	Telnet


So, from the above, my mail gateway could send out to anybody, and anybody
can send to my mail gateway (and no where else). Any machine on my local
200 subnet can ftp or telnet to anywhere, but no inbound conenctions are
allowed.


Is this possible, or are we thinking in completely the wrong way ?
At this stage it isn't necessary that the device exists in the UK,
we can import if necessary.

The device probably needs to understand name servers as well.

We also have an eye on the future, so the Vendor would need to offer
support for OSI protocols.

Neil Todd			| ..In general, it is best to assume that the
PSI%234237100122::neil		| network is filled with malevolent entities
neil@stl.stc.co.uk		| that will send in packets designed to have
STC Technology Ltd		| the worst possible effect...
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 15:20:22 GMT
From:      eru!hagbard!sunic!mcsun!ukc!icdoc!syma!nickw@bloom-beacon.mit.edu  (Nick Watkins)
To:        tcp-ip@nic.ddn.mil
Subject:   Thanks [Re: tftp needed for HP9000/835]
From article <3841@syma.sussex.ac.uk>, by nickw@syma.sussex.ac.uk (Nick 
Watkins):
> We have an X terminal which needs to use trivial ftp to download the X binary
> from an HP9000/835. tftp is not included in the TCP-IP software suite
> provided with HP-UX (LAN 9000), has anybody got a suitable (source or
> binary) version of tftp that we could have ?
Many thanks to all who responded, tftp now running on our HP.

Nick
-- 
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 16:56:04 GMT
From:      eagle!news@ucbvax.Berkeley.EDU  (Steven Eubanks)
To:        tcp-ip@nic.ddn.mil
Subject:   Netbios/TCP P/M-node implementations
Continuing my quest for more NetBIOS over TCP information...
	(Sorry, I'm kind of new to this RFC1001/1002 business)

	Are there any commercially/PD implementations of P-node or M-node
NetBIOS servers/clients??  All the implementations I've seen so far seem
to use B-nodes.  I suppose that I'm also interested in knowing about
NetBIOS name server (NBNS) and datagram distribution (NBDD)
implementations as well.

Thanks in advance,
Steve
-- 
Steven W. Eubanks,  EDS/LIMS			NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-8498					Cleveland, OH  44135
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      23 Nov 90 20:01:10 GMT
From:      jpusa1.chi.il.us!stu@gargoyle.uchicago.edu  (Stu Heiss)
To:        tcp-ip@nic.ddn.mil
Subject:   advise on ethernet card for T5100 wanted
I have SCO TCP/IP running on my toshiba T5100 and connect with slip to
the office machine.  I'm in need of advise on an ethernet card that
will work with the toshiba.  Toshiba does sell a card for the 5100,
although I don't know whose it is.  Does anyone have any experience
with the T5100 and ethernet?  SCO TCP/IP provides drivers for the
wd8003e, 3c501, 3c503, and an unsupported one for the 3c523.

Thanks in advance, Stu
-- 
Stu Heiss - stu@jpusa1.chi.il.us
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Nov 90 10:20:15 EST
From:      boudreau@bond.crim.ca (Guy Boudreault)
To:        tcp-ip@nic.ddn.mil
please remove my name from your mailing list.

Thanks

-------------------------------------------------------------------------------
Guy Boudreault            | Centre de recherche informatique de Montreal (CRIM)
Analyste de systeme (UNIX)| 3744 rue Jean-Brillant, bureau 500 
<boudreault@crim.ca>      | Montreal (Quebec) Canada H3T 1P1
<uunet!clouso!boudreau>   | tel: +1 514 340 5754 / fax: +1 514 340 5777 
-------------------------------------------------------------------------------
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 90 11:31:19 GMT
From:      BINGZHI%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU (Bingzhi Li)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Channel Problem



Hi, all.
    I am working o TCP/IP, to develop the interactive file accessing
system between IBM/VM and VAX/VMS hosts. The problem is how to deal
with the virtual channel if the client process asking files from the
remote hosts will take a long time.

    One solution is that client waits for the requested files coming
after sending the request commands. Another is that the client don't
wait for the files coming, and quit the interactive accessing state
(but the channel is alive), after sending the request commands. How
to deal with this problem if the waiting time is very long ?

    I think someone have the experience on this problem. Wish to hear
from some good ideas. Thank you in advance !

Bingzhi  LI


+=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

    CCCCC  N    N U   U  CCCCC  EEEEE
    C      N N  N U   U  C      E             ______
    C      N  N N U   U  C      EEEEE         TTTTTT
    C      N    N U   U  C      E             ::::::
    CCCCC  N    N UUUUU  CCCCC  EEEEE       ==========
                                            TTTTTTTTT
                                            :::::::::
   Bingzhi  Li                             ==========
   Institute of CNUCE                      TTTTTTTTT
   National Research Council               :::::::::
   36 Via S. Maria, Pisa, Italy           ==========
   Voice: +39 50 593343                   TTTTTTTTT    h =(1/2)*g*t**2
   Fax:       50 576751                   :::::::::
   Email: bingzhi@icnucevm.cnuce.       ============
                  cnr.it
=-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=-=-=-=-=-=-=-=-==-=-=-===-=-=-=-=-=

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Nov 90 12:31:19 MET
From:      Bingzhi Li <BINGZHI%ICNUCEVM.CNUCE.CNR.IT@CUNYVM.CUNY.EDU>
To:        All <tcp-ip@nic.ddn.mil>
Subject:   TCP/IP Channel Problem


Hi, all.
    I am working o TCP/IP, to develop the interactive file accessing
system between IBM/VM and VAX/VMS hosts. The problem is how to deal
with the virtual channel if the client process asking files from the
remote hosts will take a long time.

    One solution is that client waits for the requested files coming
after sending the request commands. Another is that the client don't
wait for the files coming, and quit the interactive accessing state
(but the channel is alive), after sending the request commands. How
to deal with this problem if the waiting time is very long ?

    I think someone have the experience on this problem. Wish to hear
from some good ideas. Thank you in advance !

Bingzhi  LI


+=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

    CCCCC  N    N U   U  CCCCC  EEEEE
    C      N N  N U   U  C      E             ______
    C      N  N N U   U  C      EEEEE         TTTTTT
    C      N    N U   U  C      E             ::::::
    CCCCC  N    N UUUUU  CCCCC  EEEEE       ==========
                                            TTTTTTTTT
                                            :::::::::
   Bingzhi  Li                             ==========
   Institute of CNUCE                      TTTTTTTTT
   National Research Council               :::::::::
   36 Via S. Maria, Pisa, Italy           ==========
   Voice: +39 50 593343                   TTTTTTTTT    h =(1/2)*g*t**2
   Fax:       50 576751                   :::::::::
   Email: bingzhi@icnucevm.cnuce.       ============
                  cnr.it
=-=-=-=-=-=-=-=-=-=-=-==-=-=-==-=-=-=-=-=-=-=-=-=-==-=-=-===-=-=-=-=-=
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Nov 90 16:39:41 GMT
From:      att!emory!stiatl!srchtec!srchtec.uucp@ucbvax.Berkeley.EDU  (Michael Almond)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet Access Costs
We were recently discussing the cost of connecting to the internet.  Someone
mentioned a magic number of $100 per month to connect to the net.  The lowest
price I had found at the time was a SLIP connection to PSInet for $250.

We'll David Smith from PSI gave me a call earlier this week to let me know, due
to some cost reductions in hardware, they will be offering SLIP connections to
PSInet for $150 a month.  This deal will only last until the end of the year
though.   I suppose they are testing the water to see if price really does
effect their market.

Anyway, we are definitely going with PSInet.  The Atlanta POP will be up
sometime in January and I can let you everyone know what SLIPing is like
on the internet.

The only bad aspect of SLIPing I can see so far is that PSInet will not call
us when they see packets with our address in them.  However, our LAN will
call PSInet because we're using a NetBlazer.

One other item: PSI says we will not have a constant IP #.  It supposedly
changes each time we establish a connection with them.  However, our address
will remain constant (probably searchtech.com).  I'm hoping this will not cause
too many problem with our local setup, but I guess we're going to find out!

---
Michael R. Almond (Georgia Tech Alumnus)           mra@srchtec.uucp (registered)
search technology, inc.				        emory!stiatl!srchtec!mra
Atlanta, Georgia                                         (404) 441-1457 (office)
[search]: Systems Engineering Approaches to Research and Development
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 90 00:11:53 GMT
From:      zaphod.mps.ohio-state.edu!think.com!barmar@tut.cis.ohio-state.edu  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when conencting to an internet
In article <3768@stl.stc.co.uk> neil@stl.stc.co.uk () writes:
>So, for example I have network 128.199, I could have an authorisation
>file like:-
>
># Source		Dest		Comment
># host.port		host.port
>
>*.smtp			mymailgw.smtp	Mail service inbound
>mymailgw.smtp		*.smtp		Mail service outbound
>128.199.200.*.ftp	*.ftp		FTP
>128.199.200.*.telnet	*.telnet	Telnet

The source port for connections is generally *not* the protocol's
well-known port.  The well-known port is normally only used as the
destination port.  The source port is usually a random port above 1024.

>Is this possible, or are we thinking in completely the wrong way ?
>At this stage it isn't necessary that the device exists in the UK,
>we can import if necessary.

cisco Gateway Servers can do packet filtering based on addresses and port
numbers.

>We also have an eye on the future, so the Vendor would need to offer
>support for OSI protocols.

cisco supports OSI protocols, although it doesn't yet seem to support them
in its filtering specifications.  It will probably come at some time,
thoug.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 90 00:56:42 GMT
From:      sdcc6!jclark@ucsd.edu  (John Clark)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Access Costs (or SLIPped connections)
In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes:
>We were recently discussing the cost of connecting to the internet.  Someone
>mentioned a magic number of $100 per month to connect to the net.  The lowest
>price I had found at the time was a SLIP connection to PSInet for $250.

I have some questions about PSInet. Does anyone know the answer to
the following:

1) Does it exist in Southern California?
2) If it does are there one time charges and then monthly plus
     connect charges?
3> Does one's SLIPped Internet number change from one connect to another.
    Or can one have an assigned Internet number for Mail etc.
-- 

John Clark
jclark@ucsd.edu
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Nov 90 10:22:43 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        sdcc6!jclark@ucsd.edu (John Clark)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Access Costs (or SLIPped connections)

 In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes:
 >We were recently discussing the cost of connecting to the internet.  Someone
 >mentioned a magic number of $100 per month to connect to the net.  The lowest
 >price I had found at the time was a SLIP connection to PSInet for $250.

 I have some questions about PSInet. Does anyone know the answer to
 the following:

 1) Does it exist in Southern California?

LA

 2) If it does are there one time charges and then monthly plus
      connect charges?

One time charge of $150.

 3> Does one's SLIPped Internet number change from one connect to another.
     Or can one have an assigned Internet number for Mail etc.

Mail is handled by {uucp,pcmail,pop} protocols and MX records, its
not an issue.

 John Clark
 jclark@ucsd.edu
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 90 03:20:35 GMT
From:      cs.utexas.edu!usc!jerico.usc.edu!kmeyer@tut.cis.ohio-state.edu  (Kraig R. Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when conencting to an internet
In article <3768@stl.stc.co.uk>, neil@stl.stc.co.uk writes:
|>...We wish to reduce the risk of unwanted external vistors
|>as far as possible, whilst allowing our internal users access to other
|>hosts.
|>
|>One possibility is to acquire a device to sit between our backbone and
|>the outside world. This device would be programmable so that I could
|>authorise connections on a per host, per port, per direction basis.

Depending on how much isolation you want from the outside world, another
option (besides using filtering at the TCP/IP level in a router) is to
use a unix box as an application level gateway.  This is definitely an
inconvenience to your users, which may or may not be a good thing depending
on what your isolation goals are and how paranoid you are.

For example, you can configure sendmail to forward mail in both directions
and then only give accounts on the gateway unix machine to those people who 
you want to allow ftp/telnet/etc access to the outside network.  That makes
access on a per-person basis, rather than on a per-IP-address basis.
Filtering in the way you've described would not, for example, prevent an
internal user from spoofing IP addresses (if that is an issue).
---------------------------------------------------------------------------
| Kraig R. Meyer		   		          kmeyer@usc.edu  |
| University of Southern California                          Los Angeles  |
---------------------------------------------------------------------------
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      25 Nov 90 23:26:00 EST
From:      "Jerry Damian" <damian@srlvx0.srl.ford.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Reducing the risks when connecting to an internet
In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to
filter on specific IP services such as TELNET, SMTP, FTP, etc. 

You can use Cisco routers to do this quite effectively. You can use their
extended access controls to filter on source and destination address as
well as port number. However, be aware that the Cisco ability to process
packets without dropping any is proportional to the size of the access
list. You can minimize the size of the lists by permitting/denying packets
by subnet rather than by IP address. Better to put this burden on a router
than a host that is probably used for something else...

Jerry Damian
Ford Motor Co.
damian@srlvx0.srl.ford.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 11:22 -0800
From:      <ken@cs.sfu.ca>
To:        tcp-ip@nic.ddn.mil
Subject:   R
please remove my name from your mailing list
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 7:05:23 PDT
From:      anthony@nms.hls.com (Anthony Chung)
To:        tcp-ip@nic.ddn.mil
Subject:   TELNET Option
Hughes LAN System Terminal server will negotiate TELNET option 222
to find out if the remote host is also Hughes LAN System Terminal server.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 7:54:07 PDT
From:      anthony@nms.hls.com (Anthony Chung)
To:        tcp-ip@nic.ddn.mil
Subject:   TELNET ECHO option negotiation
Most of TELNET implementations have implemented TELNET echo option correctly.
But, interfaces between TELNET and applications which use TELNET are not 
implemented correctly.

Echo may come from applications even TELNET WON't ECHO. For examples:

   1. A word processor software which interfces with TELNET layer may
      not know about result of ECHO negotiation.

   2. A host may not know anything about TELNET negotiations when 
      TELNET code resides in a intelligent  Ethernet controller.

   3. A host does not even know about TELNET when it connnects
      to a TCP/IP terminal server over RS232.

These problems exist for other options too, such as Binary option.
I think all these problems are local implementation issue. 

I also have found problem which some TELNET implementations do not follow
TELNET End-Of-Line convention.  I also found SUN OS(at least version 4.0.3)
still expects Supress Go Ahead negotiation to get out line mode. "Host
Requirements" RFC specifies that server TELNET SHOULD NOT support sending
GA commands. Sometimes I wonder that I should follow RFC or not.

 
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 09:11:56 PST
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil, uakari.primate.wisc.edu!samsung!munnari.oz.au!uniwa!nodecg!adrienne@ames.arc.nasa.gov
Subject:   Re:  Telnet option negotiation


Re: Telnet Options

Please see RFC 1060 page 51 for a list of Telnet Options and pointers to the
other RFC that document them.

--jon.
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 11:13:24 -0600
From:      dab@berserkly.cray.com (David Borman)
To:        eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun7!conti@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option

Before things get out of hand, here is some clarification about the
telnet ECHO option.  The response to the original question is WRONG!!!.

From the original questions:

>  (1) If I send a DO ECHO and receive a WILL ECHO, I expect the host to echo
> each character I send to them.

This is exactly correct.

>  (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive
> an echo for each character sent.

This is also exactly correct.

>  Part (1) above seems to fit properly.  If I send the DO ECHO, the host
> happily echos everything back to me.  However, part (2) doesn't seems to
> always apply -

The only reason that either part (1) or part (2) would not work is due
to a broken telnet implementation.

Now for some clarification about how the telnet ECHO option shoule be
used, in the typical "terminal/client to server".

First, there are two pieces of information involved: 1) should the
users typed data be echoed to the users screen, and 2) is the server
WILL ECHO or WONT ECHO.

	1) The connection should NEVER be WILL ECHO in both directions.
	   In the typical terminal/client to server application, there
	   is no need for the client to ever be WILL ECHO.

	2) When the server is WONT ECHO, then if the users typed data
	   is to be echoed to the users screen, then that has to be
	   done locally on the server side.

	3) If the server is WILL ECHO, then the telnet client should
	   not do any local echo of the users typed data, as the remote
	   server will be echoing any data that needs to be echoed;
	   if the client continues to do local echo, the user would
	   see double echo of the typed characters.

	4) When the server is WILL ECHO, it is not required to echo
	   the incoming data verbatim, it may chose to not echo some
	   of the data (like passwords) or may chose to echo data in
	   a different format (like control characters as a two character
	   sequence, e.g. "^A").

These diagrams represent the typical UNIX environment; your milage
may vary.  The "(tty)" and "CLIENT" boxes, and the "SERVER", "(pty)"
and "Application" boxes may be combined as appropriatly for different
systems, but the basic concept remains the same.  The double-dashed
line is the path where both normal data and echoed data is flowing.
It is assumed that the users data is to be echoed.

Server WONT ECHO:

	             (tty) CLIENT       SERVER (pty) Application
	            +-----+------+     +------+-----+---------+
	            |     |      |     |      |     |         |
	terminal  ->|--+->|----->|---->|----->|---->|->(read) |
	            |  |  |      |     |      |     |         |
	            |  |  |      |     |      |     |         |
	            |  V  |      |     |      |     |         |
	screen    <=|==+--|<-----|<----|<-----|<----|<-(write)|
	            |     |      |     |      |     |         |
	            +-----+------+     +------+-----+---------+

Server WILL ECHO:
	             (tty) CLIENT       SERVER (pty) Application
	            +-----+------+     +------+-----+---------+
	            |     |      |     |      |     |         |
	terminal  ->|---->|----->|---->|----->|--+->|->(read) |
	            |     |      |     |      |  |  |         |
	            |     |      |     |      |  |  |         |
	            |     |      |     |      |  V  |         |
	screen    <=|=====|<=====|<====|<=====|==+--|<-(write)|
	            |     |      |     |      |     |         |
	            +-----+------+     +------+-----+---------+

If the client was ever WILL ECHO (sever WONT ECHO), you would have
something like:

	             (tty) CLIENT       SERVER (pty) Application
	            +-----+------+     +------+-----+---------+
	            |     |      |     |      |     |         |
	terminal  ->|---->|---+=>|====>|=====>|====>|=>(read) |
	            |     |   ^  |     |      |     |         |
	            |     |   |  |     |      |     |         |
	            |     |   |  |     |      |     |         |
	screen    <-|-----|<--+--|<----|<-----|-----|<-(write)|
	            |     |      |     |      |     |         |
	            +-----+------+     +------+-----+---------+

which would not be very useful.

		-David Borman, Chair of the IETF Telnet Working Group
		dab@cray.com
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 04:26:00 GMT
From:      damian@SRLVX0.SRL.FORD.COM ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   Reducing the risks when connecting to an internet

In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to
filter on specific IP services such as TELNET, SMTP, FTP, etc. 

You can use Cisco routers to do this quite effectively. You can use their
extended access controls to filter on source and destination address as
well as port number. However, be aware that the Cisco ability to process
packets without dropping any is proportional to the size of the access
list. You can minimize the size of the lists by permitting/denying packets
by subnet rather than by IP address. Better to put this burden on a router
than a host that is probably used for something else...

Jerry Damian
Ford Motor Co.
damian@srlvx0.srl.ford.com

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 11:23 CDT
From:      "Kevin W. Mullet, Univ. of N. Tx" <SNMS4@vaxb.acs.unt.edu>
To:        cisco@spot.colorado.edu, protocols@rutgers.edu, tcp-ip@nic.ddn.mil, pcip@udel.edu
Subject:   IP Routing information needed

         I'm looking for as many on-line documents available through
         BITNET or the Internet reguarding IP Routing as possible. 
         Any suggestions about appropriate RFCs, IENs,
         newsgroup/mailing list archives, Postscript docs, etc., would
         be greatly appreciated.  

                          (time is of the essence.)

         As usual netiquette dictates, please reply directly to me and
         I'll post a summary to the net if I get any substantive
         replies.

         Beau coup thanks in advance,
         -Kevin Mullet
          University of North Texas
          Internet: snms4@vaxb.acs.unt.edu
          BITNET:   snms4@untvax
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 12:32:00 EST
From:      "Jerry Damian" <damian@srlvx0.srl.ford.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Re: Reducing the risks when connecting to an Internet

Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree completely
with all comments regarding host based security rather than network
imposed security. However, that is often not possible due to the internal
politics of an enterprise network and who administers its hosts. The majority
of hosts on my internet are administered by engineers NOT network managers
or systems programmers. The reality of my situation is that I cannot dictate
how individual hosts are to be configured because I do not own them. Yes,
this does lead to MANY problems... Limiting the visibility of an internet via
router/bridge filtering will buy time until you can get the job done right.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 09:42:37 GMT
From:      eru!hagbard!sunic!mcsun!ukc!tcdcs!swift.cs.tcd.ie!ccvax.ucd.ie!t_wade@bloom-beacon.mit.edu  (Tom Wade, VMS Systems)
To:        tcp-ip@nic.ddn.mil
Subject:   domain ordering brings down British Leader (:-))

	British Prime Minister quits over Domain Ordering.
			UPI 22-Nov-1990

In a dramatic twist to the "big-endian/little-endian" controversy raging
on the European networks, the British Prime Minister Thatcher Margaret
today announced that she is standing down as leader of the Conservative
Party and government.  After weathering many storms in which She Stood Alone
against the European hordes on Exchange Rate Mechanism, European Monetary
Union, European Political Union and German Reunification, the final straw
was the insistence that the UK maintain its network addressing structure
exactly the opposite way around from everyone else.  Speaking from no 10,
Downing Street (known within the UK of course as "Street Downing, 10"),
she announced that she would quit rather than adopt the Internet standard.

"We have our traditions and our standards", she said, "and though they are
at variance with everyone else, I believe that it is the rest of the world
that has got it wrong".

Heseltine Michael, the man who put himself forward for the leadership would
not confirm whether he would reverse the domain ordering if he were to
succeed the Prime Minister, but it is well known that the decisive factor
in his decision to stand was the many letters he received from domainless
sources in Austria, urging him to "reverse the anti-European trend at the
top".

The JNT, who devised the UK addressing standard (Advanced Retroactive
System for Expressing Worldwide Addresses in Yellowbook Standard or
ARSEWAYS) were not available for comment; our requests for statements
meeting with non-delivery messages in Czechoslovakian.

------------------------------------------------------------------------------
Tom Wade            |  Internet:    T.Wade@cc.ucd.ie  (all domain mailers).
Speaker To VAXes    |  Bitnet:      T_WADE@CCVAX
EuroKom             |  PSI-Mail:    PSI%27243154000712::T.WADE
University College  |  DEC EASYnet: DECWRL::"t.wade@cc.ucd.ie"     (VMS Mail)
Belfield            |  JANET:       t.wade%ie.ucd.cc@UK.AC.EARN-RELAY
Dublin 4            |  X400:        [Address Exceeds 65536 byte buffer]
Ireland             |  Telex:       (0500) 91178 UCD EI  ("TO: WADE" at start)
--------------------+---------------------------------------------------------- 
Voice: +353-1-697890|  Official Disclaimer:  "This is not a disclaimer"
Fax:   +353-1-838605|
-------------------------------------------------------------------------------

------------------------------------------------------------------------------
Tom Wade            |  Internet:    T.Wade@cc.ucd.ie  (all domain mailers).
Speaker To VAXes    |  Bitnet:      T_WADE@CCVAX
EuroKom             |  PSI-Mail:    PSI%27243154000712::T.WADE
University College  |  DEC EASYnet: DECWRL::"t.wade@cc.ucd.ie"     (VMS Mail)
Belfield            |  JANET:       t.wade%ie.ucd.cc@UK.AC.EARN-RELAY
Dublin 4            |  X400:        [Address Exceeds 65536 byte buffer]
Ireland             |  Telex:       (0500) 91178 UCD EI  ("TO: WADE" at start)
--------------------+---------------------------------------------------------- 
Voice: +353-1-697890|  Official Disclaimer:  "This is not a disclaimer"
Fax:   +353-1-838605|
-------------------------------------------------------------------------------
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 16:07:02 CST
From:      "A. Meg Brady, Mgr. of User Services" <C0017@UMRVMB.UMR.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Internet library guide - additions requested
Can I assume you want me to send them our info for accessing LUMIN
through the Internet?

Meg
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 10:10:09 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cs.columbia.edu!close.columbia.edu!ji@ucsd.edu  (John Ioannidis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when connecting to an internet
In article <9011260544.AA01255@ucbvax.Berkeley.EDU> damian@SRLVX0.SRL.FORD.COM ("Jerry Damian") writes:
>In article <3768@stl.stc.co.uk> neil@stc.co.uk is looking for a way to
>filter on specific IP services such as TELNET, SMTP, FTP, etc. 
>
>You can use Cisco routers to do this quite effectively. You can use their
>extended access controls to filter on source and destination address as
>well as port number. However, be aware that the Cisco ability to process

And remember that this should only be a temporary measure, while you
plug holes in your individual hosts. Do not get lulled into a false
sense of security. Protections and security should be enforced at the
host level. If you suspect that your networking daemons are buggy, get
your vendors (or your systems programmer) to fix them. 

/ji

PS: Hi Phil!

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
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Nov 90 12:02:54 GMT
From:      bushell@hawk.nstn.ns.ca (Tom Bushell)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP modem autodialing and idle line detection

Hello,

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

I've been able to dial the modem from Phil Karn's KA9Q using the "tip"
command, but we want to automate this process for our dial in customers,
so they just run their applications (Telnet, FTP, whatever) and the
connection will be automatically established.

We have three main requirements:

1) Must be able to automatically establish a SLIP connection over a modem.

2) Must be able to automatically accept an IP number assigned by the
terminal server being dialed into, and run public domain applications like
KA9Q and NCSD Telnet with this IP number.

3) To try to minimize connect charges for the users, we want to monitor the
line for user activity, and drop it after a specified period if there is none,
even if
he/she is still in the application.  We want to reconnect when activity is
detected.


I'm currently in the process of coding to solve #1 and #2.  Our approach is
to use a standalone C program to establish a connection, get the IP number
from the terminal server, and use it to modify the configuration file for
NSCA Telnet.  I'll probably have this working soon, but if someone were
to hand me an existing solution on a silver platter, I'd be happy to take it.

Requirement #3 looks like a bit of a bitch.  Looks like we'll have to write
a TSR that grabs the PC's system timer, and decrements a counter for the
line idle timeout.  If this counter reaches 0, the line is dropped.  We'll also
have to modify the SLIP packet driver so it resets this counter every time
a packet is sent by the user.


My questions are:

Is this a good approach to meet our three requirements?

Has anyone out there already met any or all of these goals?  

If so, can you share what you did?  


Thanks in advance to all who take the time to reply.  I will post response
to the net if interest is sufficient.  As an incentive to code sharing, I've been
given tenative permission to make the code I'm working on available.


Thanks

Tom


*************************************************************
*  Tom Bushell                            Software Kinetics Ltd  *
*                                         101 Ilsley Ave         *
*  E-mail - bushell@hawk.nstn.ns.ca       Suite 5                *
*  Phone (902)468-3680                    Dartmouth N.S., Canada *
*  Fax   (902)468-3679                    B3B 1S8                *
*************************************************************
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 15:10:17 GMT
From:      sdd.hp.com!samsung!know!pluto.hemel.bull.co.uk!pmoore@ucsd.edu  (Paul Moore)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when connecting to an internet
ji@close.columbia.edu (John Ioannidis) writes:
>And remember that this should only be a temporary measure, while you
>plug holes in your individual hosts. Do not get lulled into a false
>sense of security. Protections and security should be enforced at the
>host level. If you suspect that your networking daemons are buggy, get
>your vendors (or your systems programmer) to fix them. 

Gosh, I am glad to see somebody making that point, ("security is a host
problem not a net problem"). There is an almost Pavlovian response to
networks.
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 16:13:38 GMT
From:      att!mcdchg!ddsw1!bbs!karl@ucbvax.Berkeley.EDU  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Tn3270 with option code 0x11 - Write Structured Fields
Hi there!

We have grabbed the tn3270 off of UUNET, and gotten it to compile.

Now we have a problem -- the tn3270 we have here doesn't support the write
command 0x11, which is "Write structured field".  The tn3270.h file does
have this definition in it, but there is no code to back it up.

Does anyone have a tn3270 which supports this?  Our mainframe is rather
insistant about sending these commands....

Any help appreciated.
---

Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 16:23:00 GMT
From:      SNMS4@VAXB.ACS.UNT.EDU ("Kevin W. Mullet, Univ. of N. Tx")
To:        comp.protocols.tcp-ip
Subject:   IP Routing information needed


         I'm looking for as many on-line documents available through
         BITNET or the Internet reguarding IP Routing as possible. 
         Any suggestions about appropriate RFCs, IENs,
         newsgroup/mailing list archives, Postscript docs, etc., would
         be greatly appreciated.  

                          (time is of the essence.)

         As usual netiquette dictates, please reply directly to me and
         I'll post a summary to the net if I get any substantive
         replies.

         Beau coup thanks in advance,
         -Kevin Mullet
          University of North Texas
          Internet: snms4@vaxb.acs.unt.edu
          BITNET:   snms4@untvax

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 17:32:00 GMT
From:      damian@SRLVX0.SRL.FORD.COM ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   Re: Reducing the risks when connecting to an Internet


Referencing <1990Nov26.151017.2023@hemel.bull.co.uk>. I agree completely
with all comments regarding host based security rather than network
imposed security. However, that is often not possible due to the internal
politics of an enterprise network and who administers its hosts. The majority
of hosts on my internet are administered by engineers NOT network managers
or systems programmers. The reality of my situation is that I cannot dictate
how individual hosts are to be configured because I do not own them. Yes,
this does lead to MANY problems... Limiting the visibility of an internet via
router/bridge filtering will buy time until you can get the job done right.

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 19:45:18 GMT
From:      swrinde!mips!twg.com!david@ucsd.edu  (David S. Herron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SCO TCP/IP and E-Mail Problems
[Cross-posted & followups-to comp.mail.misc since this isn't TCP/IP specific]

In article <9011190759.aa12077@ssmct62.ssc.af.mil> hutch@ssmct62.ssc.af.mil ("Capt E. Lee Hutchins") writes:
>	MMDF is the supported mail system for SCO UNIX.  MMDF does not come 
>with an ideal set of documentation.  (At least I
>can't make heads or tails out of it).  If any one has some ideas on Docs for 
>this system which are NOT in troff form I'd appreciate them.  Configuring MMDF
>without real documentation is a real *&^%$!

Yes, I agree .. that would be rather hard.

Docs for MMDF IIb update 43 (as well as sources) are available via
anonymous ftp from louie.udel.edu.  Both uunet.uu.net & gatekeeper.dec.com
keep the sources available.  I don't remember path names, but it was pretty
obvious ..

There's two mailing lists you should be interested in:

eurmmdf@zweibrucken-emh1.army.mil

	is Army people (I suppose that since they let me be on the
	list, they'll let Air Force people be on it ;-)) working with
	MMDF.  Though the discussion seems to be more generic Unix
	problems than MMDF problems ..

	eurmmdf-request@zweibrucken-emh1.army.mil, of course, for administrivia

mmdf2@relay.cs.net

	The "official" mailing list for MMDF support.  It manages to
	focus on MMDF pretty well.

	mmdf2-request@relay.cs.net, of course, for administrivia

>	I can recieve mail from other UNIX platforms, but we have another 
>mail system running which is based on 10NET, called "COURIER MAIL".  It has 
>an "SMTP" gateway working and other UNIX boxes (AT&T 3B2 600G's) can 
>receive and send mail fine.  My box on the other hand, does
>not work with it.  The mail ends up in a queue on the "COURIER SERVER" and is 
>never returned to me or the originator.  Anybody ever experienced this????  

This sounds like the "no background deliver" as described below ..

>	By the way my machine does not always accept:
>
>	telnet machinename.domain 25
>
>When tried manually from other hosts it often closes the connection before it
>askes for the identification.  

The MMDF SMTP server can be configured to do this if the IP address
does not have a known IP->host_name mapping.  Usually, though, it's
configured to give the "foo, you are a charlatan" message ..

>In fact it seems the more mail sent to my 
>machine, the less I actually receive.  I am on *several* mailing lists and I
>expected my mail volume to be much higher than it is.

This sounds like the SCO fumble where they made some bad suggestions
in their manuals.  Specifically -- that channels be configured for
"immediate" delivery & that no deliver daemon be run to handle
background delivery.  Theoretically it sounds nice .. if it gets
delivered immediately then it doesn't make sense to have a deliver
running since it will "never" see any mail.  But in practice -- if
lots of mail arrives at once -- then some of the messages will drop
into a queue and then never get delivered.

This is especially noticeable with the local channel.  If the
mailbox is locked (for instance, it's being delivered to by another
local channel process) the channel will exit with a "temporary
failure" status & the deliver controlling that channel will go
away.  The assumption was that a background channel would take up
the slack.  Rather than simply wait around for a little while --
you don't know how long this "temporary" condition will exist --
exiting works given a background deliver.

But SCO recommended *against* using a background deliver.  Fortunately
they've seen the error of their ways and currently suggest using
"mod=reg", which pushes all delivery through the background deliver,
and run

	deliver -b -clocal &
or	deliver -b -clocal,list,uucp,smtp &

In update 43 you can abbreviate that to

	deliver -b -c &

and that daemon will work with *all* channels in the system.

>	Finally, one other tidbit, I am running the latest version of "ELM" as
>my front end to mail.

This shouldn't make any difference -- unless ELM keeps the mailbox locked
all the time.

-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Use the force Wes!
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 20:50:16 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
In article <1990Nov26.162533.5418@engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes:
   Does anybody have a version of SLIP or PPP with SLFP (Serial Line
   Framing Protocol) support in it?  Merit ... does SLFP.

Is SLFP HDLC?  If not, is SLFP documented in a readily-accessible
place?  RFC1171 (section 3) specifies that PPP uses HDLC-style framing
unless LCP negotiates otherwise.  Is it PPP if it's not basically
HDLC?
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 11:22:12 -0800
From:      dot12@okeeffe.Berkeley.EDU (P1003.12 Committee)
To:        tcp-ip@nic.ddn.mil
Subject:   Your Chance to Influence POSIX!
The POSIX process-to-process communications working group (P1003.12)
would like to solicit outside comment.

The committee wishes to publish an interface at the level of exposed
detail exhibited by both sockets and XTI.  Previously, the committee
had been of the opinion that although both sets of existing practice
were relatively similar, each had technical flaws.  Furthermore,
each had a user community unwilling to give theirs up and adopt
the other.

The working solution the commitee had been pursuing was to combine
the the best features of the two interfaces, changing the names and
semantics of the primitives, so that some amount of re-coding would
be necessary.  The committee was using as its model the level of
modification done to the job control and termios facilities of P1003.1

There has recently been vociferous opposition to this plan, arguing
that vendors would have to support THREE interfaces (sockets, XTI
and POSIX) and it would be better to have the P1003.12 committee
issue IEEE standard versions of the existing two, with possible
backwards compatible extensions and improvements.

We invite you to submit your reactions to dot12@okeeffe.Berkeley.EDU
for consideration by the committee.  It would be helpful to some of us
if you would say something about your background or experience with
either of XTI or sockets.

(Please note that comments sent only to the tcp-ip mailing list may
not necessarily be forwarded to the committee).
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      26 Nov 90 23:38:48 GMT
From:      unmvax!nmt.edu!nraoaoc@ucbvax.Berkeley.EDU  (NRAO Array Operations Center)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Access Costs
In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes:
>[...]
>One other item: PSI says we will not have a constant IP #.  It supposedly
>changes each time we establish a connection with them.  However, our address
>will remain constant (probably searchtech.com).  I'm hoping this will not cause
>too many problem with our local setup, but I guess we're going to find out!

Say what?????

I fail to see how this can be the case. Granted they can change their tables
any time they want, *but* they have the following restrictions:

     a) they have to use an Internet number assigned to them/you by the NIC
     b) the rest of the Internet has to understand the routing (if it's
        advertised, and if it isn't no-one can reach you)
     c) your system has to know *before establishing the connection* what
        its own Internet address is

Are you sure that they meant your "IP #" changes? If you are connecting
through SLIP, then your circuit number might change each time, depending
how many other connections are being made at the same time. But your own
actual Internet address should stay the same.

Even if it *could* be done, it would be such an administrative nightmare
trying to figure out "who's 123.456.789.10 this morning?" that I can't think
why they *would* do it.

I dunno, maybe the connections are volatile enough that they just assign an 
IP address in sequence or something every time a connections comes up, but
it sounds pretty weird to me.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                    Socorro NM
                            rmilner@zia.aoc.nrao.edu
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 00:46:21 GMT
From:      milton!Tomobiki-Cho!mrc@beaver.cs.washington.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option
In article <1191@disuns2.epfl.ch> conti@ltisun7.epfl.ch (Giovanni Conti) writes:
>I think there is a need to explain the WILL/WONT mechansim.

Yes, someone should explain it to you, since not only don't you
understand it, but worse, you don't know that you don't understand it
and you are spreading misinformation.  Please don't do so in the
future.  There are enough people around here who have written Telnet
software -- I've written several servers and clients for different
operating systems, going back to 1976 -- who can answer Telnet protocol
questions correctly.

The Telnet ECHO option, in a server/client environment, refers to
echoing done by the server of data from the client back to the client.

In other words, it is only meaningful for a client to send:
	IAC DO ECHO	(requesting/confirming that the server echo)
	IAC DONT ECHO	(demanding/confirming that the server not echo)
and for a server to send:
	IAC WILL ECHO	(requesting/confirming that it will echo)
	IAC WONT ECHO	(refusing/confirming that it will not echo)

In a bilateral Telnet (e.g. station-to-station) where there is no clear
server or client than it may be reasonable for echoing in both
directions.

>The ECHO is LOCAL. So if you ask your partner to do echo,
>he will duplicate his output stream (from him to you) onto
>his input stream.

Totally wrong.  The Telnet ECHO option controls remote echoing; local
echoing is only implicit.  An echo is never "a duplication by an agent
of his output stream onto his input stream."  An echo is a "duplication
by an agent of his input stream onto his output stream."

>If you ask the host to do ECHO, and assuming he answers WILL ECHO,
>that means that when he sends you the string "Username:", telnet echoes
>him a copy as if you've typed "Username:", leading to wrong behaviours.

No, no, no, 1000 times no.  That is what "IAC WILL ECHO" from the
Telnet client means.

I didn't see the original question, but it seems that you have sent
some poor guy on a wild goose chase.

 _____   | ____ ___|___   /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
 _|_|_  -|- ||   __|__   /  / R90/6 pilot, DoD #0105  "Gaijin ha doko?"
|_|_|_|  |\-++-  |===|  /  /  Atheist & Proud         "Niichan ha gaijin."
 --|--  /| ||||  |___|    /\  (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
  /|\    | |/\| _______  /  \ FAX: (206) 543-3909     "Iie, boku ha nihonjin."
 / | \   | |__|  /   \  /    \MRC@CAC.Washington.EDU  "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 09:49:15 PLT
From:      "Michael J. Irvin, WSU, 509/335-0437" <IRVINMJ@WSUVM1.CSC.WSU.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: domain ordering brings down British Leader (:-))
THAT explains it!
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 03:45:48 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   Fixed IP addresses ( Was Re: Internet Access Costs )
In article <1990Nov26.233848.20828@nmt.edu> rmilner@zia.aoc.nrao.edu (Ruth Milner) writes:
>In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes:
>>[...]
>>One other item: PSI says we will not have a constant IP #.  It supposedly
>>changes each time we establish a connection with them.  However, our address
>>will remain constant (probably searchtech.com).  I'm hoping this will not cause
>>too many problem with our local setup, but I guess we're going to find out!
>
>Say what?????
>

From what the original poster has described, I suspect PSI is using 
the same terminal server as CERFnet uses for its dial up Internet 
Access Service, DIAL n' CERF . ( from cisco Systems)

>I fail to see how this can be the case. Granted they can change their tables
>any time they want, *but* they have the following restrictions:
>
>     a) they have to use an Internet number assigned to them/you by the NIC

The address assigned to the calling party is one on the subnet on 
which the terminal  server resides. The network address is indeed
one assigned by SRI-NIC. 

>     b) the rest of the Internet has to understand the routing (if it's
>        advertised, and if it isn't no-one can reach you)

See above. The route to the subnet/net is advertized to the rest
of the Internet .

>     c) your system has to know *before establishing the connection* what
>        its own Internet address is
>

Not true. Your system has to know its IP address before
estabilishing a *IP* connection. However, for example on a cisco
terminal server, you may use BOOTP over the dial up connection to
determine your IP address.

>Are you sure that they meant your "IP #" changes? If you are connecting
>through SLIP, then your circuit number might change each time, depending
>how many other connections are being made at the same time. But your own
>actual Internet address should stay the same.
>
>Even if it *could* be done, it would be such an administrative nightmare
>trying to figure out "who's 123.456.789.10 this morning?" that I can't think
>why they *would* do it.
>

There are ways to log correspondences between port numbers, IP numbers
and user names. You can then use unix utilities like "last" etc
on this data to find out who is what this morning. Not too difficult.

I can't answer for PSI but here is why CERFnet does this.

Dial-Up services are primarily targeted at  the occasional user.
Where IP address spaces are limited, it makes sense to recycle
addresses from a small pool. This is not a problem for outgoing
FTP or Telnet connections but it does make SMTP mail difficult. 
However as has been pointed out earlier , there are ways to get over 
this problem (UUCP, POP etc ) 

(In any case if you cannot do without an IP address of your own, with
DIAL n' CERF it is possible to dynamically assign a password protected
legal IP address of your choice .)

Remember, the above applies to the occasional user.If someone is using
their Internet connection often they should consider a
( perhaps slow speed ) leased line connection where their line
would be hard wired into a port on the terminal server with a fixed
IP address with the " same subnet  as terminal server " proviso
mentioned earlier. However pricing issues come into play here.

>I dunno, maybe the connections are volatile enough that they just assign an 
>IP address in sequence or something every time a connections comes up, but
>it sounds pretty weird to me.
>-- 

I think you have the "gateway server model" of SLIP in mind where
each end of the link has two different addresses and you can have a
IP network at the remote end whose reachability may be advertized over 
the serial link. The services described above use the " terminal server
model " of SLIP (cisco jargon) where there can only be *one* host
and *one* IP  address at the remote end. This host then appears to operate
as a host on the same subnet as the terminal server. If the terminal
server is on an ethernet, the remote host appears to the rest of the
world as also on the same ethernet. 

There are terminal servers available in the market which follow
the "gateway server model" on the dial-up link. So most of the 
above decribed features have come about because of the choice
of terminal server provided by a rather popular vendor.


>Ruth Milner
>Systems Manager                     NRAO/VLA                    Socorro NM

--pushpendra
----------------------------------------------------------------------
Pushpendra Mohta
Network Co-ordinator
CERFNet
1-800-876-CERF
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 04:17:42 GMT
From:      usc!wuarchive!zaphod.mps.ohio-state.edu!samsung!umich!sharkey!ionic!gm@ucsd.edu  (Greg Miller)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option
In article <1191@disuns2.epfl.ch>, conti@ltisun7.epfl.ch (Giovanni Conti) writes:

> In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes:
 {Parts of my previous question deleted}
>
> I think there is a need to explain the WILL/WONT mechansim.
> The ECHO is LOCAL. So if you ask your partner to do echo,
> he will duplicate his output stream (from him to you) onto
> his input stream. That means that a UNIX system doing Telnet echo
> and sending you a "Username:" string will also read the same string
> in its input stream. So obviously, the UNIX system never does Telnet
> echo locally. On the other side, you (e.g. the terminal) are expected
> to do some local echo of the keyboard input to the screen (echo
> your input stream to your output stream). If the system does not
> want you to do that (e.g. when you type the password), it tells
> you DONT ECHO, which means "Just send me the characters, I will echo
> back what I think is reasonable". In that case you do not
> echo the characters locally on your screen.
>
> If you ask the host to do ECHO, and assuming he answers WILL ECHO,
> that means that when he sends you the string "Username:", telnet echoes
> him a copy as if you've typed "Username:", leading to wrong behaviours.
>
> So don't tell the host to do local echo (local to him) if you are
> a Telnet Client (or unless you know exactly what you're doing).

 Here's the important piece of RFC 857:

 - cut -

2. Command Meanings

   IAC WILL ECHO

      The sender of this command REQUESTS to begin, or confirms that it
      will now begin, echoing data characters it receives over the
      TELNET connection back to the sender of the data characters.

   IAC WON'T ECHO

      The sender of this command DEMANDS to stop, or refuses to start,
      echoing the data characters it receives over the TELNET connection
      back to the sender of the data characters.

   IAC DO ECHO

      The sender of this command REQUESTS that the receiver of this
      command begin echoing, or confirms that the receiver of this
      command is expected to echo, data characters it receives over the
      TELNET connection back to the sender.

   IAC DON'T ECHO

      The sender of this command DEMANDS the receiver of this command
      stop, or not start, echoing data characters it receives over the
      TELNET connection.

 - cut -

 Calling my system the "client", the remote system (a BSD system) the
"host", and using the above chunk of the RFC:

 My sending a DO ECHO should request that the host begin echoing all data
characters it receives back to the sender (me).

 A reply of WILL ECHO should stand as a confirmation that the host will
indeed begin echoing all data characters back to the sender.

 I don't see how this creates the situation you described.  You claimed
that this would cause the host to echo it's output back into it's input
path (which infers an infinite loop).  That's the exact opposite of what
I interpret the above as stating.

>
> >
> >  (2) If I send a DON'T ECHO and receive a WON'T ECHO, I expect NOT to receive
> > an echo for each character sent.
> >
>
> So this is wrong. But fortunately, according to your request, the BSD host
> will not read in its input stream all the characters it sent to you.

 See above.

>
> >  Part (1) above seems to fit properly.  If I send the DO ECHO, the host
> > happily echos everything back to me.  However, part (2) doesn't seems to
> > always apply -
> >
>
> The fact of echoing everything back to you means:
>
> a) that you did not do local echo in the beginning (unless you received
>    all duplicated characters. So there is an error in your Telnet
>    implementation.
>
> b) That the Application echo (e.g. the login deamon on a host) has
>    NOTHING to do with your Telnet echo commands. In fact, the application
>    running on top of telnet (e.g. csh) may echo back things, asking
>    you first NOT to do local echo (so you receive a DONT ECHO from the host).
>
> Good luck

 Thanks.  I'm going to need it.

>
> Giovanni Conti
> Ecole Polytechnique Federale de Lausanne
> Laboratoire de Teleinformatique
> EL-Ecublens
> CH-1015 Lausanne
> Switzerland
> Tel   : +41 21 693.29.07
> FAX   : +41 21 693.46.60
> E-mail: conti@ltisun.epfl.ch


 One last comment - are you by chance reading the RFC from the perspective
of the host, rather than the client?  That would lead to the interpretation
that you gave.

 Thanks.

--
     +----------------------------------------------------------------+
     | A sign of mismanagement, over-    |  Greg Miller               |
     | complication and overall idiocy:  |  ..ames!sharkey!ionic!gm   |
     |                                   |  gm@ionic.uucp             |
     |      "Designed By Committee"      |                            |
     +----------------------------------------------------------------+
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 12:28:13 CST
From:      "David W. Dearth, Director" <C0001@UMRVMB.UMR.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Internet library guide - additions requested
No. It was for your information or for Terri or maybe Jean Eisenman.
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 11:48:19 EST
From:      BDK@unb.ca
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: routing in a subnet (come on all you wizards!)
On  Tue, 27 Nov 90 12:20:45 GMT  Paul Moore <zaphod.mps.ohio-state.
edu!know!pluto.hemel.bull.co.uk!pmoore @TUT.CIS.OHIO-STATE.EDU>
writes:
I think the route you have given boxb are insufficent. One simple
solution is to give boxb a default route:

route add default boxa 1

Another solution is to get boxb to listen to whatever routing info
(e.g RIP) is broadcast by boxa which is a router of some flavor (i.e
a UNIX box running gated or routed or a real router).

> I am trying to get the following to work and cannot, it seems it
> should to me. It is on Lachman and HP-UX.
>
> All this is on a class B net (123.456 for example). The net is
> subnetted on 8 bits ( a not uncommon situation , I imagine).
> Some boxes don't do RIP so I need static routing tables.
> I don't want a global default installed for security reasons.
>
> boxa knows where all the subnets are (123.456.1 , 123.456.2 etc)
>
> boxb is installed on 123.456.1 and I want to tell it that all 123.456
> traffic that it cannot reslove should go to boxa.
>
> so i do
>
> 	route add net 123.456 boxa 2
>
> The route installs OK but is ignored, I must do
> 	route add net 123.456.2 boxa 2
> 	route add net 123.456.3 boxa 2
> 	etc..
>
> Am I being stupid? Or what
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 15:33:48 PST (Tue)
From:      rlg@desktalkdesktalk.com (Richard L. Gralnik)
To:        tcp-ip@nic.ddn.mil
Subject:   Interoperating with HP
Hi gang,
We are on the verge of great things, but I figure I'm better off forewarned
so...

Does anyone have experience connecting a 

	Sequent (Dynix 3.0.17) 

to an 

	HP 3000 (MPE/V Delta 5) with
		HP's LANIC board and TCP/IP software
		Wollongong ARPA Services for MPE TCP/IP

I have been warned off telneting from the HP, but any other gotchas would
be appreciated. 

Also, we are going to try some print sharing from the HP and the Sequent to 
a serial printer on a Xyplex terminal server.  We are debating having both
systems print to the same port and using DTR/DSR to check port availability,
or using one machine as a print server and ftp'ing files to it from the second
machine with a script on the first to watch a spool directory for new print
files.  If anyone has any scripts for something like this, or ideas/suggestions
we'd appreciate it.

Thanks,
Richard
rlg@biobio.desktalk.com
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 10:33:41 GMT
From:      eru!hagbard!sunic!mcsun!cernvax!chx400!sicsun!disuns2!ltisun!conti@bloom-beacon.mit.edu  (Giovanni Conti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option

In article <gm.3508@ionic.UUCP> gm@ionic.UUCP (Greg Miller) writes:
>
>
> One last comment - are you by chance reading the RFC from the perspective
>of the host, rather than the client?  That would lead to the interpretation
>that you gave.

1) The first time I read it (about 2 years ago) I misunderstood it, merely
   triggered by questions like yours.
   I then got the correct understanding of it by looking at our local
   net. However, when I read your mail, I remembered my first understanding
   (which was wrong). So I apologize for leading to confusion.

2) Thanks to Mark ("Gaijin") Crispin for correcting me.

Giovanni Conti
Ecole Polytechnique Federale de Lausanne
Laboratoire de Teleinformatique
EL-Ecublens
CH-1015 Lausanne
Switzerland
Tel   : +41 21 693.29.07
FAX   : +41 21 693.46.60
E-mail: conti@ltisun.epfl.ch
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 12:20:45 GMT
From:      zaphod.mps.ohio-state.edu!know!pluto.hemel.bull.co.uk!pmoore@tut.cis.ohio-state.edu  (Paul Moore)
To:        tcp-ip@nic.ddn.mil
Subject:   routing in a subnet (come on all you wizards!)
I am trying to get the following to work and cannot, it seems it should to me.
It is on Lachman and HP-UX.

All this is on a class B net (123.456 for example). The net is subnetted on
8 bits ( a not uncommon situation , I imagine).
Some boxes don't do RIP so I need static routing tables.
I don't want a global default installed for security reasons.

boxa knows where all the subnets are (123.456.1 , 123.456.2 etc)

boxb is installed on 123.456.1 and I want to tell it that all 123.456 traffic
that it cannot reslove should go to boxa.

so i do

	route add net 123.456 boxa 2

The route installs OK but is ignored, I must do
	route add net 123.456.2 boxa 2
	route add net 123.456.3 boxa 2
	etc..

Am I being stupid? Or what
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 14:55:26 GMT
From:      rti!dg-rtp!bigben!bigben!philip@mcnc.org  (Philip Gladstone)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when connecting to an internet
In article <1990Nov26.151017.2023@hemel.bull.co.uk> pmoore@hemel.bull.co.uk (Paul Moore) writes:

pmoore> Gosh, I am glad to see somebody making that point, ("security is a host
pmoore> problem not a net problem").

Security is both a network and a host problem. The more defences you
have, the better protected you are. 

Compare with a military base (a network). Even though they think that
the safe (the host) holding the codebooks is secure, they still don't
let you anywhere near it!

Similarly, even though the Bank of England beleives that their vaults
are secure, they still don't hand out the plans.

The other key advantage of network security is that (if the network is
organised correctly), all traffic passes through a small number of
points. These points can be carefully controlled. Again: I would
prefer that the Bank of England control the people entering the Bank,
rather than relying solely on the security of the vault.



--
Philip Gladstone         Dev Lab Europe, Data General, Cambridge, UK

    Listen three eyes, don't you try and outweird me, I get
    stranger things that you free with my breakfast cereal.
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 16:21:05 GMT
From:      usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!cbmehq!cbmger!acdhq!kaba@ucsd.edu  (Kai Bartels)
To:        tcp-ip@nic.ddn.mil
Subject:   IP on a serial line -- which RFC?
Hy!
I'm currently workin on an implementation of tcp-ip an during this work
i realised that i really don't know how fragments are representated on a
serial line. I don't think it's possible to have it in the same way as
it is on ethernet, 'cause on a serial line you have to know the length of
the fragment BEFORE you get it, so you don'y miss the end.

So the question is: can anybody tell me which RFC to look at?

Thanks in advance, Kai
--------------------
Kai Bartels    | kaba@acdhq.UUCP      | Where do you get your information
Hudemuehler 37 | kaba@acdhq.north.de  | From a dream or a 24-inch-screen?
D-2800 HB 41   | G14B@DHBRRZ41.BITNET |                        <Thinkman>
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 19:33:51 GMT
From:      snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@bloom-beacon.mit.edu  (Peter Murray)
To:        tcp-ip@nic.ddn.mil
Subject:   Limited version of telnet
I'm looking for a limited version of TELNET.  This program would only allow
connections to one host or a list of hosts in a text file.  What I don't want
is this program to is to domain lookups.

We would use this program to publish a LAT service for a Unix box that does not
support LAT.  Regular TELNET allows a person to enter a command mode and
connect to another host (ie, anonymous telnet).  But I really don't want to
disable the command mode.

Thanks for your help.

Peter
-- 
Peter Murray            Neat UNIX Stunts #4:             pemurray@miavx1.bitnet
176 Thompson Hall             csh> \(-            pmurray@apsvax.aps.muohio.edu
Oxford, OH 45056                       NeXT Mail:  pmurray@next4.acs.muohio.edu
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 18:21:07 +0100
From:      pansiot@isis.u-strasbg.fr (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE)
To:        tcpipl@inria.inria.fr
Subject:   X25 over IP
  
Is there a standard way to run X25 over IP ( not the other way around, Ip over 
X25 ).  We would like to use our IP network to carry non Ip traffic over X25.
I assume that either UDP or TCP would be between IP and X25 ?
Is there any product like some kind of terminal server  with X25 lines
and ethernet attachment that would permit  X25 virtual circuit
between  two (distant )ports and over IP ?
Obviously, I assume some IP-only routers along the path.

Thank you for any information
 
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

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Nov 90 22:52:43 GMT
From:      netnews.upenn.edu!grad1.cis.upenn.edu!menqjuh@rutgers.edu  (Menq J. Lee)
To:        tcp-ip@nic.ddn.mil
Subject:   Question about Socket
Hi everybody,

I am new to this field, and I am using DGRAM Socket (UDP) to build a remote
copy utility. This utility supports both ascii and binary file transfers.

I have no problem in handling binary transfer. But when it comes to ascii
transfer, the reference I read told me that I must take care of some
critical cases. Specifically, I have to do some conversion between

		newline <---> CR,LF     (Carriage Return, Line Feed)
		CR <---> CR,NULL

I have the following questions about this issue:

	1. Why is this necessary? In other words, under what situations
           will this conversion be employed to avoid foreseeable errors?

	2. Do I have to do the same conversion if I use STREAM Socket (TCP) 
	   instead of DGRAM Socket?

Any help will be highly appreciated.

--Menq
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 00:02:40 GMT
From:      usc!wuarchive!emory!ospwd@ucsd.edu  (Peter Day {EUCC})
To:        tcp-ip@nic.ddn.mil
Subject:   protocol support

For our network planning effort, I would like to know what protocols
other universities support on their campus networks and how these
protocols were chosen.  Also, what does that "support" entail?
Finally, any advice you would like to give on the subject of supported
protocols would be appreciated.

Please reply directly to me and I will summarize.

Thanks,
Peter Day

Research and Planning, Information Technology Division,
Uppergate House, Emory University, Atlanta, GA 30322 
DOMAIN: ospwd@emoryu1.cc.emory.edu                      
UUCP: gatech!emoryu1!ospwd       PHONE: +1 404 727-7678
BITNET: ospwd@emoryu1            FAX:   +1 404 727-2599   
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 00:05:10 GMT
From:      usc!orion.oac.uci.edu!mothra.nts.uci.edu!meggers@ucsd.edu  (Mark Eggers)
To:        tcp-ip@nic.ddn.mil
Subject:   Cabletron Mailing list correction
Please note that the cabltron mailing list has changed addresses.  The proper
addresses are:

Mailing list:

	cabletron-users@uci.edu
	cbltrn@uci.edu

Requests to be added:

	cabletron-request@uci.edu
	ct-rqst@uci.edu

Please report problems to ucinet-noc@uci.edu.

/mde/
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 00:16:22 GMT
From:      usc!elroy.jpl.nasa.gov!euclid.jpl.nasa.gov!pjs@ucsd.edu  (Peter Scott)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP equivalent of Manufacturing Message Specification?
Hi.  I've been asked to explore possible solutions to a problem
an area I know little about, networking protocols, so please bear
with me.  A colleague is working with a group whose aim is to
network together various lab measurement devices plugged into
PCs and workstations.  These devices are currently in operation
at Goldstone, California (some of them are pretty big, e.g.
70m dish antenna :-)).  

Anyway, another person working on the problem has proposed the
Hewlett Packard MMS (Manufacturing Message Specification) as a
tool for accomplishing it.  Features of this product, just 
released, include automatic data conversion between machines,
i.e., if transferring floating point data between a PC and a
Sun it will convert between formats, flip bytes where necessary,
etc.  However it is also based on OSI, and that causes my
colleague a few problems, to wit, OSI is rather new, harder to
obtain software for than TCP/IP, and in order to perform testing
he would have to buy another two computers just to talk OSI
to each other.

He would prefer to use TCP/IP.  Obviously a lot of custom software
has to be written to make all these devices talk to hosts and
servers, but it would be nice to avoid reinventing too many wheels.

Okay, My Question: does anyone have any suggestions for any
software product, commercial or otherwise, which would simplify
the task of data communication, runs on TCP/IP, and generally
provides the same benefits as we would find useful in MMS?


-- 
This is news.  This is your       |    Peter Scott, NASA/JPL/Caltech
brain on news.  Any questions?    |    (pjs@euclid.jpl.nasa.gov)
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 00:33:02 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Dave Wiltzius)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP trace buffer formatter?

The BSD TCP/IP networking code has a TCP level circular trace
buffer (filled by routine tcp_trace).  Does anyone have a tool
that would read this buffer from memory and format the information?
We want this only for internal use and are willing to accept
all liability, etc.  If someone did a *really* nice job (i.e. allow
filters on IP addresses, TCP ports, etc), perhaps the response
should be posted.

I would be glad to consider anything, however.  Thanks much.

  Dave Wiltzius
  Lawrence Livermore Nat'l Lab
  Livermore, CA 94550
  (415) 422-1551
  wiltzius@lll-crg.llnl.gov
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 01:07:50 GMT
From:      IRVINMJ@WSUVM1.CSC.WSU.EDU ("Michael J. Irvin, WSU, 509/335-0437")
To:        comp.protocols.tcp-ip
Subject:   Re: domain ordering brings down British Leader (:-))

THAT explains it!

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 01:45:43 GMT
From:      usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@ucsd.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP on a serial line -- which RFC?
In article <18466181.ARN13a9@acdhq.north.de>, kaba@acdhq.north.de (Kai Bartels) writes:
> Hy!
> I'm currently workin on an implementation of tcp-ip an during this work
> i realised that i really don't know how fragments are representated on a
> serial line. I don't think it's possible to have it in the same way as
> it is on ethernet, 'cause on a serial line you have to know the length of
> the fragment BEFORE you get it, so you don'y miss the end.
> 
> So the question is: can anybody tell me which RFC to look at?

	RFC 791. :-)

	The IP "length" field is the length of the packet, not the datagram.
That is, for a fragment, the "length" field tells you how big the fragment
is, but you don't know how big the datagram is until you've received the last
of its fragments (RFC 791, page 27, line 1). So, for individual packets, you
can read the min header (20 octets) and it tells you how much header & data
is there.

	But, if you want to make your life easier, you can also add your own
(or someone else's) link-level protocol and encapsulate IP and whatever else
in that. You *will* need this if you do more than just IP stuff on the line.
ARP doesn't make much sense on a 2-node network, but if it's more than just
a toy implementation, it's better to provide self-identifying packets and
while you have that, you might as well add a length field. If you like
Ethernet, just send Ethernet "frames" serially.

	You probably will also want to check out RFC 1055 and maybe 1144.

1055  Romkey, J.L.  Nonstandard for transmission of IP datagrams over serial 
      lines: SLIP.  1988 June; 6 p. (Format: TXT=12911 bytes)

1144  Jacobson, V.  Compressing TCP/IP headers for low-speed serial links.  
      1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes)

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 1990 09:54:42 PST
From:      Paul_S._Lei.El_Segundo@xerox.com
To:        tcp-ip@nic.ddn.mil
Cc:        SKwok.ES_CP8@xerox.com, Paul_S._Lei.El_Segundo@xerox.com
Subject:   TCP/IP over Macs

Hello,

Is anyone familiar with connection hardware and software available to make
Apple Macs talk TCP/IP over ethernet. I'm particularly interested in how such a
Mac would print to a network printer or even talk to a line printer deamon. Any
info on this and related topics would be very much appreciated.

Thanks very much.

/Paul Lei
PLei.ElSegundo@Xerox.com
Lei@arisia.xerox.com
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 90 12:34:37 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
       Does anybody have a version of SLIP or PPP with SLFP (Serial Line
       Framing Protocol) support in it?  Merit ... does SLFP.
    
    Is SLFP HDLC?  If not, is SLFP documented in a readily-accessible
    place?

SLFP is another way of encapsulating IP on serial lines that is neither SLIP
nor PPP.  It has never been written up in an RFC, and if anything exists
besides the source code, it is probably an internal MIT LCS document (John?
Jerry?).  In any case, it was originally supported in the MIT PCIP, but may
not have been maintained since 1985 or so.  Last summer, Merit asked me for
a Packet Driver "class" for SLFP, and I assigned 15 decimal.  I haven't seen
any drivers yet, nor any patches for existing DOS TCP/IP packages.

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

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 90 10:02:04 EST
From:      boudreau@bond.crim.ca (Guy Boudreault)
To:        tcp-ip@nic.ddn.mil
Subject:   R
please remove my name from your mailing list

<boudreau@crim.ca>
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 05:40:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   BSD getsockname() is broken in WIN/TCP for 3B4000???


Hi,
        Hi, did anybody try to use BSD getsockname() b4? I tried very hard
and cannot get it to work. It alswyas return -1, giving t_errno = 4, saying
that socket operation on Non-socket. However, the same program I try it
on Vax and Sun-3/Sun-4, all of them are working properly. I need this
routine to tell what is actual port number return after binding the sock
with port number 0.
        Thanks a lot.

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

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 07:10:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   how to get the local port# assigned without using getsockname()


Hi Netlander,
        I am doing socket programming on WIN/TCP for 3B4000. I would like
to know how to get back the local port number assigned by system WITHOUT
using getsockname(). The getsockname() in WIN/TCP seems NOT working.
I need to know the local port number assigned after bind() with port 0.
Please reply to me. I am desparate for this.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 90 17:21:01 -0500
From:      jbvb@ftp.com  (James B. Van Bokkelen)
To:        xxseub@osprey.lerc.nasa.gov
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Netbios/TCP P/M-node implementations
I have only heard of one P-node/NBNS/NBDD (you can't have one without the
others) implementation, done by somebody up in New Hampshire a year or
two ago.  I got one message from a developer and never have seen it in the
market, so it may have died aborning.  I don't know what platform they
were going to put the NBNS/NBDD on, either...

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

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 10:42:14 GMT
From:      usc!samsung!dali.cs.montana.edu!milton!ogicse!intelhf!ichips!inews!intelca!mipos3!scdt!echan@ucsd.edu  (Eldon Chan ~ )
To:        tcp-ip@nic.ddn.mil
Subject:   Latest proxy-arp daemon on Ultrix and SunOS 4.X
Can somebody tell me where can I get (FTP) a copy of the latest version
of proxy-arp daemon ?
In particular the Ultrix version.  I have a old version for SunOS, it
probably out of date already.

Any pointers are appreciated.

Thanks

Eldon Chan
echan@scdt.intel.com
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 21:40 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   BSD getsockname() is broken in WIN/TCP for 3B4000???

Hi,
        Hi, did anybody try to use BSD getsockname() b4? I tried very hard
and cannot get it to work. It alswyas return -1, giving t_errno = 4, saying
that socket operation on Non-socket. However, the same program I try it
on Vax and Sun-3/Sun-4, all of them are working properly. I need this
routine to tell what is actual port number return after binding the sock
with port number 0.
        Thanks a lot.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Nov 90 23:10 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   how to get the local port# assigned without using getsockname()

Hi Netlander,
        I am doing socket programming on WIN/TCP for 3B4000. I would like
to know how to get back the local port number assigned by system WITHOUT
using getsockname(). The getsockname() in WIN/TCP seems NOT working.
I need to know the local port number assigned after bind() with port 0.
Please reply to me. I am desparate for this.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 15:54:38 GMT
From:      n8emr!vlink01!root@tut.cis.ohio-state.edu  (Superuser)
To:        tcp-ip@nic.ddn.mil
Subject:   cisco routers
Could someone tell me the phone number/address for cisco for their routers?

Thanks in advance.


-- 
V-Link                                  | System Administration V-Link
1828 Darrow Drive                       |---------------------------------------
Powell OH   43065-9261                  | Local : root
614-365-3056                            | Remote: root@vlink01.UUCP
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 16:07:38 GMT
From:      well!osmana@apple.com  (Osman Arslaner)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM System 38 TCP/IP Connection.

We would like to connect an IBM System 38 to our TCP/IP backbone     
ethernet through a terminal server.
On the PC side, we would need a 5250 Emulator package which would
support INT 14 or BAPI interface.     
Does such a product exist ?
Any help will be appreciated....

Osman Arslaner
CN Rail, MONTREAL.
-----------[000335][next][prev][last][first]----------------------------------------------------
From:      ljm@TWG.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Netbios/TCP P/M-node implementations
>	Are there any commercially/PD implementations of P-node or M-node
>NetBIOS servers/clients??...

I believe UB, TRW, and CMC have M-node NetBIOS with their onboard
TCP/IP products.   The big problem with M-node (rather definitionally)
is that it doesn't interoperate with all of the B-node implementations
which are out there.  A number of folk, including ourselves, have
implemented NetBIOS to DNS name mapping and/or aliasing to allow
NetBIOS over TCP/IP B-node hosts to work over the Internet.

To my knowledge, we are the only ones currently shipping product
(though I kind of hope James will tell me I'm wrong given his
latest release -- that most NetBIOS over TCP/IP implementations provide
worse interconnectivity than XNS or NetBEUI is a major embarrassment).

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 22:50:00 EST
From:      "Jerry Damian" <damian@srlvx0.srl.ford.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   802.4 conformance testing

Networkers,

	Does anyone out there know what organizations do 802.4 standards
conformance and interoperability testing? A name or organization contact
would be greatly appreciated.

	Jerry Damian - damian@srlvx0.srl.ford.com

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 17:54:42 GMT
From:      Paul_S._Lei.El_Segundo@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over Macs


Hello,

Is anyone familiar with connection hardware and software available to make
Apple Macs talk TCP/IP over ethernet. I'm particularly interested in how such a
Mac would print to a network printer or even talk to a line printer deamon. Any
info on this and related topics would be very much appreciated.

Thanks very much.

/Paul Lei
PLei.ElSegundo@Xerox.com
Lei@arisia.xerox.com

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 19:11:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   RE: BSD getsockname() broken in WIN/TCP for AT&T3B4000 (Sys V)???


     I received two responses and some further query on this topic. Thanks
for the responses. I apologize for not being clear on some aspects. I re-post
this coz I have not found any solution yet. Below are the response:

From: mni@techops.cray.com (Michael Nittmann)
Message-Id: <9011271706.AA26409@techops.cray.com>
Subject: Re:  BSD getsockname() is broken in WIN/TCP for 3B4000???

>Hi,
>so on what machine does it NOT work?

 As the title suggested, the machine is an AT&T 3B4000 multiprocessor
(I think it is under 3B2 family). The TCP is an WIN product for 3B series.

>Maybe you have a wild horse of a machine that has a broken view of
>file systems and sockets. Are you on a localhost connection?
>Is your socket may be a UNIX domain socket (some broken implementations
>implicit unix domain for localhost sockets) and can your machine

 The domain of the socket is AF_INET, NOT AF_UNIX. I am aware of the problem
of the UNIX domain scoket.

>(better it's system programmers) find no other kernel hook than an
>inode (this case the kernel thinks your socket is a file and may if
>broken give up too soon when you want to have the socket's address
>structure back).

 could u please tell me how check on it?

>Maybe also your error number is wrong and you did not specify
>for namelength how much buffer you allocated?

 I am using perror(), am I missing any thing?

>Sounds like you should scrap that machine.

 I hope so if I have the the say on it. I am just an user/programmer,
not a decision maker.

From: "Michael J. Saletnik - Local Unix Wizard's Apprentice"
 <icarus@jupiter.end.tufts.edu>
Subject: Re:  BSD getsockname() is broken in WIN/TCP for 3B4000???
To: TAYBENGH@NUSDISCS.BITNET
Message-id: <9011271616.AA01750@jupiter.end.tufts.edu>

>What exactly are you trying to do?

        I am actually writing higher-level Inter-machine-communication
interfaces based on socket. One of the routine is socket creation which is:

        int inet_crt(protype, local_port)
        int protype;            /* protocol type */
        u_short *local_port;    /* local port number, if 0 is given, it
                                   will give a unique port number and
                                   assigned to local_port */
        {

           int  id,
                len;
           struct       sockaddr_in     local_sock;

           if ((id = socket(AF_INET, protype, 0)) < 0)
              inet_err("inet_crt(): socket()")

           .......

           /*
            * bind the socket
            */
          if (bind(id, &local_sock, sizeof(local_sock)) < 0)
             inet_err("inet_crt(): bind()")

           /*
            * get the actual port number assigned
            */
           len = sizeof(local_sock);
->         if (getsockname(id, &local_sock, &len))
->             inet_err("inet_crt(): getsockname()")
->Remark:  getsockname() works in both Sun-3 and Sun-4 (SunOS 4.0 & 4.1).
->         However, it did not work on TCP/IP WIN/3B for an AT&T3B4000!!!
->         WHY???
           *local_port = ntohs(local_sock.sin_port);
           return(sock);
        }

>If you have a sockaddr_in structure associated with the socket, which you
>should
>   ,
>after the bind look at
 
>struct sockaddr_in fubar;
>unsigned long port;
>port = fubar.sin_port;
 
>If I'm totally clueless as to what you're doing, possibly a more detailed
>description or a code fragment....

        Well, I did tried using your method b4, but it simply return 0 :-(.
Before bind(), the port=0; After bind(); I tried to print out the port number,
it is still 0 at both Sun-4 and AT&T machines. That's mean the bind() did not
modify the struct sockaddr_in. Am I rite?

        Thanks. Hope to hear from all of you soon.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 21:10:57 GMT
From:      mstan!jordan@uunet.uu.net  (Jordan Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Formation of the UK Internet Consortium
>	ip-interest@independent.uucp
                                ~~~~

Indeed!

/jordan
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 22:19:48 GMT
From:      eru!hagbard!sunic!mcsun!corton!litp!inria!dupont@bloom-beacon.mit.edu  (Francis Dupont)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X25 over IP
In article <9011271721.AA06559@isis.u-strasbg.fr>, pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes:
> 
> Is there a standard way to run X25 over IP (not the other way around, IP
> over X25 ).  We would like to use our IP network to carry non IP traffic
> over X25.
> ...

Cisco has a X.25 over TCP. It is useful for instance for PAD (X.3/X.28/X.29).
(OSI applications can use RFC 1086 "ISO-TP0 bridge between TCP and X.25"
but it is not possible for native usage of X.25 like PAD).
The transport of X.25 packets over TCP connections is very simple,
I've implemented it for Suns and I'm writing a description of it.

Francis.Dupont@inria.fr
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 23:16:14 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Limited version of telnet
In article <2974.27527950@miavx1.acs.muohio.edu> pemurray@miavx1.acs.muohio.edu (Peter Murray) writes:

   I'm looking for a limited version of TELNET.  This program would
   only allow connections to one host or a list of hosts in a text
   file.  What I don't want is this program to is to domain lookups.

May I suggest that it looks up the name of the host to connect to in a
table to find if it's acceptable, and then do the domain name lookup
to find the address?

You don't want to reconfigure more than you have to when addresses
change, and you don't want the text table to contain errors.

Morale: Always use the DNS.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 23:51:04 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question about Socket
In article <33562@netnews.upenn.edu>, Menq J. Lee writes:

   I am new to this field, and I am using DGRAM Socket (UDP) to build
   a remote copy utility. This utility supports both ascii and binary
   file transfers.

You may find that FTP [1] does what you need, albeit with a little more
overhead.  FTP uses TCP, because it doesn't want to bother with
retransmission, congestion problems, etc.  Neither should you.  For a
local area network remote copy utility, there exists the Berkeley Unix
system rcp(1).  I believe it's freely available from Berkeley source
repositories like UUNET.UU.NET via anonymous FTP.  It's not recommended
between different users because of security related deficiencies.

You may also look into NFS [2] if this is part of a file system design.

You may want to look at TFTP [3] for a very simple approach to file
transfer and remote file copying.

   I have no problem in handling binary transfer. But when it comes to
   ascii transfer, the reference I read told me that I must take care
   of some critical cases. Specifically, I have to do some conversion
   between

		   newline <---> CR,LF     (Carriage Return, Line Feed)
		   CR <---> CR,NULL

   I have the following questions about this issue:

	   1. Why is this necessary? In other words, under what
	      situations will this conversion be employed to avoid
	      foreseeable errors?

It is necessary because you want to relieve your client under operating
system X from knowing about the line termination conventions of
operating system Y.  This becomes progressively more pressing for large
sets of operating systems and conventions.

	   2. Do I have to do the same conversion if I use STREAM
	      Socket (TCP) instead of DGRAM Socket?

Yes.  You have to do a lot less work if you start using TCP, though.

-----
[1] RFC 959 File Transfer Protocol.  (See also RFC 1068 Background
    File Transfer Program.)
[2] RFC 1094 NFS: Network File System Protocol Specification
[3] RFC 783 TFTP Protocol (revision 2)

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 23:55:41 GMT
From:      virga.rap.ucar.edu!tres@handies.ucar.edu  (Tres Hofmeister)
To:        tcp-ip@nic.ddn.mil
Subject:   Reliability of SLIP

	I'm interested in finding a source of information for SLIP.  I'm
interested in issues such as reliability, ease of installation (under
SunOS 4.1, specifically), phone line requirements, etc.

	Any information would be appreciated.

	Please respond via email, I rarely get the chance to read the
group...

--
Tres Hofmeister
tres@ncar.ucar.edu
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Nov 90 23:58:21 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!nuug!ifi!enag@ucsd.edu  (Erik Naggum)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP on a serial line -- which RFC?
In article <1882@mentor.cc.purdue.edu>, David L Stevens writes:

	   You probably will also want to check out RFC 1055 and maybe 1144.

   1055  Romkey, J.L.  Nonstandard for transmission of IP datagrams over serial 
	 lines: SLIP.  1988 June; 6 p. (Format: TXT=12911 bytes)

   1144  Jacobson, V.  Compressing TCP/IP headers for low-speed serial links.  
	 1990 February; 43 p. (Format: TXT=120959, PS=534729 bytes)


In addition to these two documents, a full-blown point-to-point
protocol has been developed.  (Serial lines is the archetypical
point-to-point link...)

1172  Perkins, D.; Hobby, R.  Point-to-Point Protocol (PPP) initial 
      configuration options.  1990 July; 38 p. (Format: TXT=76132 bytes)

You may also find this document interesting.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863
--
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 00:16:26 GMT
From:      sdd.hp.com!caen!ox.com!b-tech!zeeff@ucsd.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
>    Is SLFP HDLC?  If not, is SLFP documented in a readily-accessible
>    place?
>
>SLFP is another way of encapsulating IP on serial lines that is neither SLIP

"slfp.info" is available for anon ftp in ais.org:/pub.


-- 
Jon Zeeff (NIC handle JZ)	 zeeff@b-tech.ann-arbor.mi.us
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 90 11:11 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   RE: BSD getsockname() broken in WIN/TCP for AT&T3B4000 (Sys V)???
     I received two responses and some further query on this topic. Thanks
for the responses. I apologize for not being clear on some aspects. I re-post
this coz I have not found any solution yet. Below are the response:

From: mni@techops.cray.com (Michael Nittmann)
Message-Id: <9011271706.AA26409@techops.cray.com>
Subject: Re:  BSD getsockname() is broken in WIN/TCP for 3B4000???

>Hi,
>so on what machine does it NOT work?

 As the title suggested, the machine is an AT&T 3B4000 multiprocessor
(I think it is under 3B2 family). The TCP is an WIN product for 3B series.

>Maybe you have a wild horse of a machine that has a broken view of
>file systems and sockets. Are you on a localhost connection?
>Is your socket may be a UNIX domain socket (some broken implementations
>implicit unix domain for localhost sockets) and can your machine

 The domain of the socket is AF_INET, NOT AF_UNIX. I am aware of the problem
of the UNIX domain scoket.

>(better it's system programmers) find no other kernel hook than an
>inode (this case the kernel thinks your socket is a file and may if
>broken give up too soon when you want to have the socket's address
>structure back).

 could u please tell me how check on it?

>Maybe also your error number is wrong and you did not specify
>for namelength how much buffer you allocated?

 I am using perror(), am I missing any thing?

>Sounds like you should scrap that machine.

 I hope so if I have the the say on it. I am just an user/programmer,
not a decision maker.

From: "Michael J. Saletnik - Local Unix Wizard's Apprentice"
 <icarus@jupiter.end.tufts.edu>
Subject: Re:  BSD getsockname() is broken in WIN/TCP for 3B4000???
To: TAYBENGH@NUSDISCS.BITNET
Message-id: <9011271616.AA01750@jupiter.end.tufts.edu>

>What exactly are you trying to do?

        I am actually writing higher-level Inter-machine-communication
interfaces based on socket. One of the routine is socket creation which is:

        int inet_crt(protype, local_port)
        int protype;            /* protocol type */
        u_short *local_port;    /* local port number, if 0 is given, it
                                   will give a unique port number and
                                   assigned to local_port */
        {

           int  id,
                len;
           struct       sockaddr_in     local_sock;

           if ((id = socket(AF_INET, protype, 0)) < 0)
              inet_err("inet_crt(): socket()")

           .......

           /*
            * bind the socket
            */
          if (bind(id, &local_sock, sizeof(local_sock)) < 0)
             inet_err("inet_crt(): bind()")

           /*
            * get the actual port number assigned
            */
           len = sizeof(local_sock);
->         if (getsockname(id, &local_sock, &len))
->             inet_err("inet_crt(): getsockname()")
->Remark:  getsockname() works in both Sun-3 and Sun-4 (SunOS 4.0 & 4.1).
->         However, it did not work on TCP/IP WIN/3B for an AT&T3B4000!!!
->         WHY???
           *local_port = ntohs(local_sock.sin_port);
           return(sock);
        }

>If you have a sockaddr_in structure associated with the socket, which you
>should
>   ,
>after the bind look at

>struct sockaddr_in fubar;
>unsigned long port;
>port = fubar.sin_port;

>If I'm totally clueless as to what you're doing, possibly a more detailed
>description or a code fragment....

        Well, I did tried using your method b4, but it simply return 0 :-(.
Before bind(), the port=0; After bind(); I tried to print out the port number,
it is still 0 at both Sun-4 and AT&T machines. That's mean the bind() did not
modify the struct sockaddr_in. Am I rite?

        Thanks. Hope to hear from all of you soon.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 02:05:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   anybody use ioctl() with /netinclude/inetioctl.h in TCP/IP WIN3B?


hi, netlander,
        I read through the WIN/TCP for 3B series, and can NOT any documntation
about ioctl() call on socket. As a result, I read the /netinclude/inetioctl.h
and found out WIN has defined several control blocks and options for IP, TCP
and UDP such as strcut tcpioctl. Did anybody use the ioctl() call with various
options such as TCPIOC_GETMYPORT, TCPIOC_GETSOCKNAME? If so, what is the
parameters that I can pass in for the third arguments for ioctl()???
Could somebody point me any reference that I can use the ioctl() on socket?
Thanks a lot.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 03:29:56 GMT
From:      munnari.oz.au!cs.mu.OZ.AU!kre@THEORY.TN.CORNELL.EDU  (Robert Elz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Telnet's ECHO option
In article <gm.3504@ionic.UUCP>, gm@ionic.UUCP (Greg Miller) writes:
> However, whenever I try this
> when I'm connected to a BSD machine, the host accepts my DONT ECHO,
> replies with WONT ECHO, and then procedes to continue echoing anyways.

There's been a lot of discussion on the nature of DO ECHO / DONT ECHO,
etc, in response to this, but I don't recall much discussion on the
actual problem being reported.

I believe that BSD systems get "DONT ECHO" right, when you ask for them
to not echo, they don't.

But note that "DONT ECHO" is not "DONT OUTPUT" - ie: you still get any
output that processes want to generate (of course).   The perceived
problem is really that some of what seems to be echo is really program
output - it just appears as if it may be echo.

In particular, the "login" program outputs the login name that you enter
(character by character).  This is not "echo", its program output, and
as such, the telnet echo options have nothing to do with it whatever.

kre
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 03:50:00 GMT
From:      damian@SRLVX0.SRL.FORD.COM ("Jerry Damian")
To:        comp.protocols.tcp-ip
Subject:   802.4 conformance testing


Networkers,

	Does anyone out there know what organizations do 802.4 standards
conformance and interoperability testing? A name or organization contact
would be greatly appreciated.

	Jerry Damian - damian@srlvx0.srl.ford.com

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Nov 90 18:05 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   anybody use ioctl() with /netinclude/inetioctl.h in TCP/IP WIN3B?

hi, netlander,
        I read through the WIN/TCP for 3B series, and can NOT any documntation
about ioctl() call on socket. As a result, I read the /netinclude/inetioctl.h
and found out WIN has defined several control blocks and options for IP, TCP
and UDP such as strcut tcpioctl. Did anybody use the ioctl() call with various
options such as TCPIOC_GETMYPORT, TCPIOC_GETSOCKNAME? If so, what is the
parameters that I can pass in for the third arguments for ioctl()???
Could somebody point me any reference that I can use the ioctl() on socket?
Thanks a lot.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 07:50:02 GMT
From:      eru!hagbard!sunic!lth.se!newsuser@bloom-beacon.mit.edu  (Ricard Wolf)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Question about Socket
In article <ENAG.90Nov29005054@hild.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes:
>In article <33562@netnews.upenn.edu>, Menq J. Lee writes:
....
>
>   I have no problem in handling binary transfer. But when it comes to
>   ascii transfer, the reference I read told me that I must take care
>   of some critical cases. Specifically, I have to do some conversion
>   between
>
>		   newline <---> CR,LF     (Carriage Return, Line Feed)
>		   CR <---> CR,NULL
>
>   I have the following questions about this issue:
>
>	   1. Why is this necessary? In other words, under what
>	      situations will this conversion be employed to avoid
>	      foreseeable errors?
>
>It is necessary because you want to relieve your client under operating
>system X from knowing about the line termination conventions of
>operating system Y.  This becomes progressively more pressing for large
>sets of operating systems and conventions.

If you use FTP in the ascii transfer mode (whcih is the default) this is
taken care of automagically.

-- 
Ricard Wolf

+--------------------------+-------------------------------------+
| Ricard Wolf              | Lund Institute of Technology        |
| email: e85rw@efd.lth.se  | If you can't buy 'em - build 'em !! |
+--------------------------+-------------------------------------+
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Nov 90 09:56:10 GMT
From:      J Jackson <jj@dcs.leeds.ac.uk>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Reducing the risks when connecting to an internet
> 
> In article <1990Nov26.151017.2023@hemel.bull.co.uk> pmoore@hemel.bull.co.uk (Paul Moore) writes:
> 
> pmoore> Gosh, I am glad to see somebody making that point, ("security is a host
> pmoore> problem not a net problem").
> 
> Security is both a network and a host problem. The more defences you
> have, the better protected you are. 
> 
> Compare with a military base (a network). Even though they think that
> the safe (the host) holding the codebooks is secure, they still don't
> let you anywhere near it!
> 
> Similarly, even though the Bank of England beleives that their vaults
> are secure, they still don't hand out the plans.
>
> ....stuff deleted.....
> 
> --
> Philip Gladstone         Dev Lab Europe, Data General, Cambridge, UK

I prefer to make the analogy between the transport system (the network)
and the bank (the host). I sure as hell would object to being stopped
at major highway junctions and told to identify myself. However I'd
object if I wasn't asked to identify myself at the bank.

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


-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Nov 90 16:07 EDT
From:      Jonathan Kruger <KRUGERJ%GBURG.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   whoisd
Hi,

   I'm trying to get a campus wide whois server going on our Sun 4.  I'd
like to avoid re-inventing the wheel, but the only whoisd program I found
out in anonymous FTPland was the one written at the University of Virginia.
While it seems to work rather well for them, it's thoroughly undocumented,
and is geared for supporting 60K+ users, while we have only about 3K users
here.

If anyone can point me in the right direction I will be most grateful...

Jonathan Kruger
Computing Services
Gettysburg College
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 19:17:44 GMT
From:      sgi!shinobu!odin!speaker!coolidge@ucbvax.Berkeley.EDU  (Don Coolidge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interoperating with HP
In article <9011271533.AA01752@desktalkdesktalk.com> rlg@desktalkdesktalk.com (Richard L. Gralnik) writes:
>Hi gang,
>We are on the verge of great things, but I figure I'm better off forewarned
>so...
>
>Does anyone have experience connecting a 
>
>	Sequent (Dynix 3.0.17) 
>
>to an 
>
>	HP 3000 (MPE/V Delta 5) with
>		HP's LANIC board and TCP/IP software
>		Wollongong ARPA Services for MPE TCP/IP
>
>I have been warned off telneting from the HP, but any other gotchas would
>be appreciated. 

The only real gotcha you have to watch out for is that native MPE doesn't
support either ARP or Ethernet - it encapsulates in 802.3 and does address
resolution with HP's Probe protocol. So, there's no way for the Sequent
to communicate with the MPE box on its own, if native MPE/V is all that's
on the HP. However, there are two ways to deal with this:

1) ARP and Ethernet can be bought for the latest Delta of MPE/V (sorry, I
   don't know if Delta 5 is the latest). Contact your HP rep.

2) If that won't work for you, you can put a cisco gateway between the two -
   cisco speaks Probe and 802.3. I also suspect (but don't know for sure)
   that some Wellfleet routers have the same capability. Finally, at InterOp
   I saw gateways at the HP booth with the HP logo on them. I'm sure that
   they, too, can translate.

Once you get over that hurdle, you'll be able to use the Wollongong services
to talk with their un*x cousins on the Sequent without much further ado.

- Don Coolidge
coolidge@speaker.wpd.sgi.com
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 21:25:59 GMT
From:      hub.ucsb.edu!spectrum.CMC.COM!lars@ucsd.edu  (Lars Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Access Costs
In article <315@srchtec.UUCP> mra@srchtec.uucp (Michael Almond) writes:
>>One other item: PSI says we will not have a constant IP #.  It supposedly
>>changes each time we establish a connection with them.  However, our address
>>will remain constant (probably searchtech.com).

In article <1990Nov26.233848.20828@nmt.edu> rmilner@zia.aoc.nrao.edu
   (Ruth Milner) writes:
>I fail to see how this can be the case. Granted they can change their tables
>any time they want, *but* they have the following restrictions:
>
>     a) they have to use an Internet number assigned to them/you by the NIC
>     b) the rest of the Internet has to understand the routing (if it's
>        advertised, and if it isn't no-one can reach you)
>     c) your system has to know *before establishing the connection* what
>        its own Internet address is
>    ...
>Even if it *could* be done, it would be such an administrative nightmare
>trying to figure out "who's 123.456.789.10 this morning?" that I can't think
>why they *would* do it.
>
>Ruth Milner
>Systems Manager                     NRAO/VLA                    Socorro NM

Ruth,
	The network number stays constant, the IP address changes.
(The confusion seems to have been caused by a bad choice of words:
The posting says "internet number" for "IP address" and "address" for
"fully qualified domain name".)

	Crazy as it seems at first glance, dynamic IP addresses are
not actually all that unusual. Client-only PC's often do this. And with
domain name service, it is doable even to handle incoming connections.

	Yes, it does create a few management hassles. You need to have a
name server with a transaction interface to change the name/address
mappings on the fly (where the run-of-the-mill BIND just reads a table
when it is reloaded) and you cannot have management utilities that
assume that name/address mappings are constant.

	But technically, at the low level, it is no harder than ARP.
You need an ARP-like handshake before you switch to IP mode. Most SLIP
interfaces already have a handshake (unix login !) before turning into
IP interfaces, so there definitely is a mechanism to do that.

	As to WHY one wants to do this ? When you have a couple hundred
PC's around, it is easier to just declare them to be generic than to try
to keep track of locations and owners for all of them. Likewise, network
providers may have only allocated class C network numbers for a routing
cluster, and may prefer the dynamic addresses over changing backbone
routing implementations with hardcoded netmasks.

/ Lars
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 22:01:12 GMT
From:      snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@bloom-beacon.mit.edu  (Peter Murray)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Limited version of telnet
In article <ENAG.90Nov29001605@hild.ifi.uio.no>, enag@ifi.uio.no (Erik Naggum) writes:
> In article <2974.27527950@miavx1.acs.muohio.edu> pemurray@miavx1.acs.muohio.edu (Peter Murray) writes:
> 
>    I'm looking for a limited version of TELNET.  This program would
>    only allow connections to one host or a list of hosts in a text
>    file.  What I don't want is this program to is to domain lookups.
> 
> May I suggest that it looks up the name of the host to connect to in a
> table to find if it's acceptable, and then do the domain name lookup
> to find the address?
> 
> You don't want to reconfigure more than you have to when addresses
> change, and you don't want the text table to contain errors.
> 
> Morale: Always use the DNS.

Excellent suggestion.  Thank you.  If/when I have to write this, it will
have this function.

If no one has seen any software to do this, can someone please e-mail me
a site that has the telnet source.  Thanks.

Peter
-- 
Peter Murray            Neat UNIX Stunts #5:             pemurray@miavx1.bitnet
176 Thompson Hall    sh> drink <bottle; opener    pmurray@apsvax.aps.muohio.edu
Oxford, OH 45056                       NeXT Mail:  pmurray@next4.acs.muohio.edu
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 22:06:36 GMT
From:      mintaka!think.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dogie.macc.wisc.edu!vms.macc.wisc.edu@bloom-beacon.mit.edu  (Dana A. Bunner)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for DOS Windows 3 TELNET
I am looking for an MS/DOS Windows 3.0 compatible version of TELNET.
We would prefer somewhat capable of running in a window.  We are
currently using the Clarkson product but it's limited data capture
and "cut and paste" capabilities are inconvenient.

If someone has knowledge of such a product please E-Mail me.

Thanks,

   Dana Alan Bunner, Asst Dir,  UW-Madison Academic Computing Center
   1210 W. Dayton St.     Madison, WI  53706          (608) 262-4418
   ARPANET: bunner@macc.wisc.edu      BITNET: bunner@wiscmacc.bitnet
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      29 Nov 90 22:49:49 GMT
From:      bbs!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM Mainframe SNA to TCP/IP Hosts; X-windows, etc
Hello net.oracle.

We're in desparate need of the following:

o)	An X-based solution to 3270 emulation and file transfer, which can
	run over something similar to (or actually a) Mitek gateway

		or

o)	Unix and PC (under B&W NFS, or NETBIOS) solutions to the above.

So far we have been spectacularly unsuccessful in doing this.  We NEED to
get from our environments here (BWNFS and Workstation) based to the
mainframe environment!

Any help or pointers appreciated.  Pay-for software and harware are fine,
ads are fine, free stuff is fine, anything we can get our hands on that
WORKS.

The tn3270 application does not work AT ALL, since our host system insists
on sending "write structured field" calls, and we can't reply to them (the
defines are there in the code source, but there's no code to back them up).
We've been unsuccessful in locating a more recent version of the code.
CUTCP (ie: Clarkson's CUTE Telnet 3270) doesn't work either, for the same
reason.

We're about to run out of options here; any help is GREATLY appreciated.  We
can do X11 on all the platforms, but we need a way to do the mainframe
connectivity.

Thanks in advance.  Ads and all advice welcome.

--
--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 00:01:51 GMT
From:      lll-crg.llnl.gov@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   reuse of addresses when calling bind()
I've got a meeting in a couple minutes so I'm going to try and ask this quickly.
If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able
to issue a bind() for a ip/port address that is already in use.  However, it
appears that it is still possible for bind() to return the error EADDRINUSE (for
example, look at routine getdatasock() in ftpd.c where they have a loop that
retries the bind() several times before giving up, all the while checking for
EADDRINUSE).  

What I'd like to know is why this happens, in lieu of the call to setsockopt().
Thanks in advance.  Email would be nice but I'll wade through stuff if need be.

regards,
mb

booloo@lll-crg.llnl.gov
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Nov 90 10:24:06 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   Call for Papers SIGCOMM '91


		       Call For Papers

		 ACM SIGCOMM '91 CONFERENCE
  Communications Applications, Architectures and Protocols

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


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

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

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

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

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

The North American program committee contact is:

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

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


Special session: Applications of High Speed Networks

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

Student Paper Award

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

IMPORTANT DATES


Deadline for paper submission:   March 2, 1991.
Notification of acceptance:      April 30, 1991.
Camera ready papers due:         May 31, 1991.
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 03:50:18 GMT
From:      bbs!karl@uunet.uu.net  (Karl Denninger)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet Drivers and 3COM coexistance; we need 3COM Netbios
Hi Usenet.oracle.

Again, I come to the well.

We have an interesting situation here.  We have a 3COM Netbios application
(the Maxess gateway) which we would like to use with TCP/IP.  We have a
Netbios-over-TCP implementation, but it doesn't seem to work with that.

Thus, our next attack point:

We are using packet drivers.  Does anyone know how to get the packet drivers
to work with someone's TCP/IP (ie: B&Ws) and 3COM's 3+OPEN Netbios drivers
at the same time?

We don't care about redirectors or other 3COM services at this point -- only
NETBIOS.  Two adapters in a machine is not an acceptable alternative.  

If anyone has made this work, please let us know how you did it!  I haven't
seen any references to this feat of magic yet... but perhaps it can be
done.

Email or posts appreciated.

--
Karl Denninger	AC Nielsen
kdenning@ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Nov 90 10:00:46 CST
From:      MAINT@ASNTSU.asn.net
To:        tcp-ip@nic.ddn.mil
I am interested in SLIP and need the RFC for it. Can some one tell me what
the RFC for it is and where I can get it? Please respond directly to me as
I am not a regular subscriber to this list. Thanks in advance.

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

       +---------------------+
       |UNA           A&M    |
       |NFDC-------C--UAH    |
       |          / \        |
       |          | |     JSU|
       |   _____UAB-+----/   |
       | UA         |        |
       |            | ____AU |
       |          DSMD       |
       |        ASU | \      |
       |           /  TSU    |
       |         /           |
       |       /             |
       |     /               |
       |  _USA---------------+
       |/  \_|
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 08:43:00 EDT
From:      "SDAV01::ZENTELIS" <zentelis%sdav01.decnet@win1.ims.abb.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Looking for SPIDER's address
Hi

I'm looking for SPIDER:s address in Great Britain or SPIDERS:s reseller in
Sweden. 
My mailing address is : ZENTELIS%SDAV01.DECnet@WIN1.IMS.ABB.COM
Nicolas Zentelis

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 05:59:16 GMT
From:      wuarchive!zaphod.mps.ohio-state.edu!usc!barnard.usc.edu!jconti@eddie.mit.edu  (John Conti)
To:        tcp-ip@nic.ddn.mil
Subject:   wanted: snmp mib compiler
I'm looking for the program used to manipulate SNMP MIBs (usually
called a mib compiler).  I have a general ASN.1 compiler but I need to
maim my mib.txt.

Email is probably the best way to reply, I'll resend to whoever wishes
it.

TIA.

-- 
	,John

John Conti	{ jconti@usc.edu | jconti@xenon.usc.edu (NeXT mail) }
Computing Services, University of Southern California, (213)740-2957
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Fri 30 Nov 90 16:37:57-PST
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   TCP options...
TCP options are apparently not included in the sequence space - At least,
all the implementations I see have the first datagram after the syn/mss
packet with a sequence number 1 greater than the syn (which covers the
syn, but not the 4 bytes of tcp options that make up the mss option.)

HR rfc requires that TCPs accept options in any packet - does this actually
mean that in order to ensure reliable delivery of an option, it has to be
sent in a packet that also contains data?  Sure seems that way...

BillW
-------
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Nov 90 17:35:15 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        Jonathan Kruger <KRUGERJ@GBURG.BITNET>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: whoisd
Johathan,

While you do not yet appear to be on the Internet, you may want to
take a look at the WhitePages service that is available using X.500,
it is a much larger protocol/implementation means to use, but it's
utility is much greater.  Send email to wp-info@psi.com and it will
point you to technical reports, software, instructions, etc..

Marty
------------

 Hi,

    I'm trying to get a campus wide whois server going on our Sun 4.  I'd
 like to avoid re-inventing the wheel, but the only whoisd program I found
 out in anonymous FTPland was the one written at the University of Virginia.
 While it seems to work rather well for them, it's thoroughly undocumented,
 and is geared for supporting 60K+ users, while we have only about 3K users
 here.

 If anyone can point me in the right direction I will be most grateful...

 Jonathan Kruger
 Computing Services
 Gettysburg College
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 13:03:05 GMT
From:      dinah@karazm.math.uh.edu (Dinah McNutt)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.protocols.appletalk
Subject:   Product Informatation

I am interested in information on different ways to connect MACs, PCs (386
and 486 types), and UNIX systems. Functionality requirements include mail,
remote login, file sharing, file transfer, printer sharing, and net news.
I am particularly interested in software that provides all the above plus
can handle PC-PC communications well. Also, some of the systems I am dealing
with are already on a Novell or Appletalk network. (Some of the PCs and MACs
are currently standalone as well.)

I would also like information on the following:

Beam and Whiteside's PC-NFS product
Intercom's Netnews and TN3270 products
MacPathway from The Wollongong Group
Star*9

and anything else that might be available.

Thanks,

Dinah


--
Dinah McNutt         		                         Senior Staff Scientist
Technology Transfer Associates	                                 Houston, Texas
internet: dinah@bcm.tmc.edu                   uucp: {rutgers,mailrus}!bcm!dinah

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 13:42:28 GMT
From:      eru!hagbard!sunic!mcsun!ukc!slxsys!jpp@bloom-beacon.mit.edu  (John Pettitt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Formation of the UK Internet Consortium
jordan@Morgan.COM (Jordan Hayes) writes:
>>	ip-interest@independent.uucp
>                                ~~~~

>Indeed!

>/jordan


Exactly our point !  There is (or rather was) no IP offering in the
UK hence the .uucp (getting a .co.uk or .ac.uk takes ages due to
the organizations involved).

John Pettitt
Specialix International
(One of the founder members, UK Internet Consortium)
john.pettitt@specialix.co.uk   or john.pettitt@specialix.com


-- 
John Pettitt, Specialix International, 
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Nov 90 14:34 GMT
From:      Bob Stine <0004219666@mcimail.com>
To:        Dave Wiltzius <lll-crg.llnl.gov@lll-winken.llnl.gov>
Cc:        tcp ip <tcp-ip@nic.ddn.mil>
Subject:   Re: TCP trace buffer formatter?
>The BSD TCP/IP networking code has a TCP level circular trace
>buffer (filled by routine tcp_trace).  Does anyone have a tool
>that would read this buffer from memory and format the information?

Have you looked at TRPT?  Its description, from RFC 1147, follows:

Regards,

Bob Stine

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

          Internet Tool Catalog                                   TRPT


          NAME
               TRPT -- transliterate protocol trace

          KEYWORDS
               traffic; IP; eavesdrop; UNIX; free.

          ABSTRACT
               TRPT displays a trace of a TCP socket events.  When no
               options are supplied, TRPT prints all the trace records
               found in a system, grouped according to TCP connection
               protocol control block (PCB).

               An example of TRPT output is:

               38241 ESTABLISHED:input
               [e0531003..e0531203)@6cc5b402(win=4000)<ACK> -> ESTA-
               BLISHED
               38241 ESTABLISHED:user RCVD -> ESTABLISHED
               38266 ESTABLISHED:output
               6cc5b402@e0531203(win=4000)<ACK> -> ESTABLISHED
               38331 ESTABLISHED:input
               [e0531203..e0531403)@6cc5b402(win=4000)<ACK,FIN,PUSH>
               -> CLOSE_WAIT
               38331 CLOSE_WAIT:output
               6cc5b402@e0531404(win=3dff)<ACK> -> CLOSE_WAIT
               38331 CLOSE_WAIT:user RCVD -> CLOSE_WAIT
               38343 LAST_ACK:output
               6cc5b402@e0531404(win=4000)<ACK,FIN> -> LAST_ACK
               38343 CLOSE_WAIT:user DISCONNECT -> LAST_ACK
               38343 LAST_ACK:user DETACH -> LAST_ACK

          MECHANISM
               TRPT interrogates the buffer of TCP trace records that
               is created when a TCP socket is marked for debugging.

          CAVEATS
               Prior to using TRPT, an analyst should take steps to
               isolate the problem connection and find the address of
               its protocol control blocks.

          BUGS
               None reported.

          LIMITATIONS
               A socket must have the debugging option set for TRPT to
               operate.  Another problem is that the output format of
               TRPT is difficult.

          HARDWARE REQUIRED
               No restrictions.

          SOFTWARE REQUIRED
               BSD UNIX or related OS.

          AVAILABILITY
               Included with BSD and SunOS distributions.  Available
               via anonymous FTP from uunet.uu.net, in file bsd-
               sources/src/etc/trpt.tar.Z.




-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 15:24:06 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Call for Papers SIGCOMM '91



		       Call For Papers

		 ACM SIGCOMM '91 CONFERENCE
  Communications Applications, Architectures and Protocols

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


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

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

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

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

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

The North American program committee contact is:

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

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


Special session: Applications of High Speed Networks

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

Student Paper Award

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

IMPORTANT DATES


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

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 16:00:46 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

I am interested in SLIP and need the RFC for it. Can some one tell me what
the RFC for it is and where I can get it? Please respond directly to me as
I am not a regular subscriber to this list. Thanks in advance.

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

       +---------------------+
       |UNA           A&M    |
       |NFDC-------C--UAH    |
       |          / \        |
       |          | |     JSU|
       |   _____UAB-+----/   |
       | UA         |        |
       |            | ____AU |
       |          DSMD       |
       |        ASU | \      |
       |           /  TSU    |
       |         /           |
       |       /             |
       |     /               |
       |  _USA---------------+
       |/  \_|

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 18:31:11 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interoperating with HP

On the subject of connecting MPE's with the rest of the networking world...

Don was correct, the latest version of MPE/V supports ethernet. So
does the next oldest release, and the next, and all the way back to
VDelta-5 ;-)  However, you would probably be well advised to upgrade
to at later release to get subnet support and accumulated fixes -
VDelta-5 is a rather old release.

rick jones
___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | XL has Ethernet too ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 20:21:55 GMT
From:      ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls61.bnr.ca!pww@beaver.cs.washington.edu  (Peter Whittaker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: reuse of addresses when calling bind()
In article <86984@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>I've got a meeting in a couple minutes so I'm going to try and ask this quickly.
>If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able
>to issue a bind() for a ip/port address that is already in use.  However, it
>appears that it is still possible for bind() to return the error EADDRINUSE (for
>example, look at routine getdatasock() in ftpd.c where they have a loop that
>retries the bind() several times before giving up, all the while checking for
>EADDRINUSE).  
>
>What I'd like to know is why this happens, in lieu of the call to setsockopt().
>Thanks in advance.  Email would be nice but I'll wade through stuff if need be.

I'm posting instead of e-mailing you directly in order to check my answer against the combined wisdom of the net...

First, the original socket must have set SO_REUSEADDR - you cannot set it 
retroactively.

Second, two independent processes cannot bind to the same port no matter 
what options are set.  SO_REUSEADDR allows the same process, or children of
that process, to bind to same port (this is how ftp works:  one server binds
its children to the same port, so all data flows from the same port).

Finally, under certain conditions (notably the use of SO_KEEPALIVE in 
an HP-UX 6.5 client), connections never disppear when the server dies/exits;
the kernel tells the server that the socket is closed, but never manages to
close it, because the HPUS 6.5 client interferes with the shutdown.  Result:
regardless of any options, the socket cannot reused until the client shuts
down or the machine is rebooted.

--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 20:26:41 GMT
From:      rock.concert.net!sunvis.rtpnc.epa.gov!fty@mcnc.org  (Frank Terhaar-Yonkers)
To:        tcp-ip@nic.ddn.mil
Subject:   DNS for SUN 386i
Howdy,

Anyone out in net land have a lib_pic.a for a SUN 386i running 4.0.2?
I've been trying to get one from Sun so I could install bind 4.8.3 but
they can't seem to find one.

They did find a shared libc with some sort of resolver in in but it 
doesn't work very well ..

-- 
thanks - Frank T-Y
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 21:27:34 GMT
From:      ubc-cs!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bigsur!bcars53!mussar@beaver.cs.washington.edu  (G. Mussar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X25 over IP
In article <1900@inria.inria.fr> dupont@inria.inria.fr (Francis Dupont) writes:
>In article <9011271721.AA06559@isis.u-strasbg.fr>, pansiot@ISIS.U-STRASBG.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes:
>> 
>> Is there a standard way to run X25 over IP (not the other way around, IP
>> over X25 ).  We would like to use our IP network to carry non IP traffic
>> over X25.
>> ...
>
>Cisco has a X.25 over TCP. It is useful for instance for PAD (X.3/X.28/X.29).
>(OSI applications can use RFC 1086 "ISO-TP0 bridge between TCP and X.25"
>but it is not possible for native usage of X.25 like PAD).
>The transport of X.25 packets over TCP connections is very simple,
>I've implemented it for Suns and I'm writing a description of it.
>
>Francis.Dupont@inria.fr

I would be interested in seeing some "standard" for carrying X.25 on TCP/IP.
It would be useful being able to have multiple vendors X.25/IP products
talking the same language. I have my own version which I use when remote
applications wish to access my X.25 port on my Sun across the LAN. Does
your implementation allow for M/D/Q bits set in packets? Has Cisco 
documented how their implementation works?
--
-------------------------------------------------------------------------------
Gary Mussar  |Bitnet:  mussar@bnr.ca                  |  Phone: (613) 763-4937
BNR Ltd.     |  UUCP:  ..uunet!bnrgate!bcars53!mussar |  FAX:   (613) 763-2626
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 21:44:07 GMT
From:      root%shiva@SHAKTI.ERNET.IN
To:        comp.protocols.tcp-ip
Subject:   (none)

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



Dear NetFolks,

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

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

Please send your card to:

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


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

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

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

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

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

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 23:00:24 GMT
From:      shlump.nac.dec.com!shug.enet.dec.com!ciarfella@decuac.dec.com  (Paul Ciarfella)
To:        tcp-ip@nic.ddn.mil
Subject:   ICMP Time Exceeded sent on non-initial fragments?

	RFC 1122 says that ICMP messages must not be generated as a
	result of receiving non-initial fragments of a datagram.

	But, what happens if reassembly of a datagram times out 
	and the initial fragment was never received.  Does this
	mean that I cannot send an ICMP Time Exceeded given that
	I don't have the initial fragment?

	Thanks,

	Paul C

  ---------------------------------------------------------------------------
    Paul Ciarfella        Digital Equipment Corporation      Littleton, MA
  ---------------------------------------------------------------------------
  Disclaimer : My opinions are my own.   |  When in doubt, mumble.
  Address    : ciarfella@shug.dec.com
  ---------------------------------------------------------------------------
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 23:13:35 GMT
From:      lll-crg.llnl.gov!booloo@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: reuse of addresses when calling bind()
In article <1990Nov30.202155.8253@bwdls61.bnr.ca> pww@bnr.ca (Peter Whittaker) writes:
>In article <86984@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>>If you setsockopt() with SO_REUSEADDR, as I understand it, you should be able
>>to issue a bind() for a ip/port address that is already in use.  However, it
>>appears that it is still possible for bind() to return the error EADDRINUSE 
>
>
>First, the original socket must have set SO_REUSEADDR - you cannot set it 
>retroactively.

This is the case.  Each socket wishing to bind to the same port number must 
issue a setsockopt() for SO_REUSEADDR.

>
>Second, two independent processes cannot bind to the same port no matter 
>what options are set.  SO_REUSEADDR allows the same process, or children of
>that process, to bind to same port (this is how ftp works:  one server binds
>its children to the same port, so all data flows from the same port).
>

This certainly isn't true.  The FTP server always binds to local port 20 for 
data connections.  The uniqueness of the connection must be guaranteed by the 
client's selection of a remote port.  Since it is possible for there to be
multiple instances of the ftp server running at one time, it is necessary to set
the data socket with the SO_REUSEADDR option. 

This issue is talked about in the Unix Programmer's Manual on page 8-31 (PS1).
Unfortunately, I still don't see how this particular error can occur once the
socket has been correctly setsockopt()'ed.

Thanks for the reply but I'm still confused.
mb
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      30 Nov 90 23:43:08 GMT
From:      sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs@lll-winken.llnl.gov  (Matthias Urlichs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Access Costs
In comp.protocols.tcp-ip, article <1990Nov29.212559.7284@spectrum.CMC.COM>,
<
< 	Crazy as it seems at first glance, dynamic IP addresses are
< not actually all that unusual. Client-only PC's often do this. And with
< domain name service, it is doable even to handle incoming connections.
< 
< 	Yes, it does create a few management hassles. You need to have a
< name server with a transaction interface to change the name/address
< mappings on the fly (where the run-of-the-mill BIND just reads a table
< when it is reloaded) and you cannot have management utilities that
< assume that name/address mappings are constant.
< 
Problem 1: Name server records get cached. A TTL of five minutes is probably
not a good idea.
Problem 2: What if my connection breaks (noisy phone line, idle connection
timeout) and I have to reconnect? Suddenly my IP number is different: and the
existing connection is broken for good. Not good either.

< 	As to WHY one wants to do this ? When you have a couple hundred
< PC's around, it is easier to just declare them to be generic than to try
< to keep track of locations and owners for all of them. Likewise, network
< providers may have only allocated class C network numbers for a routing
< cluster, and may prefer the dynamic addresses over changing backbone
< routing implementations with hardcoded netmasks.
< 
That might work for PCs or similar clients, but for external SLIP/PPP
connections (which might even have their own Class C network hanging off the
remote end) it seems to be preferable to give each client its own IP
address.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

END OF DOCUMENT