The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1992)
DOCUMENT: TCP-IP Distribution List for June 1992 (484 messages, 295826 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1992/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Mon, 01 Jun 1992 03:03:55 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Advice on network analyzers wanted

	Every so often someone posts, asking for advice on what network
analyzer to buy. I even saw a fairly complete survey go by, but my saved copy
has been munched recently. So:
	I need advice on a network analyzer similar to Novell's LANalyzer,
Network General's SNIFFER, HP's (Can't remember model number). I'm only
familiar with Novell's LANalyzer. We need to purchase one VERY QUICKLY (about
2 days, I beleive!).
	If anyone has a copy of a survey, or any general comments, could you
please email them to me? This has been hashed out before, so I see no need
for evryone to watch it go by again. I will summarize if enough people want
the information.
-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 1992 13:57:07 -0500
From:      holland@matt.ksu.ksu.edu (Rich Holland)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitor Emission snooping?

ranck@vtvm1.cc.vt.edu (Wm. L. Ranck) writes:

>>   Frankly, if you perceive that someone is THAT interested in your
>>data, you may also consider the RF emanation problem.  If I wanted to
>>steal your information, it's probably easier for me to sit outside your
>>office with about $200 worth of stuff from Radio Shack in my car...
>>and pick up the emanations from your monitor.  It may be much easier 
>>than trying to get a sniffer attached to your network.

[....]

>   I can believe that this could be feasible for an isolated monitor in
>the right circumstances, but it seems like it would take more than $200
>worth of Radio Shack parts.  Has anybody actually seen this sort of gadget
>work in a setting such as I described above?  If so, it is certainly
>worth serious thought because the stuff on your monitor screen is already
>conveniently decrypted for the snooper.

Does anyone have *ANY* references to materials/books/etc with plans, or
instructions, or even decent theory behind this?  I've always heard people
talking about these gadgets, but there seems to be a veil of secrecy when 
it comes to building a box to do it.  Hell, I'd just like the experience of
making one and setting it up across my basement, just to say I'd done it! 

 -- Rich

-- 
Rich Holland             | INTERNET:  holland@matt.ksu.ksu.edu
419 Marlatt Hall         | BITNET  :  holland@ksuvm
Manhattan, KS  66506     | UUCP    :  ...rutgers!matt.ksu.ksu.edu!holland
"Jesus saves...but Gretzky gets the rebound!  He shoots!  He scores!!"

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 09:01:01 GMT
From:      long@vax.ox.ac.uk (Neil J. Long)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: CUTCP in Windows 3.1

In article <1992May28.230748.1@vxdesy.desy.de> speth@vxdesy.desy.de writes:

>I just got Windows 3.1 installed and running off a Novell 3.11 server.  I felt
>like "kicking the tires" a bit, so I tried running CUTCP telnet from inside
>Windows.  It actually worked for a few minutes....and then all of a sudden
>dropped the connection, and Windows, and landed at DOS; this happened several
>times, alway after a few minutes.
 
>I'm running DOS 5.0 with the Windows 3.1 supplied versions of HIMEM.SYS, LSL, 
>IPXODI and NETX.  I'm using ODIPKT for the packet driver interface of CUTCP.
 
>Any suggestions? 
>Jan
HI 
I have been through similar problems. You need to use WINPKT.COM which will 
create a 'virtual' packet driver which is Windows aware. Using the default 
interrupt from ODIPKT (0x69 or decimal 105):-

WINPKT 'new_packet_driver_interrupt' 0x69

I had similar trouble with NCSA Telnet which worked fine using packet 
drivers but was very cranky based on LSL,IPXODI,ODIPKT,WINPKT - I stripped 
out a lot of 'default' check boxes in the PIF file and it seems okay now. 
I'm still back tracking to figure out where the sensitivity lies.

Until you find your magic PIF file you may find everything works fine under 
Windows 3.1 but then crashes horribly when you leave Windows :-)

You can find WINPKT almost anywhere that holds the current Crynwr Packet 
Drivers.

Neil Long

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 09:17:41 GMT
From:      sue@hardy.u.washington.edu (Shu-Chen Eclipse)
To:        comp.protocols.tcp-ip
Subject:   Novice Question: Telnet




Hello, I am accesing a Unix machine from a PC/Dos machine running PC-NFS telenet.
My problem is that when telenet makes the connection to Unix and I get a login
prompt and I misspell my user name, the backspace key only gives me ^H's, and
I have to use a delete key to backspace. Notice, I am NOT YET in Unix, so
adding stty erase ^H to my .login won't work.

How do I set PC-NFS TELENET so that I can use the backspace key for backspace
over characters I want to delete??

I noticed Pc-nfs telenet has a setup menu, but I don't see anything there about
backspace/erase: I seet auto-line feed (on), and null-cr, or cr-lf (on).

Any ideas?
thanx.
sue@hardy.u.washington.edu


-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 10:04:17 GMT
From:      sue@byron.u.washington.edu (Shu-Chen Eclipse)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Novice Question: booting TekXpress XP-27 with tftp.


Hello, 

I'm not sure if this is the proper group for this, but...

We were trying to boot TEktronix TeXpress Xp-27 from a Sun Sparc file server.
The autoboot fails. Manual Boot to download the /tftpboot/XP20/os boot file
fails with error saying it can't find the file. An ls on the server shows the
file just fine. Pinging the server seems ok.
Any ideas what we're doing wrong?
thanx.
sue@milton.u.washington.edu
.,


-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 10:33:17 GMT
From:      hansb@aie.nl (Hans Bayle)
To:        comp.protocols.tcp-ip.domains,comp.protocols,tcp-ip
Subject:   named configuration

We are using Interactive Unix SysV 386/ix rel. 3.2 vs. 3.0 with TCP/IP vs 1.3
and ran into a very interesting nameserver configuration problem. 
We are running a local TCP/IP + NFS network, that is *not* connected with
Internet. We are using UUCP for mail and news via Internet. This means that
our smail configuration should use the domain name (= aie.nl) that was given
to us by the NLUUG organization. We also want to use that domain name for
the rest of the machines in our network.
This means that the nameserver named that runs on a machine in our network,
should use the aie.nl domain extension, but logically also should be the root
nameserver for its own, because we don't have an Internet TCP/IP connection to
cache any data from outside domain authority nameservers. 
The problem is, that our nameserver with the configuration shown below keeps
complaining about missing root nameservers: the exact message is:

Jun 1 10:48:21 named[424]: No root nameserver for class 1.

When I look into the logfile of named, it seems that named comes to this
conclusion after each lookup request from a client.
Does anybody know how to configure named in such a way, that it knows that
it is its own root nameserver? Below is our current configuration.


; $Id: named.boot,v 1.1 1992/03/25 14:39:44 root Exp $
; $Source: /etc/nameserver/RCS/named.boot,v $
; $Author: root $
; $Date: 1992/03/25 14:39:44 $
;
; $Log: named.boot,v $
; Revision 1.1  1992/03/25  14:39:44  root
; Initial revision
;
;
;	Boot file for name server.
;	Hans Bayle, AI Engineering.
;
;type		domain			source file or host
;
domain		aie.nl
primary		aie.nl			/etc/nameserver/named.hosts
cache		.			/etc/nameserver/named.ca
primary		1.123.128.in-addr.arpa	/etc/nameserver/named.rev
primary		0.0.127.in-addr.arpa	/etc/nameserver/named.local



; $Id: named.ca,v 1.1 1992/03/25 14:39:44 root Exp $
; $Source: /etc/nameserver/RCS/named.ca,v $
; $Author: root $
; $Date: 1992/03/25 14:39:44 $
;
; $Log: named.ca,v $
; Revision 1.1  1992/03/25  14:39:44  root
; Initial revision
;
;
;	ca file for name server.
;	Hans Bayle, AI Engineering.
;
; This file should list the root nameservers for aie.nl ( .nl that is )
; We can't contact them
; Need a way to say the we are our own root root nameserver. But how?
; This file is intentionally empty. Do not remove it.
;
;type		domain			source file or host



; $Id: named.hosts,v 1.1 1992/03/25 14:39:44 root Exp $
; $Source: /etc/nameserver/RCS/named.hosts,v $
; $Author: root $
; $Date: 1992/03/25 14:39:44 $
;
; $Log: named.hosts,v $
; Revision 1.1  1992/03/25  14:39:44  root
; Initial revision
;
;
;	@(#)ucb-hosts	1.1 (berkely)
;	file: /etc/nameserver/named.hosts
;
;	Data file for Primary Master Server
;	running on aie5 ; Hans Bayle, AI Engineering
;
;name		ttl	record	data
;

@		IN	SOA	aie5 hansb.aie5 (
			1.4	; serial number of this file
			3600	; refresh time in secs, done by the sec. server
			60	; retry time in secs for secondary server check
			3600000	; upper limit in seconds
			3600 )	; minimum
		IN	NS	aie5
localhost	IN	A	127.1
;
aie		IN	A	128.123.1.4
		IN	HINFO	Mandax386/25 UNIX
;
;
aie1		IN	A	128.123.1.1
		IN	HINFO	Model80 Windows
;
;
aie2		IN	A	128.123.1.2
		IN	HINFO	Model80 (second)
;
;
banclient2	IN	A	128.123.2.3
		IN	HINFO	Model80 (second) in banyan vines
ban2		IN	CNAME	banclient2
;
;
aie3		IN	A	128.123.1.3	
		IN	HINFO	Mandax386/25 UNIX
;
;
aie4		IN	CNAME	aie
;
;
aie5		IN	A	128.123.1.5
		IN	HINFO	Style486/25 UNIX
;
;
tpn2		IN	A	128.123.1.80
		IN	HINFO	Eisa486/25 UNIX
;
;
aie6		IN	A	128.123.1.6
		IN	HINFO	486/33 UNIX
;
;
aie7		IN	A	128.123.1.7
		IN	HINFO	TMC486/33 UNIX
dbms		IN	CNAME	aie7
;
;
aie11		IN	A	128.123.1.11
		IN	HINFO	Style286/12 DOS
harrie		IN	CNAME	aie11
;
;
aie13		IN	A	128.123.1.13
		IN	HINFO	Style286/12 DOS
amand		IN	CNAME	aie13
;
;
aie15		IN	A	128.123.1.15
		IN	HINFO	Mandax386/25 DOS
server		IN	CNAME	aie15
;
;
sun1		IN	A	128.123.1.20
		IN	HINFO	Sparc2 Unix
sun		IN	CNAME	sun1
;
;
banyan1		IN	A	128.123.1.30
		IN	A	128.123.2.1
		IN	HINFO	Banyan server AI Lab
banserver	IN	CNAME	banyan1
ban		IN	CNAME	banyan1
;
;
aie31		IN	A	128.123.1.31
		IN	HINFO	Style 286/12 DOS
;
;
banclient1	IN	A	128.123.2.2
		IN	HINFO	Style 286/12 DOS in banyan vines
ban1		IN	CNAME	banclient1




; $Id: named.local,v 1.1 1992/03/25 14:39:44 root Exp $
; $Source: /etc/nameserver/RCS/named.local,v $
; $Author: root $
; $Date: 1992/03/25 14:39:44 $
;
;
; $Locker:  $
; $Resfile$
; $Reusing$
; $State: Exp $
;
;
; $Log: named.local,v $
; Revision 1.1  1992/03/25  14:39:44  root
; Initial revision
;
; 
;	@(#)named.local	1.1 (berkely)
;	Hans Bayle, AI Engineering
;

aie.nl.		IN	SOA	aie5.aie.nl. hansb.aie5.aie.nl. (
			1.4	; serial number of this file
			3600	; refresh time in secs, done by the sec. server
			60	; retry time in secs for secondary server check
			3600000	; upper limit in seconds
			3600 )	; minimum
		IN	NS	aie5.aie.nl.
1		IN	PTR	localhost.



; $Id: named.rev,v 1.1 1992/03/25 14:39:44 root Exp $
; $Source: /etc/nameserver/RCS/named.rev,v $
; $Author: root $
; $Date: 1992/03/25 14:39:44 $
;
; $Log: named.rev,v $
; Revision 1.1  1992/03/25  14:39:44  root
; Initial revision
;
;
;	@(#)named.hosts.rev 1.1 (berkely)
;	Hans Bayle, AI Engineering
;

1.123.128.in-addr.arpa.	IN	SOA	aie5.aie.nl. hansb.aie5.aie.nl. (
			1.2	; serial number of this file
			3600	; refresh time in secs, done by the sec. server
			300	; retry time in secs for secondary server check
			3600000	; upper limit in seconds
			3600 )	; minimum
		IN	NS	aie5.aie.nl.
		IN	NS	aie.aie.nl.
1		IN	PTR	aie1.aie.nl.
2		IN	PTR	aie2.aie.nl.
3		IN	PTR	aie3.aie.nl.
4		IN	PTR	aie.aie.nl.
5		IN	PTR	aie5.aie.nl.
6		IN	PTR	aie6.aie.nl.
7		IN	PTR	aie7.aie.nl.
11		IN	PTR	aie11.aie.nl.
13		IN	PTR	aie13.aie.nl.
15		IN	PTR	aie15.aie.nl.
20		IN	PTR	sun1.aie.nl.
80		IN	PTR	tpn2.aie.nl.


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

-- Hans Bayle		hansb@aie.nl
   Amsterdam

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


-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 10:43:00 GMT
From:      brr@abcom.ATT.COM (Rao)
To:        comp.protocols.tcp-ip
Subject:   Seeking Advice on Socket-based applications

I am trying to design (as an Academic exercise) a networked
application where over 500 terminals (users) on a LAN
use tcp-ip to get to a server on the LAN to access info
from a database.

Each user on the LAN can open a socket connection with the
corresponding server-application component on the server.

Question:
Can you have 500 (or more) socket based connection (one for each
LAN user), concurrent, for providing access to the server-side
component of the application?

Question:
Can a socket connection (LAN user client - to server application 
component) be kept up and used for long periods, say the whole
working day?

Question:
What are the sideeffects of having a server side application
that lets large numbers of users (clients) open up socket
connections? What potential problems can we expect?

Please provide some input, and alternate designs if possible.
Thanks in advance.

-bindu rama rao
(708)-293-0633

att.com!uxcom!brr

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 11:24:40 GMT
From:      gram@aim1.aztec.co.za (Graham Wheeler)
To:        comp.protocols.tcp-ip
Subject:   NetWatch

So where does one get NetWatch?

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   | 		Lao Tzu - Tao Te Ching Ch. 78
gram%aim1.uucp@olsa99.olive.co.za / gram@cs.uct.ac.za 

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 14:28:48 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!


There may be more going on here.  First off, I'd think that slow-start
wouldn't work well -- if you only bump up the effective window size
when you receive an ack, it's going to take quite a while to open it
all the way.  You can partially mitigate this by using large MTUs,
though.  Second, if the underlying link protocol has its own sliding
windows (i.e., X.25), you've got the original answer, but at another
layer.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 14:55:49 GMT
From:      ranck@vtvm1.cc.vt.edu (Wm. L. Ranck)
To:        comp.protocols.tcp-ip,comp.security.misc
Subject:   Monitor Emission snooping?

In article <1992May22.125355.5361@hellgate.utah.edu> rarobert@ursa4.cs.utah.edu (Robin Roberts) writes:

>   Frankly, if you perceive that someone is THAT interested in your
>data, you may also consider the RF emanation problem.  If I wanted to
>steal your information, it's probably easier for me to sit outside your
>office with about $200 worth of stuff from Radio Shack in my car...
>and pick up the emanations from your monitor.  It may be much easier 
>than trying to get a sniffer attached to your network.

   I have heard of this sort of thing before.  I've seen it mentioned
here before.  But, I find it somewhat hard to believe that monitor
emissions are a serious problem.  For example, I am in a building that
makes it almost impossible to listen to a radio because of the steel frame
construction.  How much of the low level RF from a monitor is even getting
to the parking lot?  Also, there are hundreds of PCs, terminals, and
workstations in this building (as most offices these days) so how is a
snooper going to get any coherent signal out of the noise?
   I can believe that this could be feasible for an isolated monitor in
the right circumstances, but it seems like it would take more than $200
worth of Radio Shack parts.  Has anybody actually seen this sort of gadget
work in a setting such as I described above?  If so, it is certainly
worth serious thought because the stuff on your monitor screen is already
conveniently decrypted for the snooper.

 *************************************************************************
 * Bill Ranck    __ O          DoD #0496           RANCK@VTVM1.CC.VT.EDU *
 *                // \                                                   *
 *              //      Lean it like you mean it!                        *
 *************************************************************************

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 15:32:20 GMT
From:      bvs@nastar.uucp (Bill Versteeg)
To:        comp.protocols.tcp-ip
Subject:   BSD reno telnetd unresolved variables



I am compiling the bsd4.3-RENO telnetd program under Microtec
cross-compilers. I get an unresolved reference to some
variables (like will_wont_resp[]) that are defined in ext.h.


The only time I find these variables defined is a 

extern char will_wont_resp[256]

in ext.h. The is no "non-external" declaration.

This causes me to get unresolved references at link time. Are
these variables defined somewhere that I am missing, or is
my compiler/linker being more stringent than the compiler/linker
normally use on this stuff?


Bill VerSteeg
VerSteeg CodeWorks

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 15:49:38 GMT
From:      eletanjm@nuscc.nus.sg (Tan Jin Meng @ NUS)
To:        comp.protocols.tcp-ip
Subject:   SLIP source

I would appreciate it if someone could mail me or point for me the
location of the source code (well documented if possible) for a SLIP
implemenation.

I am looking into the possibility of doing a TCP/IP implementation for a
PC ISDN card.

Thanks in advance.

- jin meng

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 17:28:07 GMT
From:      rwhughe@pbhyb.PacBell.COM (Bob W. Hughes)
To:        comp.protocols.tcp-ip
Subject:   Need KA9Q code for 68000

 Hi,
 I'm curious, is there a copy of KA9Q for the 68000 running
UNIX 5.3?

Thanks,

Bob Hughes


-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 18:08:49 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: Civilizing rdump?  Cheap bridges?  How not to swamp an Ethernet

[note followup-to comp.unix.misc - this is not IP related]

I write:
>	I have a simple hack called "rmtread"/"rmtwrite" that copies
>its standard input/output to/from a remote tape.

	I've had a couple of queries about this, so I've put it out for
FTP on decuac.dec.com, in ~ftp/pub/sources/rmtwrite.shar.Z

	It's unsupported, of course - right now it's *semi* unfinished -
a little buffing and polishing and it'd be pretty darn useful. As it is,
it enabled me to get backups done for quite a while. The focus is more
on disk to disk dumps than to tapes - some of the tape support could be
improved.

mjr.

This is the README:
------------------------------------------------------------------------
	these are a pair of tools I used to use to do dumps to disk over
the network.

rmtd - a daemon that is plug-compatible with rmt but can ALSO be started
from the inetd. it allows a simple specification of device access on a
host-by-host basis, and specification of files that can be written
to. [no dumping on /vmunix, thank you] the idea of rmtd is to allow remote
workstations to dump to a filesystem that gets backed up to tape later.
this way dumps can be asynchronous, and require no permissions.

rmtwrite - a user level program that allows you to shove the standard
input over the network to rmtd. there are lots of options that control
what to do if the remote device is full, or locked (locking is supported)
and so forth. the idea is that anyone can just do a
dump 9uf - | rmtwrite -f host:logicaldevice
any time during the day. there's no reason it can't be tar archives,
cpio, whatever
-- 
"...new therapies are on the horizon. The idea of mixing two drugs
together is showing great promise. Two drugs which seem to be the most
efficacious are AZT and DDT."     Dan Quayle, while visiting an AIDS Hospice

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 19:29:03 GMT
From:      speth@vxdesy.desy.de
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: CUTCP in Windows 3.1

Thanks to the many people who answered my question about Windows and CUTCP!

In summary, the problem is that the Windows memory manager swaps the packet
driver out of memory crashing CUTCP (and other network applications) running
in a DOS box.

There are many possible solutions.  The one I am now using (and have tested
for several hours on various machines with 100% success) is a shim called
WINPKT which runs on top of the packet driver (ODIPKT in my case) and creates
a packet driver interface which Windows does not swap out of memory.

WINPKT.COM and installation directions are available as \misc\WINPKT.ZIP from
netlab2.usu.edu via anonymous ftp.

My testing was all under Windows 3.1 enhanced mode, but the WINPKT docs say it
should work for "Windows 3 Enhanced mode" so I guess it works with Windows 3.0
too.  Note that I did not use a .pif file.

Another solution which I have not yet tested but which has been highly
recommended is WinQVT, a windows based telnet/ftp/mail package which looks to
be first rate (so far I've just read the docs).  WinQVT is available via
anonymous ftp from ftp.cica.indiana.edu as \pc\win3\desktop\QVTNET23.ZIP .

Cheers, Jan

Jan Speth                                         SPETH @ VXDESY.DESY.DE
Deutsches Elektronen Synchrotron, Hamburg         

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 19:48:20 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitor Emission snooping?

In article <ranck.162@vtvm1.cc.vt.edu>, ranck@vtvm1.cc.vt.edu (Wm. L. Ranck) writes:
|> In article <1992May22.125355.5361@hellgate.utah.edu> rarobert@ursa4.cs.utah.edu (Robin Roberts) writes:
|> 
|> >   Frankly, if you perceive that someone is THAT interested in your
|> >data, you may also consider the RF emanation problem.  If I wanted to
|> >steal your information, it's probably easier for me to sit outside your
|> >office with about $200 worth of stuff from Radio Shack in my car...
|> >and pick up the emanations from your monitor.  It may be much easier 
|> >than trying to get a sniffer attached to your network.
|> 
|>    I have heard of this sort of thing before.  I've seen it mentioned
|> here before.  But, I find it somewhat hard to believe that monitor
|> emissions are a serious problem.  For example, I am in a building that
|> makes it almost impossible to listen to a radio because of the steel frame
|> construction.  How much of the low level RF from a monitor is even getting
|> to the parking lot?  Also, there are hundreds of PCs, terminals, and
|> workstations in this building (as most offices these days) so how is a
|> snooper going to get any coherent signal out of the noise?
|>    I can believe that this could be feasible for an isolated monitor in
|> the right circumstances, but it seems like it would take more than $200
|> worth of Radio Shack parts.  Has anybody actually seen this sort of gadget
|> work in a setting such as I described above?  If so, it is certainly
|> worth serious thought because the stuff on your monitor screen is already
|> conveniently decrypted for the snooper.
|> 
|>  *************************************************************************
|>  * Bill Ranck    __ O          DoD #0496           RANCK@VTVM1.CC.VT.EDU *
|>  *                // \                                                   *
|>  *              //      Lean it like you mean it!                        *
|>  *************************************************************************

When I worked at Rockwell International in So. CA. there was a disturbance
at a local hotel overlooking the facility.  This facility, it was rumored,
contained a computer with siting information for defense missiles along
with other classified data.  The men in the hotel had rooms overlooking
the facility and had lots of electronic gear with them including dish 
antennas.  They and their gear were removed from the hotel and nothing made 
the local paper.  WE WERE CONCERNED.  Security WAS increased.  My area had
nothing to do with defense but all of a sudden we were being challenged 
more by security.  Management would not talk about it.  You can draw your
own conclusions (We did).
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 92 21:48:43 GMT
From:      fax@nic.near.net (Mr. Fax)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <1992May30.050716.13711@acc.com> art@acc.com (Art Berggreen) writes:
>...
>But if the FR is used to create "virtual networks" connecting a
>more constrained set of nodes (typically bridge/routers), then
>it is feasable to fully connect that set of nodes with PVCs.  In
>this model, the "virtual network" has one IP (sub)net number which
>is used for routing.  The appropriate PVC (and associated DLCI)
>is resolved from the next-hop IP address.

The nice thing about being able to interface one IP subnet to the
entire FRI is that you can put one protocol address on the entire
interface, learn about DLCIs from LMI, and autoconfigure your FR ARP
table using InARP.  No muss, no fuss for the NOC.  As simple as
Ethernet, except you have to roll your own "multicast" simulation.
> 
>If the FR connectivity is not full mesh, routing gets more difficult.  
>One can deal with this by treating the FR net as a large collection 
>of p-p links, but this tends to cause an increase in routing topology
>information (especially for OSPF).  

Not to mention all the subnet addresses and masks that must now be
configured into the router.  LMI/InARP gets more difficult now.  Might
as well attach each subnet address to each DLCI.  But wait, I don't
know what the DLCI number is going to be...  You can see how painful
this could get for managing a large partial mesh network.  It would be
easier if we could layer one protocol address onto partial mesh
topologies, but this won't work for OSPF, since it does not fit the
NBMA model.  (IETF OSPF WG is working on this.)  It also violates
assumptions in distance vector routing about split horizon.
> 
>Unfortuneatly, the pricing of FR services seems to encourage people 
>not to fully interconnect their nodes with PVCs.  This may save some 
>in PVC related charges, but careful traffic engineering must be done to 
>avoid having lots of traffic taking multiple hops across the FR net. 

Well, PVCs are like virtual serial lines and you engineer partial mesh
private line networks because you want to optimize costs.  Double
hopping in partial mesh private line nets is acceptable, so it should
be in FR as well.  If the FR network reserves bandwidth or commits
bandwidth for your PVC you will have to pay for it, although it should
cost less and be simpler to manage than private lines.  So I expected
partial mesh frame relay topologies would be popular.  Seems the
router vendors are somewhat surprised by this, based on what I have
seen.

--Kent

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Mon, 1 Jun 1992 22:51:51 GMT
From:      shields@nexus.yorku.ca (Paul Shields)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   RFC1116/1184 Telnet linemode option -- on VMS?

I am putting a Microvax onto the Internet.  The installation is
complicated by the existence of x.25 users connected to the Vax, whom
the phone company charges per-packet, so are in line-at-a-time mode.

Therefore I am looking for a VMS TCP/IP product that supports the
telnet linemode option described in rfc's 1116 and 1184.

I have asked DEC and TGV, and to my knowledge there are currently no
existing products that support it.

If you have references to software or other vendors or any other
advice I would appreciate any help,

thanks
Paul Shields
shields@web.apc.org


-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jun 1992 00:24:10 GMT
From:      mark_silbernagel@mentorg.com
To:        comp.protocols.tcp-ip
Subject:   Re: A class addresses (not assigned)

In article <1992May30.053139.10633@ddsw1.mcs.com> karl@ddsw1.mcs.com (Karl
Denninger) writes:
>In article <1992May29.234741.1386@thdhub.UUCP> tjg01@thdhub.UUCP (Terry
 Gardner) writes:
>>My company wants to use A class addresses that are not sanctioned
>>by the keepers of Internet addresses. We have a B class address
>>assigned to us, but the security folks don't want to have to
>>deal with the subnet masks. They would rather use an entire octet
>>to "subnet". We have a large corporate networking environment and
>>over 200 hosts across the country. My question is: What are the
>>ramifications of using an A class address that is not assigned to
>>us by the Internet people, with a possible gateway to Internet?
>

I agree with Karl and Marcus... Since I joined Mentor Graphics almost three
years ago we've been working to get away from 'made up' class A addressing
schemes. We've only a few small islands left, and like one of the other
posters mentioned must provide an access point or gateway between fantasy-land
and the Internet.

Of course, security drives the need for some well controlled access points
as well..  ;')

There are more and more good business reasons to keep from handcuffing
yourselves with this artifical constraint. The network addresses are there
for the asking and are 'free', so far. Subnetting isn't *that* painful, but
since it isn't default has an associated 'cost' in terms of administration.

If you have problems with subnetting, perhaps you could get a series of class
'A' networks (the 192 ones) and assign them by site. If no one site exceeds 254
users and isn't likely to saturate the network in a simple or bridged
configuration, it might work for you. Depends upon your network topology
and population characteristics (in other words, your mileage may vary).

Mark Silbernagel                |
Mentor Graphics Corporation     | ...Don't let the sands of time
8005 S.W. Boeckman Road         |    get in your shorts      ;')
Wilsonville, OR  97070-7777     |
(503) 685-4738                  |    mark_silbernagel@mentorg.com


-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 01:42:11 GMT
From:      shaun@softway.sw.oz.au (Shaun Arrundel)
To:        comp.protocols.tcp-ip
Subject:   Best ways to get high thru put on large delay leased line


	The organisation I work for has a 19.2K link between
Sydney and London (goes via New York). I have to set up a batch
script to copy approx 15MB of data every night. Whats the best ways
to copy the remote file ?. rpc, cp or tar from a remote mounted directory,
ftp, etc.

	Also how do I measure the performance I am getting in terms
of packets per second, round trip delay, bandwidth utilisation on a 
Sun sparc station. I can use nnstat to get sone summary data, ping
to get delays, but how do I find what tcp windows size is being used
and how do I change it.

	thanks

			shaun@swift.sw.oz.au

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 02:02:04 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: A class addresses (not assigned)

>I agree with Karl and Marcus... Since I joined Mentor Graphics almost three
>years ago we've been working to get away from 'made up' class A addressing
>schemes. We've only a few small islands left, and like one of the other
>posters mentioned must provide an access point or gateway between fantasy-land
>and the Internet.

	We provide the access point for security, not to isolate fantasy
land networks, but the basic effect is the same. One of the other ways that
the gateways are a big win is that in order to use them you have to be
on a correctly configured subnet of dec.com. When we put the pass-through
FTP gateway up, and coded its permissions file such that you had to be
properly registered (reverse lookup had to work and the whole bit) we
flushed a ton of backsliders.

	Best way I've ever seen to make people network right: offer them
good service and functionality if they play ball.

mjr.

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jun 1992 03:45:34 GMT
From:      mark_silbernagel@mentorg.com
To:        comp.protocols.tcp-ip
Subject:   Re: A class addresses (not assigned)

In article <1992Jun2.020204.942@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus
J. "will do TCP/IP for food" Ranum) writes:
>>I agree with Karl and Marcus... Since I joined Mentor Graphics almost three
>>years ago we've been working to get away from 'made up' class A addressing
>>schemes. We've only a few small islands left, and like one of the other
>>posters mentioned must provide an access point or gateway between
 fantasy-land
>>and the Internet.
>
>	We provide the access point for security, not to isolate fantasy
>land networks, but the basic effect is the same. One of the other ways that
>the gateways are a big win is that in order to use them you have to be
>on a correctly configured subnet of dec.com. When we put the pass-through
>FTP gateway up, and coded its permissions file such that you had to be
>properly registered (reverse lookup had to work and the whole bit) we
>flushed a ton of backsliders.
>
>	Best way I've ever seen to make people network right: offer them
>good service and functionality if they play ball.
>
>mjr.
>

Absolutely correct about the backsliders! Nothing like hearing they can't 
access the news machine until they're on a 'registered' network; It
works here too. That just leaves the few who don't really care . . .

BTW: I made, duh, 'the' silly mistake typing my first response. A 192.*.*.*
network is class 'C', of course. 

Mark Silbernagel                |
Mentor Graphics Corporation     | ...Don't let the sands of time
8005 S.W. Boeckman Road         |    get in your shorts      ;')
Wilsonville, OR  97070-7777     |
(503) 685-4738                  |    mark_silbernagel@mentorg.com


-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 04:03:48 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   nfs tracing with filenames?

Is there any ethernet nfs monitoring code that tracks file useage by filename?

I know of two partial answers.

  * The SRI "nfswatch" will track particular files specified in advance, but
     won't detect files by name

  * Matt Blaze reported on "nfstrace" at USENIX including filename reporting,
    but deleted this from the public distribution as being too fragile. In
    the readme Matt offers to supply the code on request, but I have had no
    luck reaching him.

---
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: Voice (404) 727-7963, FAX 727-5611


-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 10:36:16 GMT
From:      ojr@itk.unit.no (Ornulf Rodseth)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for iRMX?


Have anyone ported a TCP/IP implementation to iRMX? We are interested
in doing this for PC based architecture with a PC-bus Ethernet card.
Please mail, and I'll summarize if I get any info.

--
Ornulf Jan Rodseth M.Sc.	ojr@itk.unit.no
SINTEF Automatic Control	+(47 7) 594351 (direct) / 594375 (switchboard)
N-7034 TRONDHEIM, NORWAY	+(47 7) 594399 (fax)

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 10:56:58 GMT
From:      curmw@dcatla.uucp
To:        comp.protocols.tcp-ip
Subject:   Getting "on the internet"


We are investigating getting "on the internet" here; we currently get
a news/email feed via Georgia Tech's internet feed, but get no other
internet services.

We have received information about setting us up from both PERFORMANCE
SYSTEMS INTERNATIONAL and UUNET.  Does anyone have experience with
either of these companies, or better yet, have other advice about how
we could go about getting up and running with full internet services?  I
would very much apreciate it.

Thanks,

Rob Waterson
DCA, Inc
Atlanta, GA
(404) 442-4978
curmw@dcatla.uucp

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 13:15:13 GMT
From:      wstef@hubcap.clemson.edu (W. Gregg Stefancik)
To:        comp.protocols.tcp-ip
Subject:   Subnetting Query

Given a class B network say 130.127.0.0 is it possible to use different
subnet masks on the different physical subnets?  This appears to break
lots of things from my perspective.  Somewhere I got the impression that
the subnetmask had to remain constant throughout the network.

The ability to do this would of course be very adventageous when
thinking about efficient use of address space.

The following situation seems to create a routing nightmare at least if one
were to use RIP:

130.127.8.0 --- R1 ---  130.127.16.0 --- R2 ---- 130.127.32.0
255.255.254.0           255.255.255.0            255.255.255.0

How would packets from 130.127.32.2 destined for say 130.127.9.10 do the
right thing.  Using RIP I would expect to see a route for 130.127.8.0,
but not a route for 130.127.9.0 coming from R2. 


-- 
W. Gregg Stefancik
wstef@eng.clemson.edu

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 15:42:21 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting Query

In article <1992Jun2.131513.15795@hubcap.clemson.edu>, wstef@hubcap.clemson.edu (W. Gregg Stefancik) writes:
|> Given a class B network say 130.127.0.0 is it possible to use different
|> subnet masks on the different physical subnets?  This appears to break
|> lots of things from my perspective.  Somewhere I got the impression that
|> the subnetmask had to remain constant throughout the network.
|> 
|> The ability to do this would of course be very adventageous when
|> thinking about efficient use of address space.
|> 
|> The following situation seems to create a routing nightmare at least if one
|> were to use RIP:
|> 
|> 130.127.8.0 --- R1 ---  130.127.16.0 --- R2 ---- 130.127.32.0
|> 255.255.254.0           255.255.255.0            255.255.255.0
|> 
|> How would packets from 130.127.32.2 destined for say 130.127.9.10 do the
|> right thing.  Using RIP I would expect to see a route for 130.127.8.0,
|> but not a route for 130.127.9.0 coming from R2. 
|> 
|> 
|> -- 
|> W. Gregg Stefancik
|> wstef@eng.clemson.edu

What your asking for works if your routers use OSPF and their 
implementation supports variable length subnet masks.  If they
do your in luck, otherwise....


-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 15:52:02 GMT
From:      stank@snow.tek.com (Stan Kalinowski)
To:        comp.protocols.tcp-ip
Subject:   Re: Monitor Emission snooping?

In article <ranck.162@vtvm1.cc.vt.edu> ranck@vtvm1.cc.vt.edu (Wm. L. Ranck) writes:
	.
	.
	.
>   I have heard of this sort of thing before.  I've seen it mentioned
>here before.  But, I find it somewhat hard to believe that monitor
>emissions are a serious problem.  For example, I am in a building that
>makes it almost impossible to listen to a radio because of the steel frame
>construction.  How much of the low level RF from a monitor is even getting

I saw a demonstration of this a while back on TV.  I can't recall
which program it was, but the theme of the show was privacy.
Basically, they hired a detective to snoop on a display in a building
across the street.  As far as being able to pick out a single terminal
in a room of terminals, its a matter of having good antennas,
good detection equipment, and being able to move around the source
site to find a "window" that affords the best signal.  Given the
advanced signal processing capabilities available to our government
it seems to me that quality of EMI type snooping is simply a matter
of how desperate you are to see that data, the more technology that
is brought to bear, the more you can see.

This problem is well known and understood by security professionals.
A specific class of security called TEMPEST security addresses the
leakage of signals that may be intercepted.  A system is said to be
TEMPEST qualified when it meets the appropriate emissions standards.
They do things like add extra EMI shielding to system cabinets and
transparent conductive screens over the monitor face to reduce the
amount of emissions.  Typically, monitors are the most difficult thing
to shield while maintaining good ergonomic qualities.

							stank
--
US Mail: Stan Kalinowski, Tektronix, Inc., Network Displays Division
         PO Box 1000, MS 60-850, Wilsonville OR 97070   Phone:(503)-685-2458
e-mail:  {ucbvax,decvax,allegra,uw-beaver}!tektronix!orca!stank
    or   stank@orca.WV.TEK.COM

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 16:03:18 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnetting Query

In article <1992Jun2.131513.15795@hubcap.clemson.edu> wstef@hubcap.clemson.edu (W. Gregg Stefancik) writes:
>Given a class B network say 130.127.0.0 is it possible to use different
>subnet masks on the different physical subnets?  This appears to break
>lots of things from my perspective.  Somewhere I got the impression that
>the subnetmask had to remain constant throughout the network.
>
>The ability to do this would of course be very adventageous when
>thinking about efficient use of address space.
>
>The following situation seems to create a routing nightmare at least if one
>were to use RIP:
>
>130.127.8.0 --- R1 ---  130.127.16.0 --- R2 ---- 130.127.32.0
>255.255.254.0           255.255.255.0            255.255.255.0
>
>How would packets from 130.127.32.2 destined for say 130.127.9.10 do the
>right thing.  Using RIP I would expect to see a route for 130.127.8.0,
>but not a route for 130.127.9.0 coming from R2. 
>
>
>-- 
>W. Gregg Stefancik
>wstef@eng.clemson.edu

This depends heavily on your routers and routing protocols.  OSPF can handle
this situation by design.  RIP wasn't really designed to handle this, and
the routers have to be very careful about keeping track of subnet masks and
collapsing routing information properly when advertising routes to
nets with different levels of subnetting.  In general, routers based on
BSD Unix can not handle this.  Also note that it is fairly easy to create
subnets which are ambiguous and create a situation where a host doesn't
know if the destination is local or via a router.

I'd recommend against doing it unless you feel you understand the
routing implications.

Art

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 17:35:20 GMT
From:      tannerc@cu18.crl.aecl.ca (Chris Tanner)
To:        comp.protocols.tcp-ip
Subject:   TRAILERS

Hello

We have a TCP/IP network with a collection of UNIX systems, PC's, MAC's
and VMS (running Wollongong). Many of our UNIX systems and WIN/TCP can
be set up to use TRAILERS, but we have turned this off. 

Do TRAILERS work, and to they provide any improvements?

Thanks in advance.

Chris
-- 
Chris Tanner                  Email: tannerc@CU18.CRL.AECL.CA
AECL Research                 Phone: (613) 584-3311 X4053       
Chalk River, Ont.             FAX:   (613) 584-1082
Canada, K0J 1J0

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 18:19:55 GMT
From:      jh@etana.funet.fi (Juha Heinanen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

I have found that most current router implementations (and also
routing protocols) don't match very well with the fact that a single
physical interface can consist of several logical interfaces each
possibly with their own IP address and metrics, eg. access speed.
This problem doesn't only show up in FR, but also in X.25, SMDS, and
ATM.  Based on my experience I have got the feeling the whole old
internet routing model and routing protocols needs major revision.

-- Juha

Ps. If someone is interested in details, check the paper
datanet.tele.fi:frame-relay/jenc92-article.ps.
--
--	Juha Heinanen, FUNET, Finland, jh@funet.fi, +358 49 500958

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 18:29:34 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: TRAILERS

In article <1992Jun2.173520.11667@cu23.crl.aecl.ca> tannerc@cu18.crl.aecl.ca (Chris Tanner) writes:
>Hello
>
>We have a TCP/IP network with a collection of UNIX systems, PC's, MAC's
>and VMS (running Wollongong). Many of our UNIX systems and WIN/TCP can
>be set up to use TRAILERS, but we have turned this off. 
>
>Do TRAILERS work, and to they provide any improvements?
>
>Thanks in advance.
>
>Chris

Trailers should be considered obsolete and to be avoided.

TRAILERS very invented as a performance measure for BSD Unix running
on DEC VAX hardware.  Trailers are usually not supported outside
this environment, and likely wouldn't have any performance benefit
if they were.

Art

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 19:25:50 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: TRAILERS

tannerc@cu18.crl.aecl.ca (Chris Tanner) writes:
>Do TRAILERS work, and to they provide any improvements?

	Trailers were an experiment that was supposed to provide a
performance boost when one 4.xBSD Vax was talking to another 4.xBSD Vax.
It took advantage of some details of Vax memory management.  It's not clear
if it even did any good in the intended environment, and it certainly
doesn't work between other machines.

	My recommendation is that it should be disabled on every machine,
regardless of hardware or OS type.
-- 
roy@wombat.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 19:52:15 GMT
From:      brown@jho.com (Jim Brown)
To:        comp.protocols.tcp-ip
Subject:   How do acknowledges work in the TCP protocol?

In the world of TCP/IP, if a process returns with a successful return from
(for example) a write call, is the process assured that the message has been
successfully sent and acknowledged back to the sending process?

In other words, is the write/read process a synchronous process?  Or does
the write complete without the sending process knowing that the buffer was
sent?

--
uupsi!jho!brown

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 20:11:25 GMT
From:      wag5@quads.uchicago.edu (john peter wagner)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

Many of you seem to be concerned with securing lines.  There may be a
physical way of doing it as follows;
	Between a sender and receiver of data have an electronic
pulse sent periodically, perhaps ten pulses per second.
There will be a certain voltage drop in the current which is related
to the distance traveled through the conducting medium and on the
resistance of the conducting medium itself.  If, when the network
is first set up, the transmitter and receiver both measure this
voltage drop, at any time in the future when there is a sudden
change or repetitively significant change in this voltage
drop, which would come from a drain caused by a physical security
breach.  The Transmitter or receiver which notices the modified
current/voltage could then send the information to a central
computer which would use the results from various sources tro
determine which section of the net is contaminated.  It could
then notify people in charge of security or it could immediately
reroute the network, if that could be accomplished.
	If the hacker is caught in the act obviously a source
of peril can be eliminated for at least a while.
	One problem which might come up is the possibility
that the hacker could place a number of coils around the circumference
of the cable and hook them up to amplifiers, to read a signal.
Unless the coils are very passive there would be a voltage drain.
Thus the coils would have to be very sensitive.  Another wire might
then be sent through the cable to provide jamming or confusing
effects.  The hacker would have to then write some software
to eliminate the extraneous wave, which I would suggest should
be for all purpose generated by a random number generator timed
or seeded from root login times.
	The key to this scenario is that connections between
devices/paraphernalia must be taken care of by the paraphernalia
themselves; otherwise an intelligent hacker could use the
information gleaned from one hack to infiltrate the entire
net by any means chosen.

				J. Wagner
.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1992 20:35:08 GMT
From:      tcpdump@ee.lbl.gov
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   tcpdump version 2.2 released

Version 2.2 of tcpdump is now available for anonymous ftp from
ftp.ee.lbl.gov (128.3.112.20), in the compressed tarchive
tcpdump-2.2.tar.Z.  Tcpdump is a tool for monitoring network traffic
and collecting packet traces.

The latest version of the Berkeley/BSD Packet Filter (BPF) is also
included in the tarchive.  (BPF, like SunOS Streams NIT and the Ultrix
packetfilter, provides user level access to network interfaces.)
BPF is the stock interface for 4.4BSD, and can be dropped into SunOS
as an (efficient) replacement for Streams NIT.  (NOTE: YOU NEED FULL 
SUNOS SOURCE TO INSTALL BPF IN SUN KERNELS.)  There have been a few
bug fixes to BPF, and tcpdump is incompatible with previous BPF releases,
so BPF users should bring their kernels up to date.  The interface is 
now stable and future releases will be backward compatible.

Changes to tcpdump include:

- Easy access to icmp packets, via the 'icmp' keyword.  For example,

	% tcpdump 'icmp[0] != 8 and icmp[0] != 0'

  matches non-echo/reply ICMP packets.

- An improved filter code optimizer.

- A multicast keyword.  Also, the broadcast keyword can now be qualified 
  with a protocol layer.  For instance, "ip broadcast" and "ether multicast"
  are valid filters.

- Support for monitoring the loopback interface (i.e. 'tcpdump -i lo').
  Jeffrey Honig (jch@MITCHELL.CIT.CORNELL.EDU) contributed the kernel
  patches for netinet/if_loop.c.

- Support for the Ungermann-Bass Ethernet on IBM/PC-RTs running AOS.
  Contact Jeffrey Honig for the diffs.

- Decoding of EGP and OSPF packets, thanks to Jeffrey Honig.

- The tcpslice program, thanks to Vern Paxson (vern@ee.lbl.gov).  Tcpslice
  is a tool for manipulating large trace files -- check out the man page
  (tcpslice.1) for more information.

Problems, bugs, questions, desirable enhancements, etc., should be sent
to the email address "tcpdump@ee.lbl.gov".  We welcome all such feedback.

 - Steve McCanne (mccanne@ee.lbl.gov)
   Craig Leres (leres@ee.lbl.gov)
   Van Jacobson (van@ee.lbl.gov)

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 20:55:49 GMT
From:      tan@ct.mcd.mot.com (Tan Bronson)
To:        comp.protocols.tcp-ip
Subject:   reliable broadcast of files ?


    We've got a customer who needs to update 15-20 nodes with a 1M byte
file 'ASAP' via ethernet. They were using sequential rcp's, but this was
too slow.  I've written a trivial broadcast file transfer program
(hacked from rwhod), but without any handshake this program is prone
to network errors.

    Does PD code exist which supports a form of reliable broadcasting?
I was thinking of writing my own, but I'm hoping someone has already
done it!

    Any clues would be greatly appreciated

    thanks
	tan
p.s. I don't have internet access :-(
-- 
Tan Bronson, TSD Systems Engineer	Email:	tan@ct.mcd.mot.com
Motorola, Wallingford Ct 06492		Voice:	(203)-949-4140

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 21:01:25 GMT
From:      psn6493@usl.edu (Nagpal Prakash S)
To:        comp.databases,comp.networks,comp.tcpip
Subject:   SQL - sun interface

Hey folks! 
Anyone out there worked on running sql queries off of a sun worksation,
( sql host being the ibm - 3090 ). The code on the ibm side requires the 
use of RPC at the other end. I would appreciate any help on this subject.
Thanks in advance.
Prakash.
prakash@usl.edu  


-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 1992 21:20:25 GMT
From:      ellozy@farber.dfci.harvard.edu (Mohamed Ellozy)
To:        comp.protocols.tcp-ip
Subject:   Robust NFS for Macs

A couple of days ago I posted the following to comp.protocols.appletalk,
got one reply from a vendor and zero replies from users!

    I would appreciate experience with using various NFS products for the
    Mac over Ethernet.  We will be sharing rather large files (5 to 50 Meg)
    between Macs, PCs and a Sparc acting as file and partial compute
    server.

    For our purposes robustness and vendor responsiveness are more important
    than price.  Above all, robustness (Maytag repairman need not be very
    responsive!).

    Thanks.

    Mohamed

I really would appreciate user experiences.

Mohamed

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 92 21:28:04 GMT
From:      rob@jdsny.com (Rob Yampolsky)
To:        comp.protocols.tcp-ip
Subject:   SLIP over a modem

Are there any restrictions on modem error correction or flow control
when running SLIP over a modem?  For example, I've been told that uucp
will not work if your modem is set up for XON/XOFF flow control.

I am trying to test SLIP connecting two ISC version 3.0 systems using 
Hayes smartmodem 9600's.  I am able to establish a 9600 baud connection and 
start up an 'rlogin' session between the machines; however, there are large
echo delays, and eventually the session hangs.  The modems default (I think)
to some kind of error checking mode, and before I mess with them, I thought
I'd ask.

Eventually, I plan to run SLIP over a leased 56Kb line.  Any comments on
using ethernet routers instead?  SLIP's got to be cheaper, but does it really
work reliably?  For that matter, do routers?

-- 
================================================================
=     Mail replies appreciated if possible (who has time to    =
=     read this stuff?)               Thanks, rob@jdsny.com    =
================================================================

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jun 1992 22:52:35 GMT
From:      mirza@seine.eng.ohio-state.edu (Khalid Mirza)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Question about transfer rates on Ethernet

I am evaluating the feasibility of a Sun Sparcstation based high
performance machine tool controller.  The setup consists of two
Sparcstations connected through an Ethernet, with one Sparcstation
performing the low-level real-time control tasks, and the other
performing the high-level planning tasks.

My questions are about the performance of such a setup regarding the
transfer rate of messages across Ethernet using TCP sockets:

1.  What is the time required to send a 4k byte message from one
    workstation to another.  Is this a "constant" time for two
    dedicated workstations, since a predictable time is an essential 
    requirement for real-time control.

2.  What is the optimal message size for fastest transfer of data 
    between the two workstations.

3.  Is any other protocol (e.g. MAP) better than TCP for this 
    purpose to obtain better transfer rates. 

I would appreciate any help answering these questions or if
somebody would point me in the right direction where to get these
answers.  Thanks in advance.

Khalid
--
Khalid Mirza
The Ohio State University                 mirza@ee.eng.ohio-state.edu
Columbus, Ohio 43210                      Phone: (614) 293-9638
-- 
Khalid Mirza                              DIGITS Robotic Hand Project
Dreese Lab, Room 569                      Internet FAX Project
The Ohio State University                 mirza@ee.eng.ohio-state.edu
Columbus, Ohio 43210                      Phone: (614) 293-9638

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 00:13:32 GMT
From:      medici@dorm.rutgers.edu (Mark Medici)
To:        comp.os.ms-windows.apps,comp.protocols.ibm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   tn3270 under MS-Windows (PC/DOS) with Novell ODI stack


We are looking for MS-DOS/MS-Windows based tn3270 (3270 emulation over
TCP/IP networks) software compatible with Novell's ODI client stack.


Rutgers University  is a state  university in New  Jersey with approx-
imately 50,000 students and 10,000 faculty/staff  members on its three
main  campuses.  There are an  estimated 4,000  IBM/compatible PCs, of
which about 1/6 run MS-Windows on a  regular basis.   At  the present,
about 1/4 of all PCs have access to our campus-wide network.  We use a
variety of network protocols, but the most prevalent on PCs in NetWare
(IPX/SPX) and TCP/IP.

The standard PC   network  configuration is   the  current release  of
Novell's DOS  ODI  client shell with a   packet-driver   shim for ODI,
(ODIPKT), which allows  concurrent  NetWare and  TCP/IP  access.   The
supported network topology is Ethernet,  though there are two or three
Token-Ring and  ArcNet sites.  We use  Clarkson University's or NCSA's
character mode Telnet,  FTP and  tn3270 to  access  a  variety of UNIX
hosts  (mostly Suns),  some DEC  mini's and VaxStations,  and  two IBM
Mainframes running TCP/IP.  Windows  users have  found WinQVT/Net  the
best solution in this environment.

Rutgers is only  now beginning to officially  support  the  MS-Windows
environment.    We  have   selected a   number    of  bread-and-butter
applications and are putting together support infrastructure and lists
of recommended and supported software.   Though it  is not a  standard
need,  there  is some demand   for  MS-Windows based tn3270  software.
However, we have not yet been able to identify any suitable candidates
for use  in our  environment.  This is  a  growing problem, because we
would prefer to announce a recommended/supported tn3270 package before
the user base becomes too fragmented (which makes support harder).

So, I am posing this question  in the hope  of getting some solutions.
We need a product that  provides tn3270 access  within  the MS-Windows
environment.   Ideally,   the product  would   provide  the  following
features:

     -  Full  effective  use of the MS-Windows  environment, including
	pull-down menus, dialog boxes and on-line help.
     -	A button-bar or  floating   box that provides quick  access to
	3270 keys not normally or easily available on a PC keyboard.
     -  IND$FILE file transfer support.
     -	Ability to change fonts, font sizes and screen geometry, using
	fonts available via MS-Windows.

     -  Compatibility with Novell's ODI stack for MS-DOS clients.
     -	Ability to  run  over FTP  Software  Inc's PDS Ethernet packet
	driver (PDS = Packet Driver Spec), implemented via ODIPKT;
     *** OR ***
        Ability to run over FTP Software's PC-TCP kernel;
     *** OR ***
	Ability  to run over  Novell's LAN  Workplace  for  DOS TCP/IP
	kernel.

Of the  above,  we would prefer to be  able to  maintain compatibility
with our existing TCP/IP applications.   This  means staying with  the
ODI  stack and ODIPKT.  If this  is not possible,  we would consider a
package  that uses  FTP Software  Inc's  PC-TCP transport  kernel  for
TCP/IP, as this  will be an alternative configuration  for users  that
require X-Windows support and may still allow the  use of some  of our
standard TCP/IP software.

If you have any recommendations for a product, please mail  me direct-
ly.  I will summarize all responses and post them on request.
-- 
_________________________________________________________________________
RUCS     | Mark A. Medici, Systems Programmer III, User Services Division
User     | Rutgers University Computing Services, New Brunswick, NJ 08903
Services | [medici@gandalf.rutgers.edu]                    [908-932-2412]

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 06:15:03 GMT
From:      ofer@GENIUS.TAU.AC.IL (Ofer Lapid 4X6OJ)
To:        alt.sources.wanted,comp.dcom.lans.novell,comp.os.msdos.desqview,comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.sun.wanted,comp.unix.questions
Subject:   Wanted: NetBios or IPX driver for unix to talk with DV/X


Since DV/X is a looking like the best X windows solution for PCs and since it
lacks TCP/IP at the basic price I was thinking perhaps a different aproach
will save us all a lot of money....

DV/X encapsulated X-Protocol within NetBios or IPX packets and sends over the
lan to its peer.

What I am looking for is a driver for a unix machine (preferrably a sun) which
will do the same thing on the UNIX server and allow DV/X to act as an Xterminal
to the UNIX.

Had it been done?

Any ideas?

Ofer

-- 
Ofer Lapid 4X6OJ
E-mail: ofer@genius.tau.ac.il
Packet: 4X6OJ%4X1GP@4X4HF

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 07:02:23 GMT
From:      thorson@typhoon.atmos.colostate.edu (Bill Thorson)
To:        comp.protocols.tcp-ip
Subject:   Learning SLIP but having problems


  
  I have been trying to get a slip connection between two machines.  The
first is my NeXTStation at home.  I have a slip implimentation that should
work fine.  The other machine is trouble.  It is a Sun386i.  I found
the slip_sun4.0 version on the archives and got the kernal reconfigured
and think I'm fireing it up correctly.  First I will show the Sun's
configuration and problems and then I will show a log of the NeXT's
session and it's configuration.

  I sure hope someone can let me know what I'm doing wrong or if it's
a sliplogin problem.

Bill

==========================SUN386============================================
$netstat -r
Routing tables
Destination          Gateway              Flags    Refcnt Use        Interface
bob                  typhoonS             UH       0      0          slip0
default              atmos-gw             UG       0      1375       ie0
csu-atmos-ether      typhoon              U        3      605        ie0
localnet             localhost            U        3      828        lo0

/etc/hosts:
129.82.107.24  typhoon  typhoon.atmos.colostate.edu
129.82.107.201 typhoonS typhoonS.atmos.colostate.edu
129.82.107.200 bob bob.atmos.colostate.edu

/etc/passwd:
sliptest:hXG2j5i6ULtgo:300:3:SLIP Account::/usr/local/bin/sliplogin

==========================NeXT (at home) ====================================
bob# netstat -r
Routing tables
Destination      Gateway            Flags     Refs     Use  Interface
bob              localhost          UH          0        0  lo0
typhoon          bob                UH          0        0  slip0
localhost        localhost          UH          0      244  lo0
default          typhoon            UG          0        0  slip0
default          129.82.107.24      UG          0        0  slip0
129.82.107       129.82.107.250     U           5     1492  en0

bob# nidump hosts .
127.0.0.1       localhost 
255.255.255.255         broadcasthost 
129.82.103.11   csu-ts.UCC.ColoState.EDU 
129.82.107.201  typhoon typhoon.atmos.colostate.edu 
129.82.107.200  bob bob.atmos.colostate.edu 

============================ SLIP Session from bob ========================
Jun  3 00:11:22 bob diald-slip0[444]: (Dialing 555-1234)
Jun  3 00:12:07 bob diald-slip0[444]: (Connected 38400)
Jun  3 00:12:07 bob diald-slip0[444]: (Begin Unix login)
Jun  3 00:12:11 bob mach: duinit: unit 0 ds x10e0e000
Jun  3 00:12:11 bob diald-slip0[444]: (Entering SLIP mode)
Jun  3 00:12:11 bob diald-slip0[444]: duconnect: Did SIOCSIFADDR on "slip0"
Jun  3 00:12:11 bob diald-slip0[444]: Changing silo delay for /dev/cub from 13000 usec
Jun  3 00:12:11 bob diald-slip0[444]: Connected to "typhoon.atmos.colostate.edu" via "slip0"
Jun  3 00:12:11 bob diald-slip0[444]: (Link UP event (bringup) for slip0 for typhoon.atmos.colostate.edu)
Jun  3 00:12:11 bob diald-slip0[444]: Timeout for "slip0" set to 9999999
Jun  3 00:12:11 bob diald-slip0[444]: Outbound interface "slip0" starting ipkts = 0, opkts = 0
Jun  3 00:12:11 bob diald-slip0[444]: (slip0/typhoon.atmos.colostate.edu IF flags changed from 0x0 => 0x11)
Jun  3 00:12:11 bob diald-slip0[444]: (slip0/typhoon.atmos.colostate.edu SOFT flags changed from 0x0 => 0x120)
Jun  3 00:12:11 bob diald-slip0[444]: makecasignal 0 for "slip0"
Jun  3 00:12:11 bob mach: dutclose line xbc1
Jun  3 00:12:11 bob mach: dutnetclose: ds  3 00:12:11 boblip0[444]: hangup: Inpackets = 0, Outpackets = 0, Average = 0.00 packets/sec
Jun  3 00:12:11 bob diald-slip0[444]: Timeout for "slip0" set to 10000000
Jun  3 00:12:11 bob diald-slip0[444]: hangb diald-slip0[444]: (Link DOWN event for slip0 for typhoon.atmos.colostate.edu)
Jun  3 00:12:12 bob tcldiald[120]: Child pid 444 for slip0/typhoon.atmos.colostate.edu exited.

============================= syslog on typhoon =============================
Jun  3 00:12:28 typhoon sliplogin[747]: ioctl (I_PUSH): Not owner
Jun  3 00:12:28 typhoon sliplogin[747]: ioctl (I_PUSH): Not owner

 
======================= the part of sliplogin that errors ===================
        /* set up the line parameters */
        if (ioctl(SLIPFD, TCGETS, (caddr_t)&tios) < 0) {
                syslog(LOG_ERR, "ioctl (TCGETS): %m");
                exit(1);
        }
        tios.c_cflag &= (CRTSCTS | 0xf);   /* only save the speed and CTSRTS */
        tios.c_cflag |= CS8|CREAD|HUPCL;
        tios.c_iflag = IGNBRK;
        if (ioctl(SLIPFD, TCSETS, (caddr_t)&tios) < 0) {
                syslog(LOG_ERR, "ioctl (TCSETS): %m");
                exit(1);
        }

        /* push the SLIP module */
        if (ioctl(SLIPFD, I_PUSH, "slip") < 0) {
                syslog(LOG_ERR, "ioctl (I_PUSH): %m");
                exit(1);
        }


-- 
#!/bin/sh
#-----------------------------------------------------------------------#
echo Bill Thorson                   thorson@typhoon.atmos.colostate.edu
echo Dept of Atmospheric Science    +1 303 491-8339
echo Colorado State University
echo Ft. Collins,  CO  80523
#-----------------------------------------------------------------------#

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 19:35:47 -0700
From:      ewilts@galaxy.gov.bc.ca (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun3.235852.9683@PacBell.COM>, restock@srv.PacBell.COM (Bob Stockwell) writes:
> What are the consequences of configuring two hosts with the same IP
> addresses, accidentally?  If I understand ARP correctly, they would
> both reply to an ARP request, and the ARP requestor would update the
> ARP table with the last reply.  This could cause a lot of confusion.
> Does anybody have experience with this problem?  Is there a suggested
> way of avoiding and/or detecting the problem?  We are moving from a
> NetBIOS network to an IP network.  In NetBIOS you must broadcast your
> intention to use a NetBIOS name, before using it.  Is there a similar
> protocol for IP, which would broadcast within a subnet?

We did once on two Vax/VMS systems running MultiNet.  TCP/IP traffic heading to
one of the systems (I forget which one) hung.  It cost us a system reboot :-(

-- 

Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 12:11:36 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!

In article <87305@bu.edu>, apollo@buengc.bu.edu (Doug A. Chan) writes:
> I'm currently taking care of a WAN which includes a link between the US
> and Japan.  The link currently has 256K bandwidth with approx. 128ms
> round trip delay.  However, recently, our carrier had a undersea fiber
> repeater failure and our link was routed over satellite.  Our 128ms
> round trip delay became 600ms after the re-route.
> 
> Using rcp to copy files between the US and Japan nodes, our average
> thruput on that 256kbps link w/128ms delay was about 120kbps.
> That's about 50% utilization!  Not very impressive at all.
> 
> Now, when that link was routed over satellite, the thruput dropped to
> 33kbps (13% utilization)...

This is a very interesting problem. As pointed out in many answers, the
limitation is probably due to TCP flow control at the receiving end, which
would not advertize enough credits. Back of the enveloppe computations shows
that you would need 8 to 10KO with the "undersea" line, 20 to 24 KO with the
"satellite" line. The figures you quote correspond to a buffer size of 1.9 KO
for "undersea", 2.5 KO for "satellite" -- which tends to tell us that there
might be something more going on. In any case, you should check that, and try
to either update the default size of the receiving buffer, or use a
"setsockopt" option (or whatever is available on your PC) to change this on a
perconnection basis.

I dont know what implementation of TCP is available on your PCs. A "state of
the art" implementation should incorporate Van Jacobson "slow start" algorithm
which adapt the "congestion window" at the emitter, thus allowing the receiver
to advertize very large windows without saturating the network. However, VJ's
algorithm was first tested for the interconnection of two Ethernets through a
short distance 56kbps link; some numerical parameters of the algorithm can be
inadequate in your configurations, for at least two reasons:

* it takes about 5 round trip delays for the slow start algorithm to converge
to the 24 kO window if you use packets of 1.5 KO, 7 if you use packets of 
512 O. This is equivalent to a penalty of 3 to 4 sec per file transfer
(actually, per TCP connection) in the "satellite" case, and is probably
very noticeable if you are transfering "small" files.

* using very large windows in a long delay path can lead to "clustering of
packets" in some conditions, in particular if you have bilateral trafic. In
that case, there is a chance that your PC will send a "train" of 20
consecutives packets, that might "swamp" the gateway between Ethernet and
link, leading to a packet loss. TCP will correct that loss, but the "slow
start" algorithm will, here again, penalize you with the equivalent of 3 to 4
sec of silence.

Could you mail me more detailed information on what exactly occured?

Christian Huitema

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 13:25:21 GMT
From:      felix@escape.vsse.in-berlin.de (Felix the double Helix)
To:        comp.protocols.tcp-ip
Subject:   NCSA telnet and ET4000 vga-boards

hi!

i have the feeling that NCSA telnet doesn't work with ET-4000 VGA video
boards. at least i found that out empirically. on three different
computers equipped with an et-4000 board ncsa telnet just hung (not
even ctrl-alt-del worked anymore), and by changing the vga card in one
of them it worked instantly.

is the bug known yet? or has it been fixed already? i think i got the
latest version from simtel about two months ago, i'm sorry i don't
remember the version number, since i don't use ms-dog at home ;-)

so long,
	felix
-- 
Felix Gaehtgens, Homburger Str. 26, 6000 Frankfurt/main(argc, argv) 90, FRG
EMAIL: felix@escape.vsse.in-berlin.de - mount: Warning: /dev/africa mounted as /

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jun 1992 13:25:33 GMT
From:      mark@homebase.vistachrome.com (Mark Alexander)
To:        comp.protocols.tcp-ip
Subject:   Help using FTP protocol to transfer inside C program

I am seeking advice on using the FTP protocol to communicate and transfer files
with FTP sites from within a C program.  What I plan to do is initiate FTP
at the remote site from my program and handle the request and transfer within my
program instead of letting the FTP implementation on the local machine handle
it.  It may be that I can handle the Protocol Interpreting and let the local FTP
handle the Data Transfer.  I don't know what I should do yet.  I need to use
FTP services to provdide file access to an application without letting errors
interfere and with the application indicating to the user when the access
is not successful.  Perhaps there is a better way.

The work I am doing is for my Masters Thesis at Florida State University.

Any comments are appreciated.

Mark 

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 13:51:46 GMT
From:      danson@lgc.com (Doug Anson)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a modem

In article <1992Jun2.212804.4582@jdsny.com>, rob@jdsny.com (Rob Yampolsky) writes:
|> Are there any restrictions on modem error correction or flow control
|> when running SLIP over a modem?  For example, I've been told that uucp
|> will not work if your modem is set up for XON/XOFF flow control.
|> 
|> I am trying to test SLIP connecting two ISC version 3.0 systems using 
|> Hayes smartmodem 9600's.  I am able to establish a 9600 baud connection and 
|> start up an 'rlogin' session between the machines; however, there are large
|> echo delays, and eventually the session hangs.  The modems default (I think)
|> to some kind of error checking mode, and before I mess with them, I thought
|> I'd ask.
|> 
|> Eventually, I plan to run SLIP over a leased 56Kb line.  Any comments on
|> using ethernet routers instead?  SLIP's got to be cheaper, but does it really
|> work reliably?  For that matter, do routers?
|> 
|> -- 
|> ================================================================
|> =     Mail replies appreciated if possible (who has time to    =
|> =     read this stuff?)               Thanks, rob@jdsny.com    =
|> ================================================================

I have experienced the same problems setting up SLIP between SVR4 at 2400 baud
and a Zylogics Annex II terminal server. Basically I am able to bring up slip,
do a couple of fingers, etc (BTW, the finger(1) reply will dump the correct
output but will then wait and wait and wait -- it doesnt seem to exit cleanly.
I know it is not my finger program, etc because I have set up slip with the
same workstation and a sun SPARC at 2400 baud -- everything worked great then).

After a couple of fingers, the session simply hangs.  The Annex II is connected
to TeleBit T2000 rack modems.  I am running them at 2400 baud (so I believe
PEP is not running at that speed).  XON/XOFF flow control is on however I have
tried shutting that off -- the sessions still hang.

Anyone else out there had this type of problem with SL/IP?

Any gentle help, pointers greatly appreciated.
doug

-------------------------------------------
Doug Anson					
Internet: danson@lgc.com			
Phone:	  713-579-4739
SNAIL:    Landmark Graphics Corporation LGC	
	  333 Cypress Run			
	  Houston, TX 77094			
-------------------------------------------

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jun 1992 14:25:49 GMT
From:      holemans@reks.uia.ac.be (Wim Holemans)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   emulex terminal servers

Hi,

we have two Emulex P4000 terminal servers with TCPIP/LAT support. We are
using software release 2.1.
We have one terminal server with 16 ports and one with an extra extention
of 16 ports (so 32 ports). We have severe performance problems on the terminal
server with 32 ports even when there are just 3 or 4 users on it and the
show server status command just gives an max cpu usage of 56 %.

has anyone similar experiences and solutions ? 

I have a second question. Has anyone used used the slip options of these
terminal servers before and how did you set this up ?

Greetings,

W. Holemans
Network/System manager
holemans@reks.uia.ac.be


-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jun 1992 15:13:25 GMT
From:      joer@inca.law.csuohio.edu (Joe Rosenfeld)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a modem

In article <1992Jun2.212804.4582@jdsny.com> rob@jdsny.com (Rob Yampolsky) writes:
>From: rob@jdsny.com (Rob Yampolsky)
>Subject: SLIP over a modem
>Date: 2 Jun 92 21:28:04 GMT
 
>Are there any restrictions on modem error correction or flow control
>when running SLIP over a modem?  For example, I've been told that uucp
>will not work if your modem is set up for XON/XOFF flow control.
 
>I am trying to test SLIP connecting two ISC version 3.0 systems using 
>Hayes smartmodem 9600's.  I am able to establish a 9600 baud connection and 
>start up an 'rlogin' session between the machines; however, there are large
>echo delays, and eventually the session hangs.  The modems default (I think)
>to some kind of error checking mode, and before I mess with them, I thought
>I'd ask.
 
>Eventually, I plan to run SLIP over a leased 56Kb line.  Any comments on
>using ethernet routers instead?  SLIP's got to be cheaper, but does it really
>work reliably?  For that matter, do routers?
 
>-- 
>================================================================
>=     Mail replies appreciated if possible (who has time to    =
>=     read this stuff?)               Thanks, rob@jdsny.com    =
>================================================================

Yes, make sure you set the modem's hardware control to "on" and that it is 
reflected in the rest of your SLIP implementation, such as any SLIP 
drivers.  Most Terminal Servers, nowadays, allow for hardware control and I 
have had by far the best performance when I use hardware control.

Joe

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 16:45:46 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <1992Jun2.201125.23128@midway.uchicago.edu> wag5@midway.uchicago.edu writes:
>	Between a sender and receiver of data have an electronic
>pulse sent periodically, perhaps ten pulses per second.
>There will be a certain voltage drop in the current which is related
>to the distance traveled through the conducting medium and on the
>resistance of the conducting medium itself.  If, when the network
>is first set up, the transmitter and receiver both measure this
>voltage drop, at any time in the future when there is a sudden
>change or repetitively significant change in this voltage
>drop, which would come from a drain caused by a physical security
>breach...

Any competent tapper will use tap electronics with a very high impedance,
which will not be detectable by such methods.  It's not that big a trick
to build an amplifier whose input impedance is essentially infinite, so
electrically it looks much like the insulation on the wire.  The tapper
can do anything he wants with the output of such an amplifier without
disturbing your pulses at all.  Once upon a time such amplifiers were
bulky, expensive lab equipment; now they're the size of a fingernail
and cost a few dollars.  Only the crudest and most primitive taps can
be noticed by looking at DC properties of the line, like voltage drop.

More sophisticated techniques like time-delay reflectometry will improve
the odds of detecting a tap, but a skillful tapper still isn't going to
have much trouble remaining invisible.  Effectively "hardening" your
wiring against tappers requires more drastic methods like putting it
in gas-pressurized conduit and monitoring the conduit pressure.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 92 16:53:47 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.sys.novell,comp.protocols.tcp-ip
Subject:   Re: CUTCP in Windows 3.1

In article <long.8@vax.ox.ac.uk> long@vax.ox.ac.uk (Neil J. Long) writes:

    ... use WINPKT.COM which will create a 'virtual' packet driver which
    is Windows aware....

WINPKT is allright for CUTCP, PCIP and so forth, where the protocol stack
is linked into the application's .EXE file.  However, don't use WINPKT with
a TSR protocol stack that is already in memory when Windows is started
(e.g. our PC/TCP, Sun's PC-NFS, the TWG product, and probably WATTCP).

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

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jun 1992 23:58:52 GMT
From:      restock@srv.PacBell.COM (Bob Stockwell)
To:        comp.protocols.tcp-ip
Subject:   Duplicate IP addresses.

What are the consequences of configuring two hosts with the same IP
addresses, accidentally?  If I understand ARP correctly, they would
both reply to an ARP request, and the ARP requestor would update the
ARP table with the last reply.  This could cause a lot of confusion.
Does anybody have experience with this problem?  Is there a suggested
way of avoiding and/or detecting the problem?  We are moving from a
NetBIOS network to an IP network.  In NetBIOS you must broadcast your
intention to use a NetBIOS name, before using it.  Is there a similar
protocol for IP, which would broadcast within a subnet?
-- 
Bob Stockwell
Pacific Bell
pacbell.com!ptsfa!res

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Jun 1992 00:28:57 GMT
From:      fff@wimsey.bc.ca (Fred Fierling)
To:        comp.protocols.tcp-ip
Subject:   Clarkson Telnet

'm implementing a TELNETD/TCP/IP driver for a realtime system.
Currently, it works well with SUN, SCO, Ka9Q, and FTP Software's TELNET/TCP/IP
packages.

However, I'm having problems with NCSA's TELNET for DOS running on a
WD 8013EP Board.  Strange thing is that NCSA's TELNET works with all
the other systems except my realtime implementation.

I've defined the TELNET's TCP variables as such
rwin=512
mtu=512
maxseg=512

I've also defined the TELNET's HARDWARE as such
hardware=wd8003e
address=c800
ioaddr=240
base=3

When it interacted with my TELNETD, two back to back packets sent 
by my TCP caused the NCSA's TCP to incorrectly parse the data 
packet sequence numbers; my back to back packets did not exceed the
window space or duplicate the sequence numbers.  It doesn't ack the
last few bytes in the second packet and first few bytes in the 
second packet are not shown on the TELNET screen (seems to shift the
data space).

So I piggybacked ACK + DATA packets into one so that no back to back packets
are sent to it.  This reduced the problem frequency.  However, now 
whenever I send large data packets the problem persists.  Breaking the
packets into smaller data chunks doesn't affect it at all.

Also, varying the receive window sizes has no effect.

Is there any peculiarities about the NCSA Telnet or TCP that I should
be aware of?

Could it be the fact that I'm using 8003 driver for 8013 ?  If so, why
does it work with other systems but not mine?

Thanks in advance.
-- 
Fred Fierling    fff@wimsey.bc.ca       Tel: 604 942-1063   Fax: 604 875-9029

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 01:03:30 GMT
From:      jack@cscdec.cs.com (Jack Hudler)
To:        alt.sources.wanted,comp.dcom.lans.novell,comp.os.msdos.desqview,comp.protocols.tcp-ip,comp.sources.wanted,comp.sys.sun.wanted,comp.unix.questions
Subject:   Re: Wanted: NetBios or IPX driver for unix to talk with DV/X

In article <1992Jun3.061503.16007@aristo.tau.ac.il> ofer@GENIUS.TAU.AC.IL (Ofer Lapid 4X6OJ) writes:
>
>Since DV/X is a looking like the best X windows solution for PCs and since it
>lacks TCP/IP at the basic price I was thinking perhaps a different aproach
>will save us all a lot of money....
>
>DV/X encapsulated X-Protocol within NetBios or IPX packets and sends over the
>lan to its peer.
>
If you find someone who has done this let me know too. If I could talk IPX
from my Sun I'd be in hog heaven!
-- 
Jack Hudler - Computer Support Corporation - Dallas,Texas - jack@cs.com

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jun 1992 02:52:50 GMT
From:      MLONG@isucard.card.iastate.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun3.235852.9683@PacBell.COM>                                   
restock@srv.PacBell.COM (Bob Stockwell) writes:                                 
                                                                                
>What are the consequences of configuring two hosts with the same IP            
>addresses, accidentally?  If I understand ARP correctly, they would            
>both reply to an ARP request, and the ARP requestor would update the           
>ARP table with the last reply.  This could cause a lot of confusion.           
>Does anybody have experience with this problem?  Is there a suggested          
>way of avoiding and/or detecting the problem?  We are moving from a            
>NetBIOS network to an IP network.  In NetBIOS you must broadcast your          
>intention to use a NetBIOS name, before using it.  Is there a similar          
>protocol for IP, which would broadcast within a subnet?                        
>--                                                                             
>Bob Stockwell                                                                  
>Pacific Bell                                                                   
>pacbell.com!ptsfa!res                                                          
>                                                                               
This happened at our location on DecStations 2100 running Ultrix.  I was not    
really involved with the problem, but when one would come up, it would totally  
lock the other unit up.  Then when that unit would be restarted it would        
totaly lock the other unit up.                                                  
Sorry if this messes up your news reader :->                                    
Mike Long                                                                       
Iowa State University                                                           

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jun 1992 04:10:16 GMT
From:      ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700)
To:        comp.protocols.tcp-ip
Subject:   "r" commands and security


	Can anyone enlighten me as to the security considerations/problems
	of running "r" commands.

	We are considering allowing "r" commands across our wide area
	network but I am more than a little concerned about the
	security implications.

	Any help would be gratefully accepted.


Bruce Ingham                            Phone: +61 9 4206700
Engineering Computer Centre             Fax:   +61 9 4207585
3rd Floor Telecom Centre                Email: ingham@telecomwa.oz
80 Stirling Street, Perth
Western Australia 6000

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 09:24:57 GMT
From:      snyder@axis.sdd.comsat.com (Jeff Snyder)
To:        comp.protocols.tcp-ip
Subject:   Looking for electronic copy of TCP standards

Does anyone know where I can get a copy of MIL-STD-1778 (TCP) via ftp either
as plain text or in a mac readable format?

Please respond via email: snyder@axis.sdd.comsat.com

Thanks.
-Jeff

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jun 1992 09:25:21 GMT
From:      snyder@axis.sdd.comsat.com (Jeff Snyder)
To:        comp.protocols.tcp-ip
Subject:   Looking for electronic copy of TCP standards

cat net.news

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Jun 1992 09:57:56 GMT
From:      dylan@ibmpcug.co.uk (Matthew Farwell)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun3.235852.9683@PacBell.COM> restock@srv.PacBell.COM (Bob Stockwell) writes:
>What are the consequences of configuring two hosts with the same IP
>addresses, accidentally?  If I understand ARP correctly, they would
>both reply to an ARP request, and the ARP requestor would update the
>ARP table with the last reply.  This could cause a lot of confusion.
>Does anybody have experience with this problem?  Is there a suggested
>way of avoiding and/or detecting the problem?  We are moving from a
>NetBIOS network to an IP network.  In NetBIOS you must broadcast your
>intention to use a NetBIOS name, before using it.  Is there a similar
>protocol for IP, which would broadcast within a subnet?

Bad idea.  We did that accidentally once. Never again. Not only it crash
the two NCSA Telnet's, but it crashed the TCP/IP on the Xenix machine
they were connecting to.

Dylan.
-- 
It is no coincidence that in no known language does the phrase 'As
pretty as an Airport' appear -- Douglas Adams

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 11:31:43 GMT
From:      efk@ddsdx2.jhuapl.edu (Eileen Baust)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Big Endian to Little Endian Conversion in Data Structures

I need to be able to convert
a data file that was created on a SUN 3/260 using
data structures with floats, bit fields, bytes,integers, and long words.
The data is to be used by a Dell 486. There is a problem with
bit fields in that the bit order gets reversed. Any one know of
any existing routines?
Also are there routines that are able to do the reverse over a network?
(Sending data on the fly from a 486 to sun 3/260 for display purposes)
Eileen Baust

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 14:47:24 GMT
From:      ccdave@ut-emx.uucp (David Stewart)
To:        comp.protocols.iso,comp.protocols.misc,comp.protocols.tcp-ip
Subject:   OSI vs TCP/IP information & opinions requested


                     INFORMATION WANTED

                       OSI vs TCP/IP

     I am looking for current information on the state of OSI
as compared to TCP/IP.  I am writing a paper for a telecom
class with the goal of showing how upper management can easily
grasp the concepts of OSI (lots of non-technical press aimed at
management types) but the implementors still prefer TCP/IP due
to its ability to accomplish real work.  This results in a
problem for everyone concerned.  The major point I want to get 
across is that OSI started top-down with general concepts that
everyone has agreed are a "goodness" in principle.  Management 
easily grasped these concepts and wanted to join "the good guys."
TCP/IP, on the other hand, started out at the bottom with the
basics of functionality as its purpose.  Since TCP/IP was more
bottom-up in design, management was can't get their arms
around it very well.

     I would be interested in any FTP sites that keep informative
archives on OSI.  Does anyone have copies of a news thread that is
in line with this subject?  I have been reading tne news groups
lately but can find no such action happening at present (at least
in groups that my host subscribes to).

     If anyone would like to E-mail me with their opinion, that
would be appreciated also.  Please keep in mind that you may be 
quoted and used as a reference unless you request otherwise.

     Please direct any responses to: ccdave@emx.cc.utexas.edu

Thanks,
Dave Stewart

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jun 1992 17:35:07 GMT
From:      tab@tfs.com (Theresa Breckon)
To:        comp.protocols.tcp-ip
Subject:   Question reg: MacTCP and Class C address bug

We have recently bought a software package called eXodus to allow
us to run X software on our Macs. Our Macs are configured using MacTCP
with internal ethernet boards. eXodus crashes when we try to
launch xclients from the Mac. eXodus support blames this on our
Class C addressing, claiming that there is a known bug in the
current version of MacTCP regarding class C addresses.

Funny thing is that NCSA Telnet works just fine with this supposedly
buggy version of MacTCP.

Anyone heard about this "known MacTCP bug" before.

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 19:19:31 GMT
From:      gcasey@brtph424.bnr.ca (Errol Casey P910)
To:        comp.protocols.tcp-ip
Subject:   Telnet Program/Extending telnet to support file transfers

I'm interested in knowning  if there exist a version of telnet
that can be used between unix hosts to transfer files.
I'm unaware of any such functionality in the original program,
and would be interested if anybody has added Xmodem, Ymodem,
Zmodem, or even Kermit to telnet.

I would like to be able to telnet to a host, and execute ckermit
or s(x,b,z) to receive a file from the other host.

Please contact me,  Errol Casey (gcasey@x400gate.bnr.ca) or post a
reply with any information regarding a modified version of telnet, how this
maybe done, or other comments.

(Note: I'm aware of the ftp program, I'm interested in expanding
telnet because I have to use telnet to access a modem pool).

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 19:39:25 GMT
From:      M16302@mwvm.mitre.org
To:        comp.protocols.tcp-ip
Subject:   Protocol Technology Forecast Questionnaire


 
    QUESTIONNAIRE TO FORECAST CAPABILITIES OF COMMUNICATION PROTOCOLS
                      FOR END-USER WORKSTATIONS
 
                            BACKGROUND
 
I am performing a survey that forecasts the present and future
capabilities of several communications protocols, hosted on end user
workstations, for several protocol services (e.g., file transfer).
An end user workstation may be thought of as the principal workstation
in a regular working office (as opposed to a "Lab" location).  The
forecasts are done separately for different types of end user
workstations (e.g., IBM PC Compatible).  I am seeking respondents,
knowledgeable of the present and future capabilities of several
protocols, for one or more protocol service areas. From the respondents
point of view, the questionnaire for each protocol service is
independent of the other services, so a particular respondent may fill
out the questionnaire for only one protocol service.  Of course, if
a respondent has the knowledge and the time to fill out the
questionnaire for more than one protocol service, this would be greatly
appreciated.  The format of the questionnaire is the same for each
protocol service.
*
The objective is to rate different protocols for several protocol
services over the time interval from 1992 to 1999.  The rating should
consider all of the factors that affect the ability of a protocol to
provide the service in question - - technical, speed/performance,
product availability ...   . However, the rating should not consider
cost. The ratings are done separately for three types of workstations:
(1) IBM PC compatibles, (2) Macintosh, (3) UNIX.
*
In order to perform the ratings, you may feel a need to know the power
of the operating systems and the computers, particularly for the
less-powerful PC workstations.  Assume that sufficient processing power
and Random Access Memory (RAM) is available to support the protocol
software.  For PC operating systems, assume that the current PC
workstations have Windows 3.1 capability and that the transition to a
32 bit multiprocessing operating system such as Windows NT or OS/2 will
be completed within 3 years.  For Macintosh operating systems, assume
System 7 is the current standard.  Operating system power should not
be an issue for UNIX.
*
Please rate the protocols on a scale from 0.0 to 10 using a W3 format
(any floating point number of field width 3).  Thus, scores of "10."
and "9.9" are both legitimate.
*
If you are able to rate some workstations, but not others, that is O.K.
Just set Workstation = "none" where it now says Workstation = IBM PC,
Macintosh, or UNIX for the workstations that you are not rating.
*
If you feel you are unable to estimate beyond a certain year, then
please try anyway!!  But if you can't, just do as many years as you can.
*
You may respond by Email or regular mail.  If you have an ASCII
text editor & can avoid changing the template, I prefer Email because I
can read your responses electronically.  If you respond by Email, please
make copies of this questionnaire for each service/capability that you
are forecasting.  Please place answers on the row with the first line
of the protocol suite description (where the x.x appears for the first
description).  Please send Email to RSHAIN @MITRE.ORG.
*
If you prefer to fill-in a hard copy of the questionnaire, please print
a copy of the questionnaire for each service that you are rating, and
send to: Robert Shain, The MITRE Corporation, Mailstop W633, 7525
Colshire Drive, McLean, Va. 22102.
*
                          NOTES
(1) "All standard services" means the set of services, based on the
GOSIP schedule, expected to be commercially available for the protocol
in the target year.  For example, if you believe that Remote Database
Access (RDA) capability will be commercially available for the OSI
protocol in 1993, then this expectation should be considered when rating
the OSI protocol for RDA capability.
(2) A response to the questionnaire within two weeks would be
appreciated.
*
Thank you in advance for your participation.
*
 
************************************************************************
Name: _______________________
(Write over underline if you reply electronically.)
 
         RATINGS OF PROTOCOL SUITES BY YEAR FOR END USER WORKSTATIONS
 
Please place an "x" in column 1 for the (one) service/capability that
you are forecasting on each filled-in questionnaire.
 
_ Remote Procedure Call
_ Remote Database Access
_ Transaction Processing
_ Security
_ Virtual Terminal
_ File Transfer
_ Directory Services
_ Network Management
_ Messaging/Electronic Mail
_ Technical Projects
_ Commercial Off the Shelf Software (not linked to Application)
_ Upper Layer Services
_ Lower Layer Services
_ Links to Commercial Off the Shelf Software (COTS)
_ Links to X Windows (or equivalent)
************************************************************************
Scale: 0 (lowest) to 10 (highest); Format F3.1 (e.g., 8.3)
 
      Workstation = IBM PC
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I1 OSI STACK + ALL STD. SERVICES (COM- |x.x|   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************
 
************************************************************************
      Workstation = Macintosh
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M1 OSI STACK + ALL STD. SERVICES (COM- |   |   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************
      Workstation = UNIX
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U1 OSI STACK + ALL STD. SERVICES (COM- |   |   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************

ROBERT B. SHAIN               RSHAIN @MITRE.ORG
THE MITRE CORPORATION         VOICE: (703)883-5592
ECONOMIC ANALYSIS CENTER      FAX: (703)883-6991
MAILSTOP W633
7525 COLSHIRE DRIVE
MCLEAN, VA. 22102

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 21:10:01 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

Oddly, I haven't seen much of a flame war on this subject before.
Maybe I just haven't been subscribing to the right groups at the
right times. Anyway...

Interop last month left me with the feeling that OSI transport
protocols (and below) were simply not worth bothering with.  You have
a choice of two incompatible standards (TP0 vs TP4).  Neither ISO
transport protocol provides services as good as what is routinely
available in the Internet environment.

I attended Marshall Rose's farewell tutorial on ISODE internals.
Besides being probably the "biggest" ISO implementer there is, he's
also one of its biggest detractors. Referring to the good parts of the
ISO protocol suite he said, "Well, it's after the accident and now we
need to decide if we can transplant the liver, and maybe the
spleen..." In short, he thinks there are a few good things (like maybe
the directory) but the rest of it is inferior to the Internet suite.

For references (after all, the original poster says he needs to write
a paper on this) check out any of Rose's books ("Open Book" or "Simple
Book" or "Little Black Book") since each contains at least a section
trying to explain what's wrong with the ISO protocol suite.

I heard a rumor that the next revision of GOSIP was going to recognize
TCP/IP as an acceptable protocol to reside below the transport level
interface of a GOSIP compatible stack.  Nobody at Interop had heard
the same rumor, unfortunately.  The general tone of the ISO vs
Internet debate seems to preclude such an approach, even though it
seems eminently sensible to me.

Rick.
smith@sctc.com     arden hills, minnesota

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 22:11:43 GMT
From:      hoey@AIC.NRL.Navy.Mil (Dan Hoey)
To:        comp.unix.shell,comp.sys.sun.misc,comp.sys.sun.admin,comp.protocols.tcp-ip
Subject:   Unix shell TCP tools and /usr/etc/mconnect bug

I occasionally write simple TCP clients as a shell script.  The only
tool I really need for the job is a filter that will connect the
standard input and output to the streams of a TCP connection.  Once
upon a time I used telnet as the filter, but that had a problem: When
the connection dropped, you would lose the end of the
output--sometimes all the way back to the beginning.

So I was happy to see mconnect(8) in the Sun distribution (did Sun
write it, or is from BSD?) because it does exactly the right thing for
me--almost.  It has three problems, and two of them are minor.  The
third, however, is a fairly severe bug, and I would like suggestions
for solving it.

Problem 1: Mconnect does not translate NETASCII back to ASCII, so you
get carriage returns (^M) in the output.  I pipe the output through
    tr -d '\015'
and that solves the problem.  It would be faster, though, if mconnect
did the translation.  Also, I'm a little concerned that mconnect may
not be inserting carriage returns on input, though I haven't run into
problems with that yet.

Problem 2: Mconnect prints
	connecting to host nic.ddn.mil (192.112.36.5), port 101
	connection open
at the beginning of the output.  But most tcp services put out some
sort of initial greeting that I have to ignore anyway, so ignoring two
more lines is no problem.  Still, this stuff should be on stderr.

Problem 3: Mconnect SOMETIMES inserts
	connecting to host nic.ddn.mil (192.112.36.5), port 101
	connection open
at some random place in the output.  It is apparently timing
dependent, and I have no source to find out where it's coming from,
and I really don't want to have to delete those lines when they could
be valid output.

For instance, the command

    echo ALL-MIL | /usr/etc/mconnect -p 101 nic.ddn.mil | grep -n connect

gives me output like

    1:connecting to host nic.ddn.mil (192.112.36.5), port 101
    2:connection open
    1436:connecting to host nic.ddn.mil (192.112.36.5), port 101
    1437:connection open

where the second set of line numbers occur somewhere between 1000 and
5000.  Has anyone fixed the problem 3 bug?

Is there a publicly available version of mconnect or equivalent?  So
far I've found "tcpcon" in Simtel20's PD6:<UNIX-C.NETWORKS> directory,
but that doesn't have the code to wait for the output to drain.

Please mail me your suggestions, and I'll report any solutions that
come in.

Dan Hoey
Hoey@AIC.NRL.Navy.Mil

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 22:20:06 GMT
From:      rick@rgbsys (Rick Davis)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

We did a similar system where a X-windows interface ran on a 
workstation and controlled objects on a video processor.  The link
between the two was ethernet, running IP.  IP was based on UDP, and
we used tftp to boot.  The protocol suite on the video processor end
was implemented with a PSOS operating system and our own Lance 
ethernet drivers. 
	The performance in the end was unsatisfactory because TCP/IP
cannot guarantee bandwidth.  The upper bound on transport time is very
soft due to many factors, not the least of which are the non-real time
aspect of Unix and the inherent slowness of layered protocols.  The peak
transfer rate is not determined by how long things spend "on the wire";
rather it is set by how long it takes to get packets to the ethernet 
chip and the time to re-assemble them at the other end.  If you want to
avoid this overhead, you arrange to always send 1140 byte messages
( or whatever you have implemented the ethernet packet size as ).
You also have the fastest possible processors at either end, and
as much memory as you can afford for the ethernet chip's ring buffers.

Just as a rule of thumb, anticipate 50% software overhead.  If you have
a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
be around 600kbit/sec, or about 75kbyte/sec.  If there is anything else
sharing the ethernet, this rate wil fluctuate down by quite a bit.  The
downward fluctionations depend on how you have the back-off set up in
the TCP protocol.  FOr a great introduction to all of this, check out
Doug Comer's book "Internetworking with TCP/IP" and get hold of the
RFCs relevant to what you want to do.

Good Luck;

Rick Davis

-- 
               /\/\/\/\/\/\/\/\/\/\/\/\       <uunet,usenix>!rgbsys!rick
             /      R  G  B  Spectrum   \     rick@rgb.com
-------|  |--|     Alameda, California  |--|  |------
       |__|                                |__|

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 00:02:56 GMT
From:      ciarfela@sigma.ece.ucsb.edu (Ciarfella)
To:        comp.protocols.tcp-ip
Subject:   Throughput calculation in ttcp test program


Hi,

I've been running the 'ttcp' test program over an Ethernet connection
and am wondering how the throughput calcuation is made.  When I run 1000 byte 
packets over udp, ttcp tells me that the throughput is 13.11 Mbps (which
obviously is greater that Ethernet's 10 Mbps).

Can someone explain how ttcp calculates throughput?

Thanks.

Paul C

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 00:36:37 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: How do acknowledges work in the TCP protocol?

In article <1992Jun02.195215.7366@jho.com> brown@jho.com (Jim Brown) writes:
   In the world of TCP/IP, if a process returns with a successful return from
   (for example) a write call, is the process assured that the message has been
   successfully sent and acknowledged back to the sending process?

(assuming Unix) No: a successful return code only indicates that the data has
been accepted by the socket on the sending system for transmission.
--
				-- Frank Solensky / Clearpoint Research
Red Sox magic number: 119
"finger bosox@animal.clearpoint.com" for current info.

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 01:14:12 GMT
From:      mwitt@ogicse.ogi.edu (Mike Witt)
To:        comp.protocols.tcp-ip
Subject:   Re: Throughput calculation in ttcp test program

In article <4974@ucsbcsl.ucsb.edu> ciarfela@sigma.ece.ucsb.edu (Ciarfella) writes:
>
>I've been running the 'ttcp' test program over an Ethernet connection
>and am wondering how the throughput calcuation is made.  When I run 1000 byte 
>packets over udp, ttcp tells me that the throughput is 13.11 Mbps (which
>obviously is greater that Ethernet's 10 Mbps).
>
>Paul C

Are you getting this number on the sending or receiving side?
On the sending side, the "throughput" of UDP is just the
number of bits that the UDP sending process is able to relieve
itself of.  This could be more than the bandwidth of the
underlying hardware if sender's lower layer protocols drop
some of the traffic on the way out, for some reason.  This
would be bad design, but perfectly legal.

Another thing to check is that you're actually running long
enough to get a valid test.  That is, not just sending one
short burst of data.  Of course the data won't actually go
out over the net faster than 10Mbits, but it sure can get out
of the sending user process faster than that.  I ussually
send at least a Megabyte (way more than you need to avoid that
problem).

If you're getting that statistic on the receiving process,
well... I don't know what to say.

-Mike

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 01:35:13 GMT
From:      umrice02@ccu.umanitoba.ca (Stephen Rice)
To:        comp.protocols.tcp-ip
Subject:   Information about TCP/IP required

I am not terribly familiar with TCP/IP but I was wondering if it would be
the answer in our situation:  We have a number of IBM, MAC and Unix 
machines.  We require a networking solution that allows us to transfer files
to/from the Unix machines and handle printing.  The ability to have access
to the file system on the Unix machines as well as the file systems on 
various other machines would be a GREAT asset.

Is TCP/IP the answer?  If so, how would it work?  Who is a good manufacturer
of such hard/software.

Any help in this matter would be GREATLY appreciated -- THANX!
-- 
+-----------------------------------------------------------------------------+
Stephen Rice                                          "I am, therefore I think"
umrice02@ccu.umanitoba.ca                 "These are definitely my own opinions
University of Manitoba  CANADA                  or I would not have said them."

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 14:34:18 -0700
From:      jbridges@galaxy.gov.bc.ca
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: emulex terminal servers

In article <1992Jun3.142549.12650@reks.uia.ac.be>, holemans@reks.uia.ac.be (Wim
Holemans) writes:

> we have two Emulex P4000 terminal servers with TCPIP/LAT support. We are
> using software release 2.1.
> We have one terminal server with 16 ports and one with an extra extention
> of 16 ports (so 32 ports). We have severe performance problems on the terminal
> server with 32 ports even when there are just 3 or 4 users on it and the
> show server status command just gives an max cpu usage of 56 %.
> 
> has anyone similar experiences and solutions ? 
> 

Then I wrote (forgetting to insert the reference above)

> Please post any solutions - I too have serious performance problems
> with a 32 port Emulex P4000 series TS, running with Hardware A.1,
> Software version 2.15. 

bruce@gordian.com pointed out my omission:

> This either went to the wrong group, or we need a LOT more info....

(Thanks for pointing this out, without flames - we only become
familiar with the use of Usenet, by such corrections :-} ) 

Further info:

 Software version 2.15 is from release 2.1
 Loader Firmware:   (NL) 1.73
 DECnet Type Load:       P4KTL0E
 Protocols: Lat_compatible, TCP/IP

Traffic on the ethernet strand is 80% LAT, running at about 1200 to 1800
packets per second.

Is there a better group to deal with ethernet terminal server
performance questions? If this group is reasonable for such questions,
can anyone respond with additional information (or questions, or 
corrections)

Thanks
-- 
        Jim        Preferrred:  JBRIDGES@GALAXY.GOV.BC.CA
Jim Bridges         Alternate:  JBRIDGES@BCSC02.BITNET    (604) 389-3147
B.C. Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 04:03:51 GMT
From:      robert@swanee.ee.uwa.oz.au (Roberto Togneri)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Packet Driver for Apricot Qi -- anybody know of one?

I am currently using the SOSS program to allow our unix hosts to mount a 
PC hard disk and thereby permit backing up the PC to a tape. I can do this
for all our PC's bar one:  our Apricot Qi. This PC has its own internal
ethernet interface and I need a Packet Driver to run SOSS. I looked at the
drivers.zip from Clarkson and not surprising there is no such thing.

Does anybody know or have a packet driver for an Apricot Qi? 

Thanks for any help,
--
Dr. Roberto Togneri                        Phone: +61-9-380-2535     _--_|\
Centre for Intelligent Information Processing Systems               /      \ 
Dept. of Electrical & Electronic Engineering                        *_.--._/
The University of Western Australia        Fax:   +61-9-380-1101          v 
NEDLANDS WA 6009 Australia                 Email: robert@swanee.ee.uwa.edu.au

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 1992 04:52:02 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: "r" commands and security

In article <1992Jun4.041016.19718@nodecg.ncc.telecomwa.oz.au> ingham@nodecg.ncc.telecomwa.oz.au (bruce ingham 4206700) writes:
>	Can anyone enlighten me as to the security considerations/problems
>	of running "r" commands.

The security of these commands is pretty mediocre.  They're designed to be
used within a "friendly" community.  If you're connected to the Internet
then you're not in such a community.

Access control is basically done using lists of trusted hosts, in
/etc/hosts.equiv and ~/.rhosts.  But this depends on IP addresses being
correct, and it's possible for hosts to pretend to be other hosts (although
it's generally not possible to pretend to be a host on the target system's
network if you're not physically on that net).

Trusted hosts are generally expected to support the restriction that only
trusted programs can open TCP connections with a source port below 1024.
The r-commands don't send passwords; the client just sends a user name, and
the server believes it if the source port is in this range.  Putting a PC
in a trusted host list is not a good idea, since it has was to implement
such a restriction.

Combining the above two aspects, you see that it may not be a good idea to
trust any hosts on the same network as PC's.  That's because a PC could
easily be programmed to pretend to be that host, and then it could login as
anyone who lists that host in their .rhosts file (or anyone if the host is
in hosts.equiv).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 06:49:35 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun3.235852.9683@PacBell.COM> restock@srv.PacBell.COM (Bob Stockwell) writes:
>What are the consequences of configuring two hosts with the same IP
>addresses, accidentally?  If I understand ARP correctly, they would
>both reply to an ARP request, and the ARP requestor would update the
>ARP table with the last reply.  This could cause a lot of confusion.
>Does anybody have experience with this problem?  Is there a suggested
>way of avoiding and/or detecting the problem?  We are moving from a
>NetBIOS network to an IP network.  In NetBIOS you must broadcast your
>intention to use a NetBIOS name, before using it.  Is there a similar
>protocol for IP, which would broadcast within a subnet?

Duplicate IP address will result in BIG problems (thoughyour network will
probably not go down :-)). Packets will be routed to the wrong host,
connections will be dropped, diskless workstations are going to hang, etc,
etc, etc.

Many IP implementations are paranoid enough to ARP for their own IP address
to detect this problem and complain about it. My suggested way to avoid
this problem is to maintain a central database with IP addresses for your
site. When somebody needs an IP address, he must ask his network
administrator. If your site is large, hand out complete IP subnets to local
administrators. I'd suggest that you setup DNS (Domain Name Service) and
give it the same authority structure that you use for handing out IP
addresses (ie. the network administrator who is authorized to hand out an
IP address, will also be responsible to include the corresponding records
in the DNS).

Regards,
-Roger
(I speak for myself)


-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 11:56:12
From:      morse@quark.mpr.ca (Daryl Morse)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


In article <1992Jun5.175015.2946@colorado.edu> schwartz@latour.cs.colorado.edu (Mike Schwartz) writes:

   In article <1992Jun4.211001.29145@sctc.com> smith@sctc.com (Rick Smith) writes:
>   >I attended Marshall Rose's farewell tutorial on ISODE internals.
>   >Besides being probably the "biggest" ISO implementer there is, he's
>   >also one of its biggest detractors...
>   >For references check out any of Rose's books...
 
>   Here's a more precise (but less easily available) reference:
 
>	   M. T. Rose.  The Future of OSI: A Modest Prediction.

Modest?!? Not likely. *Nothing* about Marshall Rose is modest...

>	   Proceedings of the Conference on Upper Layer Protocols,
>	   Architectures, and Applications, pp. 356-365, IFIP Working Group
>	   6.5, Vancouver, Canada, May 1992.
 
>   The paper compares the standardization processes of OSI and the Internet
>   protocols, and discusses a number of technical and administrative
>   deficiencies of important OSI protocols (MHS, CMIP, CO/CL, etc.)  It was
>   a fun talk to attend, and a worthwhile paper to read.

I have been resisting commenting on this thread, but I can't restrain
myself any longer. I would urge and plead anyone interested in OSI to
NOT use Marshall Rose as your reference point. He is riding a hobby
horse that's going nowhere. When the Open Book was published, it was
already out of date. Now, a couple of years later, it's even more out
of date. Many of the problems that he raised in the book (and
continues to raise) have been addressed and are no longer issues. I
find it unfortunate that he (and others of his calibre) can't/won't
constructively contribute to the standards process to ensure that
their concerns about OSI are addressed, rather than to make money
detracting it. Maybe they don't like standards bodies because there
aren't any spotlights, I don't know. While I won't claim that OSI is
perfect, I will claim that it's much better than Rose and other IAB
types would like us to believe. The standards bodies may be slow, but
they do work.
--
Daryl Morse                     | Voice : (604) 293-5476
MPR Teltech Ltd. 		| Fax   : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail: morse@mprgate.mpr.ca
Canada, V5A 4B5                 | Part of the B.C. Tel Group of Companies...

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 09:36:18 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested


 >I attended Marshall Rose's farewell tutorial on ISODE internals.
 ...
 >ISO protocol suite he said, "Well, it's after the accident and now we
 >need to decide if we can transplant the liver, and maybe the
 >spleen..." 

the TCP red corvette just drove over the ISO hedgehog,

unfortunately, it now has a flat and is heading for a cliff...

(paul tsuchiya just said)

j.

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 10:13:03 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Need help with performance on long-delay paths!



 >> and Japan.  The link currently has 256K bandwidth with approx. 128ms
 >> round trip delay.  However, recently, our carrier had a undersea fiber
 >> repeater failure and our link was routed over satellite.  Our 128ms
 >> round trip delay became 600ms after the re-route.
 
 >> thruput on that 256kbps link w/128ms delay was about 120kbps.
 >> That's about 50% utilization!  Not very impressive at all.
 
 >> Now, when that link was routed over satellite, the thruput dropped to
 >> 33kbps (13% utilization)...

if you asre receive window limited, then you are receive window at
data rate per round trip time limited

you have about 4* the round trip time on satellite, so about a 1/4 the
throughput

not really surprising...

as Chrsitian Huitema says, so long as you have slow start, then it is
safew to get the recceivers to advertise a bigger window (say 4-16k,
instead of the 2k it looks like you have...)

btw, i hadnt seen KO (KiloOctet) before - i assume it is SI unit for
KByte:-)

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 11:40:47 GMT
From:      chris@visionware.co.uk (Chris Davies)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

efk@ddsdx2.jhuapl.edu (Eileen Baust) writes:
: I need to be able to convert
: a data file that was created on a SUN 3/260 using
: data structures with floats, bit fields, bytes,integers, and long words.
: The data is to be used by a Dell 486. There is a problem with
: bit fields in that the bit order gets reversed. Any one know of
: any existing routines?

Sun's XDR (eXternal Data Representation) stuff is very useful for this
sort of thing.  It's now in the public domain, and there's an RFC about
it (but I can't remember the number offhand).

: Also are there routines that are able to do the reverse over a network?
: (Sending data on the fly from a 486 to sun 3/260 for display purposes)

Yes. RPC (Remote Procedure Calls) using XDR.  Wonderful stuff.

Oh yes, there's now a reasonably good Nutshell book about RPCs which is
well worth getting and reading in conjunction with the relevant RFCs.


Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jun 1992 11:45:26 GMT
From:      caf@omen.UUCP (Chuck Forsberg WA7KGX)
To:        comp.protocols.tcp-ip
Subject:   Re: NCSA telnet and ET4000 vga-boards

In article <1992Jun3.132521.2577@escape.vsse.in-berlin.de> felix@escape.vsse.in-berlin.de (Felix the double Helix) writes:
>hi!
>
>i have the feeling that NCSA telnet doesn't work with ET-4000 VGA video
>boards. at least i found that out empirically. on three different
>computers equipped with an et-4000 board ncsa telnet just hung (not
>even ctrl-alt-del worked anymore), and by changing the vga card in one
>of them it worked instantly.

Check for an address space conflict between the Ethernet card and the
VGA.  There may be a problem with the VGA BIOS forcing the bus into
16 bit mode which affects all devices in its address range.

After reading Felix's posting I checked Telnet on the machine that
had a Genoe 7900 (Tseng 4000 controller) and sure as hell Telnet
died.  In this case however, DOS 5's himem.sys et al were the problem.
I ran the WD diagnostic program and fiddled until the RAM test passed
and then changed config.tel to the new value.

There may be other 4000 based SVGA cards that mess with Ethernet
cards, but moving the RAM address to a different place may still
fix the problem.
-- 
Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 11:58:00 GMT
From:      kovar@world.std.com (David C Kovar)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Need basic information on network services


  I'm giving a presentation next week to the MUMPS Development Committee
on "Network Services". This is supposed to be a fairly light survey of
what's out there, how it works, and what it is used for. I was going
to cover things like NFS, NIS, DNS, print servers, and WAIS. To make
the presentation as complete as possible, I would like to ask the net
for the following information:

	What do you consider "network services"?
	What services are currently provided by, or on, networks?
	How do they work? 
		How do you find a server?
		How do you ask for a service?
		What information is passed, and
			how is it passed?
	Do you know any good intro documents? Where can they be found
		and what is their reference number? (For a reading list.)

  As I said, it's a survey presentation, so if you could provide a
quick outline of your favorite network service and a quick outline of some
mainstream network service, that would be most appreciated. (Other than
the RFCs and vendor's manuals, I'm not aware of intro documents on
NFS, NIS, and DNS. Pointers to that sort of information would be
most welcome.)

  I realize that this is rather sweeping but it's better to have too
much information and have to pare it down. Thanks very much in advance.

-David

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 92 17:11:24 +1200
From:      pete@cosc.canterbury.ac.nz (Pete Glassenbury)
To:        comp.protocols.tcp-ip,comp.periphs.printers,comp.unix.questions
Subject:   Bootp on ethernet printers


I am posting this for a friend -- email me any replies and I'll sumarize

BOOTP/ETHERNET PRINTING
=======================

We have been attempting to connect an HP LaserJet IIID
via ethernet to a Data General AViiON running DG/UX 5.4.

The IIID requires bootp as its initial communicator over
TCP/IP.  Bootp is not standard issue with the AViiON and
so a Sun based version was secured from the net along with
the necessary AViiON update for handling arp.

Current status - bootpd appears to be running correctly ...
answering requests as issued by the printer but, the latter
does nothing with the reply.

Can anyone point me in the right direction regards what
the bootp protocol is supposed to consist of, the vendor
specific extensions (T144) and/or detail on RFC1048.



Peter Glassenbury                       Computer Science dept.
pete@cosc.canterbury.ac.nz              University of Canterbury
                                        New Zealand

--
Peter Glassenbury			Computer Science dept.
pete@cosc.canterbury.ac.nz		University of Canterbury
					New Zealand

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 13:43:07 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip.ibmpc,bit.listserv.novell,comp.protocols.tcp-ip,comp.sys.novell,comp.dcom.lans.ethernet
Subject:   Please subscribe to packet drivers mailing list.

There are too many people who are uninterested in packet drivers for
me to send packet driver information to all these newsgroups/mailing
lists.  If you want to stay abreast of current packet driver-related
information, please subscribe to the packet drivers mailing list.
Send a message to listserv@sun.soe.clarkson.edu saying "add drivers".
If you do not get a reply, also include "path <mumble>" where
<mumble> is replaced by your email address IN DOMAIN NAME FASHION.

I will continue to send new release and status information to these
newsgroups/mailing lists on a quarterly (more or less) basis.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 14:58:24 GMT
From:      greil@guug.de (Anton Greil)
To:        comp.protocols.tcp-ip
Subject:   PC/FTP and terminal emulators


We are using the product PC/FTP from the ftp Software Inc., to connect
an IBM PC via Ethernet to a UNIX computer, System V.4 .

The problem we have is caused by the characterset ISO 8859-1, which is
used on the UNIX machine and which is not correctly supported by the
emulators of PC/FTP I have used (perhaps in the wrong way).

Which emulators are able to do the mapping between the charactersets
ISO 8859-1 and the char. set of the IBM PC ? This is needed for terminal
emulation and for the transfer of text files.

Especially we want to run database applications of INGRES via the emulation
(with data coded in ISO 8859-1) and want to use the (hardware) functionkeys 
to control the menus.

***  Is MS-Kermit, Vers. 3.11, a suitable terminal emulator for PC/FTP?   ***

In the PC/FTP manual, in "Users Guide", 3.2 Glass terminal emulation, you
can read:
   "... The tnglass and rlogingl programs allow you to use a commercial
    terminal emulator that supports the DOS Interrupt 14 interface. You
    can also use tnglass and rlogingl in conjunction with a console device
    driver, such as ansi.sys to perform whatever terminal emulation is
    needed."
How to install such a device driver, what is the interface to rlogingl and 
tnglass?

Thank you!

Toni Greil, Muenchen (Germany)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 15:01:02 GMT
From:      greil@guug.de (Anton Greil)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP products for IBM Serie/1 with RPS 7.2



We are searching a TCP/IP product for the system

	IBM Serie/1  with RPS 7.2

- commercial or public domain.

Thank you for hints!

Toni Greil                          Phone: 0049-89-456911-0
MultiNET Services GmbH              Fax:   0049-89-456911-21
W-8011 Grasbrunn (near Muenchen)
Germany

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 15:33:50 GMT
From:      davidliu@tin.ssc.gov (David Liu, SSCL, (214)708-6068,)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for PC or MAC

I have similar need for information about SLIP or PPP on PC.



-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 92 16:32:51 GMT
From:      shj@ultra.com (Steve Jay {Ultra Unix SW Mgr})
To:        comp.protocols.tcp-ip
Subject:   Re: Throughput calculation in ttcp test program

In <38203@ogicse.ogi.edu> mwitt@ogicse.ogi.edu (Mike Witt) writes:

>underlying hardware if sender's lower layer protocols drop
>some of the traffic on the way out, for some reason.  This
>would be bad design, but perfectly legal.

In all BSD based implementations of sockets/TCP/IP, the data link layer
driver has no choice but to discard packets when the higher layers are
feeding it more data than it can shove out onto the wire.  As Vernon
Schryver gently pointed out to me some months ago in this newsgroup,
there's no way for the data link layer to apply back pressure to the
upper layers to slow them down.  If the data link layer doesn't start
discarding stuff when it's transmit queues fill up, you'd eventually
fill up all available memory with queued packets.

If you start thinking about how it might be possible for the data
link layer to apply back pressure, particularly all the way back to
the specific application that is flooding the network, it's hard to
see how it could be done.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 16:39:00 GMT
From:      gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
To:        comp.protocols.tcp-ip
Subject:   RS6000 AIX bug: broadcast addresses on subnets


	If anyone has a fix or any info on the following, an email
	reply would be appreciated!

	Class B network, netmask 255.255.0.0 broadcast UDP packets
	work fine.

	Netmask 255.255.255.0 broadcast UDP packets work fine.

	Netmask 255.255.128.0 the RS6000 is unable to either
	send or receive UDP broadcast packets.  Not only can it
	not figure out the broadcast address correctly on its
	own, but even when explicitly given, it can't send out
	the packet...

	I'd be more specific with "can't" and "doesn't" but our
	sniffer software is _STILL_ somewhere out in 'on the way
	to you' land.


	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
I'm wearing PAMPERS!!

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 17:01:27 GMT
From:      bourman@hpcc01.corp.hp.com (Bob Bourman)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a modem



	Help. I thought SLIP was a synchronous packet framing protocol?

	Or am I all confused? Can someone please clear up my confusion and
	tell me how to use Serial Line IP over dial modems?

	Thanks

	BOBB

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jun 92 17:05:18 GMT
From:      mischler@cubic.com (Dave Mischler)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Want something like KA9Q for commercial use

Is there a FAQ for this group?  I couldn't find one on my system.

My company is interested in locating commercial or publicly available software
to manage TCP/IP communications in a multi-tasking environment on (essentially)
a dedicated PC.  It looks to me like KA9Q would do the job admirably, but it
cannot be distributed commercially.  Would something like PC/TCP and some
horrible hack on DOS do what I want?  Is OS/2 a viable alternative?

I need to run a primary application that communicates over a TCP port (socket),
with DNS name resolution, plus a telnet daemon, and time synchronization with
NTP.  The system must respond properly to ICMP & SNMP requests.  The ARP cache
must be flushable.

The hardware people feel that a hard disk cannot survive in the target
environment, so storage will be quite limited (UNIX is not an option).
There is some cost sensitivity here, too.

Thanks for any information you can provide.

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 19:06:02 GMT
From:      apollo@buengc.bu.edu (Doug A. Chan)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP over long-delay links (summary + more)

I thank everyone who gave me some ideas as to what may be the cause of
the bottleneck when doing 'rcp' over long-delay links.
-TCP window size:
  In order to get full thruput over a 256Kbps link with 128ms delay, I'm
  going to need a window size of around 4Kbytes.
  20Kbyte window for a satellite link (592ms)

-SCO's TCP/IP implementation:
  According to SCO, the window size is 1500 bytes maximum!
  Also, there is no way to adjust the window size... ouch!!
  Apparently, this number is the same as the MTU (maximum transmission
  unit)

-rcp's underlying xfer mechanism:
  I was corrected on that... It does use TCP and not UDP.
  I was also able to verify this by running netstat before and after
  a file transfer with rcp.  The number of bytes in the tcp section
  reported by netstat was incremented by the size of the file+overhead.

-I did the same test (rcp between two machines with a 256Kbit/sec link and
 128ms round-trip delay) but also tried doing two and three simutaneous
 rcps.
 Results:  The times scaled linearly with the number of transfers!
           (a single rcp took ~1 minute, two rcps took ~2 minutes each,
            three rcps took 3 minutes each.)  The average thruput was
           130-140Kbits/sec regardless of the number of rcps.

 I would not have expected this if the TCP window size was the limiting
 factor.  I'm guessing that our bandwidth is actually being limited by
 the bandwidth managers on both ends due to their overhead of frame
 acknowledgements.  I'll be doing a few more tests to confirm/deny this.

-Is there something to simulate a long path delay?
  Ie. some modified bridge/router with some adjustable packet queue?
  I was thinking of modifying PC-Route or PC-Bridge but if there is
  something already out there it would really save me some time.  I
  need to do more tests under controlled conditions.

-Doug
apollo@buengc.bu.edu

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 21:52:55 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

morse@quark.mpr.ca (Daryl Morse) writes:

>I have been resisting commenting on this thread, but I can't restrain
>myself any longer. I would urge and plead anyone interested in OSI to
>NOT use Marshall Rose as your reference point. He is riding a hobby
>horse that's going nowhere.

Thank you. This is the first pro-OSI post I've ever read on this
thread. I was beginning to wonder if there were no OSI partisans out
there.

>I find it unfortunate that he (and others of his calibre) can't/won't
>constructively contribute to the standards process to ensure that
>their concerns about OSI are addressed, rather than to make money
>detracting it.

Given that Rose has a cachet as an OSI expert (whether deserved or
not) and has two books about OSI protocols, I'd say he has more of a
financial stake in OSI than not. Also, if I understand the story
correctly, Rose was and continues to be involved in various standards
activities. But this is tangent to the point of this thread.

>While I won't claim that OSI is
>perfect, I will claim that it's much better than Rose and other IAB
>types would like us to believe. The standards bodies may be slow, but
>they do work.

Aah. the promise of some meat. Could you amplify on this point,
please?  We all know there's a dispute and I've heard lots of bad
things about OSI. Are there any good things to report?

Rick.
smith@sctc.com            arden hills, minnesota

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 1992 22:02:14 GMT
From:      SCHMCH2@AWIIMC12.IMC.UniVie.AC.AT (Christoph Schmutterer)
To:        comp.dcom.lans,comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Routing Token Ring to Ethernet (3270 Emulation)

 
 
In our department we are using a Thin Wire Ethernet but
for some of our users it is necessary to use the services
of an IBM mainframe. The mainframe services are brought
via Token Ring and the PC3270 Emulation program by IBM.
 
Since all of our users are connected to the Ethernet
but access to Token Ring is limited to two connections
our questions are:
 
1) Is it possible to set up a local gateway between the
   Token Ring and the Ethernet so that every Workstation
   can act as an 3270 Terminal (no other services are
   needed from the Token Ring environment) ?
   I am thinking of a simple software solution for a PC
   connected to both, the Ethernet and the Token Ring.
 
2) Can we use our Novell Netware 3.11 to do that.
   And if, how ?
   The description of routing possibilities is rather
   limited in the documentation provided by Novell.
 
Thanks,
-------------------------------------------------------------------
CHRISTOPH SCHMUTTERER     E-MAIL: SCHMCH2@AWIIMC12.IMC.UNIVIE.AC.AT
DEPARTMENT OF BIOMEDICAL  PHONE : +(1)-40400 3985
ENGINEERING AND PHYSICS   FAX   : +(1)-40400 3988
UNIVERSITY OF VIENNA
AUSTRIA, EUROPE
QUIT
RSITY OF VIENNA
AUSTRIA, EUROPE

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jun 92 22:17:29 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable broadcast of files ?

Consider the Coherent File Distribution Protocol, RFC 1235.

BTW, your e-mail address is incorrect.

-- 
Stephen Trier        Dumb error message of the month:
CWRU IRIS/INS         "Mar  1 18:07:18 ziggy xntpd[65]: Clock appears to
trier@ins.cwru.edu     be 86398 seconds slow, something may be wrong"

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 92 23:06:23 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun4.211001.29145@sctc.com>, smith@sctc.com (Rick Smith) writes:
|> Oddly, I haven't seen much of a flame war on this subject before.
|> Maybe I just haven't been subscribing to the right groups at the
|> right times. Anyway...
|> 
|> Interop last month left me with the feeling that OSI transport
|> protocols (and below) were simply not worth bothering with.  You have
|> a choice of two incompatible standards (TP0 vs TP4).  Neither ISO
|> transport protocol provides services as good as what is routinely
|> available in the Internet environment.

Transport Class 0 (TP0) and Transport Class 4 (TP4) are defined 
in one standard (ISO 8073).  The transport class is negotiated
(downward if necessary) for each transport connection.  This is
an end system negotiation which should not generally be a problem
in compliant systems (i.e. those supporting the required transport
classes).  I'm not arguing that the multi-class option is good or
necessary, I'm trying to clarify the issue.

NOTE - the choice of network service does impact the
transport class options (e.g. TP0 over CLNP is not supported).

The real problem is that there are two unique network
layer standards which are not interoperable or
negotiable.  The CONS/X.25 network
layer service and protocol are generally supported in Europe 
(and several other countries outside of the U.S.) and
more recently by U.S. phone companies (embedded in their X.400 
services).  The U.S. government has chosen CLNS/CLNP as the network
layer service and protocol.  Hence we have two distinct domains
through which packets cannot transcend without the assistance of
a gateway protocol (e.g. transport gateway, application gateway,
etc.).  This obviously punishes the implementors and is of no
benefit to users either.  This is one of the many reasons the 
OSI standardization process has been chastised.

It would be nice to see this disappear but individuals have tried
for many years without any success.
  
NOTE - stating that TCP is a better protocol than TP4 is 
typical unsubstantiated rhetoric that leads to mindless debates.
The protocols are simply different, each having some advantages.
TCP clearly has much more practical user deployment and some
improved implementation features (slow start, nagle's algorithm,
etc.) which have led to a solid world-wide infra-structure.
This does not mean that the TCP protocol is better, it simply
means your chances of getting a world-wide, interoperable solution 
in 1992 are better.

|> 
|> I attended Marshall Rose's farewell tutorial on ISODE internals.
|> Besides being probably the "biggest" ISO implementer there is, he's
|> also one of its biggest detractors. Referring to the good parts of the
|> ISO protocol suite he said, "Well, it's after the accident and now we
|> need to decide if we can transplant the liver, and maybe the
|> spleen..." In short, he thinks there are a few good things (like maybe
|> the directory) but the rest of it is inferior to the Internet suite.
|> 

You may wish to look at the contributors in the ISODE header
decks before you enlist all of your praises to one individual.
Marshall is a dynamic speaker and writer, and knows a significant
amount about OSI issues.  However, there are a number of individuals
in the industry and in academia (especially the U.K.) who have 
significant knowledge of OSI.

Just an opinion from the bleachers.....

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      06 Jun 92 00:09:22 GMT
From:      Mark.McIntosh@engr.UVic.CA (Mark  McIntosh)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

On 5 Jun 92 11:40:47 GMT, chris@visionware.co.uk (Chris Davies) said:
>efk@ddsdx2.jhuapl.edu (Eileen Baust) writes:
>: I need to be able to convert a data file that was created on a SUN
>: 3/260 using data structures with floats, bit fields,
>: bytes,integers, and long words.  The data is to be used by a Dell
>: 486. There is a problem with bit fields in that the bit order gets
>: reversed. Any one know of any existing routines?
>Sun's XDR (eXternal Data Representation) stuff is very useful for this
>sort of thing.

You might also want to check out netCDF, the Network Common Data
Format, from the Unidata and the University of Carolina.  I just
discovered it but it sounds very interesting.  It is based on XDR as
well.  It might be more straightforward to use, I don't know.

I've attached the netCDF README file below.  There was a more recent
release than the date on the README would indicate.

Mark J. McIntosh <Mark.McIntosh@engr.UVic.CA>
____________________________________________________________________________
University of Victoria, Faculty of Engineering - Dean's Office
Box 3055, Victoria, BC, CANADA    \ "...the mystery of life isn't a problem to
V8W 3P6            (604) 721-6049  \    solve but a reality to experience." 
UUCP: ...!{uw-beaver,ubc-vision}!uvicctr!sirius!mmcintos  \ from Dune


--------------------
			       Unidata netCDF
				October 1990

		 Copyright (C) 1988, 1989, 1990 UCAR/Unidata
	
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose without fee is hereby granted, provided
that the above copyright notice appear in all copies, that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of UCAR/Unidata not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission.  UCAR makes no
representations about the suitability of this software for any purpose.
It is provided "as is" without express or implied warranty.  It is
provided with no support and without obligation on the part of UCAR or
Unidata, to assist in its use, correction, modification, or enhancement.

Included in this distribution are: the C source for the netCDF data
access library, sources for the FORTRAN jacket library for various
systems, documentation for the netCDF library and utilities in the form
of a netCDF User's Guide, source for the netCDF utilities ncdump and
ncgen, a directory of test programs to verify the correct implementation
of the netCDF library in new environments, and a directory of XDR
(eXternal Data Representation) source code for environments that do not
support XDR.

The purpose of the Network Common Data Form (netCDF) interface is to
allow you to create, access, and share scientific data in a form that
is self-describing and network-transparent.  "Self-describing" means
that a file includes information defining the data it contains.
"Network-transparent" means that a file is represented in a form
that can be accessed by computers with different ways of storing
integers, characters, and floating-point numbers.  Using the netCDF
interface for creating new scientific data sets can improve the
accessibility of the data.  Using the netCDF interface in new software
for scientific data access, management, analysis, and display can
improve the reusability of the software for other data sets and by
other users.

The netCDF software provides common C and FORTRAN interfaces for
applications and data.  It has been tested in various environments,
including various versions of UNIX, VMS, OS/2, MacOS, and MSDOS.  It is
being made freely available to encourage the sharing of both scientific
data and the software that makes the data useful.

You can obtain a copy of the latest version of netCDF software using
anonymous FTP.  For UNIX systems, a compressed tar file can be
accessed (in binary mode) from the file netcdf.tar.Z in the anonymous
FTP directory of unidata.ucar.edu (128.117.140.3).  VMS sites can get
a backup saveset of the same software from the anonymous FTP directory
of laurel.ucar.edu (128.117.140.6).

A mailing list, netcdfgroup@unidata.ucar.edu, exists for discussion of
the netCDF interface and announcements about netCDF bugs, fixes, and
enhancements.  To subscribe, send a request to

	netcdfgroup-adm@unidata.ucar.edu


-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 01:18:45 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP over long-delay links (summary + more)

In article <87921@bu.edu>, apollo@buengc.bu.edu (Doug A. Chan) writes:
} 
} -I did the same test (rcp between two machines with a 256Kbit/sec link and
}  128ms round-trip delay) but also tried doing two and three simutaneous
}  rcps.
}  Results:  The times scaled linearly with the number of transfers!
}            (a single rcp took ~1 minute, two rcps took ~2 minutes each,
}             three rcps took 3 minutes each.)  The average thruput was
}            130-140Kbits/sec regardless of the number of rcps.
} 
}  I would not have expected this if the TCP window size was the limiting
}  factor.  I'm guessing that our bandwidth is actually being limited by
}  the bandwidth managers on both ends due to their overhead of frame
}  acknowledgements.  I'll be doing a few more tests to confirm/deny this.

I posted something on this earlier, but maybe it went into the net
bitbucket.  What is the nature of the underlying serial link?  Some
link layers have their own windows.  What you're seeing is consistent
with that hypothesis.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Jun 1992 01:56:39 GMT
From:      MLONG@isucard.card.iastate.edu
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Re: Routing Token Ring to Ethernet (3270 Emulation)

>                                                                                                                                                     
>                                                                                                                                                     
>In our department we are using a Thin Wire Ethernet but                                                                                              
>for some of our users it is necessary to use the services                                                                                            
>of an IBM mainframe. The mainframe services are brought                                                                                              
>via Token Ring and the PC3270 Emulation program by IBM.                                                                                              
>                                                                                                                                                     
>Since all of our users are connected to the Ethernet                                                                                                 
>but access to Token Ring is limited to two connections                                                                                               
>our questions are:                                                                                                                                   
>                                                                                                                                                     
>1) Is it possible to set up a local gateway between the                                                                                              
>   Token Ring and the Ethernet so that every Workstation                                                                                             
>   can act as an 3270 Terminal (no other services are                                                                                                
>   needed from the Token Ring environment) ?                                                                                                         
>   I am thinking of a simple software solution for a PC                                                                                              
>   connected to both, the Ethernet and the Token Ring.                                                                                               
>                                                                                                                                                     
>Thanks,                                                                                                                                              
>-------------------------------------------------------------------                                                                                  
>CHRISTOPH SCHMUTTERER     E-MAIL: SCHMCH2@AWIIMC12.IMC.UNIVIE.AC.AT                                                                                  
1. You could use OS/2 2.0 with Extended Services.  It has a SNA Gateway                                                                               
that will support your configuration (upstream Token Ring, downstream                                                                                 
Ethernet).  IBM PC/3270 program will need to be used on the workstaions,                                                                              
PC 3270 V3, and 3270 Workstation Prog is not supported on Ethernet.  The Gatewa                                                                       
y would not need to be dedicated, it could also be running LAN Server, DBM                                                                            
Server, or could even be somebodys workstation as long as they did not turn it                                                                        
off:->                                                                                                                                                
2.  If you have TCP/IP on your host, you could set up a TCP/IP gateway                                                                                
with IBM OS/2 2.0 and IBM TCP/IP 1.2, and use CUTCP or some other TN3270                                                                              
program on the workstations.  This is could also be non-dedicated.                                                                                    
                                                                                                                                                      
Mike Long                                                                                                                                             
Iowa State Univ.                                                                                                                                      
Sorry if this post messes up your news reader :->                                                                                                     
                                                                                                                                                      
                                                                                                                                                      

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 02:40:33 GMT
From:      mwitt@ogicse.ogi.edu (Mike Witt)
To:        comp.protocols.tcp-ip
Subject:   Re: Throughput calculation in ttcp test program

In article <1992Jun5.163251.825@ultra.com> shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
>
>In all BSD based implementations of sockets/TCP/IP, the data link layer
>driver has no choice but to discard packets when the higher layers are
>feeding it more data than it can shove out onto the wire.

This part certainly makes sense.  But I would have thought that
the higher layer could stop accepting data from the user process
when the lower layer queue was full.

>If you start thinking about how it might be possible for the data
>link layer to apply back pressure, particularly all the way back to
>the specific application that is flooding the network, it's hard to
>see how it could be done.

Hmmm... Given multiple user programs all sharing the same "data
link" layer, I guess I would have to agree.

A quick check of *my* system seems to confirm what you're saying.
UDP output speed is just how fast the application process can
pump the stuff out.

-Mike


-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 04:28:43 GMT
From:      rcain@netcom.com (Robert Cain)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

chris@visionware.co.uk (Chris Davies) writes:
: 
: Sun's XDR (eXternal Data Representation) stuff is very useful for this
: sort of thing.  It's now in the public domain, and there's an RFC about
: it (but I can't remember the number offhand).

Aw common, please try.  Really.

: 
: Yes. RPC (Remote Procedure Calls) using XDR.  Wonderful stuff.
: 
: Oh yes, there's now a reasonably good Nutshell book about RPCs which is
: well worth getting and reading in conjunction with the relevant RFCs.
: 

Yes?  And it is...   :-)

Thanks,

Bob

-- 
Bob Cain    rcain@netcom.com   408-358-2007

There has been an alarming increase lately In the number of things
about which I know absolutely nothing.
                                      Ashleigh Brilliant

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 04:48:55 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip,comp.dcom.sys.cisco
Subject:   SUMMARY: TCP/IP over X.25


Following is a summary of the responses that I received via e-mail in
response to the following query:

 >I am in the unenviable position of finding out what kind of performance
 >I can get from running TCP/IP through routers (say cisco) over a
 >semi-private X.25 network (access lines of 19.2kbps to 56 kbps).
 >
 >Are there any pitfalls to running TCP/IP over X.25 other than the obvious
 >ones (increased latency - how much?  Increased packetizing overhead)?
 
I received lots of interesting and informative replies.  I feel much
better, actually, about this endevour and know enough to learn more now.
Thanks again.

------

Phil,

we run it for over 35,000 hosts in the UK over 2Mbps x.25
it works quite well of your x.25 switches are any good & can set
parameters on VCs very high (i.e. window & packet size) otherwise its
rubbish...

mail R.Day@jnt.ac.uk 
(bob day) who is the manager if the JIPS (JANET IP Service)
 
for technical details

 jon


------

We have run IP over our private X.25 network for some time using the
default level 2 window and packet size.  It helps a lot to have multiple
virtual circuits defined for each destination.  I think the cisco defaults
to 4, and you can use up to 8.  It would help to open up the X.25 window
and increase the packet size, but our X.25 people would not do that for us.
With multiple IP destinations in your X.25 map you can pretty much keep the
line busy.  The X.25 packet overhead is not that much when you are sending
large IP packets.  It works if you must do it that way.  We are moving to
FT1 links now using hdls direct links, as our packet network only runs to
56K.  We also run DECnet and AppleTalk over the packet network.

Dave.

------

> I am in the unenviable position of finding out what kind of performance
> I can get from running TCP/IP through routers (say cisco) over a
                                                     ^^^^^
Or say Wellfleet.
        
> semi-private X.25 network (access lines of 19.2kbps to 56 kbps).
>
> Are there any pitfalls to running TCP/IP over X.25 other than the obvious
> ones (increased latency - how much?  Increased packetizing overhead)?

Yes.  The customer may wish at some time to *migrate* to Frame Relay.
If so, you need to choose a vendor's router that can run both X.25
and Frame Relay at the same time.  Wellfleet can do this and other
major vendors can not.

> Thanks for any info...

If possible, I would suggest running two X.25 links to the same site
and using the W&G DA30 to measure traffic statistics.

------

The amount of demand on bandwidth will determine any increased latency
you may notice.  For instance, if you only run a couple of telnet
sessions to machines on the remote LAN, you probably won't notice
any latency at all (even at 19.2kbps).  However, if you have dozens
of hosts on one LAN performing continuous NFS requests to a remote
LAN, even at 56kbps you will notice pretty sluggish performance.

Packetizing overhead will probably be negligible compared to the
bandwidth difference.  However, you can minimize any packetizing
overhead by using as large a X.25 packet size as you can over the
X.25 network.

-------

The two ways of putting IP in X.25 have their advantages and 
disadvantages.  One way is to set the M bit in the X.25 header and
let the IP packet span multiple X.25 packets.  The receiving X.25
entity the reassembles the IP packet by abutting the parts.  This
is efficient but non-standard.  Also, if one packet is dropped the
entire IP packet is bad.
        
The other method is to set the MTU for the line to the packet size
of the X.25 link.  This causes IP fragments to be made.  These 
fragments will pass through the network until the destination is
reached before reassembly.  This is the method mentioned in the 
RFC for IP over X.25.  

With both of these methods it is desired to negotiate the X.25 packet
size to be as large as possible.  In some networks this is not allowed
because some X.25 switches take a severe preformance hit when handling
large packets.

Good Luck

Mark

-------

Hi Phil,

Your question opens up a rather large area.  Unfortunately, any answer
should end with "...your mileage may vary".

The principle variables besides bandwidth are packet size and X.25 net
delay.  Usually you have no control over either, so all you can do is
predict what you'll end up with.

One way to state performance is as useful user data throughput as a
fraction of nominal line bandwidth.  If you get 80% you're doing OK, but it
can range from 5% to 95%.  Telnet/TCP/IP over X.25 is generally quite
inefficient, due to 40 bytes of TCP/IP + 5 bytes of X.25 per 1 byte of user
data.  File transfers might get you to 95% efficiency if you can send 1K
packets and if the delay across the net is such that you don't get flow
control blocked, by either TCP, X.25 packet level, or LAPB frame level.
Typically TCP will offer a 4k window, and X.25 typically varies from
window-2/packetsize-128 to window-7/packetsize-2048.

If the application is File Transfer, or some other big-packet background
application, then you don't have to worry too much, but if the application
is interactive traffic with remote echo, its worthwhile trying to improve it. 
Depending on your application, there's a variety of techniques you might
want to draw on that can make substantial improvements.  (Apologies in
advance for the semi-commercial).  

For interactive traffic (Telnet), you can make big improvements by getting
rid of the 40 byte TCP/IP header.  One way to do this is to use a protocol
translator to convert Telnet to X.25/X.29/X.28/X.3 at the edge of the X.25
net, and then back to Telnet at the other side.  We have customers that do
this and get very low round trip times for interactive remote echo
applications.  The downside is there's more configuration than just using
straight TCP/IP over X.25.  Another way to reduce the 40 bytes is to use
Van-Jacobson TCP/IP Header Compression over the X.25 links.  This will
reduce the 40 bytes to 5, typically.  We have this in our 9.0 release.
This will improve not only Telnet traffic, but any small average
packet-size application, such as SMTP, SNMP, etc.

Have fun, good luck, and remember, your mileage may vary!

  -- Jim
-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-243-8100 (day)  
                              | Fax:      415-243-0471

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 09:31:00 GMT
From:      thad@btr.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable broadcast of files ?

In article <1992Jun2.205549.11696@ct.mcd.mot.com> tan@ct.mcd.mot.com (Tan Bronson) writes:
>
>    We've got a customer who needs to update 15-20 nodes with a 1M byte
>file 'ASAP' via ethernet. They were using sequential rcp's, but this was
>too slow.  I've written a trivial broadcast file transfer program
>(hacked from rwhod), but without any handshake this program is prone
>to network errors.
>
>    Does PD code exist which supports a form of reliable broadcasting?
>I was thinking of writing my own, but I'm hoping someone has already
>done it!
>
>    Any clues would be greatly appreciated

I cannot answer your question directly (re: reliable broadcasts), but here
are some thoughts along with a suggestion for re-structuring your application.

Given a 1MB file, I've noticed on my net that I can rcp such a file anywhere
between 7 to 10 seconds more-or-less consistently.  This means a rough average
of 130 KBytes/sec.

If you have to update 15-20 nodes with separate rcp's, this could require
up to 3 minutes (at 130 KBytes/sec including all attendant overhead).

Reading between your lines, I have the impression your application is some
kind of database or "real-time inventory-control"-type situation.  If so,
it may be better to NFS-mount the partition containing that file and with
a server/client protocol have your 15-20 nodes access the file that way
during the active period(s) of the day; then rcp the file to each node (for
failsafe or shadow-like backup, presumably) during off-hours when the time
constraint doesn't apply.

If I read your situation incorrectly, then you might wish to investigate
the rdist program.

I have the distinct "feeling" that broadcast are not the way to distribute
data for critical applications.

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 15:33:04 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun5.064935.22143@medtron.medtronic.com>, rh0083b@medtronic.COM (Roger Hunen) writes:
> In article <1992Jun3.235852.9683@PacBell.COM> restock@srv.PacBell.COM (Bob Stockwell) writes:
>>What are the consequences of configuring two hosts with the same IP
>>addresses, accidentally?  If I understand ARP correctly, they would
>>both reply to an ARP request, and the ARP requestor would update the
>>ARP table with the last reply.  This could cause a lot of confusion.
>>Does anybody have experience with this problem?  Is there a suggested
>>way of avoiding and/or detecting the problem?  We are moving from a
>>NetBIOS network to an IP network.  In NetBIOS you must broadcast your
>>intention to use a NetBIOS name, before using it.  Is there a similar
>>protocol for IP, which would broadcast within a subnet?
> 
> Duplicate IP address will result in BIG problems (thoughyour network will
> probably not go down :-)). Packets will be routed to the wrong host,
> connections will be dropped, diskless workstations are going to hang, etc,
> etc, etc.
> 
> Many IP implementations are paranoid enough to ARP for their own IP address
> to detect this problem and complain about it. My suggested way to avoid
> this problem is to maintain a central database with IP addresses for your
> site. When somebody needs an IP address, he must ask his network
> administrator. If your site is large, hand out complete IP subnets to local
> administrators. I'd suggest that you setup DNS (Domain Name Service) and
> give it the same authority structure that you use for handing out IP
> addresses (ie. the network administrator who is authorized to hand out an
> IP address, will also be responsible to include the corresponding records
> in the DNS).
> 
> Regards,
> -Roger
> (I speak for myself)
-------------------
	While I agree with everything folks have said about "Don't even
think about it" I did run some tests. The tests were to log into various
local machines from PCs with a duplicate PC IP address. Depending on whether
one went through a NW 3.11 server acting as an IP router or not the results
differed. Basically it seems to be more of a test of arp caches than anything
else. Some replace old entries with new ones, others keep the old and reject
the new (until timed out). I think that covers the possibilities. In any
case all that happened was connections died, there were no routing snarls
because RIP ignores clients.
	I have an EXOS 205T Ethernet board, the smart kind with a cpu chip.
That board senses something and when warm reset it generates a new Ethernet
address each time according to some algorithm. Hmmm, big hmmmmm. Well, when
that occurs it takes a dozen or so outgoing packets from the PC to cause
arp caches of name server and local target host to believe the new Ethernet
address (hectoring into submission I suppose). 
        Joe D.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 09:50:04 GMT
From:      thad@btr.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable broadcast of files ?

In article <1992Jun5.221729.2852@usenet.ins.cwru.edu> trier@slc6.INS.CWRU.Edu (Stephen C. Trier) writes:
>Consider the Coherent File Distribution Protocol, RFC 1235.

Thanks for the reference to RFC 1235; it looks very interesting.

But unless I mis-interpreted the RFC, it requires the CLIENTS to initiate
the broadcast by contacting the server with either a full file transfer
request, FULREQ, or a partial file transfer, PARREQ.

The original poster's article gave me the impression that a single system
containing the "master" copy of the 1MB file self-initiates the transfer
to the other 15-20 nodes ("clients").

The RFC cites the reference client and server implementations as available
for ftp from cs.columbia.edu in the pub/cfdp directory; those programs appear
to be a good starting point!

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 92 16:45:05 GMT
From:      blarson@blars.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Program/Extending telnet to support file transfers

(why does someone in candada use distribution usa?)
In article <1992Jun04.191931.17314@brtph560.bnr.ca> gcasey@brtph424.bnr.ca (Errol Casey P910) writes:
>I'm interested in knowning  if there exist a version of telnet
>that can be used between unix hosts to transfer files.

Not that I know of, but the latest version of kermit (in open beta
test) supports telnet.  Look in the kermit/test directory on
watsun.cc.columbia.edu for files ck* .

-- 
blarson@usc.edu			usc!blarson			blarson@zog
		C news and rn for os9/68k!
But I was lonley, I was lost -- Without my little black box.
I pick up the phone and go Execute.			-- Kate Bush

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 92 09:23:33 -0700
From:      ewilts@galaxy.gov.bc.ca (Ed Wilts)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting "on the internet"

In article <1992Jun7.014017.15156@serveme.chi.il.us>, joeg@gagme (joe grosch) writes:
> curmw@dcatla.uucp writes:
> : 
> : We are investigating getting "on the internet" here; we currently get
> : a news/email feed via Georgia Tech's internet feed, but get no other
> : internet services.
> : 
> : We have received information about setting us up from both PERFORMANCE
> : SYSTEMS INTERNATIONAL and UUNET.  Does anyone have experience with
> : either of these companies, or better yet, have other advice about how
> : we could go about getting up and running with full internet services?  I
> : would very much apreciate it.
> : 
> 
> 	In order to get on the internet you need to do 3 things:
> 
> 		1.	Select 1 bright person from your office and and have that person
> 			deligate half their working day (at first) to getting your
> 			orginazition on Internet.

At least a half-day...  You'll need to identify software and hardware,
evaluate, test, install, etc.  This isn't a trivial task...

> 	Of course, all of the above is based on the premis that you have at
> least one UNIX system in house, and can dedicate a large part of it's 
> resources to an Internet feed. One should note that the current feed for 
> news is running about 25 Meg a day and depending on the size of your
> organization, how many additional offices you have and how many people are
> going to use the Internet your volume could be half again that volume. What
> I am getting at is in order to properly support this feed one needs at least
> one fast modem, several large disks, and a reasonablely fast UNIX box.

Please re-read the original question.  He ALREADY has a News feed and is now
looking for more complete Internet services.  This may include FTP, Telnet,
NFS-mounting volumes across the Internet, etc.

You can do all of this without speaking Unix.  Internet <> Unix <> News.
Our VaxCluster is behaving quite nicely on the Internet offering all sorts of
services.  The only real requirement to being on the Internet is that you must
run TCP/IP.  This is by no means Unix-specific.  As a side point, we also have
News running on our Vaxes.

> 	The modem of choice is a Telebit modem. These modems can run up to 9600
> bps when talking to another modem. The "hot" feature about these modems is
> they can sense another Telebit on the other end of line and they drop into a
> propritary compression mode and can obtain 48,000 (I think) bps. This is
> over normal phone lines, not T1 leased lines. Almost every Internet site
> uses these modems and I strongly recommend you do the same.

Sure they do...  Many Internet sites find that 9600 bps is far too slow and are
running 56K lines up to T3.  I would venture a guess that a very small
percentage of Internet sites actually use Telebits.  

> 	In order to store the traffic off the Internet one should dedicate at
> least one disk to this feed. The standard rule of thumb is your feed volume
> times the number of days the messages are going to exist on the system (7 to
> 10 days is normal) plus 15 percent fudge factor. A 350 Meg disk fits the
> bill nicely. 

Note that the original poster already has a News feed so he knows what he's up
against.  In order to store the traffic off the Internet, you don't need
anything.  Internet doesn't generate traffic - a News feed does.

> Josef Grosch         | UNIX/C Consultant. Specalizing in X/Motif, 
> joeg@gagme.chi.il.us | network programming, Internet, TCP/IP, and 
> Chicago, IL.         | UNIX System Admin. (708) 397-4804 

Specializing in Internet?  Appears to me you can't differentiate between
Internet services and a News feed...

I suggest the original poster contact Georgia Tech and talk to their network
people about registering as an Internet host and determine what the physical
link between the two sites should be.  In Canada, the procedures for
registration vary from province to province and this makes it difficult for me
to give the poster any specifics on how to connect...

-- 

Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Jun 1992 01:40:17 GMT
From:      joeg@gagme (joe grosch)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting "on the internet"

curmw@dcatla.uucp writes:
: 
: We are investigating getting "on the internet" here; we currently get
: a news/email feed via Georgia Tech's internet feed, but get no other
: internet services.
: 
: We have received information about setting us up from both PERFORMANCE
: SYSTEMS INTERNATIONAL and UUNET.  Does anyone have experience with
: either of these companies, or better yet, have other advice about how
: we could go about getting up and running with full internet services?  I
: would very much apreciate it.
: 

	In order to get on the internet you need to do 3 things:

		1.	Select 1 bright person from your office and and have that person
			deligate half their working day (at first) to getting your
			orginazition on Internet.

		2.	Hand a copy of Managing uucp and Usenet by Tim O'Reilly and
			Grace Todino to your Internet person. Your Internet person 
			should read this book very carefully BEFORE you begin the 
			process. _Managing uucp and Usenet_ is published by O'Reilly 
			& Associates, Inc. ISBN 0-937175-48-X. It cost about $25.00.

		3.	Have your Internet person contact and develop contacts at
			Georgia Tech. These people are priceless resources and can 
			help you every step of the way.

	Of course, all of the above is based on the premis that you have at
least one UNIX system in house, and can dedicate a large part of it's 
resources to an Internet feed. One should note that the current feed for 
news is running about 25 Meg a day and depending on the size of your
organization, how many additional offices you have and how many people are
going to use the Internet your volume could be half again that volume. What
I am getting at is in order to properly support this feed one needs at least
one fast modem, several large disks, and a reasonablely fast UNIX box.

	The modem of choice is a Telebit modem. These modems can run up to 9600
bps when talking to another modem. The "hot" feature about these modems is
they can sense another Telebit on the other end of line and they drop into a
propritary compression mode and can obtain 48,000 (I think) bps. This is
over normal phone lines, not T1 leased lines. Almost every Internet site
uses these modems and I strongly recommend you do the same.

	In order to store the traffic off the Internet one should dedicate at
least one disk to this feed. The standard rule of thumb is your feed volume
times the number of days the messages are going to exist on the system (7 to
10 days is normal) plus 15 percent fudge factor. A 350 Meg disk fits the
bill nicely. 

	Good luck and welcome to a larger world.

--
Josef Grosch         | UNIX/C Consultant. Specalizing in X/Motif, 
joeg@gagme.chi.il.us | network programming, Internet, TCP/IP, and 
Chicago, IL.         | UNIX System Admin. (708) 397-4804 

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 92 04:07:14 GMT
From:      mgic@mixcom.mixcom.com (mgic)
To:        comp.unix.questions,comp.protocols.tcp-ip
Subject:   ifconfig & slattach : Things I don't understand (yet)


I need to understand how ifconfig and slattach (SLIP driver)
are related. The problem I have is that a pseudo tty cannot be 
dedicated to being a SLIP device. The tty must be turned into
a SLIP device, then the driver detached so that the pseudo tty
can be used for non-SLIP access. 

I understand how to use the tools to configure a tty to be 
a dedicated SLIP device, but not how to use them to regularly
attach and detach a SLIP driver from a tty, and make sure
everything understands what it is supposed to be at all times.

Here are the details:

Remote computers will access a host via X.25. The remote
systems (PCs) will be using SLIP to get TCP/IP through
modems. The host will see a connection come in through
a pseudo tty. This is shown below.

[PC]-[modem]----[modem]-|
                        |
[PC]-[modem]----[modem]-|X.25 Network|----[AIX host]
                        |
[PC]-[modem]----[modem]-|


Each remote computer will not have a dedicated IP address.
Instead, the algorithm described below will be used to
allocate IP addresses.

Each pseudo tty has a number (0, 1, 2, etc.). The number will be
used as part of the host ID for the SLIP device, and part of the
remote computer's IP address. For example, assume the
network address is 3.0.0.0, and the tty is "1". The host address
for tty 1 is 3.1.0.0, while the address of the remote computer will
be 3.0.0.1. (The tty number will be transferred to the remote computer
each time it calls so that the TCP/IP kernel can be configured
prior to being started. The tty number will be transferred using
std. async communications before the SLIP driver is attached on
the host side.)

This algorithm will be used because a remote computer does not
know what tty it will be connected to when it calls (via a
X.25 network). Therefore it will not know the IP address of the 
host (SLIP device) until after it connects.

The problem again: A tty cannot be dedicated to being a SLIP device.
When a session completes, the SLIP driver needs to be detached
from tty.

When ifconfig is used, a SLIP device (sl0, sl1, sl2, etc.) is
specified. But when the SLIP driver (slattach) is used, only
the tty name is specified ("slattach pty1"). How do I make sure
a tty is associated with a SLIP device? For example, I want
pty1 to be sl1, pty2 -> sl2, etc.

	ifconfig  sl0  inet  3.0.0.1  3.1.0.0  up
	slattach  pty0

As far as I can determine, when a tty is dedicated as a SLIP 
device this happens because the commands are used sequentially
(ifconfig -> slattach -> ifconfig, etc.). In my case the ifconfig
and slattach will be performed, then undone at the end of a session,
then performed again for the next session on the same tty, while
this is also happening on other ttys.

The host system is an RS/6000 running AIX 3.2.

(If the tty did not need to be used for non-SLIP sessions, this
seems like it would be easy - just configure each pseudo tty
as a SLIP device. But, I cannot dedicate certain pseudo ttys to 
be SLIP devices, and others to not be SLIP devices, and force
in-coming SLIP sessions to connected to a SLIP tty.)

Thank you.

Dean

P.S. Are there any books that describe and explain UNIX network 
configuration in detail?

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Jun 1992 05:00:22 GMT
From:      surendar@maxine.wpi.edu (Surendar C.)
To:        comp.protocols.tcp-ip
Subject:   Novice Question: Using the UDP broadcast facility

I am writing an application where the server broadcasts messages. The
applcation will run on a Ethernet based LAN and so I was hoping to use
the UDP broadcast. However, the sendto() expects a special broadcast 
address. How can I find this address? I'm working on a bunch of Sun 
Sparc IPC's. 

THank you for any help
surendar

surendar@cs.wpi.edu


-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 92 05:44:31 GMT
From:      libes@cme.nist.gov (Don Libes)
To:        comp.protocols.tcp-ip
Subject:   Re: Telnet Program/Extending telnet to support file transfers

In article <1992Jun04.191931.17314@brtph560.bnr.ca> gcasey@brtph424.bnr.ca (Errol Casey P910) writes:
>I'm interested in knowning  if there exist a version of telnet
>that can be used between unix hosts to transfer files.
>I'm unaware of any such functionality in the original program,
>and would be interested if anybody has added Xmodem, Ymodem,
>Zmodem, or even Kermit to telnet.
>
>I would like to be able to telnet to a host, and execute ckermit
>or s(x,b,z) to receive a file from the other host.

tip, cu and any similar program does file transfer across the same
channel.  You can steal their technique pretty easily.  One way is to
tip back to yourself and then start telneting/kermitting out.  When you
reach the final host, just use the tip (or whatever) conventions.

You could copy what these programs do, and at the same time avoid the
extra physical loop with an Expect script.  Something like:

	set out [open $outfile w]
	send "cp $infile /tmp/$pid\r"; 			expect -re $prompt
	send "compress -f /tmp/$pid\r";			expect -re $prompt
	send "uuencode /tmp/$pid.Z /tmp/$pid.Z > /tmp/$pid.Z.uu\r"
							expect -re $prompt
	send "cat /tmp/$pid.Z.uu\r"
	expect -re "(\[^\r].*)(\r|\n)*" {
		puts $out $expect_out(1,string)
		if [string match $expect_out(1,string) end] {
			close $out
		} else {
 continue -expect
		}
	}
	exec uudecode $pid.Z.uu
	exec uncompress $pid.Z

(PS: I didn't just write this.  It came out of a program similar to
what you described a need for.)

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

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 03:08:54 GMT
From:      apollo@buengc.bu.edu (Doug A. Chan)
To:        comp.dcom.modems,comp.protocols.tcp-ip
Subject:   Help with SLIP on Xylogics Annex XL...

I'm trying to get SLIP working between a terminal server and a PC.
The terminal server is a Xylogics Micro Annex XL (v6.1 software) with
a Telebit Trailblazer attached to port 8 (full modem control lines).

I've tried two different PC setups, one with PC-NFS v3.5 and the other
running SCO Unix.  The two machines can talk to each other using SLIP
just fine over a direct (null modem) connection.

-PC-NFS connected to the terminal server _directly_ with a null modem
 and running at 2400bps works fine. I can ping and telnet (albeit, very slow).
-PC-NFS connected to the terminal server via modem at 2400bps
 doesn't quite work.  I can sometimes get ping to work but never telnet.
 Also, if ping works and then I try to telnet (which will fail), the
 pings following it will fail.
-I couldn't get the SCO Unix machine to ping or telnet via 2400bps modem.
 I haven't tried a direct connection yet...
The SLIP compression stuff on the terminal server has been turned off.
Does anyone have any ideas? Or a similar working setup?

-Doug
apollo@buengc.bu.edu

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 03:13:40 GMT
From:      bushman@che.utexas.edu (Scott Bushman)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: tape backup of dos machine to unix tape drive




 What follows is a summary of responses I received from people for the
 posting given below.  This should interest most people with access to
 unix based tape backups available to them.

 1  The original message

    > Subject: Software for remote backup to tape drives on unix machines
    >
    > I am interested in performing tape backup of my DOS machines harddisk
    > to a remote UNIX machines tape drive directly.  I have a Western
    > Digital Elite Plus ethernet card installed on my pc.  I am familiar
    > with ftp and telnet, however, I am interested in backing up the entire
    > drive, not just single files.
    >
    > One possibility, would depend on the availability of a dos version of
    > the unix command rdump.  Presently, I use cutcp for my internet
    > access.  This gives me lpr, lprm, lpq, rcp, ftp access from my dos
    > machine.  The next step is to allow a command such as rdump from my
    > dos machine.
    >
    > Please send replies either to the news group or to my e-mail.  In any
    > case, I will post a summary of responses that I receive on this
    > subject.

 2  Thanks to the following for responding

    Al Stangenberger  forags@nature.Berkeley.EDU
    John Davis        CHEM194@csc.canterbury.ac.nz 
    Mike Krasnicki    kraz@born.phys.virginia.edu
    Richard Robison   rr@isye.gatech.edu 
    Philippe Villard  pv@faulty.che.utexas.edu
    Adrian Miranda    ade@clark.edu
    Tony Catone       catone@dmark.wharton.upenn.edu

 3  A summary of different techniques suggested in mail or News

    One solution is to use commercial software, and according to Al
    Stagenberger, Adrian Miranda, and Phillippe Villard, is that FTP
    Software has tcp-ip software that will do the job.  With a remote tar
    function you can dump a whole DOS logical volume as a tar archive to a
    Unix box.  This solution is excellent because you do not have to leave
    the DOS environment.  The disadvantage is it requires the use of
    commercial software, which may be difficult for economically hampered
    users

    Another commercial product, mentioned by Richard Robison and John
    Davis is that of PC-LifeLine from Sun will allow you to do this
    through PC-NFS.

    In the public domain, John Davis also suggested SOSS (son of stan's
    server - a PD nfs server package for the PC) to allow me to mount PC's
    to our unix box, and then back them up from that end. The other nice
    thing about doing it that way is if you've got a lot of small HD's on
    the pc's , and a decent sized tape drive to back up to you can mount
    several PC's, start the backup going to do the whole lot.

    Tony Catone, posted the following to the Net which suggests using
    SOSS, but mentions the improved version and gives a ftp site, and also
    mentions some of the major limitations.  We use SOSS, the PD NFS
    server for DOS, available via anonymous ftp from various places
    (including hilbert.wharton.upenn.edu [128.91.11.35] in pub/pc/tcpip)
    to export the drive(s) to be backed up to the Unix system with the
    tape drive.  At night, the Unix system checks to see which PC drive(s)
    in the dept. are NFS mountable and mounts them under a /pc directory.
    Once we have mounted all available drives, we fire tar on the Unix
    system and backup the /pc directory to tape.  The version of SOSS at
    hilbert fixes a couple of bugs (SOSS didn't handle directories with
    extensions properly, and had a problem with IP numbers).  The major
    limitation of SOSS is that it holds the inode list in memory, and only
    uses conventional DOS memory; backing up a big hard disk with lots of
    files (several thousand) can exceed the memory of your DOS system and
    cause SOSS to die.

 4  My eventual technique and implementation

    Of the above techniques, my choosen techique was to use SOSS from the
    ftp site hilbert.wharton.upenn.edu [128.91.11.35] in pub/pc/tcpip.  The
    installation guide of this software is very good and goes through all of
    the changes and commands that must be made on both the DOS and the Unix 
    machines.  The only confusing thing for me was changing the subnet mask.
    This is done bye specifying the number of subnet bits, whether 0, 8, or 
    16.  (If you want a subnet mask of 255.255.0.0, use a number of subnet 
    bits of 0, for 255.255.255.0, use 8, and so on).  Also, another 
    limitation of the software (besides a limited number of inodes), was that
    the pc must be dedicated. i.e., you mount the harddrive and back it up,
    but the pc is not usable during this time (at least that's what I found
    out, I couldn't figure out a way to make it a TSR).

 5  Newsgroups this is cross-posted to for those interested in the subject

  	 comp.protocols.nfs! 1-4564,4580
	 comp.protocols.tcp-ip! 1-20529,20590
	 comp.protocols.tcp-ip.ibmpc: 1-10827
	 comp.sys.ibm.pc.hardware: 1-30113
	 comp.sys.ibm.pc.misc: 1-25299
	 comp.sys.ibm.pc.net: 1-129
	 comp.unix.msdos! 1-1349,1352
	 comp.windows.misc! 1-3489,3495


I hope this answers anybodys questions in regards to tape backup of a 
DOS machine to a tape device on a unix machine.

If you still have questions drop me a line and I'll see if I can help

-- 
Scott Bushman
Dept. of Chemical Engineering		phone:	(512) 471-1046
University of Texas @ Austin		FAX:	(512) 471-7060
Austin, TX  78705			e-mail:	bushman@che.utexas.edu

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 09:24:20
From:      morse@quark.mpr.ca (Daryl Morse)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


In article <1992Jun5.215255.21135@sctc.com> smith@sctc.com (Rick Smith) writes:

   morse@quark.mpr.ca (Daryl Morse) writes:

[...]

>   Thank you. This is the first pro-OSI post I've ever read on this
>   thread. I was beginning to wonder if there were no OSI partisans out
>   there.

We're around, just not always taking time to defend OSI...

>   >I find it unfortunate that he (and others of his calibre) can't/won't
>   >constructively contribute to the standards process to ensure that
>   >their concerns about OSI are addressed, rather than to make money
>   >detracting it.
 
>   Given that Rose has a cachet as an OSI expert (whether deserved or
>   not) and has two books about OSI protocols, I'd say he has more of a
>   financial stake in OSI than not. Also, if I understand the story

Careful. While Rose is somewhat unusual, in that he has a kind of dual
persona, he is hardly a friend of OSI. He seems like the upper layers
(sort of) but ruthlessly bashes the lower layers. Actually, he seems
to like the application layer, but less so everything else. To be
honest, I really don't like speaking for Marshall Rose. I suggest
reading his book and finding out for yourself. Just remember to take
quite a few of his negative statements with a grain of salt big enough
to acknowledge to the fact that the book was written several years
ago. Several years, even in the OSI standards community is a long time.

>   correctly, Rose was and continues to be involved in various standards
>   activities. But this is tangent to the point of this thread.

To my knowledge, Rose only participates in IAB standards activities. I
believe he is presently the chair of the SNMP committee.  To
reiterate, my point is that Marshall Rose spends his time (and makes
money) bashing the __OSI__ standards process, but makes virtually no
effort to contribute positively to that process. He has made *many*
negative remarks in many forums about those who attend __OSI__
standards meetings. A colleague of mine (who was intimately involved
in the OSI network layer) met Rose recently after being bashed at
Rose's tutorial at the recent IFIP OSI conference at UBC. If Rose
wanted to, he is quite capable of making a significant contribution to
the __OSI__ standards process.  However, it seems that he is not
interested...

>   >While I won't claim that OSI is
>   >perfect, I will claim that it's much better than Rose and other IAB
>   >types would like us to believe. The standards bodies may be slow, but
>   >they do work.
 
>   Aah. the promise of some meat. Could you amplify on this point,
>   please?  We all know there's a dispute and I've heard lots of bad
>   things about OSI. Are there any good things to report?

This is not exhaustive:

BER: This has been discussed much lately. There are many people who
are more informed on the topic than I who could give an update on the
improvements that will come from new methods of encoding (i.e. PER,
etc.).

CMISE: Irrespective of those who continue to advocate SNMP (i.e.
Rose), CMISE is moving steadily towards being utilized in real network
management situations. SONET/SDH, the basis for B-ISDN will be managed
by CMISE. The object definitions are nearing final revisions. Mark my
words, SNMP will never be utilized to manage a telecommunications
switching equipment or transmission equipment. (I'm not saying SNMP is
going to be immediately replaced by CMIP for LANS...)

IS-IS: This is the OSI routing protocol. It has been extended to
support IP (i.e. Dual IS-IS) and will continue to be extended to
support other protocols as well. (i.e. Integrated IS-IS). NOTE: The
OSI network layer WILL NOT run out of addresses, unlike the Internet
network layer.

X.400, X.500: SMTP isn't in the same league as S.400. Nore is there an
equivalent of X.500 in the Internet protocol family.

B-ISDN: You will be hearing alot about this in the coming years. It
will form the basis for many of the advances in commercial computing
that will occur during the later half of this decade. B-ISDN is an OSI
protocol stack.

--
Daryl Morse                     | Voice : (604) 293-5476
MPR Teltech Ltd. 		| Fax   : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail: morse@mprgate.mpr.ca
Canada, V5A 4B5                 | Part of the B.C. Tel Group of Companies...

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 09:20:47 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

Someone asked "Is there anything good in OSI?"  The answer is X500.
Other than that I can't think of one.

Hank Nussbacher

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 15:58:09
From:      morse@quark.mpr.ca (Daryl Morse)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


In article <1992Jun8.213849.26223@nntpd.lkg.dec.com> goldstein@carafe.enet.dec.com (Fred Goldstein [k1io; FN42jk]) writes:

[stuff deleted...]

   In article <MORSE.92Jun8092420@quark.mpr.ca>, morse@quark.mpr.ca (Daryl Morse) writes:

>   >B-ISDN: You will be hearing alot about this in the coming years. It
>   >will form the basis for many of the advances in commercial computing
>   >that will occur during the later half of this decade. B-ISDN is an OSI
>   >protocol stack.
 
>   That's such complete and utter hogwash that I couldn't let it go by 
>   unchallenged!

[stuff deleted...]

You might be partially correct. In any case, I didn't make my point
properly, if at all.  As I have seen it, B-ISDN implies the bottom
three OSI layers. It doesn't imply upper layers.  SDH is physical.
ATM is datalink. Some other LAP-* goes at the network layer.
--
Daryl Morse                     | Voice : (604) 293-5476
MPR Teltech Ltd. 		| Fax   : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail: morse@mprgate.mpr.ca
Canada, V5A 4B5                 | Part of the B.C. Tel Group of Companies...

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 1992 13:16:20 GMT
From:      doc@magna.com (Matthew J. D'Errico)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

>-------------------
>	While I agree with everything folks have said about "Don't even
>think about it" I did run some tests. The tests were to log into various
>local machines from PCs with a duplicate PC IP address. Depending on whether
>one went through a NW 3.11 server acting as an IP router or not the results
>differed. Basically it seems to be more of a test of arp caches than anything
>else. Some replace old entries with new ones, others keep the old and reject
>the new (until timed out). I think that covers the possibilities. In any
>case all that happened was connections died, there were no routing snarls
>because RIP ignores clients.

The point was multiple *hosts* with the same IP address...  The description
to which you are replying mentioned multiple *servers* which would have
significantly different impact(s) than would multiple *clients*...


-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 92 14:32:32 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: reliable broadcast of files ?

In article <6921@public.BTR.COM> thad@btr.BTR.COM (Thaddeus P. Floryan) writes,
in regards to CFDP:
>But unless I mis-interpreted the RFC, it requires the CLIENTS to initiate
>the broadcast...

That is correct, but why can't the server tell the clients to initiate the
transfer?  :-)

The simplest way to do this would be via a UDP broadcast message.  In the
interest of reliability, I would much prefer opening a TCP connection to
each system at client startup, then signalling over those connections when
the file has changed and the clients should start CFDP.

-- 
Stephen Trier        Dumb error message of the month:
CWRU IRIS/INS         "Mar  1 18:07:18 ziggy xntpd[65]: Clock appears to
trier@ins.cwru.edu     be 86398 seconds slow, something may be wrong"

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 14:53:02 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

gsa@easyaspi.udev.cdc.com (gary s anderson) writes:

>NOTE - stating that TCP is a better protocol than TP4 is 
>typical unsubstantiated rhetoric that leads to mindless debates.
>The protocols are simply different, each having some advantages.
>TCP clearly has much more practical user deployment and some
>improved implementation features (slow start, nagle's algorithm,
>etc.) which have led to a solid world-wide infra-structure.
>This does not mean that the TCP protocol is better, it simply
>means your chances of getting a world-wide, interoperable solution 
>in 1992 are better.

The prevailing opinion seems to be that TCP is comparable in in
capabilities and performance to the ISO transport protocols. There
may be subtle differences that make specific activities perform better
in one suite than another, but overall both should work OK. At least
that's what I'm hearing.

If that is the case then why would anyone want to migrate _from_
TCP/IP to an ISO transport stack? It has been shown that you can
build an ISO transport level interface atop TCP/IP and run your
ISO upper level protocols on top of it. High performance TCP/IP
is much more easily available and I suspect interoperability
is easier to achieve.

>You may wish to look at the contributors in the ISODE header
>decks before you enlist all of your praises to one individual. ...

I brought up Marshall simply because he was the source of much of my
information on ISO protocols. My own motives for promoting this
discussion is to compare his notably dramatic opinions with those of
others. I've tried to find other _readable_ sources about ISO to no
avail. The standards themselves are awful.. I find RFCs to be lucid by
comparison. As for practical information (how much works, how much is
really used) the net looks like the best source.

Rick.
smith@sctc.com               arden hills, minnesota

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 16:54:13 GMT
From:      ccganzhorn@mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   TCP PUSH bit

I would like to hear from developers of TCP code regarding their conventions in
sending received data up to an application.  RFC 793 states only two conditions
for passing data up to the application:

1.	The receive buffer is full
2.	A PUSH bit has been received.

However, I have a TELNET and an FTP client implementation that never sets the
PUSH bit and they both work with a variety of TCP's (except for one, gee, guess
that's why I'm writing this).  So it would seems that most TCP's also send data
up to the application either when a timer expires or they simply always send
the incoming data up.

I'd like to know what the convention is in general.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 17:08:33 GMT
From:      preece@npdiss1.StPaul.NCR.COM (Bently Preece)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun4.211001.29145@sctc.com> smith@sctc.com (Rick Smith) writes:

   [about Marshall Rose]
   Besides being probably the "biggest" ISO implementer there is, he's
   also one of its biggest detractors.

I've read three of his books, and they were all full of good information.
The only thing Rose seems to like more that criticizing OSI, however, is
praising himself.  I disagree almost completely with almost all his
complaints against OSI;  and although the Internet suite of protocols are
very good, they're not as good as Rose thinks.

Rick also wrote,

   You have
   a choice of two incompatible standards (TP0 vs TP4).  Neither ISO
   transport protocol provides services as good as what is routinely
   available in the Internet environment.

Not exactly.  The most common complaints about OSI seem to be these:

A)  Poor design for the network layer.
B)  Poor lower layer performance (network/transport layers).
C)  Overly-complex upper layers (session/presentation/application layers).
D)  Overly-complex network management.

I think Rick was repeating A) and B) again.  These four arguments are
usually accompanied by some comment about how much better the Internet
solutions are.  In most cases, either the differences are imaginary, or
else the OSI scheme solves problems which were never considered by 
Internet.  For what it's worth, here's my two cents worth.

A)  Poor design for the network layer.

OSI allows three configurations for the network layer:  the connectionless
protocol CLNP, the connection-oriented protocol X.25, and a combination
which allows X.25 as a subnetwork to CLNP.  None of these is compatible 
with any of the others.  In contrast, Internet's single connectionless
protocol IP is supposed to be much cleaner.

The problem is that the world is already full of X.25 networks.  The PTTs
and other service providers won't throw away their existing networks
and start over, so how do you fit them into the new scheme?  I don't know
Internet's solution.  (Can anyone tell us?)  OSI chose to put CLNP over
X.25.  On the other hand, a pure X.25 network doesn't need CLNP at all,
since X.25 already does the routing.  The extra layer is wasteful overhead,
so ISO also allows X.25 to be used alone as the network protocol.

If you're concerned about interworking with arbitrary networks, use
CLNP on LANs, and CLNP over X.25 on WANs.  Only use X.25 alone on a
pure X.25 network.  The transport layer negotiates to provide whatever
service you need.

B)  Poor lower layer performance (network/transport layers).

The usual claim is that TCP/IP is faster/more reliable/more efficient/more
whatever than TP4/CLNP.  The only hard data I've seen on this seems to
show that the implementation has more effect on the performance than the
differences in the protocol, and that other things being equal TP4/CLNP
is as fast/reliable/efficient as TCP/IP.

I think that a lot of work needs to be done before this question is
answered.  Or else the work which has been done needs to be made more
public.  (Anyone?)

C)  Overly-complex upper layers (session/presentation/application layers).

As opposed to the Internet applications which are very simple.  On Unix
anyway.  Internet has a file transfer protocol which doesn't understand
file types or character sets.  (The peripheral liveware system does that, 
although I've never read the RFC on it.  Be sure to install one).  The
mail transfer protocol has problems handling non-English character
sets, non-text data, and other special cases, and gatewaying to other
types of systems.  Putting Internet applications on MVS or some other
operating systems has its own problems.

The OSI protocols are more complex, but they tried to be complete.

D)  Overly-complex network management.

Ditto.  Rose especially likes SNMP with its "Powerful get-next operator"
(which he invented), but even he admits that the first try at SNMP was
overly simple.  Wait for the final version.

All this isn't to say that the Internet suite is bad and OSI is good, only
that they have different problems.

The Internet philosophy, essentially, is to implement it, and when the
bugs are out, to write it up.  The advantage is that you know what you've
got when you're finished.  The disadvantage is that you're perpetually
stuck with the prototype.  On the other hand, the problem with ISO is
that they're so good at building camels.

If I want to download a file from a network server, then FTP is the perfect
solution, but I would be unhappy if I learned that my bank was using it to
send its daily transaction files to the home office.  Telnet is great for
logging onto the development host and editing a few files, but I wouldn't
suggest Wall Street use it for its automatic trading programs.

Anyway, take everything you hear with a grain of salt.  (Including this.)
-- 
-------------  
Bently Preece                                      NCR Network Products Div.
software engineer                                      2700 Snelling Ave. N.
b.preece@StPaul.NCR.COM                               St. Paul, MN USA 55113

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 17:52:35 GMT
From:      mgic@mixcom.mixcom.com (mgic)
To:        comp.unix.aix,comp.protocols.tcp-ip
Subject:   AIX SLIP limits - how to expand?


System: RS/6000
        AIX 3.2

The system appears to have a SLIP device limit of 8 (sl0 - sl7).
I cannot find any mention of limits in the AIX docs.
Does anyone know how to change (increase) this number?
Thank you.

Dean

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 18:29:33 GMT
From:      bourman@hpcc01.corp.hp.com (Bob Bourman)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a modem

/ hpcc01:comp.protocols.tcp-ip / bourman@hpcc01.corp.hp.com (Bob Bourman) / 10:01 am  Jun  5, 1992 /


>	Help. I thought SLIP was a synchronous packet framing protocol?
>
	>Or am I all confused? Can someone please clear up my confusion and
	>tell me how to use Serial Line IP over dial modems?
>
	>Thanks
>
	>BOBB
>----------

	Thanks for all those who replied. I must have been thinking of PPP.

	BOBB

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 1992 18:40:50 GMT
From:      bourman@hpcc01.corp.hp.com (Bob Bourman)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over a modem

/ hpcc01:comp.protocols.tcp-ip / bourman@hpcc01.corp.hp.com (Bob Bourman) / 11:29 am  Jun  8, 1992 /
/ hpcc01:comp.protocols.tcp-ip / bourman@hpcc01.corp.hp.com (Bob Bourman) / 10:01 am  Jun  5, 1992 /


#>	Help. I thought SLIP was a synchronous packet framing protocol?
#>
	#>Or am I all confused? Can someone please clear up my confusion and
	#>tell me how to use Serial Line IP over dial modems?
#>
	#>Thanks
#>
	#>BOBB
#>----------
#
	#Thanks for all those who replied. I must have been thinking of PPP.
#
	#BOBB
#----------

		NEVERMIND !!!   %';  I have been enlightened.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 1992 06:47:36 -0700
From:      ajayshah@alhena.usc.edu (Ajay Shah)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   SLIP over X.25?


I am posting this for a friend who does not have net.access.

---
Hi,

I wonder if anyone is aware of any implementation of SLIP over X.25 - either
public domain or commercial is fine. Let me describe the problem that I am
trying to address -- maybe someone has suggestions on how to tackle it.

We have an application running over a network of Sun machines and PCs 
(some of which run SCO Unix and some MS-DOS). Basically, we need to be
able to print to a printer attached to a PC from anywhere in the network. 
In other words, we need lpd functionality on a PC. With TCP/IP over Ethernet
things are fine. But we plan to migrate this to a WAN which is an X.25
network. In the long term, IP routers will be used, but I need a quick and
dirty solution now. Any suggestions? Will SLIP help at all?

Thanks,
-- 

Ajay Shah, (213)749-8133, ajayshah@usc.edu

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 19:34:05 GMT
From:      M16302@mwvm.mitre.org
To:        comp.protocols.tcp-ip
Subject:   Protocol Technology Forecast Questionnaire (Revised Instr')


 
    QUESTIONNAIRE TO FORECAST CAPABILITIES OF COMMUNICATION PROTOCOLS
                      FOR END-USER WORKSTATIONS
 
                            BACKGROUND
 
I am performing a survey that forecasts the present and future
capabilities of several communications protocols, hosted on end user
workstations, for several generic protocol services (e.g., File
Transfer). An end user workstation may be thought of as the principal
workstation in a regular working office (as opposed to a "Lab"
location).  The forecasts are done separately for different types of end
user workstations (e.g., IBM PC Compatible).  I am seeking respondents,
knowledgeable of the present and future capabilities of several protocol
suites, for one or more generic protocol services. From the respondents
point of view, the questionnaire for each generic protocol service is
independent of the other generic protocol services, so a respondent
may fill out the questionnaire for as few as one one generic protocol
service.  Of course, if a respondent has the knowledge and the time to
fill out the questionnaire for more than one generic protocol service,
this would be greatly appreciated.  The format of the questionnaire is
the same for each protocol service.
*
The objective is to rate different protocol suites for several generic
protocol services over the time interval from 1992 to 1999.  The rating
should consider all of the factors that affect the ability of a protocol
suite to provide the generic protocol service in question --
technical functionality, speed/performance, product availability ...   .
However, the rating should not consider cost.  The ratings are done
separately for three types of workstations: (1) IBM PC compatibles,
(2) Macintosh, (3) UNIX.
*
In order to perform the ratings, you may feel a need to know the power
of the operating systems and the computers, particularly for the
less-powerful PC workstations.  Assume that sufficient processing power
and Random Access Memory (RAM) are available to support the protocol
software.  For PC operating systems, assume that the current PC
workstations have Windows 3.1 capability and that the transition to a
32 bit multiprocessing operating system such as Windows NT or OS/2 will
be completed within 3 years.  For Macintosh operating systems, assume
that System 7 is the current standard.  Operating system power should no
be an issue for UNIX.
*
Please rate the protocol suites on a scale from 0.0 to 10. using a W3
format (any floating point number of field width 3).  Thus, scores of
"9.9" and "10." are both legitimate.
*
If you are able to rate some workstations, but not others, that is O.K.
Just set Workstation = "none" where it now says Workstation = IBM PC,
Macintosh, or UNIX for the workstations that you are not rating.  If you
fell that the service you are rating is independent of the type of
workstation, set Workstation = "all."
*
If you feel you are unable to estimate beyond a certain year, then
please try anyway!!  But if you can't, just do as many years as you can.
*
 
You may respond by Email or regular mail.  If you have an ASCII
text editor & can avoid changing the template, I prefer Email because I
can read your responses electronically.  If you respond by Email, please
make copies of this questionnaire for each service/capability that you
are forecasting.  Please place answers on the row with the first line
of the protocol suite description (where the x.x appears for the first
description).  Please send Email to RSHAIN @MITRE.ORG.
*
If you prefer to fill-in a hard copy of the questionnaire, please print
a copy of the questionnaire for each service that you are rating, and
send to: Robert Shain, The MITRE Corporation, Mailstop W633, 7525
Colshire Drive, McLean, Va. 22102.
*
                          NOTES
(1) "All standard services" means the set of services, based on the
published schedules (e.g., the GOSIP schedule), expected to be
commercially available for the protol suite in the target year.
For example, if you believe that Remote Database Access (RDA) capability
will be commercially available for the OSI protocol suite in 1993,
then this expectation should be considered when rating the OSI protocol
suite for RDA capability.  Please understand that what you
are rating is a SPECIFIC generic protocol service FOR a Protocol/
Standard Service Set (e.g., DOD Stack + All Standard Services).  YOU
ARE NOT RATING A PROTOCOL/STANDARD SERVICE SET FOR THE TOTAL SET OF
SERVICES.
 
(2) A response to the questionnaire within two weeks would be
appreciated.
*
* SURVEY RESPONDENTS WILL RECEIVE PRIORITY IN RECIEVING THE RESULTS OF
THE SURVEY!
 
*Thank you in advance for your participation.
*
 
************************************************************************
Name: _______________________
(Write over underline if you reply electronically.)
 
         RATINGS OF PROTOCOL SUITES BY YEAR FOR END USER WORKSTATIONS
 
Please place an "x" in column 1 for the (one) generic protocol service
that you are forecasting for each filled-in questionnaire.  An "x"
should be placed in column 1 for ONLY 1 OF THE BELOW GENERIC SERVICES
FOR EACH FILLED-IN QUESTIONNAIRE.
 
_ Remote Procedure Call
_ Remote Database Access
_ Transaction Processing
_ Security
_ Virtual Terminal
_ File Transfer
_ Directory Services
_ Network Management
_ Messaging/Electronic Mail
_ Technical Projects
_ Commercial Off the Shelf Software (not linked to Application)
_ Upper Layer Services
_ Lower Layer Services
_ Links to Commercial Off the Shelf Software (COTS)
_ Links to X Windows (or equivalent)
************************************************************************
Scale: 0 (lowest) to 10 (highest); Format F3.1 (e.g., 8.3)
 
      Workstation = IBM PC
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I1 OSI STACK + ALL STD. SERVICES (COM- |x.x|   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
I4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************
 
************************************************************************
      Workstation = Macintosh
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M1 OSI STACK + ALL STD. SERVICES (COM- |   |   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
M4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************
      Workstation = UNIX
 
     Protocol/Standard Service Set     |92 |93 |94 |95 |96 |97 |98 |99 |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U1 OSI STACK + ALL STD. SERVICES (COM- |   |   |   |   |   |   |   |   |
   MERCIALLY AVAILABLE IN TARGET YEAR) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U2 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
                                       |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U3 DOD STACK + ALL STD. SERVICES       |   |   |   |   |   |   |   |   |
   + PROPRIETARY DATABASE ACCESS (RDA) |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
U4 UPPER 3 LAYERS OF OSI STACK RUN OVER|   |   |   |   |   |   |   |   |
   TCP/IP STACK + ALL STD. SERVICES    |   |   |   |   |   |   |   |   |
---------------------------------------|-- |-- |-- |-- |-- |-- |-- |-- |
************************************************************************

ROBERT B. SHAIN               RSHAIN @MITRE.ORG
THE MITRE CORPORATION         VOICE: (703)883-5592
ECONOMIC ANALYSIS CENTER      FAX: (703)883-6991
MAILSTOP W633
7525 COLSHIRE DRIVE
MCLEAN, VA. 22102

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 20:40:40 GMT
From:      daemon@wilma.nmsu.edu
To:        comp.protocols.tcp-ip
Subject:   Question about IP to Physical Address mapping


Hi TCP gurus!!

This is a simple question in the Comar book chap 5 on ARP

question: Given a small set of physical addresses (+ve integers), can you 
find a function 'f' and an assignment of Internet addresses such that 'f'
maps the Internet addresses 1-to-1 onto the physical addresses, and computing 'f' is efficient?

CAn somebody throw some light on this?


P.s.: This is not a academic assignment. Just for my own knowledge.


Thanks!


Ravi

ravi@nmsu.edu

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 1992 21:32:34 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

 morse@quark.mpr.ca (Daryl Morse) writes:
>
> smith@sctc.com (Rick Smith) writes:
>
>   morse@quark.mpr.ca (Daryl Morse) writes:
>
>>   >While I won't claim that OSI is
>>   >perfect, I will claim that it's much better than Rose and other IAB
>>   >types would like us to believe. The standards bodies may be slow, but
>>   >they do work.
 
>>   Aah. the promise of some meat. Could you amplify on this point,
>>   please?  We all know there's a dispute and I've heard lots of bad
>>   things about OSI. Are there any good things to report?
>

As an avid TCP/IP supporter and implementor, I would like to see
some of the OSI developments coming into mainstream Internet.  The
religious protocol wars (as always) are based on what psychologists
often term as splitting, identifying all good with one and all bad
with another.  But its not because everyone is childish or psychotic,
admitting the good seems to imply agreement with other statements
which we don't necessarily agree with, some sort of guilt by association.

It is reasonable to want something like X.500, we really could
use a directory service, and yes, IP is hurting for address space,
so what's wrong with looking at OSI for some answers?

Well, the mere suggestion of liking one part of OSI seems to place 
you in the category of 'believers' who insist we must chuck TCP/IP 
for OSI.  It also seems to imply you agree with the decision making 
process, you don't mind the delays, you don't want to keep the practical 
experience that the TCP/IP Internet has given us, and you think
there is something terribly wrong with the TCP/IP Internet and all
it offers and stands for, whatever that means.

The Internet is currently synonomous with TCP/IP, but that will be
a dated statement.  I don't believe it will be replaced with pure
OSI, but we would be stupid to not adopt some OSI protocols or to
learn from what they've done.  We don't run the old NCP and we've
upgraded practically every old DARPA protocol, so obviously 
we're open to change, but change will have to resemble the way
the Internet does things.  The difference is more in protocol
than the protocol themselves.

As for IAB people being anti-OSI, our new IAB pope is a former OSI
man.  He, for one, seems to find little excuse for not merging the
two to reap the reward of a better, more complete networked world.  

Or I could be wrong about all of this,
Erick
 
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 1992 21:38:49 GMT
From:      goldstein@carafe.enet.dec.com (Fred Goldstein [k1io; FN42jk])
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


I was going to stay out of this flamefest, since it's basically a 
religious war.  Some folks like OSI, some TCP/IP.  However,

In article <MORSE.92Jun8092420@quark.mpr.ca>, morse@quark.mpr.ca (Daryl Morse) writes:

>B-ISDN: You will be hearing alot about this in the coming years. It
>will form the basis for many of the advances in commercial computing
>that will occur during the later half of this decade. B-ISDN is an OSI
>protocol stack.

That's such complete and utter hogwash that I couldn't let it go by 
unchallenged!

B-ISDN has nothing whatsoever to do with OSI.  Zilch.  In fact, its own 
Reference Model even avoids using OSI terms, since there is no agreement 
as to which OSI layers the B-ISDN layers and sublayers correspond to!

The B-ISDN layers are, bottom up, PHY (or PMD), ATM, AAL, and User-specific.
In my book (I mean that literally), the ATM layer is essentially the top 
of the OSI Physical layer.  PHY contains PMD, Bit timing, transmission
frame adaptation.  ATM contains cell confirmation/delineation, cell
header verification, cell rate decoupling, cell mux/demux, cell routing.
Atop that goes ATM Adaptation Layer (AAL) which for data is basically 
datalink.  (But one big phone/switch company in NJ thinks it's Transport.)

The protocols that go into B-ISDN are derived from many sources, such as 
N-ISDN (Q.93B based on Q.931) and SONET.  But OSI?  Only at the 
periphery of some optional PHY management systems.

Yes, I do know about these things.  Credentials upon request.
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.


-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 22:01:35 GMT
From:      hughes@logos.ucs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1450@npdiss1.StPaul.NCR.COM>, preece@npdiss1.StPaul.NCR.COM (Bently Preece) writes:
> Not exactly.  The most common complaints about OSI seem to be these:
>
> A)  Poor design for the network layer.
> B)  Poor lower layer performance (network/transport layers).
> C)  Overly-complex upper layers (session/presentation/application layers).
> D)  Overly-complex network management.

Perhaps, but another complaint I've commonly heard is that TCP/IP
is based on years of empirical experience, whilst OSI is based on
years of political compromise.  Can anyone disagree with that?
(Serious question).

 //==================================================================\\
||      Larry J. Hughes, Jr.       |        hughes@indiana.edu        || 
||       Indiana University        | "The person who knows everything ||
||  University Computing Services  |        has a lot to learn."      ||
 \\===================================================================//

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 22:05:44 GMT
From:      drw@nevanlinna.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1450@npdiss1.StPaul.NCR.COM> preece@npdiss1.StPaul.NCR.COM (Bently Preece) writes:
   As opposed to the Internet applications which are very simple.  On Unix
   anyway.  Internet has a file transfer protocol which doesn't understand
   file types or character sets.

   The Internet philosophy, essentially, is to implement it, and when the
   bugs are out, to write it up.  The advantage is that you know what you've
   got when you're finished.  The disadvantage is that you're perpetually
   stuck with the prototype.  On the other hand, the problem with ISO is
   that they're so good at building camels.

   The OSI protocols are more complex, but they tried to be complete.

There is always a point at which more features could be added, but
that the cost that the feature incurs is higher than the benefit to
be gained from the feature.  Committee-written standards usually go
far beyond the maximum-net-benefit point; implementor-written
standards usually fall short.

Unfortunately, committee-written standards often incorporate solutions
to problems that shouldn't exist.  Imagine the early days of the
automobile, and someone designing the "industry-standard fuel station"
-- can you imagine the incredible array of different fuels that all
those experimental autos used?  Can you imagine the cost if every fuel
station was required to stock all of them?  The present situation is
far better -- there are a very small number of fuels that an auto can
use, and while that may force some particular type of auto to be
sub-optimal, it dramatically reduces the cost of the fuel stations.

"EBCDIC -- Just say No!"

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Cyberspace, in its present condition, has a lot in common with the 19th 
Century West. It is vast, unmapped, culturally and legally ambiguous, 
verbally terse (unless you happen to be a court stenographer), hard to get 
around in, and up for grabs. Large institutions already claim to own the 
place, but most of the actual natives are solitary and independent, 
sometimes to the point of sociopathy. It is, of course, a perfect breeding 
ground for both outlaws and new ideas about liberty.
-- John Perry Barlow

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 92 23:36:56 GMT
From:      paulp@uts.amdahl.com (Paul Popelka)
To:        comp.protocols.tcp-ip
Subject:   Explaination of loose source routing?

Does anyone out there know how the IP option "loose source
and record route" is supposed to work.  I've read the appropriate
sections of rfc 791 and the 1st edition of Comer's book.
And, I'm still mystified.  The rfc states "the smallest
legal value for the pointer is 4".  Why is this?
Are the first 4 bytes after the option, length, and pointer
supposed to contain the address of the orignating host?

The name of a better reference would be good.
A non-trivial example of how loose source routing is used would be great.
Maybe showing the IP header of a packet emitted by the originating
host, and then showing the IP header as it progresses through
a couple of gateways, and then show what the destination host
receives.

Out of curiousity whose implementations of IP support loose
source routing?  Whose do it corrently?  I have to be able to
test this once I fix it.

Thanks,
Paul
paulp@sde.uts.amdahl.com

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jun 1992 23:40:53 GMT
From:      john@citr.uq.oz.au (John Gottschalk)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

morse@quark.mpr.ca (Daryl Morse) writes:


>This is not exhaustive:
 
>BER: This has been discussed much lately. There are many people who
 
>CMISE: Irrespective of those who continue to advocate SNMP (i.e.
 
>IS-IS: This is the OSI routing protocol. It has been extended to
 
>X.400, X.500: SMTP isn't in the same league as S.400. Nore is there an
 
>B-ISDN: You will be hearing alot about this in the coming years. It

People often mention old OSI application layer standards, but what about
new ones such as Remote Database Access (RDA), Transaction Processing and CCR?
Are there any equivalents in the Internet world? 


===================================================================== 
     John Gottschalk (john@citr.uq.oz) 
     Centre for Information Technology Research,
     The University of Queensland, 4072, 
     Brisbane, Queensland, Australia,
     +61 7 365 4321 (phone), +61 7 365 4399 (fax)
===================================================================== 

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 00:16:15 GMT
From:      brunner@adobe.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Silence Please (was Re: OSI vs TCP/IP information & opinions requested)

Would the non-implementors please refrain from posting zealotry? Some of us
are working! This list sould be un-gatewayed from net news, it collects
opinions like a sweater collects cat hairs.

-- 
#include <std/disclaimer.h>
Eric Brunner, consulting at and not speaking for Adobe
uucp: uunet!practic!brunner or uunet!adobe!brunner
trying to understand multiprocessing is like having bees live inside your head.

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 02:20:25 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

preece@npdiss1.StPaul.NCR.COM (Bently Preece) writes:

>OSI allows three configurations for the network layer:  the connectionless
>protocol CLNP, the connection-oriented protocol X.25, and a combination
>which allows X.25 as a subnetwork to CLNP.  None of these is compatible 
>with any of the others.  In contrast, Internet's single connectionless
>protocol IP is supposed to be much cleaner.
 
>The problem is that the world is already full of X.25 networks.  The PTTs
>and other service providers won't throw away their existing networks
>and start over, so how do you fit them into the new scheme?  I don't know
>Internet's solution.  (Can anyone tell us?)

In the Internet scheme of things, X.25 is a network protocol, sitting
below the Internet Layer, in the same place as e.g. Ethernet. Addressing
is a bit of a pain - you either control the address space and make it
correspond to IP numbers (ala the DDN) or you need ad-hoc tables. 

>B)  Poor lower layer performance (network/transport layers).
>The usual claim is that TCP/IP is faster/more reliable/more efficient/more
>whatever than TP4/CLNP.  The only hard data I've seen on this seems to
>show that the implementation has more effect on the performance than the
>differences in the protocol,

I would agree whole-heartedly, with one exception - the Fletcher
checksum. 

> and that other things being equal TP4/CLNP
>is as fast/reliable/efficient as TCP/IP.

The only hard numbers I've seen in published research show that there is
still a ways to go. (Ittner, Journal of Data and Computer
Communications, Fall 91 - ~2Mbit/sec) Still, that's only a few years
behind TCP/IP. 

>C)  Overly-complex upper layers (session/presentation/application layers).
>As opposed to the Internet applications which are very simple.  On Unix
>anyway.  Internet has a file transfer protocol which doesn't understand
>file types or character sets.

It also has a few de-facto network file system standards, which OSI is
still lacking. (In theory FTAM can be used as an NFS replacement. The
mind boggles at the thought.)

 ----

Perhaps a reasonable description would be that the Internet community
has concentrated on solving its own problems, while ISO has concentrated
on solving everyone else's problems. (for instance, although FTP doesn't
handle MVS files very well, it does a tolerable job on 36-bit Tenex
files) It's also worth noting that the Internet suite has achieved
popularity by acquisition rather than conversion, for the most part. If
you solve your own problems well enough, people may just throw out their
old problems and buy your solutions.

				Peter Desnoyers
-- 

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 02:55:03 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Silence Please (was Re: OSI vs TCP/IP information & opinions requested)

In article <1992Jun9.001615.13512@adobe.com> brunner@adobe.com (Eric Brunner) writes:
>Would the non-implementors please refrain from posting zealotry? Some of us
>are working! This list sould be un-gatewayed from net news...

Bear in mind that doing this will cut you off from (probably) a majority
of the implementors.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 10:11:32
From:      morse@quark.mpr.ca (Daryl Morse)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


In article <1992Jun9.153657.21944@nntpd.lkg.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:

   In article <MORSE.92Jun8155809@quark.mpr.ca>, morse@quark.mpr.ca (Daryl Morse) writes...
   >You might be partially correct. In any case, I didn't make my point
   >properly, if at all.  As I have seen it, B-ISDN implies the bottom
   >three OSI layers. It doesn't imply upper layers.  SDH is physical.
   >ATM is datalink. Some other LAP-* goes at the network layer.
 
>   Ah, but that's not true!

[stuff deleted...goes on to explain why...]

Thanks for your comments. Clearly things aren't as obvious as I
originally stated. From this response and another that was directly
emailed to me, I believe it is save to conclude that the relationship
between OSI lower layers and B-ISDN is in considerable flux. According
to one reference (A. Day, August 1991 IEEE LTS), alignment of B-ISDN
with OSI Reference Model requires further analysis by the CCITT. That
seems pretty clear.  I think I was misled into thinking they were
aligned by a reference that I don't currently have in front of me.
When I get the time, I plan to dig it up and reread it. Sorry for any
confusion.

Since I'm talking about responses to my post, I will talk about a
couple of others...

First, it was pointed by a couple of people that MIME provides much of
the functionality of X.400 at a significantly simpler implementation
effort. Sounds good to me, but does it work with X.500, which almost
everyone seems to agree is not available in the Internet family of
protocols? 

Second, it was pointed out (both directly and via another post) that
there are now some "OSI-apologists" in the IAB. I was not aware of
that. I think it's a good thing.

Third, I point out to myself that my post had an unnecessarily rude
tone to it and contained a remark about Marshall Rose that shouldn't
have been there. I apologise to anyone that may have been offended, in
particular, to Marshall Rose. My intent was more to point out that
Rose is as capable of speaking his mind as he is capable (IMHO, that
isn't a negative thing because he is very capable.), but unfortunately
I didn't write it that way.

Finally, the bidirectional flames clearly indicate that the OSI vs IP
argument is deeply buried in religion. I hope we end up with a
combination of the good things from both. Maybe the groups working on
futures such as B-ISDN and gigabit networks will force a reality check
on *both* sides.

If you intend to comment on this post, please email me directly as I
will be away for a couple of weeks.

Thanks.
--
Daryl Morse                     | Voice : (604) 293-5476
MPR Teltech Ltd. 		| Fax   : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail: morse@mprgate.mpr.ca
Canada, V5A 4B5                 | Part of the B.C. Tel Group of Companies...

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 07:52:06 GMT
From:      marcusj@apricot.co.uk (Marcus Jenkins)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Packet Driver for Apricot Qi -- anybody know of one?

robert@swanee.ee.uwa.oz.au (Roberto Togneri) writes:

>I am currently using the SOSS program to allow our unix hosts to mount a 
>PC hard disk and thereby permit backing up the PC to a tape. I can do this
>for all our PC's bar one:  our Apricot Qi. This PC has its own internal
>ethernet interface and I need a Packet Driver to run SOSS. I looked at the
>drivers.zip from Clarkson and not surprising there is no such thing.
 
>Does anybody know or have a packet driver for an Apricot Qi? 

Yes.  It comes on the 'Network Drivers' diskette which is shipped with
every On-Board Ethernet machine.  If you have a slightly older model 
Apricot, you will probably need to get the latest version of the floppy, 
since we only wrote the Packet Driver about two years ago.  Ring:

	+44 21 717 7171

 _ _ _
' ) ) )                         Internet: marcusj@apricot.co.uk
 / / / __.  __  _. . . _        UUCP: marcusj@apricot.uucp
/ ' (_(_/|_/ (_(__(_/_/_)_      If all else fails from US, try:  
Marcus Jenkins                  apricot!marcusj@relay.EU.net
Tel: +44 21 472 3002  Fax: +44 21 471 2935
Disclaimer:  Anything I wrote above is, of course, my own view and
             does not in any way represent my employer.

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jun 1992 15:10:02
From:      fks@vax.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Packet Driver for Apricot Qi -- anybody know of one?

In article <robert.707717031@swanee> robert@swanee.ee.uwa.oz.au (Roberto Togneri) writes:

    Does anybody know or have a packet driver for an Apricot Qi? 
    
Apricot wrote one - try asking them for it.

--

Frances Kirk Selkirk		 fks@ftp.com	           (617) 246-0900


-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jun 1992 15:10:55
From:      fks@vax.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: "r" commands and security

In article <10mrtiINNbsm@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

> Trusted hosts are generally expected to support the restriction that only
> trusted programs can open TCP connections with a source port below 1024.
> The r-commands don't send passwords; the client just sends a user name, and
> the server believes it if the source port is in this range.  Putting a PC

Some implementations of "r" commands (our clients, for example) will force 
a password authentication if there is no .rhosts file on the server. 

--

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


-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 11:12:08 GMT
From:      ag129@cl.cam.ac.uk (Alasdair Grant)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun8.220135.22075@bronze.ucs.indiana.edu> hughes@logos.ucs.indiana.edu (larry hughes) writes:
>Perhaps, but another complaint I've commonly heard is that TCP/IP
>is based on years of empirical experience, whilst OSI is based on
>years of political compromise.  Can anyone disagree with that?
>(Serious question).

a) nearly all the "empirical experience" was in the USA
b) they obviously didn't have much experience with concepts like forms-mode
   terminals, odd character sets, and odd filing systems
c) some, if not most, of the later RFCs are just speculative, while I have
   heard at least one described as pure vaporware to attract research funding.

Also there is _some_ experience behind OSI, notably X.25 and experimental
protocols such as the UK's Coloured Books. The difference is that having
got this experience, OSI are not just codifying existing practice.

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 12:39:33 GMT
From:      bob@snuffy.dracut.ma.us (Bob Smith)
To:        comp.protocols.tcp-ip
Subject:   routing daemon size grows when cslip connection dropped

The situation is this:

SunOS 3.5 on Sun2 and Sun3 machines configured with cslip.  The
routing daemons on these machines show a nominal size as reported
by 'ps -axv' of 36k, (the actual size is probably not important here).
As long as a slip connection is never made on the machines, the size
of the routing daemon is static, as soon as a slip connection is made
and then dropped, the size will start growing without bound!  I've
seen it grow to over 4Meg(!) in a 24 hour period...

I've hacked around in the slip code with it's memory allocation stuff
to see if I could effect any changes in the symptom...  The only thing
I was truly successful at was creating a couple of pretty nasty mclput
panics! :-)

My question is this... When this version of slip comes down, it removes
its routing table entry.  I've been led to believe that routed normally
ignores point-to-point routes, I've found that to be not necessarily
true...  Would I be better off letting routed remove the route entry?
(if it will...)

Thanks for any input or words of wisdom anyone might want to impart...

-- 
 \ Bob Smith               \ mx: bob@snuffy.dracut.ma.us
  \ 1215 Pawtucket Blvd. #4 \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Lowell, MA. 01854       \ office && voice mail: +1 508 670-6712

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 13:22:13 GMT
From:      ojr@itk.unit.no (Ornulf Rodseth)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for iRMX: Summary


I posted a request for information on iRMX implementations of the
TCP/IP protocol.  I appreciate the interest from all you netters and I
am particularly grateful to those that had some information. I hope
this summary is of interest to others.

Here are the answers I received.

*************************************
From: joel@wisdom.weizmann.ac.il (Isaacson Joel)
Subject: Tcp/Ip for Rmx

  I have implemented Tcp/Ip for Rmx based on the BSD tcp/ip code. It works
under Rmx II and Rmx III. It uses Intel's raw EDL interfacce so it works with
any Intel network interface.
						Joel Isaacson
						joel@wisdom.weizmann.ac.il
*************************************
From: Ian Heavens <ian@spider.co.uk>
Organization: Spider Systems Limited, Edinburgh, UK.

We have a STREAMS-based TCP/IP implementation and our own implementation
of Streams - the latter has been ported to various realtime o/ses (Vrtx,
pSOS, QNX) - iRMX, I don't think so, but it shouldn't be too difficult.

I can send you details if you're interested.

ian
---

Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)


The details:
*************************************

Ornulf,

Here are some details of our TCP/IP and Streams products.  I have passed
your request for pricing information to Dave Gibb, who is responsible
for European sales.  

We have a Streams-based TCP/IP stack and also an implementation of Streams
which together have been ported to many architectures (80x86, 680x0, 3B2,
MIPS R4000, Clipper, Transputer) and operating systems (V.2, V.3, V.4, 
Vrtx, QNX, DYNIX, VME-B, etc.). 

Please contact Dave Gibb (davidg@spider.co.uk) for marketing and pricing
information.  I can answer any detailed technical questions you may have.

I append the functionality of the current product (SpiderTCP Release 6),
as both nroff source and ASCII output.

yours

Ian Heavens

---
Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)
--

Nomenclature:
.BL
.LI
SpiderStreams is Spider's implementation of Streams
.LI
SpiderStreams/MP is Spider's implementation of Streams in a symmetric
multiprocessor environment
.LI
SpiderX25 is Spider's Streams-based X.25 stack.
.LE

SpiderTCP Release 6 Functionality:

.BL
.LI
kernel stack: \fBTCP, UDP, IP\fP (including subnetting, IP routing, and
multihoming), \fBARP\fP (including trailer), \fBSNAP/LLC1\fP
.LI
Full set of BSD applications (BSD4.2/4.3 based)

\fBtelnet, ftp, tftp, rlogin, rsh, rcp, rwho, ruptime, named, sendmail, routed, finger, talk, inetd, netstat\fP
.LI
Network Management:SNMP & Internet MIB I 
.LI
BOOTP, Reverse ARP
.LI
Ethernet support (including example driver)
.LI
SNAP/LLC1/IEEE802.\fIN\fP support
.LI
Token Ring support (excluding driver)
.LI
SLIP
.LI
AT&T \fIDLPI\fP support
.LI
BSD \fIsockets\fP 
.LI
AT&T \fITLI\fP support 
.LI
Symmetric multiprocessor support for all kernel drivers
.LI
UNIX V.3 support for applications and system administration
.LI
UNIX V.4 support for applications and system administration
.LI
kernel driver support for
.BL
.LI
UNIX V.3 Streams
.LI
SpiderStreams
.LI
UNIX V.4 Streams
.LI
SpiderStreams/MP
.LI
SVR4/MP Streams
.LE
.LI
in-kernel \fItelnet\fP and \fIrlogin\fP
.LI
IP over X.25 (with SpiderX25).
.LI
NetBIOS over TCP and UDP 
.LI
Enhanced \fIping\fP with IP option support
.LI
Utility to spool to remote printer.
.LI
ANSI C conformance
.LI
90% RFC1122 compliance.  
.LI
Trouble report system
.LI
Automated, documented test suites (on UNIX V.3/4) for all features
.LI
Full implementation documentation for all kernel drivers (online and hardcopy)
.LE

**** I removed the nroff output, send me a message if you need it
**** - ojr
*************************************
From: Leo Smith <shaman@cix.compulink.co.uk>

This is not hard information, but I think Process software did one:
Also maybe Network Research (Fusion). These two certainly did RSX/11
on PDP and maybe I am getting confused.

But I am sure there is one implementation somewhere.
*************************************
From: bhl@myrias.ab.ca (Brian Lake)

You can contact Network Research. 2380 N Rose Avenue. Oxnard
California. 93030
(805) 485-2700. FAX (805) 485-8204.

They provide TCP/IP for a large number of platforms including iRMX. 
I don't know anything about their iRMX platform, but have used their
TCP/IP stuff on a PC under DOS. Their PC product also included NFS
client support, ftp, telnet, etc.

Brian
--
Brian Lake
Myrias Computer Technologies Inc.
8522 Davies Road, Edmonton, Alberta, Canada.  T6E 4Y5
Tel 403-463-1337 Fax 403-465-0130 Email bhl@myrias.ab.ca
-- 
*************************************
A comment:
*************************************
From: tal@netcom.com (Tal Dayan)

> You can contact Network Research. 2380 N Rose Avenue. Oxnard

As far as I know, they support TCP/IP on IRMX only with 'smart' controlers,
which have CPU and implement the transport layer. Try to get information
from Odile Lapidus  odile@nrc.com . She is very knowledgeable about their
products.

No, I don't have any interest in NRC.

Tal Dayan

tal@netcom.com

-- 

 =======================================================================
 Tal Dayan (TM)             tal@netcom.com              tal@cse.ucsc.edu 
 =======================================================================
*************************************
From: joel@wisdom.weizmann.ac.il (Isaacson Joel)
Subject: Tcp/Ip for Rmx

  I have implemented Tcp/Ip for Rmx based on the BSD tcp/ip code. It works
under Rmx II and Rmx III. It uses Intel's raw EDL interfacce so it works with
any Intel network interface.
						Joel Isaacson
						joel@wisdom.weizmann.ac.il

--
Ornulf Jan Rodseth M.Sc.	ojr@itk.unit.no
SINTEF Automatic Control	+(47 7) 594351 (direct) / 594375 (switchboard)
N-7034 TRONDHEIM, NORWAY	+(47 7) 594399 (fax)

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 15:34:47 GMT
From:      stephan@cs.kuleuven.ac.be (Stephan Biesbroeck)
To:        comp.protocols.tcp-ip
Subject:   multiplexing & data compression on IP-lines

Hello,

We are thinking of multiplexing a 64 Kbps IP-line (into 2 seperate lines).
One company offered us multiplexers that do also compression.
They claim that they can multiplex 3 64Kbps lines into 1 64 Kbps line.
Does this make sense on IP-lines. Is this possible to reach such
a compression with IP-packets ???

Any help will be appreciated ?

Regards,

Stephan Biesbroeck
stephan@Belgium.EU.net
stephan@cs.kuleuven.ac.be
stephan@ub4b.buug.be

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 16:29:54 GMT
From:      goldstein@carafe.enet.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested


In article <MORSE.92Jun8155809@quark.mpr.ca>, morse@quark.mpr.ca (Daryl Morse) writes...
>You might be partially correct. In any case, I didn't make my point
>properly, if at all.  As I have seen it, B-ISDN implies the bottom
>three OSI layers. It doesn't imply upper layers.  SDH is physical.
>ATM is datalink. Some other LAP-* goes at the network layer.

Ah, but that's not true!

ATM is physical.  SDH is one PMD option at the lower half of the 
Physical layer.  LAP-* refers to datalink protocols, not network
protocols, and there are no LAPs in B-ISDN anyway; the sensible
CO-datalink layer is "SSCOP" (service specific connection-oriented
protocol).  (The signaling datalink protocol is not decided yet.)

One problem is that some folks don't like to call ATM "physical", since 
it has both framing and routing.  But the framing is fixed-length cells,
for the network's convenience, which to me is NOT a datalink function.
It is more like the phone network + MNP2, all within the "modem".  A 
phone network routes calls, but you normally run a datalink atop it.
One other issue (problem with OSI modeling in B-ISDN) is that ATM 
delivers 385-bit SDUs, while most physical layers deliver bits or 
octets.

Still, it is possible to have a "pure ATM" scenario in which the ATM
layer provides a routing service and you run a combined datalink/
transport protocol above it, skipping Network, since you've redefined
the architecture to allow direct ES-ES connection via physical.  This
is a very, very non-OSI scenario!  Trying to fit it into the OSI model
is pretty hopeless.
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com   voice:+1 508 952 3274
Standard Disclaimer:  Opinions are mine alone; sharing requires permission.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 16:52:52 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1450@npdiss1.StPaul.NCR.COM> preece@npdiss1.StPaul.NCR.COM (Bently Preece) writes:
>    .
>    .
>The OSI protocols are more complex, but they tried to be complete.
>

I often think that this may be as much a problem as it is a solution.

The world keeps changing.  The available technologies (both from
engineering and cost perspectives) keep changing.  The problem spaces
keep evolving, based on what becomes standard procedure using current
technologies.  The customer base becomes more sophisticated and new
applications or different approaches to problems develop.  Even the
changing international political/economical situation has an impact.

If we try to delude ourselves into thinking that we can design a
single set of solutions that will optimally serve everyone for some
arbitrary period into the future, I think we'll lose.

Standards are a neccessary compromise for the effective use of
technology as it is developed, but standards can not be an endpoint.

If the development of standards does not happen quicker than the
evolution of the technology it is based on, then either they will never
reach closure, or they will not cover capabilities available in new
technologies.  I think examples of both cases surround us.

I often wonder what lays beyond both TCP/IP and ISO (but my crystal
ball is murky at its best).

Just some idle musings.

Art

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 17:23:24 GMT
From:      dzubin@doc.siast.sk.ca (Thomas Dzubin)
To:        comp.protocols.tcp-ip
Subject:   Re: Getting "on the internet"

 >curmw@dcatla.uucp writes:
 >: 
 >: We are investigating getting "on the internet" here; we currently get
 >: a news/email feed via Georgia Tech's internet feed, but get no other
 >: internet services.
 >: 

In article <1992Jun7.014017.15156@serveme.chi.il.us> joeg@gagme (joe grosch) writes:
 >
 >	Of course, all of the above is based on the premis that you have at
 >least one UNIX system in house, and can dedicate a large part of it's 
 >resources to an Internet feed. One should note that the current feed for 
 >news is running about 25 Meg a day and depending on the size of your
 >organization, how many additional offices you have and how many people are
 >going to use the Internet your volume could be half again that volume. What
 >I am getting at is in order to properly support this feed one needs at least
 >one fast modem, several large disks, and a reasonablely fast UNIX box.
 >

Actually,
You don't need a UNIX system to be on the Internet...all that is really
needed is a host which "speaks" TCP/IP and a neighboring site which you
can connect to.  ...and probably (hopefully) a router in between.

My microcomputer on my desk is "on the Internet" right now and it's just
a lowly MS-DOS machine with an Ethernet card and packet driver software.

Also note that Usenet NEWS is not the same as "the Internet".
A couple of my VAXen are "on the Internet", but don't get news.  What you
say is undoubtably true for Usenet news, but not necessarily for Internet.

 >	Good luck and welcome to a larger world.
 >
 >--
 >Josef Grosch         | UNIX/C Consultant. Specalizing in X/Motif, 
 >joeg@gagme.chi.il.us | network programming, Internet, TCP/IP, and 
 >Chicago, IL.         | UNIX System Admin. (708) 397-4804 

-----------------------------------------------------------------------------
Thomas Dzubin, Networks person and random TCP/IP fall guy.
Saskatchewan Institute of Applied Science & Technology (SIAST), CANADA
dzubin@siast.sk.ca    (or if you really must: 1-(306)-933-5006)

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 17:25:39 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Explaination of loose source routing?

In article <15Vc03Ns0e8k00@amdahl.uts.amdahl.com> paulp@uts.amdahl.com (Paul Popelka) writes:
>Does anyone out there know how the IP option "loose source
>and record route" is supposed to work.  I've read the appropriate
>sections of rfc 791 and the 1st edition of Comer's book.
>And, I'm still mystified.

The LSRR option is used to specify one or more systems that the packet
must pass through on its way to the final destination.  What path it
takes between these systems is not a concern (Loose Route), unlike
SSRR (Strict Route) where EVERY hop is prespecified.

>The rfc states "the smallest
>legal value for the pointer is 4".  Why is this?
>Are the first 4 bytes after the option, length, and pointer
>supposed to contain the address of the orignating host?

IP option offsets are specified relative to the beginning of the entire
option.  The first byte is considered to be at offset 1 (this can
be confusing).  Since the first IP route/record field follows three
bytes of option info (type, length and offset fields) it is at offset
4.  As each IP address is consumed and replaced by the recorded route,
the offset is increased by 4 until it points past the last address
field.

>The name of a better reference would be good.
>A non-trivial example of how loose source routing is used would be great.
>Maybe showing the IP header of a packet emitted by the originating
>host, and then showing the IP header as it progresses through
>a couple of gateways, and then show what the destination host
>receives.
>
>Out of curiousity whose implementations of IP support loose
>source routing?  Whose do it corrently?  I have to be able to
>test this once I fix it.

I would expect most commercial routers to support this properly.
TCP/IP implementations derived from BSD Unix (like SUNOS) often
have problems with IP options.  (I've crashed Suns when testing
IP options).
>
>Thanks,
>Paul
>paulp@sde.uts.amdahl.com

Art

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 17:33:09 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: multiplexing & data compression on IP-lines

In article <1992Jun9.153447.6005@cs.kuleuven.ac.be> stephan@cs.kuleuven.ac.be (Stephan Biesbroeck) writes:
>Hello,
>
>We are thinking of multiplexing a 64 Kbps IP-line (into 2 seperate lines).
>One company offered us multiplexers that do also compression.
>They claim that they can multiplex 3 64Kbps lines into 1 64 Kbps line.
>Does this make sense on IP-lines. Is this possible to reach such
>a compression with IP-packets ???

It depends on what those IP packets are carrying.  3:1 compression of
normal ASCII text is fairly common.  If the IP packets are mostly
large and contain readily compressable data, then it is certainly
doable.  If the IP packets are small or contain uncompressable data
(like already compressed files), then things will be different.

Can you live with varying amounts of avaiable bandwidth from your
link?

>Any help will be appreciated ?
>
>Regards,
>
>Stephan Biesbroeck
>stephan@Belgium.EU.net
>stephan@cs.kuleuven.ac.be
>stephan@ub4b.buug.be

Art

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 92 19:07:35 GMT
From:      jjf@peewee.enet.dec.com (35G-FRANEY)
To:        comp.protocols.tcp-ip
Subject:   VMTP RFC????? or RFC TOC


I want to find the latest RFC of the Versatile Message Transport Protocol.
The one I have is RFC 1045, but I hope there is a later version.

Does any one know the RFC number for the latest VMTP spec?

Unless I am mistaken, there are RFCs that list other RFCs; an RFC table
of contents, so to speak.  Does any one know the RFC number of the latest
RFC that plays this role?  (I'll look for VMTP myself then).

Thanks,
John Franey

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 20:17:42 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

morse@quark.mpr.ca (Daryl Morse) writes about X.400 and X.500:

>First, it was pointed by a couple of people that MIME provides much of
>the functionality of X.400 at a significantly simpler implementation
>effort. Sounds good to me, but does it work with X.500, which almost
>everyone seems to agree is not available in the Internet family of
>protocols? 

I think ISODE and the X.500 White Pages Pilot provide strong evidence
that X.500 is available to Internet based hosts.

This seems to imply that the ISO protocols above the transport level
fit just as nicely atop the Internet transport facilities as they do
over theologically pure ISO transport stacks.  Thus it's only a matter
of time before many of them get incorporated into the Internet suite,
like X.25. Many have observed that the Internet could benefit from
a directory standard, something better than the Name Server.

Rick.
smith@sctc.com       arden hills, minnesota

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 20:51:31 GMT
From:      oldera@twg.com (Ed Alcoff -  Prod Mtg)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

Correction, please.  Marshall Rose did not "invent" the
"powerful GET_NEXT operator" of SNMP.  Marshall's
involvement, besides the Chair of IETF Workgroup, was in
co-authoring the original MIB and SMI (orig. RFCs 1065, 1066)
with Keith McCloughrie while both were employed here at Wollongong.

If I recall what Jeff Case, co-author of SNMP, told me,
he went away for a weekend and when he came back, his
grad student, Ken Key(?) had written the GET_NEXT which Jeff
affectionately refers to as "the powerful ...".

Cheers,

Ed Alcoff


-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 21:20:52 GMT
From:      krd@adpgate.UUCP (Keith Dickey)
To:        comp.protocols.tcp-ip
Subject:   Telnet 3270 client support.

Does anyone know where I can find a telnet client that emulates
an IBM 3270.  I need to run the telnet client on a Motorola Delta
Series M88K box running Motorola's SVR3.2.

Please reply by email.

Thanks.


Keith R. Dickey           | mcspdx!adpgate!adpplz!krd
Software Staff Specialist |
ADP, Inc.                 |
2525 S.W. 1st Avenue      |
Portland, OR 97201        |

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 21:29:56 GMT
From:      fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

Duplicating some addresses can have spectacular effects.
We had a user who configured his PC with the address of the cisco router
used to connect us to the Internet.  Before long all the local Internet
traffic was directed at his PC (which acted as a black hole).

We are now much more sensitive to that possibility, and we are building
a list of IP addresses with corresponding ethernet addresses (using
etherhostprobe) so that we can locate the offender quickly.

-- 
Bob Fillmore, Central Computing & Communications   email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953    

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 21:42:51 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Identifying Service Users (was: OSI vs TCP/IP)

art@acc.com (Art Berggreen) writes:

>I often wonder what lays beyond both TCP/IP and ISO (but my crystal
>ball is murky at its best).

I'm beginning to suspect that both protocol stacks and their
corresponding reference models will end up in the trash can in the
next couple of decades simply because they don't propagate information
about who's using them. User identity and authentication is all
grafted on at the application level. I think this is a fatal flaw.
I wrote off ISO/OSI when I realized they propagate this flaw.

For example, when a host gets an incoming Telnet connection request,
it has no clue as to who has generated the request. Thus, the network
listening process (inetd for example) must fork off a process to
handle it. This process must run with superuser privileges since it
needs to handle user authentication and then set its user ID to that
of the authenticated user.

The same thing happens with FTP. The server starts a _different_
privileged process that must authenticate the user and then transition
into the user's file permission context. 

The same thing happens in the X.500 directory, if you're supporting
authentication at all. You provide some kind of authentication widget
and the X.500 server authenticates you. Since these protocols are all
different, the code for collecting, validating, and acting on
authentication data is different for each application.

I think authentication belongs much lower in the stack. When a
connection request comes in, the authentication data really should be
part of the request. Then the recieving host can use a single
authentication procedure regardless of the type of service being
requested. Otherwise you have one implementation per application, each
increasing the risk that it was done wrong somewhere.

RPC is the only protocol I know of that comes close to doing this
right. It even supports multiple authentication styles. Maybe some
vendor proprietary protocols do, too.

Rick.
smith@sctc.com        arden hills, minnesota

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 92 22:10:25 GMT
From:      heilbron@Informatik.TU-Muenchen.DE (Stephen Heilbronner)
To:        comp.protocols.tcp-ip
Subject:   Doc for rlogin/rexec protocol

I was wondering whether somebody could point out to me a ftp server
that holds the docs for the rlogin/rexec protocol.

Thx very much,
Stephen

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Tue, 9 Jun 1992 23:52:38 GMT
From:      john@citr.uq.oz.au (John Gottschalk)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

art@acc.com (Art Berggreen) writes:

>I often wonder what lays beyond both TCP/IP and ISO (but my crystal
>ball is murky at its best).

I may be wrong, but I thought that most networks in the world do NOT use
OSI OR TCP/IP. Surely others are more common, such as SNA, Novell, etc.
Will OSI or TCP/IP ever dominate over these? I once had a talk with 
an IBM employee about OSI and SNA, and they quickly stated "what is OSI?".
Of course, IBM does do work with OSI protocols, but to me this seemed to be
an example of how other protocols are much more important than OSI or TCP/IP
outside of the telecommunications and research world that I work in.


			-- John Gottschalk

===================================================================== 
     John Gottschalk (john@citr.uq.oz) 
     Centre for Information Technology Research,
     The University of Queensland, 4072, 
     Brisbane, Queensland, Australia,
     +61 7 365 4321 (phone), +61 7 365 4399 (fax)
===================================================================== 

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 00:40:43 GMT
From:      SCHMCH2@AWIIMC12.IMC.UniVie.AC.AT (Christoph Schmutterer)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   KA9Q on NDIS and 3Com 3C527 ?

 
We have a 3Com 3c527 adapter in a PS/2 Model 90 but it seems
there is no PD packet driver available for this adapter
(or does anyone know ?).
 
Somewhere I read about using KA9Q on top of NDIS (which is
supplied with the card). Has anyone some experience on that and
can give me some hints on configuring KA9Q and NDIS?
 
Thanks,
------------------------------------------------------------------------
CHRISTOPH SCHMUTTERER          E-MAIL: SCHMCH2@AWIIMC12.IMC.UNIVIE.AC.AT
DEPARTMENT OF BIOMEDICAL       PHONE : +(1)-40400 3985
ENGINEERING AND PHYSICS        FAX   : +(1)-40400 3988
UNIVERSITY OF VIENNA
AUSTRIA, EUROPE

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 03:40:03 GMT
From:      janssen@parc.xerox.com (Bill Janssen)
To:        comp.protocols.tcp-ip
Subject:   RPC newsgroup?

Is there a newsgroup or mailing list specializing in RPC
protocols and implementations, such as Xerox's XNS Courier, or
Sun's TIRPC, or the Object Management Group's work?

Bill

--
 Bill Janssen      janssen@parc.xerox.com      (415) 812-4763
 Xerox Palo Alto Research Center      FAX: (415) 812-4777
 3333 Coyote Hill Road, Palo Alto, California   94304

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 92 10:17:48 MDT
From:      gritton@alaska.caedm.byu.edu (Jamie Gritton)
To:        comp.protocols.tcp-ip
Subject:   Re: reserved ports?

hofer@rchland.vnet.ibm.com (Kent Hofer) writes:

> Is the concept of 1-1024 port numbers being reserved for TCP/UDP a
> unix convention or is it actually spelled out somewhere in the RFCs?
> Are there any RFCs that talk about reserved ports?

   It's just UNIX. The concept of having a superuser to reserve these
ports for is OS-dependent. I don't recall this showing up in any RFCs.
--
James Gritton - gritton@byu.edu - I disclaim

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 10:51:26
From:      Steinar.Haug@delab.sintef.no (Steinar Haug)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc,comp.dcom.lans.ethernet
Subject:   Re: Question about transfer rates on Ethernet

rick@rgbsys (Rick Davis) writes:
> We did a similar system where a X-windows interface ran on a 
> workstation and controlled objects on a video processor.  The link
> between the two was ethernet, running IP.  IP was based on UDP, and
> we used tftp to boot.  The protocol suite on the video processor end
> was implemented with a PSOS operating system and our own Lance 
> ethernet drivers. 

Um, UDP sits on top of IP, not the other way around...

> Just as a rule of thumb, anticipate 50% software overhead.  If you have
> a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
> be around 600kbit/sec, or about 75kbyte/sec.  If there is anything else
> sharing the ethernet, this rate wil fluctuate down by quite a bit.  The
> downward fluctionations depend on how you have the back-off set up in
> the TCP protocol.  FOr a great introduction to all of this, check out
> Doug Comer's book "Internetworking with TCP/IP" and get hold of the
> RFCs relevant to what you want to do.

I would definitely not call this a well-balanced system.

With reasonably good/modern implementations of TCP/IP, you can easily
get a full 1 MByte/s (yes, one Mega*byte*, 1048576 bytes) between two
stations.  I have repeatedly done this between two Sparcstation IPCs,
for instance.  Note that this is 1 MByte/s of *user data*. If you take
protocol overhead into account, this is (obviously) *higher* than
1MByte/s, and you can get very close to the 10 Mbit/s that Ethernet
can give you.

With more than two stations sharing the Ethernet, you will get some
collisions, and your total throughput may drop somewhat. But it is
still possible to drive the Ethernet close to max capacity.

I have seen this myth about low utilization/throughput on Ethernet
spread again and again - and also seen it refuted again and again. My
only possible conclusion is that there are *lots* of lousy TCP/IP
implementations out there. And lousy Ethernet hardware - Van Jacobsen
showed quite clearly that the Ethernet hardware is important.

For some empirical evidence of Ethernet's ability to move data, see:

	Measured Capacity of an Ethernet: Myths and  Reality
	David R. Boggs, Jeffrey C. Mogul,  Christopher  A. Kent.
	Proceedings of the SIGCOMM '88 Symposium  on  Com-
	munications   Architectures   and  Protocols,  ACM
	SIGCOMM, Stanford, CA., August 1988, 31 pps.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 06:37:37 GMT
From:      ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

In article <MARK.MCINTOSH.92Jun5160923@sombrio.UVic.CA>, Mark.McIntosh@engr.UVic.CA (Mark  McIntosh) writes:
> 			       Unidata netCDF
> 				October 1990
> "Network-transparent" means that a file is represented in a form
> that can be accessed by computers with different ways of storing
> integers, characters, and floating-point numbers.  Using the netCDF
                         ^^^^^^^^^^^^^^^^^^^^^^
> The netCDF software provides common C and FORTRAN interfaces for
> applications and data.  It has been tested in various environments,
> including various versions of UNIX, VMS, OS/2, MacOS, and MSDOS.

I note that Macintoshes and machines that can run MS-DOS or OS/2 use
IEEE 754 arithmetic (or something very close), that "various versions
of UNIX" also use IEEE 754, and that the VAX floating-point format is
_very_ close to 754 (I have coded 754<->VAX<->IBM<->754 conversion 
myself in the past).  These ways of storing floating-point numbers
don't look so very different to me.

-- 
You can lie with statistics ... but not to a statistician.

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 06:53:08 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: VMTP RFC????? or RFC TOC

In article <1992Jun9.190735.9041@e2big.mko.dec.com> jjf@peewee.enet.dec.com (35G-FRANEY) writes:
>I want to find the latest RFC of the Versatile Message Transport Protocol.
>The one I have is RFC 1045, but I hope there is a later version.
>
>Does any one know the RFC number for the latest VMTP spec?

RFC 1045 is the latest (at least until April 1992).

>Unless I am mistaken, there are RFCs that list other RFCs; an RFC table
>of contents, so to speak.  Does any one know the RFC number of the latest
>RFC that plays this role?  (I'll look for VMTP myself then).

The index to the RFCs is available by anonymous FTP from NIC.DDN.MIL. The
index does not have an RFC number. It is just updated regularly.

Regards,
-Roger
(I speak for myself)

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 08:09:43 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <1992Jun4.222006.26536@rgbsys> rick@rgbsys (Rick Davis) writes:
>Just as a rule of thumb, anticipate 50% software overhead.  If you have
>a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
>be around 600kbit/sec, or about 75kbyte/sec.

[ 50% of 10Mbit is 5mbit or 500Kbyte.  600kbit is about 6% of the
  bandwidth of the ethernet ]

I've seen peak rates of 900Kb/sec on an ethernet with ftp (output to
/dev/null from a file in memory) for a microVAX II class machine.
75Kb is way slow for any real TCP/IP implementation.  Even WIN/TCP for
VMS 3.2 over a DEQNA on a microvax II was faster than that, and it
didn't have the Van Jacobson speedups or any of the fancy algorithms
common today in it (I should note that it has improved quite a bit in
the 8 years since 3.2 came out).  500Kb is common on the Suns here for
large files.  That is over a network that is typically being used
randomly, so the round trip times are quite variable.

50% overhead for software and "layering" is silly and completely
bogus.  You must have been using a really really really bad TCP/IP
implementation with a broken ethernet card on a noisy, busy ethernet
segment to get this bad a performance.  I've seen 90%+ utilization of
the ethernet on many different machines (VAXen, Suns, sgi, etc).
Others who do research in this area can tell you more about FDDI tcp
performance, as well as other high speed networks.

Warner


-- 
Warner Losh		imp@Solbourne.COM

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 08:49:57 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested



 >>is based on years of empirical experience, whilst OSI is based on
 >>years of political compromise.  Can anyone disagree with that?

not if they know about the history of the Internet (now around 18% in
Europe)

 >a) nearly all the "empirical experience" was in the USA

Not true - not on LANs - we ran IP on our cambridge rings in 1982
alongside universe datagrams and the color books

 >b) they obviously didn't have much experience with concepts like forms-mode
 >   terminals, odd character sets, and odd filing systems
Not true, see tn3270, also most CDC and IBM systems had TCP access
quitew early - bob braden did the MVS version way back when, and coped
with EBCDIC and other rubbish...

 >c) some, if not most, of the later RFCs are just speculative, while I have
 >   heard at least one described as pure vaporware to attract research funding.
i think you should read:
"1250  Postel, J.B.,ed.  IAB official protocol standards.  1991 August;
28 p.  (Format: TXT=65279 bytes)  (Obsoletes RFC 1200)"
before making statements with low semantic content.

RFCs never have to describe exisiting software, originally, Milspecs
did, now the Internet SOcienty and its IAB do...
 
 >Also there is _some_ experience behind OSI, notably X.25 and experimental
 >protocols such as the UK's Coloured Books. The difference is that having
 >got this experience, OSI are not just codifying existing practice.

The color books are NOT OSI, and mostly are only about as sophisticated as
the Internet equivalents - in the cast of Remote Job entry (sorry
JTM/JTMP), they excelled themselvces in emulating ISO in complexity, and not getting widely
implemented either:-)

 jon

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 15:31:08 -0400
From:      Craig_Everhart@transarc.com
To:        comp.protocols.tcp-ip
Subject:   Re: reserved ports?

Excerpts from netnews.comp.protocols.tcp-ip: 10-Jun-92 Re: reserved
ports? Jamie Gritton@alaska.cae (432)

> hofer@rchland.vnet.ibm.com (Kent Hofer) writes:
 
> > Is the concept of 1-1024 port numbers being reserved for TCP/UDP a
> > unix convention or is it actually spelled out somewhere in the RFCs?
> > Are there any RFCs that talk about reserved ports?
 
>    It's just UNIX. The concept of having a superuser to reserve these
> ports for is OS-dependent. I don't recall this showing up in any RFCs.

As I read it, the question wasn't about Unix; it was about reserved
ports.  (The ports weren't ``reserved for root'' but ``reserved.'') 
There is the well-understood concept in the RFCs of the well-known port
number, or ``service contact port.''  RFC 1060 (``ASSIGNED NUMBERS,'' J.
Reynolds and J. Postel, ISI, March 1990) is the most recent Assigned
Numbers RFC that I know about.  It lists several such contact port
numbers in the range 1-255 without reference to a specific platform.  It
also lists what it calls ``Unix Standard'' service port numbers
referring to a conventional range of 256-1024, and then lists TCP port
numbers ranging from 7 to 9535 and UDP port numbers ranging from 7 to
17007.

		Craig


-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 11:50:57 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested


 >If I want to download a file from a network server, then FTP is the perfect
 >solution, but I would be unhappy if I learned that my bank was using it to
 >send its daily transaction files to the home office.  Telnet is great for
 >logging onto the development host and editing a few files, but I wouldn't
 >suggest Wall Street use it for its automatic trading programs.

you may be concerned to learn, then, that at least one of the big 4
banks in the UK, and two of the largest share info services (in the
world) both make extensive use or are about to, of IP, TCP, Telnet, FTP and
(yuck) NFS - to the tune of > 4000 routers...

no, you can't reach them from the Internet (yet)

 jon

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 12:04:38 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <1992Jun4.222006.26536@rgbsys> rick@rgbsys (Rick Davis) writes:
>We did a similar system where a X-windows interface ran on a 
>workstation and controlled objects on a video processor.  The link
>between the two was ethernet, running IP.  IP was based on UDP, and
                                         ^^^^^^^^^^^^^^^^^^^
>we used tftp to boot.  The protocol suite on the video processor end
>was implemented with a PSOS operating system and our own Lance 
>ethernet drivers. 

UDP is a transport protocol implemented on top of IP, as is TCP. I suppose
you chose UDP as the transport agent in the TCP/IP protocol suite. You
should realize that when using UDP, you have no guarantee that the data
actually makes it to the destination application. For reliable transport
use TCP which implements retransmission of lost datagrams, as well as flow
control to prevent swamping the receiving host with packets it cannot
handle fast enough.

>	The performance in the end was unsatisfactory because TCP/IP
>cannot guarantee bandwidth.  The upper bound on transport time is very
>soft due to many factors, not the least of which are the non-real time
>aspect of Unix and the inherent slowness of layered protocols.  The peak
>transfer rate is not determined by how long things spend "on the wire";

No protocol that uses a shared wire can guarantee bandwidth. Layered
protocols sacrifice some performance to structure, but layered protocols
are NOT inherently slow. UNIX real-time behaviour is usually lousy and may
not suit your needs.

>rather it is set by how long it takes to get packets to the ethernet 
>chip and the time to re-assemble them at the other end.  If you want to
>avoid this overhead, you arrange to always send 1140 byte messages
>( or whatever you have implemented the ethernet packet size as ).
>You also have the fastest possible processors at either end, and
>as much memory as you can afford for the ethernet chip's ring buffers.

Every packet protocol's efficiency increases with increased packet size, as
long as there is no need to fragment packets. On ethernet the MTU (maximum
transmission unit) is 1514 bytes (including a 14 byte MAC layer header, but
excluding the frame check sequence), effective payload is 1500 bytes. So you
can do somewhat better.

>Just as a rule of thumb, anticipate 50% software overhead.  If you have
>a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
>be around 600kbit/sec, or about 75kbyte/sec.  If there is anything else
>sharing the ethernet, this rate wil fluctuate down by quite a bit.  The
>downward fluctionations depend on how you have the back-off set up in
>the TCP protocol.  FOr a great introduction to all of this, check out
>Doug Comer's book "Internetworking with TCP/IP" and get hold of the
>RFCs relevant to what you want to do.

Either your ethernet or host is very busy, or your TCP/IP implementation is
broken.  You can easily do over 400 kByte/sec between ethernet hosts under
TCP/IP, provided that you have configured them correctly (correct MTU,
sufficiently large TCP receive window).

Regards,
-Roger
(I speak for myself)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 13:52:34 GMT
From:      dcarr@gandalf.ca (Dave Carr)
To:        comp.protocols.tcp-ip
Subject:   Re: multiplexing & data compression on IP-lines

In <1992Jun9.153447.6005@cs.kuleuven.ac.be> stephan@cs.kuleuven.ac.be (Stephan Biesbroeck) writes:

>We are thinking of multiplexing a 64 Kbps IP-line (into 2 seperate lines).
>One company offered us multiplexers that do also compression.
>They claim that they can multiplex 3 64Kbps lines into 1 64 Kbps line.
>Does this make sense on IP-lines. Is this possible to reach such
>a compression with IP-packets ???

Depends on the nature of the data and the utilization of the link.  If
the line is used for example as an Internet feed for mail, news, etc,
then you shouldn't settle for less than 4:1.  If you are doing compressed
binary transfers, expect 1:1.

For interactive type traffic (eg. telnet), it could go much higher,
possibly 8:1 or more.  The reason is that these IP packets are mostly
headers, which are very predictable.

What a statistical multiplexer (not a TDM) does is dynamically share the
bandwidth between the 3 lines, and any idle bandwidth on one line is used
by the other.  Therefore, if your utilization isn't 100 percent on all
lines, the multiplexer doesn't even have to get 3:1 compression on the
channels to get all 3 channels over one 64 Kbps link.

What the statmux will do when all 3 lines are used 100 percent, and the 
compression drops below 3:1, is slow down the clocks on the input lines
to effectively flow control the line.  This is usually not noticeable to
the end user however.

Let me guess, Symplex or Memotech, which manufacturer?     

By the way, we make a COMPRESSION BRIDGE which handles IP traffic very
nicely.  Maybe you don't need 2 lines.  The bridge is rated for one 64K 
link, but in July we should be able to handle 2 x 64K.

Depending on your traffic type, the numbers should follow the
above quoted rates.  We also make statmuxes, but not at 64K with
compression.
-- 
Dave Carr               | dcarr@gandalf.ca       | It's what you learn, 
Principal Designer      | TEL (613) 723-6500     | after you know it all,
Gandalf Data Limited    | FAX (613) 226-1717     | that counts. 

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 13:54:14 GMT
From:      Andrew@cs.swarthmore.edu (Andrew Rieger)
To:        comp.protocols.tcp-ip
Subject:   Routing to a machine with 2 net interfaces

  I am working on two DecStation 5000/240s. Each machine has a connection to
the local ethernet.  Both of the machines also have FDDI cards and are linked
directly by fiber.  We want to set things up so that any traffic
from machine A to machine B goes over the FDDI card and not the ethernet card.
We can do this if the user specifies the host name or IP address for the FDDI
interface.  However, we want to set up the routing on the two machines so that
all traffic is routed over the FDDI regardless of which interface the user
tries to specify.  We can set up the routes on machine A so that all traffic
to B goes over the FDDI simply by using false metrics in the routing tables.
Unfortunately, machine B does not recognize the packets addressed to its
ethernet interface when they come over the FDDI side.  Is there any way to do
this?  Any help is much appreciated.

				
				-- Andrew
-------------------------------------------------------------------------------
Andrew Rieger						
Unix Sysadmin and Networking Type Person
Andrew@cs.swarthmore.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 14:15:46 GMT
From:      ignacij@meishan.animal.uiuc.edu (Ignacy Misztal)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

rick@rgbsys (Rick Davis) writes:

>	The performance in the end was unsatisfactory because TCP/IP
>cannot guarantee bandwidth.  The upper bound on transport time is very
>soft due to many factors, not the least of which are the non-real time
>aspect of Unix and the inherent slowness of layered protocols.  The peak
>transfer rate is not determined by how long things spend "on the wire";
>rather it is set by how long it takes to get packets to the ethernet 
>chip and the time to re-assemble them at the other end.  If you want to
>avoid this overhead, you arrange to always send 1140 byte messages
>( or whatever you have implemented the ethernet packet size as ).
>You also have the fastest possible processors at either end, and
>as much memory as you can afford for the ethernet chip's ring buffers.
 
>Just as a rule of thumb, anticipate 50% software overhead.  If you have
>a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
>be around 600kbit/sec, or about 75kbyte/sec.  If there is anything else
>sharing the ethernet, this rate wil fluctuate down by quite a bit.  The
>downward fluctionations depend on how you have the back-off set up in
>the TCP protocol.  FOr a great introduction to all of this, check out
>Doug Comer's book "Internetworking with TCP/IP" and get hold of the
>RFCs relevant to what you want to do.
 
>Good Luck;
 
>Rick Davis

On our local LAN we are getting binary FTP up to 300 kbytes/s. An
accross campus transfer to a Cray approaches 250 kbytes/s. These are much
higher than 75 kbytes/s you report.
----------------------------------------------------------------------
Ignacy Misztal			E-mail: ignacy@uiuc.edu
University of Illinois		Phone: (217) 244-3164
1207 W. Gregory Dr.
Urbana, IL 61801
----------------------------------------------------------------------


-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 14:29:26 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   reserved ports?

Is the concept of 1-1024 port numbers being reserved for TCP/UDP a unix convention or is it actually spelled out somewhere in the RFCs?  Are there any RFCs that talk about reserved ports?

Thanks!
Kent Hofer


(My opinions are only my own, not my employers)

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 15:27:51 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   UDP sequence numbers

I am trying to implement sequence numbers inside of UDP messages in order
to tell if a message was lost.  If the sequence number of the recieved message
does not equal the expected sequence number, and alarm recored and the the 
sequence number of the recieved message is now the new sequence number.  

My question is does UDP insure that the sending side's messages will get out in
order? Also does UDP messages insure that messages recieved will be delivered 
in order to the software application?

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 15:36:08 GMT
From:      vittallo@ssd.comm.mot.com (John Vittallo)
To:        comp.protocols.tcp-ip
Subject:   UDP sequence numbers II

Sorry, the first one did not come out too good.

I am trying to implement sequence numbers inside of UDP messages in order
to tell if a message was lost.  If the sequence number of the recieved message
does not equal the expected sequence number, an alarm is recored and the 
sequence number of the recieved message is now the new sequence number.  

My question is does UDP insure that the sending side's messages will get out in
order? Also does UDP insure that messages recieved will be delivered 
in order to the software application?

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 16:24:36 GMT
From:      paul@frcs.Alt.ZA (Paul Nash)
To:        comp.protocols.tcp-ip,sanet.config
Subject:   Does KA9Q (Nos) run on Xenix

Does anyone out there know for sure whether the new (NOS-based) ka9q
runs on Xenix (or almost _any_ flavour) of Unix?  Version 890421
definitely did, but that was before NOS.  Everything that I have seen
since looks pretty solidly PC-only.

I am looking for a cheap way to run a PPP/SLIP link between two
Xenix boxes, with telnet & ftp available to users at each end.
 
 ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---
 Paul Nash                                         paul@frcs.Alt.ZA
 Box 12475, Onderstepoort, 0110 South Africa         +27-12-5611879

      "You don't want to get locked into open systems" -- IBM

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 16:45:18 GMT
From:      sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
To:        comp.arch,comp.protocols.tcp-ip,comp.arch.storage
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

In article <aj_lc#f.rcain@netcom.com> rcain@netcom.com (Robert Cain) writes:
>chris@visionware.co.uk (Chris Davies) writes:
>: 
>: Sun's XDR (eXternal Data Representation) stuff is very useful for this
>: sort of thing.  It's now in the public domain, and there's an RFC about
>: it (but I can't remember the number offhand).
>
>Aw common, please try.  Really.


XDR: External Data Representation Standard 	RFC#1014	SMI-June-87

>
>: 
>: Yes. RPC (Remote Procedure Calls) using XDR.  Wonderful stuff.
>: 

RPC: Remote Procedure Call Protocol Specification Ver.2  RFC#1050  SMI-June-88


(*) I don't know if those are the latest versions.



======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski		University of Virginia Physiology Dept.
 sdm7g@Virginia.EDU		Box 449 Health Sciences Center
 Voice: (804)-982-0831/32	1300 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 17:14:26 GMT
From:      sdm7g@aemsun.med.Virginia.EDU (Steven D. Majewski)
To:        comp.arch,comp.protocols.tcp-ip,comp.arch.storage
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

In article <MARK.MCINTOSH.92Jun5160923@sombrio.UVic.CA> Mark.McIntosh@engr.UVic.CA (Mark  McIntosh) writes:
>On 5 Jun 92 11:40:47 GMT, chris@visionware.co.uk (Chris Davies) said:
>>efk@ddsdx2.jhuapl.edu (Eileen Baust) writes:
>>: I need to be able to convert a data file that was created on a SUN
>>: 3/260 using data structures with floats, bit fields,
>>: bytes,integers, and long words.  The data is to be used by a Dell
>>: 486. There is a problem with bit fields in that the bit order gets
>>: reversed. Any one know of any existing routines?
>>Sun's XDR (eXternal Data Representation) stuff is very useful for this
>>sort of thing.
>
>You might also want to check out netCDF, the Network Common Data
>Format, from the Unidata and the University of Carolina.  I just
>discovered it but it sounds very interesting.  It is based on XDR as
>well.  It might be more straightforward to use, I don't know.
>
>I've attached the netCDF README file below.  There was a more recent
>release than the date on the README would indicate.
>

I've deleted the netCDF README, but I would like to redirect the 
followup to comp.arch.storage, and start a general discussion of
"network neutral" file storage. 

File _conversion_ was fine in the world of ftp & kermit, etc. but 
distributed filesystems like nfs demand portable files. 

The has been a lot of discussion and a mailing list ( hdf-netcdf ) 
started to discuss the possible "merger" of the netCDF and NCSA HDF
data models. 

What else is going on (anything?) in the realm of standards for 
"network neutral" portable files & databases? 

And on a different but related topic: 
What is the latest status of the ANSI X3B11 WORM filesystem? 

[ What I REALLY want to ask is "When can I buy an implementation of 
  an interchangable file system for re-writable optical disks?" but 
  I may not REALLY want to hear the answer! :-) ]



======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski		University of Virginia Physiology Dept.
 sdm7g@Virginia.EDU		Box 449 Health Sciences Center
 Voice: (804)-982-0831/32	1300 Jefferson Park Avenue
 FAX:   (804)-982-1616		Charlottesville, VA 22908

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 17:51:48 GMT
From:      edi@hadassah.bitnet
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: emulex terminal servers

I just read this:
>> we have two Emulex P4000 terminal servers with TCPIP/LAT support. We are
>> using software release 2.1.
I was wondering: we have had half a dozen P4000 terminal sever for several
years already with LAT only.  In order to get both LAT and TCP/IP, is this
merely a software change or a hardware upgrade as well?  We have switched to
Xyplex and Datability in oder to get the two protocolls.

Greetings,
Edi Landau

Hadassah University Hospital, Jerusalem, Israel.
Bitnet: Edi@Hadassah       Phone: 972-2-447312/3

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 18:04:43 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers

vittallo@ssd.comm.mot.com (John Vittallo) writes:
>My question is does UDP insure that the sending side's messages will get out in
>order? Also does UDP messages insure that messages recieved will be delivered 
>in order to the software application?

It's beyond UDP's control. An intermediate router might resequence packets;
different packets might be sent via different routes and arrive in a different
order. A packet might arrive 0 or more times, and packets may arrive in any
sequence. You might want to consider just using TCP.
-- 
	- john romkey	  ELF Communications	 romkey@ELF.com

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 18:47:46 GMT
From:      apple@drvax3.msfc.nasa.gov (Kathleen Applegate)
To:        comp.protocols.tcp-ip
Subject:   Re: reserved ports?

hofer@rchland.vnet.ibm.com (Kent Hofer) writes:

>Is the concept of 1-1024 port numbers being reserved for TCP/UDP a unix convention or is it actually spelled out somewhere in the RFCs?  Are there any RFCs that talk about reserved ports?

RFC 1060 lays it all out.

--
Kathleen Applegate                     |  New Technology Inc.
Senior Analyst                         |  700 Boulevard South, #401
drvax3!apple@freedom.msfc.nasa.gov     |  Huntsville, AL  35802

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 19:23:40 GMT
From:      kgnome@concour.cs.concordia.ca (MATIS stephane)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   10BaseT and no HUB

Ok, I have a PC with a Ethercard (10BaseT), it runs SOSS. 
I also have a NeXTstation, which of course has a 10BaseT.
I have don't have a hub. Do I need one ? Can I go without ?
If I had a 10Base2 (ThinNet) Ethernet card in my PC, will
I siplify my life ?

If you think these questions are like "What is the last digit of Pi ?"
, Then I am trully sorry for having wasted your time reading this.


+-------------------------------------------------------------------------+
 From     : Stephane I. Matis                "It Just Works..." 
 Internet : kgnome@concour.cs.concordia.ca     - Steve Paul Jobs, CEO NeXT
+-------------------------------------------------------------------------+
Summary: 
Expires: 
References: <robert.707717031@swanee> <920609151002@desire.ftp.com>
Sender: 
Followup-To: 
Distribution: 
Organization: Concordia University, Montreal, Quebec
Keywords: 

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 92 19:51:25 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: Duplicate IP addresses.

In article <1992Jun9.212956.25893@emr1.emr.ca> fillmore@emr1.emr.ca (Bob Fillmore 992-2832) writes:
>We are now much more sensitive to that possibility, and we are building
>a list of IP addresses with corresponding ethernet addresses (using
>etherhostprobe) so that we can locate the offender quickly.

That's a good idea.  We rely on our BOOTP tables and host registration
database to give a list of "valid" Ethernet-to-IP address mappings, then
continuously check the packets on the net by using NNStat to build lists
of all active IP-Ether address pairs.  It's not pretty, but it does work. :-)

-- 
Stephen Trier        Dumb error message of the month:
CWRU IRIS/INS         "Mar  1 18:07:18 ziggy xntpd[65]: Clock appears to
trier@ins.cwru.edu     be 86398 seconds slow, something may be wrong"

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 92 20:03:11 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: reserved ports?

In article <gd@byu.edu> gritton@byu.edu writes:
>   It's just UNIX. The concept of having a superuser to reserve these
>ports for is OS-dependent. I don't recall this showing up in any RFCs.

It's mentioned in RFC-1122.  The gist of the section is that the convention of
reserved ports is neither good nor bad by itself, as long as the host doesn't
expect all other hosts to support the convention.

-- 
Stephen Trier        Dumb error message of the month:
CWRU IRIS/INS         "Mar  1 18:07:18 ziggy xntpd[65]: Clock appears to
trier@ins.cwru.edu     be 86398 seconds slow, something may be wrong"

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1992 20:18:39 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing to a machine with 2 net interfaces

In article <GQ9KBF1X@cc.swarthmore.edu> Andrew@cs.swarthmore.edu (Andrew Rieger) writes:
>Unfortunately, machine B does not recognize the packets addressed to its
>ethernet interface when they come over the FDDI side.  Is there any way to do
>this?  Any help is much appreciated.

Turn on IP forwarding on machine B.  It will then try to route the incoming
packet, and discover that it's addressed to its other interface and simply
move it to that interface's input queue.

At least, that's what it *should* do.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1992 20:32:49 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: reserved ports?

In article <1992Jun10.142926.11431@rchland.ibm.com> hofer@rchland.vnet.ibm.com (Kent Hofer) writes:
>Is the concept of 1-1024 port numbers being reserved for TCP/UDP a unix
>convention or is it actually spelled out somewhere in the RFCs?  Are there
>any RFCs that talk about reserved ports?

As someone else already said, the concept of "privileged" ports is a
Unix-ism.  On Multics, for instance, I believe we did something similar by
using a directory with files whose access control lists are used to control
access to individual ports; on Unix, if TCP ports were accessed using
device special files, the analogous thing would be to restrict access to
/dev/tcp25.

The only concept of "reserved ports" in the RFC's is in the assignment of
well-known ports to services.  If you look at the PORT NUMBERS section of
the Assigned Numbers RFC (currently RFC 1060), you'll see that all the
ports from 0 to 255 are either assigned or explicitly marked "Reserved".
This means that only the IANA is allowed to assign well-known meanings to
ports in this range.  It's become conventional to use ports in the 256-1023
range for common, but not officially standard, protocols, and higher ports
as the arbitrary local ports for contacting them.  It's this convention
that resulted in Unix's definition of ports below 1024 as "privileged".

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 20:43:43 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <ignacij.708185746@meishan.animal.uiuc.edu>, ignacij@meishan.animal.uiuc.edu (Ignacy Misztal) writes:
> ...
> On our local LAN we are getting binary FTP up to 300 kbytes/s. An
> accross campus transfer to a Cray approaches 250 kbytes/s. These are much
> higher than 75 kbytes/s you report.


WHile `ftp` is a handy, nearly universally available tool to measure
things, but it does not just measure the speed of the network, unless you
get /dev/zero and put it into /dev/null.  Some file systems don't do much
better than 300KBytes/sec.  FTP is often, perhaps usually limited by the
speed of the file systems on both ends of the TCP link.

Also, the standard FTP sources are not tuned for speed.  For one thing, they
does not use large, well-aligned buffers.


Vernon Schryver,   vjs@sgi.com


-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 20:43:56 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <1992Jun4.222006.26536@rgbsys>, rick@rgbsys (Rick Davis) writes:
> ...
> Just as a rule of thumb, anticipate 50% software overhead.  If you have
> a 10 Mbit/sec ethernet, the max rate if everything is well-balanced will
> be around 600kbit/sec, or about 75kbyte/sec.  If there is anything else
> sharing the ethernet, this rate wil fluctuate down by quite a bit.  The
> downward fluctionations depend on how you have the back-off set up in
> the TCP protocol.


The TCP timers have no effect in a properly installed and not overloaded
ethernet.  TCP slow start, congestion avoidance, and so on does not start
until packets are lost, and in a well run ethernet, packets are very, very
rarely lost.

Common, commercially available, inexpensive (~ $10K) UNIX workstations get
a lot more than 75KByte/sec as measured by the TCP and UDP benchmark,
ttcp.  (It does no more than send and receive the same buffer over and
over.)  The machines I know about get from 850KBytes/sec to 1150KBytes/sec
through TCP with `ttcp -t`.  On a quiet ethernet (no collisions) they
transmit arbitrarly large numbers of ~100 byte packets from user space with
the minimum 9.6 usec spacing (4.3BSD style `ping -l 999999`).  TCP speed on
those machines over ethernet is limited by collisions caused by the ACK's.
The faster TCP machines use a more "polite" ethernet chip than the standard
describes, which reduces the collsion rates.


Vernon Schryver,   vjs@sgi.com


-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 1992 20:55:44 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers

In article <1992Jun10.152751.3143@lmpsbbs.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:
>My question is does UDP insure that the sending side's messages will get out in
>order? Also does UDP messages insure that messages recieved will be delivered 
>in order to the software application?

UDP insures neither.  UDP provides the following services: multiplexing
(via port numbers) and optional checksum of the data.  For delivery, it
just passes the datagram to IP, which provides no guarantees of delivery or
order.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 21:29:14 GMT
From:      alanlb@bethesda.cs.vt.edu (Alan L. Batongbacal)
To:        comp.protocols.tcp-ip
Subject:   NEED HELP WRITING TELNET CLIENT

Hi!  I'm writing an application that needs to pretend to be a dumb
terminal.  I open a TELNET port to a host (I've tried this with AIX,
A/UX, ULTRIX, MVS and VMS hosts) and the first thing I read is an
"IAC DO TERMINAL-TYPE".

Fine.  The way I wrote my client stuff, anything the remote TELNET
process asks for by way of options, I turn down.  That is, if it says
"IAC DO x", I respond with "IAC WONT x"; similarly,if it says "IAC WILL x",
I respond with "IAC DONT x".  The way I read RFC 854, this should leave
me with a bare-bones half-duplex line-oriented connection.

My problem is this: the bare-bones network virtual terminal I'm supposed
to be left with shouldn't do echoing, right?  However, everytime I write
text data to the remote TELNET, the very same data shows up in my input
stream, i.e. when I read from the connection.  Isn't this remote
echoing that really shouldn't be happening, as specified by the RFC?

As an attempt to fix the problem, I tried sending out "IAC WONT ECHO IAC
DONT ECHO" immediately after doing the connect(), even though this
is supposed to be the default state of the connection.  I got exactly
the same echoing response.

I'm really stumped.  I'd appreciate any pointers.  Thanks!

-alan
-alanlb@cs.vt.edu

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 92 21:59:21 GMT
From:      toma@troi.cc.rochester.edu (Tom Armading)
To:        comp.protocols.tcp-ip
Subject:   Apertus Telnet server experience anyone?

I am about to add telnet & tn3270 service to my IBM mainframe, and
one vendor's product is very interesting, but I've not heard much
about them.

If you have had any experience with Apertus Technologies products I
would like to hear from you.

-Tom Armading

My e-mail address is:  toma@cc.rochester.edu

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jun 1992 23:55:38 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <MORSE.92Jun8092420@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes:
> Careful. While Rose is somewhat unusual, in that he has a kind of dual
> persona, he is hardly a friend of OSI. He seems like the upper layers
> (sort of) but ruthlessly bashes the lower layers.

That's really interesting. I've never read anything by Rose, but my own
experience with OSI parallels this. Once you get systems talking the
upper layer applications are quite nice, but getting the lower layers to
agree on the settings is a pain.

> X.400, X.500: SMTP isn't in the same league as S.400. Nore is there an
> equivalent of X.500 in the Internet protocol family.

Since X.400 isn't a real parallel for SMTP (it's more like RFC-822, SMTP,
and other protocols and standards rolled into one), isn't this a pretty
meaningless statement?

Certainly X.400 addresses are strictly from hell.

X.500 is nice. FTAM is nice. VT is nice. But how in the hell do I figure
out what the NSAP is for an existing network with no OSI-specific
documentation?
-- 
Peter da Silva                                                      `-_-'
/* No comment */                                                     'U` 
Ferranti International Controls Corporation                    Have you hugged
Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 00:05:46 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <peterd.708056425@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> It also has a few de-facto network file system standards, which OSI is
> still lacking. (In theory FTAM can be used as an NFS replacement. The
> mind boggles at the thought.)

Well, Intel claims that OpenNET is using FTAM. If so, I'm VERY happy with the
result. OpenNET makes NFS, RFS, and what I know of AFS look really really
bad by comparison.
-- 
Peter da Silva                                                      `-_-'
/* No comment */                                                     'U` 
Ferranti International Controls Corporation                    Have you hugged
Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 06:54:39 GMT
From:      tru@kddnews.kddlabs.co.jp (Tohru Asami)
To:        comp.protocols.tcp-ip,comp.protocols.ppp,comp.unix.ultrix
Subject:   How to install Dialup IP 2.0 into DECstations under ULTRIX 4.0 or later


We have to connect our DECstation 3100 under ULTRIX 4.2A to a
DECstation 5000/200 under ULTRIX 4.0 with SLIP.

I've found the version of SLIP distributed with Unsupported Software
Subset cannot work correctly for ULTRIX 4.0. So I try to install other
type of SLIP into that DECstation.

I think Dialup IP, which was made by Bolt Beranek and Newman, Inc.
and CREN/CSNET will be the best one. So I have been trying to install
it for last 2 days. However the distribution kit of Dialup IP 2.0 only
support the following machines:

   (1) Sun-OS 3.5
   (2) 4.3BSD
   (3) Ultrix3.x on VAX

So it does not run on DECstation 5000/200, whose operating system is
ULTRIX 4.0 for a MIPS chip.

If someone have succeeded installing Dialup IP 2.0 into DECstation,
please let me know how.

Regards,

--
Tru (Tohru Asami)
Artificial Intelligence Group, KDD R&D Labs.
2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan
Phone: +81 492 66 7383 FAX  : +81 492 66 7512

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 07:15:13 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers

In article <1992Jun10.152751.3143@lmpsbbs.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:
>I am trying to implement sequence numbers inside of UDP messages in order
>to tell if a message was lost.  If the sequence number of the recieved message
>does not equal the expected sequence number, and alarm recored and the the 
>sequence number of the recieved message is now the new sequence number.  
>
>My question is does UDP insure that the sending side's messages will get out in
>order? Also does UDP messages insure that messages recieved will be delivered 
>in order to the software application?

I guess that most (if not all) implementations will preserve message order
(it takes an extra effort to create disorder). However your IP network will
not guarantee delivery in correct order. Remember that two datagrams may
follow different routes in a network and may thus not be delivered in
order.

If you require delivery in order, as well as reliable delivery: use TCP!

Regards,
-Roger


-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 12:33:40
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <MORSE.92Jun8092420@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes:

    
    BER: This has been discussed much lately. There are many people who
    are more informed on the topic than I who could give an update on the
    improvements that will come from new methods of encoding (i.e. PER,
    etc.).
    
So, once ASN.1 gets fixed enough so its speed can compete, OSI will have a
clear advantage.  However, to deliver this to actual users will require
upgrading the installed base.  Likewise, delivering the features of 1988
X.400 requires upgrading everyone who bought 1984 products.

Coping with CONS/CLNS requires either getting rid of one or the other
(unlikely), or building a global directory that can tell a node initiating
a connection which transport protocol to use (you *can* use TP4 over CONS,
but it'll cost you enough so you probably won't).

Compare this with the IP address space problem: either there is a new IP
header, which can probably be delivered backwards-compatibly such that only
those who want to use the full Internet need to upgrade, or there are
gateways between 32-bit addressing domains and a hairy directory system
that tells you how to use them.  Seems to me the only advantage OSI has
is that the size of its installed base (and thus the scale of the directory
problem) is smaller...

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


-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 12:34:30
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Explaination of loose source routing?

RFC 1122 (Host Requirements lower layers) discusses how this works (the
text was borrowed from an RFC Jon Postel wrote up, but was never formally
issued).

PC/TCP for DOS has contained a PING program which can generate both kinds
of source route since v2.05 came out (1990).  This works will all the routers
I've tried it on.

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


-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 10:07:59 GMT
From:      huitema@mitsou.inria.fr (Christian Huitema)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun9.111208.10600@cl.cam.ac.uk>, ag129@cl.cam.ac.uk (Alasdair Grant) writes:
> c) some, if not most, of the later RFCs are just speculative, while I have
>    heard at least one described as pure vaporware to attract research funding.

Not all RFC are Internet standards. Freedom of speech and free dissemination
of information is considered an essential part of the Internet process. Some
RFC are informational, other just describe experiments. The list of Internet
standards and of those RFC which describe them is regularly published by the
IAB.

An, to add a calming note to this debate, lets observe that the IAB did
encourage the experimentation of some OSI technologies in the Internet, and
that several members of the IAB do believe that incorporating bits and pieces
of OSI technologies in the evolving Internet suite is a very reasonable idea.

I personnaly believe that there are a couple of interesting parts in the OSI
production, like ASN.1 and perhaps also CLNP and X.500 -- although I believe
both would need extensive rewriting in light of practical experience. And,
then, I believe that the basic OSI model is just obsolete; see Tennenhouse and
Crowcroft papers for justifications + alternative proposals. We are at a point
now where researcher have to design new models, propose new experiments,
before developing new standards. I doubt this will be done in the ISO arena.
Judging form the past, I have no confidence whatsoever in the OSI
standardization process, which lacks the openness, speed of the IETF process,
as well as its ability to take experimental results into account.

Christian Huitema

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 11:07:37 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Crashing UNIX (wasRe: Explanation of loose source routing?)

> 
> I would expect most commercial routers to support this properly.
> TCP/IP implementations derived from BSD Unix (like SUNOS) often
> have problems with IP options.  (I've crashed Suns when testing
> IP options).
> >

I would appreciate receiving any info on which
versions of UNIX on which machines can be crashed by 
sending them certain TCP/IP features/options...

I'll summarize to the net.

--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 11:57:26 GMT
From:      stewart@tweety.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <lt606pg@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Jun4.222006.26536@rgbsys>, rick@rgbsys (Rick Davis) writes:
>> ...
>> The
>> downward fluctionations depend on how you have the back-off set up in
>> the TCP protocol.
>
>The TCP timers have no effect in a properly installed and not overloaded
>ethernet.  TCP slow start, congestion avoidance, and so on does not start
>until packets are lost, and in a well run ethernet, packets are very, very
>rarely lost.

It's implementation specific, but according to both logic and the
recommendations of many experts, the presence of slow start (and
friends) in the protocol has quite a bit to do with performance,
from the first moment.  When a TCP connection is first established,
the window size is set to one segment.  As acknowledgements arive,
this is increased by one.  This continues until a packet is lost,
at which time (if you're using using multiplicative decrease) the
window size is decreased by half.  I'll spare further painful
details, so for a more complete explanation, see the TCP chapter
(or whatever it's called) in Comer's _Internetworking With TCP/IP
Volume I_.

/jws

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 12:07:59 GMT
From:      berthold@edfd.uucp (Berthold Michel)
To:        comp.protocols.tcp-ip
Subject:   Packet driver

Hello kermit user,

we are looking for a packet driver for tcp/ip which works together
with kermit 3.11. We want to use the vt220 terminal emulation, but
the drivers supported by the ethernet card distributor don't work.
We have WD8013EWC cards in our pcs.
Is there anybody who has the same configuration and who can tell me
where to get a suitable driver ?

Many thanks in advance.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 12:19:00 GMT
From:      short@microcom.com (Todd Short)
To:        comp.protocols.tcp-ip
Subject:   Re: Novice Question: Telnet

In article 28795@u.washington.edu, sue@hardy.u.washington.edu (Shu-Chen Eclipse) writes:
>
>
>
>Hello, I am accesing a Unix machine from a PC/Dos machine running PC-NFS telenet.
>My problem is that when telenet makes the connection to Unix and I get a login

Once you make the connection to Unix, you are "in Unix" (but not logged in).  The
"default" erase key is Delete when you first log in, you should be able to use the 
'Delete' ('.' on the numeric pad) key or Ctrl-BackSpace for delete.

>prompt and I misspell my user name, the backspace key only gives me ^H's, and
>I have to use a delete key to backspace. Notice, I am NOT YET in Unix, so
>adding stty erase ^H to my .login won't work.
>
>How do I set PC-NFS TELENET so that I can use the backspace key for backspace
>over characters I want to delete??
>
>I noticed Pc-nfs telenet has a setup menu, but I don't see anything there about
>backspace/erase: I seet auto-line feed (on), and null-cr, or cr-lf (on).
>
>Any ideas?
>thanx.
>sue@hardy.u.washington.edu
>

Most terminals that are used for unix have both a Delete and a Backspace key.
Adding that line only helps after you have logged in.  Most of the communication
programs that I know of (CrossTalk, Windows Terminal, PC-Kermit, TeleMate, and
others) do not (to my knowledge) allow you to map BS to DEL.  My best suggestion
to you is to
a: type your name a bit slower
b: get used to using Ctrl-Backspace to delete (i.e. don't put 'stty erase ^H' in
your login, PUT IT IN YOUR .cshrc (if you have one)).
---
-Todd
/* short@python.eng.microcom.com */


-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 13:04:56 GMT
From:      paul@tivoli.UUCP (Paul Greenspan)
To:        comp.protocols.tcp-ip
Subject:   TLI connectionless-mode device on Sun

Hi,

I'm converting a application from sockets to TLI.  The application uses
UDP.  On Sun, what is the device that I specify in the t_open() call?  
There's no /dev/udp, /dev/tidg, etc.

Thanks in advance.

Paul

-- 
Paul Greenspan              paul@tivoli.com 
Tivoli Systems              6034 West Courtyard, Suite 210
Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 92 20:14:12 PDT
From:      Lee_Robert_Willis@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   How to optimize ethernet?

Hi Net!

ETHERNET QUESTION: (Hope this is the right place)

My company is putting together a system which consists of a
handful of Sun workstations connected via ethernet.  One of the
systems has several gigabytes of storage available, which serves
as our data repository. We're going to be pumping a lot of data
(10-30 Mbyte files) back and forth between workstations across
the ethernet.  There will be a lot of network traffic, and
response time is very critical.

From my all-of-one-week class on networking I learned that
ethernet degrades horribly when the network is busy. I'm looking
for methods to minimize this.  The only idea I've come up with
so far is to implement a pseudo-token-ring protocol on top of
the ethernet to prevent contention for the net.

Any suggestions would be welcome.

Thanks!

--
Lee      Lee_Robert_Willis@cup.portal.com

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 14:32:35 GMT
From:      kgnome@concour.cs.concordia.ca (MATIS stephane)
To:        comp.sys.next.sysadmin,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   10BaseT and no HUB

I'd like to thank all the folks who have replied to my question. General
consessus is that :

	1. At least in theory, a crossover 10BaseT cable should work.
	2. My life would be simple if I used a 10Base2 card and cable
	combo instead.

Unfortunately, the experiment so far has been inconclusive. For lack of
better explanation, it's either my custom crossover cable or the Digital
DEPCA Ethernet card for the PC. You pick the culprit. ;-)

Later today, I'll try to put my paw on a 10Base2, and repeat the
experiment. Here's hoping...


> If you think these questions are like "What is the last digit of Pi ?"
> , Then I am trully sorry for having wasted your time reading this.

My thanks to :

David Lemson <lemson@jupiter.fnbc.com>
Irving_Wolfe <Irving_Wolfe@happy-man.com>
Jim Cathey <jimc@tau-ceti.isc-br.com>
Mark Reardon <mwr%eng.tridom.com@mathcs.emory.edu>
Robert W Berry <rwberry@hubcap.clemson.edu>
Steve Hayman <Steve_Hayman@NeXT.COM>
WiseGuy <DWEISSMAN@amarna.gsfc.nasa.gov>

+-------------------------------------------------------------------------+
 From     : Stephane I. Matis                "It Just Works..." 
 Internet : kgnome@concour.cs.concordia.ca     - Steve Paul Jobs, CEO NeXT
+-------------------------------------------------------------------------+

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 92 15:10:57 GMT
From:      dhanson@isis.cs.du.edu (David L. Hanson)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   OSI vs TCP/IP opininion


morse@quark.mpr.ca (Daryl Morse) writes:

<stuff deleted ...>
< I don't know.  While I won't claim that OSI is perfect,
>I will claim that it's much better than Rose and other IAB
>types would like us to believe.  The standards bodies may be slow
>they do work.

Much of what Mr. Rose said at Interop was not about the theoretical
problems with OSI but with the practical problems (implementations
don't interoperate).  My experience is that he is absolutely correct.
We might have the most politically internationally correct standars with
OSI.  There might be this fanstastic international consensus that
makes everyone (especially the "one world" types) feel "warm and fuzzy",
but so what if the standards aren't implementable at a reasonable
cost and in a way that they will interoperate in actual use.

We have been working for more than 5 months to get 8 different X.400
implementations working (really these are X.400 gateways to proprietary
email packages because that is the state of the commercial X.400
world today, at least on our platforms).  I have to admit we have had very
few problems with the network and transport layers of OSI; in fact,
I can't think of any.  We did have to figure out an adressing scheme
which took some time simply because there are a zillion ways to do it.
Our OSI routers are happily routing OSI packets among a half a dozen
central US locations.

Unfortunately, our task is not to make OSI transport stacks work with
other OSI transport stacks.  It is to make X.400 gateway implementations
to interoperate over an X.400 backbone (using OSI transport).
They simply do NOT interoperate in a usable way.  So big deal if it
is an "international standard"; if it won't work or if it so hard that it
is
impossible to put in production use, it's useless.  I know, I know,
"someday" the world will be perfect and OSI implentations will really
work and everything will be "nice".  Another of Grimm's fairy tales, me
thinks.

OSI has taught me to love TCP/IP.  X.400 has taught me to love SMTP.

(Hopefully, it is obvious I don't want to argue/discuss which is
a "better"standard; OSI can be "better" or even the "best" but
so far it don't work.)

David L. Hanson
Naperville, IL
zdlh19@sc.msc.edu


-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 15:20:55 GMT
From:      smith@sctc.com (Rick Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

huitema@mitsou.inria.fr (Christian Huitema) writes:

>... the basic OSI model is just obsolete; see Tennenhouse and
>Crowcroft papers for justifications + alternative proposals. 

Could you give a more complete citation of a paper that discusses
alternative reference models? Thanks.

Rick.
smith@sctc.com          arden hills, minnesota

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 16:39:03 GMT
From:      ronf@panther4.panther.mot.com (Ron Feigen)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

Does any one have any info on reliably delivered UDP. I have heard thier is some PD software around.
I would even mind paying for it (but not too much).  I need to impliment this in Kernal space not
User space.

Thanks,

-- 
Ron Feigen
ronf@panther.mot.com

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 17:34:27 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <id.SMIQ.X85@ferranti.com> peter@ferranti.com (Peter da
Silva) writes:
>Certainly X.400 addresses are strictly from hell.

For better or worse, many people judge X.400 harshly because the
addressing scheme is too byzantine.  They think, rightly or wrongly,
that if they have to make my mailing address look like some mutant DCL
or JCL command, then they don't want to have anything to do with it.

Pity.  X.400 has some cool things in it.

Warner
-- 
Warner Losh		imp@Solbourne.COM

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 17:52:32 GMT
From:      tschudin@uni2a.unige.ch
To:        comp.protocols.tcp-ip
Subject:   Re: Question about transfer rates on Ethernet

We made simple measurements at the UofGeneva using UDP between Suns and HP
workstations:
without tuning we got a throughput (user data) of 500 to 1000 kbytes/sec
on the same segment, with varying userdata size.

The most relevant factor are routers inbetween segments. We did not test
this exhaustively, but a Sun connected to two segments drops a lot of
packets, also Ciscos. So be prepared to have a throughput of a magnitude
less if you have to pass through more than one router.
It seems that inter-packet gap plays an important role when you overrun
a router: you can achieve the SAME throughput by introducing such a gap, but
now you will have nearly no loss (and therefor a less saturated ethernet).
The problem on UNIX systems is that with only a 10 msec resolution timer
for user processes you can not adjust this gap fine enough.

christian

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Christian Tschudin                          Universit\'e de Gen\`eve
eMail: <tschudin@cui.unige.ch>              Centre Universitaire d'Informatique
X.400: /S=tschudin/OU=cui/O=unige           12, rue du Lac
       /C=ch/A=arcom/P=switch/              CH-1207 Geneva
Tel  : +41 22 787 65 88                     Fax: +41 22 735 39 05
 
The head is round so that the direction of thinking can change. Francis Picabia
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 18:15:11 GMT
From:      drw@jordan.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   OSI packet addressing scheme

OK, I'm really naive here (I think of the Internet as "You throw an IP
packet overboard and it (usually) swims to the destination host."),
but I have heard suggestions that an OSI connectionless protocol could
be used in place of IP as the bottom layer of the Internet protocols.
This is proposed as a way to solve the 32-bit address problem that the
Internet now has.  Would anybody like to post a discussion of what
this connectionless protocol is like and what its addressing system
is, or at least post a pointer to the information?

Thanks,

Dale

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
There was only one Christian, and he died on the Cross.	-- Friedrich Nietzsche

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 19:39:35 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   problems with the NOS-to-Sun Port

   A few months ago I ftp'ed A. Klemets' port of NOS to SunOs. I
didn't have a chance to fire it up then but I am trying now and dying
miserably. I am running on a Sun IPX running SunOs4.1. I am using the
lwp version of the port. (Haven't installed the tunnel driver. I
willstart of with the NIT).I can't get past the first lwp_suspend. When
the main process has initialized everything and is ready to start real
work it eventually calls "lwp_suspend(SELF)". At this point I get a
SEGV (segmentation fault core dump) and it crashes. Tracing with dbx 
tells me I in _chg_context which is called from _schedule both of
which are in the Sun provided lwp library. The Sun documentation (FM)
for the lwp, particularly the explanations of "CHECK()" and
lwp_checkstk are rather less than transparent. This doesn't help much.
I also can't get "tprint" to work.  This is disappointing. NOS is a
great product and the port to the Suns looks good and when I get it
working it will solve all my problems (marital, nutritional,
cardiovascular, spiritual etc). I must be doing
something stupid.  Any help would be appreciated.


-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 92 19:43:23 GMT
From:      wjudmaie@isis.cs.du.edu (Werner Judmaier)
To:        comp.protocols.tcp-ip
Subject:   Using file transfer protocols over telnet session


 

Hallo everybody!
   I am wondering if some expert can provide some information  upon
the following question:
   While connecting to a remote host via telnet (internet) I would like
to start a file transfer using Z-Modem, X-Modem, Y-Modem or whatever
variant thereof is appropriate. I vaguely remember that I succeded doing it
in the past, however meanwhile the OS on the local machine changed to UNIX
To clarify: Ihave to use a terminal program to be able to connect to
the UNIX machine first, so I do not have any problems starting the
file tansfer download protocol on the PC I am using.  However the telnet
connection 'scrambles' the protocol and the file transfer fails. 
My attempts to transfer files since then failed, independant  of the
remote system I am connecting to. I also tried 'rlogin', still with no
success. Are there any parameters (switches) that an be applied to make
a connection work for transfer protocols?
YES, I am familiar with FTP, however not every system is ftp'able - so
I have to resort to whatever -modem file transfer during a telnet session.
I would be glad if someone could post any answer to this group and, if
possible a copy to my E-Mail adress, since my connection to the news-
reader is only sporadic.
My home adress: C54101@u1.uibk.ac.at
Whith many thanks


                              Werner Judmaier
                      Univ. of Innsbruck, Austria








-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jun 1992 21:00:31 GMT
From:      stewart@tweety.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <920611123340@cream.ftp.com> jbvb@ftp.com writes:
>Likewise, delivering the features of 1988
>X.400 requires upgrading everyone who bought 1984 products.

Not only that, but in order for X.400 to achieve the ubiquity
and richness promised, a good, practical X.500 directory must
exist.  The CCITT study period ending 1988 leaves a lot of
things out of X.500 that are necessary for this (most
importantly: shadowing and caching of data, and communication
of knowledge information between DSA's).  Maybe the OSI
people can pick up the ball on this as impetus to prove
X.400's worthiness...

/jws

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 92 22:56:32 GMT
From:      k@hprnd.rose.hp.com (Steve Kao)
To:        comp.protocols.tcp-ip
Subject:   Re: 10BaseT and no HUB

Stephane Matis posts:
> Ok, I have a PC with a Ethercard (10BaseT), it runs SOSS. 
> I also have a NeXTstation, which of course has a 10BaseT.
> I have don't have a hub. Do I need one ? Can I go without ?

If you want to connect your PC to your NeXTstation using 10baseT, you
don't need a hub.  You can build a crossover cable to connect the two.
Of course, such a connection means that nothing else can connect to
either machine via the cards which the 10baseT crossover cable connects.

To build a crossover cable, leave pins 4, 5, 7, and 8 alone, and connect
the following.

Side A                 Side B
------                 ------
pin 1  (white/orange)  pin 3
pin 2  (orange/white)  pin 6
pin 3  (white/green)   pin 1
pin 6  (green/white)   pin 3

You can purchase crossover 10baseT cables from many vendors.  Even HP
sells them (HP part number 92214W), but you can probably buy them
cheaper elsewhere.  It's probably cheapest to make one yourself.

- Steve Kao

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 01:55:29 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers II

In article <1992Jun10.153608.3279@lmpsbbs.mot.com> vittallo@ssd.comm.mot.com (John Vittallo) writes:

   My question is does UDP insure that the sending side's messages will get
   out in order? Also does UDP insure that messages recieved will be delivered
   in order to the software application?

No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
is no guarentees as to if the message will be received at all much less
resequenced.

You may want to consider using TCP instead.
--
				-- Frank Solensky / Clearpoint Research
Red Sox magic number: 114
"finger bosox@animal.clearpoint.com" for current info.

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 1992 01:57:07 GMT
From:      stewart@tweety.cis.udel.edu (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Crashing UNIX (wasRe: Explanation of loose source routing?)

In article <1992Jun11.110737.14603@stc.nato.int> koelman@stc.nato.int writes:
>I would appreciate receiving any info on which
>versions of UNIX on which machines can be crashed by 
>sending them certain TCP/IP features/options...

This message is for comic relief only, and thus I did not follow
the directions and reply only to koelman@stc.nato.int.

A common method used to check the implementation of IP on either
an end-host or an IMP is to send it a "Christmas Tree" packet (I
believe David Mills is the father of this term) where the packet
is "decorated" with *every* option.

/jws

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 12:55:19 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip,comp.sys.sun.misc
Subject:   Re: Question about transfer rates on Ethernet

In article <ignacij.708185746@meishan.animal.uiuc.edu> ignacij@meishan.animal.uiuc.edu (Ignacy Misztal) writes:
>[...]
>On our local LAN we are getting binary FTP up to 300 kbytes/s. An
>accross campus transfer to a Cray approaches 250 kbytes/s. These are much
>higher than 75 kbytes/s you report.


Yeah.  I just snarfed the latest GNU gcc-2.1.1.tar.Z (6.6+ MB) from
prep.ai.mit.edu to California over the Internet; the rate was 35KBytes/sec
for the 3,000 mile cross-country transfer.

Transferred that file to QIC-24 tape and loaded it onto a Sun-3/60 for
distribution to my other office machines.  Ftp's reported transfer rates on
the local net ranged from 400Kbytes/sec to 450Kbytes/sec between that Sun-3/60
and (for example) SGI IRIS and HP9000/710.

I ran the ftp again and the transfer rates were the same TO the Sun-3/60.

If you're getting only 75Kbytes/sec on a local net ftp, that strongly suggests
a bottleneck due to, perhaps, disk fragmentation.  Recall that the stats
include the time spent reading a file from one system, pushing the bytes down
the wire, and writing a file on the destination system.

One way to see if your disks are the cause would be to run the latest copy
of iozone (version 1.15) on each of your systems; you may be shocked.  I
know I was when ONE system tested at 25Kbytes/sec ... that one has an old
AT&T filesystem, and I temporarily "cured" it by a full-backup on the "bad"
partition followed by a mkfs and a reload from tapes.

To test your local net's performance, use ttcp to time the interface-to-
interface data rate.

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 13:15:12 GMT
From:      hrubin@pop.stat.purdue.edu (Herman Rubin)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures, etc.

In article <MARK.MCINTOSH.92Jun5160923@sombrio.UVic.CA> Mark.McIntosh@engr.UVic.CA (Mark  McIntosh) writes:
>On 5 Jun 92 11:40:47 GMT, chris@visionware.co.uk (Chris Davies) said:
>>efk@ddsdx2.jhuapl.edu (Eileen Baust) writes:
>>: I need to be able to convert a data file that was created on a SUN
>>: 3/260 using data structures with floats, bit fields,
>>: bytes,integers, and long words.  The data is to be used by a Dell
>>: 486. There is a problem with bit fields in that the bit order gets
>>: reversed. Any one know of any existing routines?
>>Sun's XDR (eXternal Data Representation) stuff is very useful for this
>>sort of thing.
 
>You might also want to check out netCDF, the Network Common Data
>Format, from the Unidata and the University of Carolina.  I just
>discovered it but it sounds very interesting.  It is based on XDR as
>well.  It might be more straightforward to use, I don't know.

I did check both of these out.  I find both of them totally inadequate,
and locked into specific object sizes.

We should not be trying to send objects whose size is tied to a particular
architecture, or language, or combination thereof, but the necessary
objects which need to be communicated.  There is general agreement on
the representation of decimal integers, decimal fixed-point numbers,
and decimal floating-point numbers.  There is considerable agreement
on binary, octal, and hexadecimal integers. 

However, I am unaware of anything comparable on versions of fixed-point
and floating point numbers related to base 2.  For fixed-point numbers,
there SHOULD be little problem in merely allowing the introduction of
the "." in a binary or octal or hex number with the obvious meaning.

For floating, the problem is somewhat more difficult.  I personally
would want to use the above hex fixed point representation, with
the power of 2 multiplying this being written in hex.  This would
be relatively easy to translate to and from machine representation
on all the machines I know of.  IEEE, VAX, Cray, and CYBER would be
essentially straight bit manipulation, and IBM 360 and its descendents
only slightly harder.

So instead of trying to restrict data transmission to IEEE or something
like it, get a simple flexible procedure in place.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 1992 13:32:18 GMT
From:      vaarisko@tnclus.tele.nokia.fi
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   lpr problem with WinQVT/Net

I have a problem using WinQVT /Net's LPR client:

What might be the reason causing WinQVT's LPR to say "LPR daemon refused 'send
control file' command"? I've never been able to print any files usiong WinQVT,
but other lpr software (PC-TCP, for example) works ok. I have tried different
host machines, with no success. And what is this lpr control file, anyway ?
Please help!
-- 
___________________________________________________________________________
 Jouni V{{riskoski             E-Mail:vaarisko@tnclus.tele.nokia.fi 
 Nokia Telecommunications      X400: ou=SWS/p=Nokia Telecom/a=Mailnet/c=FI
                               Tel: 358-0-511 6337 Home: 358-0-466 050
---------------------------------------------------------------------------

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 16:04:00 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested



 >>... the basic OSI model is just obsolete; see Tennenhouse and
 >>Crowcroft papers for justifications + alternative proposals. 
 >
 >Could you give a more complete citation of a paper that discusses
 >alternative reference models? Thanks.
 
Rick,

Author(s): David Clark and David Tennenhouse
Title    : Architectural Considerations for a new Generation of
Protocols
Journal  : ACM SIGCOMM90, ACM
Date     : September 1990

Author(s): D L Tennenhouse 
Title    : Layered Multiplexing Considered Harmful
Journal  : H Rudin & R Williamson editors, Protocols for High Speed
Networks
Date     : May 1989
Pages    : Elsevier Science Publishers, IFIP

and

Crowcroft, J. , Wakeman, I. , Wang, Z, Sirovica, D,
"Layering Considered Harmful", IEEE Networks, Jan 1992.
(also see next edition for graphs)
 jon

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 16:28:17 GMT
From:      solensky@animal.clearpoint.com (Frank T. Solensky)
To:        comp.protocols.tcp-ip
Subject:   The "U" in UDP (was: Re: UDP sequence numbers II)

In article <SOLENSKY.92Jun11205529@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
   No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
   is no guarentees as to if the message will be received at all much less
   resequenced.

Mea culpa!  I stand corrected.  Dennis Shiao at ANS correctly points out
that the "U" is, indeed, "User" in RFC-768.  All other documents that I've
been able to find (Host Requirements, Router Requirements, etc) concur.

Oh, well...
--
				-- Frank Solensky / Clearpoint Research
Red Sox magic number: 114
"finger bosox@animal.clearpoint.com" for current info.

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 16:35:37 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: The "U" in UDP (was: Re: UDP sequence numbers II)

In article <SOLENSKY.92Jun12112817@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>In article <SOLENSKY.92Jun11205529@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>   No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
>   is no guarentees as to if the message will be received at all much less
>   resequenced.
>
>Mea culpa!  I stand corrected.  Dennis Shiao at ANS correctly points out
>that the "U" is, indeed, "User" in RFC-768.  All other documents that I've
>been able to find (Host Requirements, Router Requirements, etc) concur.
>
>Oh, well...

But "Unreliable Datagram Protocol" probably IS a better description.

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 92 16:41:37 GMT
From:      ayman@umich.edu (Ayman Kayssi)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: lpr problem with WinQVT/Net

In article <1992Jun12.153218.1@tnclus.tele.nokia.fi> vaarisko@tnclus.tele.nokia.fi writes:
>What might be the reason causing WinQVT's LPR to say "LPR daemon refused 'send
>control file' command"? I've never been able to print any files usiong WinQVT,
>but other lpr software (PC-TCP, for example) works ok. I have tried different
>host machines, with no success. And what is this lpr control file, anyway ?
>Please help!

This is becoming a FAQ. It is a known bug in qvtnet: The control file that it
generates is not compatible with the majority (all?) of lpd daemons on unix 
hosts. The control file is a file that the lpr client sends together with the
file to print and contains information about the print job, like printer name,
file name, etc. lpd daemons expect a certain format that qvtnet, apparently,
is not conforming to.

--
Ayman I. Kayssi                               |    ayman@eecs.umich.edu
Advanced Computer Architecture Laboratory     |   ayman@engin.umich.edu
EECS Department                               +------------------------
The University of Michigan                    |          (313) 764-8033

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 1992 18:34:55 GMT
From:      dsbarr@modula.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <1992Jun11.163903.1889@panther.mot.com> ronf@panther4.panther.mot.com (Ron Feigen) writes:
>Does any one have any info on reliably delivered UDP. I have heard thier is some PD software around.
>I would even mind paying for it (but not too much).  I need to impliment this in Kernal space not
>User space.

Yes, it's called "TCP".  And you probably already have it.

--Dave
-- 
Dave Barr            | -- NewsGrazer, a NeXTstep(tm) news reader, posting --
dsbarr@cs.psu.edu    | NOT!

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 1992 19:14:16 GMT
From:      restock@PacBell.COM (Bob Stockwell)
To:        comp.protocols.tcp-ip
Subject:   Re: The "U" in UDP (was: Re: UDP sequence numbers II)

In article <SOLENSKY.92Jun12112817@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>In article <SOLENSKY.92Jun11205529@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>   No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
>   is no guarentees as to if the message will be received at all much less
>   resequenced.
>
>Mea culpa!  I stand corrected.  Dennis Shiao at ANS correctly points out
>that the "U" is, indeed, "User" in RFC-768.  All other documents that I've
>been able to find (Host Requirements, Router Requirements, etc) concur.

Yes, but the D stands for Datagram, which implies no relationship with
any message before or after.
>
>Oh, well...
>--
>				-- Frank Solensky / Clearpoint Research
>Red Sox magic number: 114
>"finger bosox@animal.clearpoint.com" for current info.


-- 
Bob Stockwell
Pacific Bell
pacbell.com!ptsfa!res

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jun 1992 21:54:16 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: The "U" in UDP (was: Re: UDP sequence numbers II)

In article <1992Jun12.191416.21970@PacBell.COM> restock@PacBell.COM (Bob Stockwell) writes:
>In article <SOLENSKY.92Jun12112817@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>>In article <SOLENSKY.92Jun11205529@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>>   No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
>>   is no guarentees as to if the message will be received at all much less
>>   resequenced.
>>
>>Mea culpa!  I stand corrected.  Dennis Shiao at ANS correctly points out
>>that the "U" is, indeed, "User" in RFC-768.  All other documents that I've
>>been able to find (Host Requirements, Router Requirements, etc) concur.
>
>Yes, but the D stands for Datagram, which implies no relationship with
>any message before or after.

You're right, of course, but i'm still all for changing the "user"
into "unreliable" in the protocol's official name just to try to
reduce the number of people that ask for a reliable UDP.  This is,
after all, the most frequently asked of all the frequently asked
questions.  Perhaps we should try to make it a little more obvious to
those that haven't pondered the meaning of "datagram" as much as the
rest of us have.
						don provan
						donp@novell.com

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Jun 92 03:51:22 GMT
From:      ehall@cmpny.sscnet.ucla.edu (Eric Hall)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: KA9Q on NDIS and 3Com 3C527 ?

NDIS is fairly simple.  It involves a protocol manager, a nic driver, and 
protocols.  Then you "bind" them all together to create a network interface. 
The driver you've got is probably just for the adapter, and you'll still need 
to obtain the protocol manager and protocols.  If you've got the FTP stuff, 
then you've got the protocol.

Without the protocol manager and the binding utilities, you're outta luck.  
Maybe you can "find" a copy of LAN Manager or Vines somewhere, since they 
both use NDIS.

Eric Hall, Director East Coast Labs

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 92 12:40:40 GMT
From:      baos@caip.rutgers.edu (Bancroft Scott)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

jbvb@vax.ftp.com (James B. VanBokkelen) writes:

>In article <MORSE.92Jun8092420@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes:
 
>    
>    BER: This has been discussed much lately. There are many people who
>    are more informed on the topic than I who could give an update on the
>    improvements that will come from new methods of encoding (i.e. PER,
>    etc.).
>    
>So, once ASN.1 gets fixed enough so its speed can compete, OSI will have a
>clear advantage.  However, to deliver this to actual users will require
>upgrading the installed base.

Switching to the new encoding rules will be trivial if your application uses
an ASN.1 compiler or some other approach which totally hides from view the
nature of the actual encodings (e.g., the application NEVER sees anything that
hints of a tag).  That applications see no tags is important, since none of
the new encoding rules uses tags at all (except for the Canonical and 
Distinguished Encoding Rules of ASN.1 .. CER and DER are described below).

The compiler-generated data structures manipulated by applications to which
tags are invisible in no way changes with the new encoding rules, so all
that is required to switch out the underlying encoding/decoding functions
to an encoding rule that gives you the type of performance that you desire
(Packed Encoding Rules (PER) for greatly compressed encodings, Light Weight
Encoding Rules (LWER) for exceedingly faster encoding/decoding times).  
Indeed, this aspect of the new encoding rules makes it possible for you to
defer until connect time which set of encoding rules you will use, falling
back to BER if your peer does not speak one of the optimized encoding rules
that you support.

CAVEAT: I said that application data structures generated by ASN.1 compilers
will not have to change with the new encoding rules.  This is not true if one
party changed the likes of:

        A ::= CHOICE {
		a INTEGER,
		b REAL
	}
to
	A ::= INTEGER	-- was a choice, but we we never use REAL
	
without the other party also making the same change to the abstract syntax 
spec.  Going the other way also presents a problem for the newer encoding
rules.  Yes, I know what Note 1 in ISO 8824 (1990) clause 24.1 states; it
has been changed to reflect the fact that the above transformation poses 
a problem for some encoding rules.

DER is nothing other than the Directory DER (i.e., BER with only a single 
way to encode values of each ASN.1 type), which has been assigned an object
id and moved into ISO 8825-3 with a couple minor backward-compatible 
modifications.  CER is used by the likes of ODA, and its primary difference
from DER is that it uses indefinite-length encodings, as opposed to DER's
definite-length encodings (makes handling of humungous PDU's easier).

Parting word: As a member of the ISO working group that went through the long 
and very tedious exercise of trying to identify and expunge all aspects of 
BER that makes it so absolutely horrible, I have developed a newfound
respect for it.  Every time that we tweeked it this way or that, we lost 
functionality.  The strength of BER is its flexibility.  And yes, flexibility
is also its weakness, for those who have no need for it.

=====================================|========================================
Bancroft Scott			     |		Open Systems Solutions, Inc.
609-987-9073			     |		Princeton, N.J.
=====================================|========================================

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 92 17:24:15 GMT
From:      shih@madrone.eecs.ucdavis.edu (Alan S. Shih)
To:        comp.protocols.tcp-ip
Subject:   3com503 Driver for 386Unix?

Hi Netlanders:

	Is there a 3com503 driver for sysv386 unix systems? I look through
	the pkg for 3com and found nothing.  Can anyone direct me
	to ftp site or should I just call 3com to find it out?

	any info is greatly appreciated


-- 
|   ALAN SHIH  
|   UC.Davis EE dept
|   "When I realized my life is full of sh*t, it was good;
|      because I can start cleaning it UP."

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 92 19:09:58 GMT
From:      bob@comlab.gatech.edu (Bob Baggerman)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   Re: KA9Q on NDIS and 3Com 3C527 ?

In article ehall@cmpny.sscnet.ucla.edu (Eric Hall) writes:
>Without the protocol manager and the binding utilities, you're outta luck.  
>Maybe you can "find" a copy of LAN Manager or Vines somewhere, since they 
>both use NDIS.

I don't know if they are technically in the public domain but Microsoft
has made Protocol Manager and Netbind freely available.  FTP Software may
have a copy available from their system "vax.ftp.com" via anonymous ftp. 
If not they can probably be had from the Microsoft LAN Manager forum on
CompuServe or I can make them available on my system if need be.

Bob

--
Bob Baggerman                         !  bob@comlab.gatech.edu
Communications Laboratory             !  rwb@csdvax.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 92 20:34:49 GMT
From:      preece@npdiss1.StPaul.NCR.COM (q)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Apology to Mr. Rose (was Re: OSI vs TCP/IP ...)

In a previous article, I expressed the following opinion of Marshall Rose:

    The only thing Rose seems to like more that criticizing OSI, however, is
    praising himself.

Mr. Rose quite reasonably objected, and I found that I had no good reason
for that opinion.

I have apologized to Mr. Rose. 

Please do not let my statement alter your opinion of him.

-------------  
Bently Preece                                      NCR Network Products Div.
software engineer                                      2700 Snelling Ave. N.
b.preece@StPaul.NCR.COM                               St. Paul, MN USA 55113
-- 
-------------  
Bently Preece                                      NCR Network Products Div.
software engineer                                      2700 Snelling Ave. N.
b.preece@StPaul.NCR.COM                               St. Paul, MN USA 55113

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Sat, 13 Jun 1992 22:15:37 GMT
From:      brown@wucs1.wustl.edu (Mike Brown)
To:        comp.protocols.misc,comp.dcom.lan,comp.protocols.tcpip
Subject:   Looking for NETBIOS, SMB protocol references

I'm looking for references that document the protocols used by Microsoft
Lan Manager 1.x and 2.x servers and clients.  The purpose is to
aid analysis of network traces.


Regards,
Mike Brown

		brown@wucs1.wustl.edu
		or mb2452@swuts.sbc.com

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Sun, 14 Jun 1992 20:01:50 GMT
From:      flog@open.ch (Florian Gutzwiller)
To:        comp.protocols.tcp-ip
Subject:   Secure 10BaseT Hubs

I was pointed out. thate there is a Secure 10BaseT Hub by AT&T. 

	1. Will it connect to FDDI ?
	2. Are there other vendors offering the same ?
	3. What is meant by Secure 10BaseT ?

	4. What Secure TCP/IP protocol implementations
	   are available.


Thanks

-Florian

--
Florian A. Gutzwiller	Phone:  +41-61-281-8600 
Open Systems AG		Fax:    +41-61-281-8603
Basel/Switzerland	E-Mail: flog@open.ch (NeXT)

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 00:54:43 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure 10BaseT Hubs

In article <1992Jun14.200150.13023@bernina.ethz.ch>, flog@open.ch (Florian Gutzwiller) writes:
> I was pointed out. thate there is a Secure 10BaseT Hub by AT&T. 
> 
> 	1. Will it connect to FDDI ?

I don't think so, but any standard router or FDDI bridge could do the job.
There are fiber hubs, so you can set up a building-wide 10BaseT network.

> 	2. Are there other vendors offering the same ?

I think so, but I don't know.

> 	3. What is meant by Secure 10BaseT ?

You configure the hub with the Ethernet address of each wire.  When packets
are transmitted, all wires -- that is, all stations -- not receiving
the packet receive a garbage packet instead.  It can't just suppress
the packet, because the other machines still need to see the carrier;
besides, it's doing this on the fly, not store-and-forward.

> 	4. What Secure TCP/IP protocol implementations
> 	   are available.

Now it's my turn -- waht do you mean by ``Secure TCP/IP''?

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 05:30:03 GMT
From:      west@chance.dsg.ti.com (Roger West)
To:        comp.protocols.tcp-ip
Subject:   Re: The "U" in UDP (was: Re: UDP sequence numbers II)


On 12 Jun 92 21:54:16 GMT,
donp@novell.com (don provan) said:

> You're right, of course, but i'm still all for changing the "user"
> into "unreliable" in the protocol's official name just to try to
> reduce the number of people that ask for a reliable UDP.  This is,
> after all, the most frequently asked of all the frequently asked
> questions.  Perhaps we should try to make it a little more obvious to
> those that haven't pondered the meaning of "datagram" as much as the
> rest of us have.
> 						don provan
> 						donp@novell.com

Well, I guess I'm one of those people.  But I don't see what is so silly in
wanting a reliable connectionless transport protocol (especially for rpc and
database query applications).  Wouldn't it just amount to the kernel keeping
track of timeouts, sending retries, and rejecting duplicates, instead of the
application?

On the same note, what ever happened to VMTP (I think it was) which Comer
mentions in the first edition of his book?  Isn't this the type of service it
was supposed to provide?  How come it never caught on?



-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 07:43:08 GMT
From:      rh0083b@medtronic.COM (Roger Hunen)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers II

In article <SOLENSKY.92Jun11205529@animal.clearpoint.com> solensky@animal.clearpoint.com (Frank T. Solensky) writes:
>No.  Bear in mind that the "U" stands for Unreliable (not "User"): there
>is no guarentees as to if the message will be received at all much less
>resequenced.

NO!!!! RFC 768: User Datagram Protocol!

Regards,
-Roger
(I speak for myself)

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 13:39:07 GMT
From:      jcburt@cs.wm.edu (John Burton)
To:        comp.unix.aix,comp.os.os2.networking,comp.protocols.tcp-ip
Subject:   help!!! newbie SLIP question...

Okay, I know this will sound like a dumb question to some folks on 
the net, but please be kind...

Basically I have an IBM RS/6000 running AIX 3.2 and a Gateway 2000
486/33 running OS/2 2.0 connected to a fairly large (ethernet)
local network (>10,000 machines). The net.gods for our local
net assign the numeric addresses of the machines (of course). We
also have several PC's and Macs that we would like to have access
to the net, but each ethernet connection costs $$$. I've read about
SLIP (Serial Line Internet Protocal ?) and wondered if this could
be used to set up a sort of subnet...i.e.

<==============+====Ethernet LAN=========+==================>
               |                         |
               |                         |
             486/33                   RS/6000
               |                      /     \
               |                     /       \
               PC                  MAC       PC                    

The internet addresses for the 486/33 and the RS/6000 are established
by the local.net.gods. The PC'S and Mac are connected via serial lines
to the appropriate machine. From what I can figure, for SLIP to operate,
the PC's and Mac also need a numeric address, and internet addresses
are unique... I would like to avoid bothering the local.net.gods about
addresses for the PC's and Mac but NOT muck up the network in the process...

can someone point me to a good reference or give me step by step
instructions on how to accomplish this? HELP!!!

John

+--------------------------------------------------------------------+
| John Burton                                                        |
| G & A Technical Software                                           |
| jcburt@gatsibm.larc.nasa.gov                                       |
| jcburt@cs.wm.edu                                                   |
|                                                                    |
| Disclaimer: Hey, what can I say...These are *my* views, not those  |
|             of anyone else, be they employer, school, or government|
+--------------------------------------------------------------------+

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 13:44:26 GMT
From:      doug@happy.vf.ge.com (Doug Hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: TLI connectionless-mode device on Sun

According to Answerbook SunOS 4.1.2 and under do not do connectionless
TLI.. It is unsupported.
  There are a lot of things about TLI that are unsupported on SunOS.
I believe the concept of an orderly release is unsupported also, but
I could be wrong.  The general consensus that I've gotten from people
is that the SUN implementation of TLI is generally buggy in its current
form.  Wait for Solaris I suppose..

In article <1599@tivoli.UUCP>, paul@tivoli.UUCP (Paul Greenspan) writes:
> Hi,
> 
> I'm converting a application from sockets to TLI.  The application uses
> UDP.  On Sun, what is the device that I specify in the t_open() call?  
> There's no /dev/udp, /dev/tidg, etc.
> 
> Thanks in advance.
> 
> Paul
> 
> -- 
> Paul Greenspan              paul@tivoli.com 
> Tivoli Systems              6034 West Courtyard, Suite 210
> Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623
 
-- 
 ___			|	GE software developer
( / ) _       _,	|	doug@happy.vf.ge.com
_/_/ <_>_/_/_<_>	|	uunet!crdgw1!ge-dab!happy.vf.ge.com!doug
             <_>	|	2B | !2B > The_Question
________________________|______________________________________________________

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 13:44:48 GMT
From:      adnan@odin.icd.ab.com (Adnan C. Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

>>>>> On Fri, 12 Jun 1992 18:34:55 GMT, dsbarr@modula.cs.psu.edu (Dave Barr) said:
 Dave> In article <1992Jun11.163903.1889@panther.mot.com> ronf@panther4.panther.mot.com (Ron Feigen) writes:
>Does any one have any info on reliably delivered UDP. I have heard thier is some PD software around.
>I would even mind paying for it (but not too much).  I need to impliment this in Kernal space not
>User space.

Dave> Yes, it's called "TCP".  And you probably already have it.

I have often seen this question and this response.  I wonder why
whenever a developer runs up against a problem which can be nicely
solved by a reliable datagram protocol some people always insist that
you can and should solve it with TCP.  This logic seems similar to
saying you should use the telephone every time you want to send a
registered letter, return receipt requested.

In support of my belief that there is a place for a reliable user
datagram protocol in any protocol suite, I offer you the this excerpt
from the introduction of the XTP Protocol Definition, Revision 3.6:
"XTP meets these and other needs by providing:
	o ...
	o real-time reliable datagram capability
	o ..."

Maybe Mr. Feigen may find some help in the XTP specification, and maybe
Mr. Barr should first see what Mr. Feigen wants to do with a reliable
datagram protocol before he recommends TCP.



--
Adnan Yaqub (adnan@icd.ab.com)
Allen-Bradley Company, Inc., 747 Alpha Drive, Highland Hts., OH 44143, USA
Phone: +1 216 646 4670 FAX: +1 216 646 4484

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 14:36:49 GMT
From:      dsbarr@modula.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <ADNAN.92Jun15084448@odin.icd.ab.com> adnan@odin.icd.ab.com (Adnan C. Yaqub) writes:
>Maybe Mr. Feigen may find some help in the XTP specification, and maybe
>Mr. Barr should first see what Mr. Feigen wants to do with a reliable
>datagram protocol before he recommends TCP.

Good advice.  In order to recommend UDP you should have a good description
of the problem.  TCP is there because it is a general solution for a reliable
tranmission protocol.  I've seen several people get it stuck in their head
that since UDP has less overhead than TCP that they should use UDP instead
of TCP for their protocol.  (even if the protocol is a point-to-point one)
Granted, a general-purpose, reliable, broadcast-based (as in many hosts, not
necessarily a broadcast packet) UDP protocol would be a handy thing to
have.

Where is this XTP spec?

--Dave
-- 
Dave Barr         |  It takes a big man to cry,
dsbarr@cs.psu.edu |  but it takes a bigger man to laugh at that man.

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 16:21:45 GMT
From:      rla@media03.UUCP (Raymond van der Laan)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   setting buffersize for sockets

Hello,

Sorry if this is a trivial question, but I want to know...

How can one set the buffer-size that sockets use to send 
and receive data? I found out that my SysV R4 (Intel)
machine can only 1024 bytes per write/read call.
I tried setsockopt(), but despite no errors, it didn't make
a difference.

Anyone got a clue? Thanks.

-- 
Raymond van der Laan           Email: sun4nl!media01!rla
Mediasystemen BV               Tel. : +31 23-319075            
Haarlem                        Fax  : +31 23-315210
The Netherlands                                   
                                    'There is no masterplan.
                                     This is what we do now.'
                                            - Stuart Adamson

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 16:32:19 GMT
From:      adnan@odin.icd.ab.com (Adnan C. Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

Dave> Where is this XTP spec?

I contacted Protocol Engines and they sent me a copy:

	2011 N. Shoreline Blvd., Suite A
	Mountain View, CA 94043-1321
	Telephone 415-691-0364
	Fax 415-691-1286

	e-mail xtp-request@pei.com
--
Adnan Yaqub (adnan@icd.ab.com)
Allen-Bradley Company, Inc., 747 Alpha Drive, Highland Hts., OH 44143, USA
Phone: +1 216 646 4670 FAX: +1 216 646 4484

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 16:41:07 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

adnan@odin.icd.ab.com (Adnan C. Yaqub) writes:

Ron wrote:Does any one have any info on reliably delivered UDP. 

Dave replied: Yes, it's called "TCP".  And you probably already have it.

>I have often seen this question and this response.  I wonder why
>whenever a developer runs up against a problem which can be nicely
>solved by a reliable datagram protocol some people always insist that
>you can and should solve it with TCP.  This logic seems similar to
>saying you should use the telephone every time you want to send a
>registered letter, return receipt requested.

There are a lot of good reasons why this happens.  The slow start,
and adapting window features of TCP become necessary when you deal with
a varied set of network hardware, so in the design you start looking
at connection-oriented, variable windows, feedback, etc., and you end
up with much of the TCP protocol.  There are some immediate inefficiesies
when you adopt TCP for block transfers, but intelligently selecting 
the parameters yields the same performance as you get from other protocols.
There are examples where this is validated, and a brief glance over the
recent paper on the harmful effects of layerring gave some instances
of what to avoid.  But the raw deal is that TCP gives an excellent
best case performance, and its worst case is usually not too bad.

If the Internet adopts a reliable datagram protocol, that would be nice,
I would be happy and so would you.  But I think it should be more along 
the lines of a complete (revised) RPC mechanism as I believe raw 
reliable datagrams are a trivial RPC.

>Maybe Mr. Feigen may find some help in the XTP specification, and maybe
>Mr. Barr should first see what Mr. Feigen wants to do with a reliable
>datagram protocol before he recommends TCP.

But if Mr. Feign wishes to write his program today and wishes to do it
with (as he suggested) the minimal amount of effort and money, he can
do it today with tcp, there's a better chance that he already has it.

Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 16:51:18 GMT
From:      brunner@adobe.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: UDP sequence numbers II

There seems to be some naming-heat associated with this thread, so for
the nonce, while the "U" really does stand for the token "User", there
is a reason why many of us use the token "Unreliable" when thinking or
writing about it -- having to do with the semantics of the transport
mechanisms of tcp and udp.

In a related thread or sub-thread there is an apparent query for a udp
transport implementors guide to streams-like semantics, independent of
the existing tcp stream semantics -- note that the token "stream" in
singular or plural _does not_ have any relation to AT&T's Edition 8 or
SysVr3 or later protocol-stack implementation by the same name.

Since there are several semi-reliable udp transport implementations in
the research and commercial literature, and since this is one of the
more commonly asked questions, it would be nice if someone would write
up such a bibliography and place it on an anonymous ftp/mail-server
host, and post a pointer.

Then we'd have a bit less traffic on the list... at least over the merits
(as-understood) of A or B, or "U" and "U".

-- 
#include <std/disclaimer.h>
Eric Brunner, consulting at and not speaking for Adobe
uucp: uunet!practic!brunner or uunet!adobe!brunner
trying to understand multiprocessing is like having bees live inside your head.

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 17:14:51 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: How to optimize ethernet?

In article <60468@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes:
>From my all-of-one-week class on networking I learned that
>ethernet degrades horribly when the network is busy...

Let me guess... this was taught by someone who either (a) has a financial
interest in token ring, or (b) believes everything IBM says.

Ethernet performance degrades, mostly slowly and gracefully, as offered load
climbs.  Some early simulations suggested otherwise, but the fact is that
Ethernet is quite difficult to simulate accurately, and the problem was
in the simulations rather than in Ethernet.  That hasn't stopped those
long-discredited results from being widely cited by Ethernet's competitors.

This is not to say that Ethernet is perfect, but any blanket claim that
it "degrades horribly when the network is busy" is made from ignorance
or malice.

>... methods to minimize this.  The only idea I've come up with
>so far is to implement a pseudo-token-ring protocol on top of
>the ethernet to prevent contention for the net.

Remember what happens when the token gets lost (yes, this does happen):
a long silence while some sort of token-recovery-consensus protocol works.

>... We're going to be pumping a lot of data
>(10-30 Mbyte files) back and forth between workstations across
>the ethernet.  There will be a lot of network traffic, and
>response time is very critical.

Gut reaction:  this network should be designed by someone with more
than an "all-of-one week class on networking".  Seriously -- you are
talking about a demanding application, and hiring somebody who really
knows what he's doing will be a very smart investment.  For one thing,
he will have the experience and background to tell you whether what you
want is simply beyond the capabilities of the network technology you're
using.  (It is definitely conceivable, depending on details, that it
simply can't be done with a single Ethernet.)  Hiring a networking expert
for a week will be far more cost-effective than trying to do it yourself,
unless your bosses will tolerate a lengthy period of experimentation
with no guarantee of success.

(Lest I be suspected of ulterior motives, I should add that I am *not*
such an expert.)

If you don't want to take that advice, I would say that the single most
useful thing you can do is to set up a prototype *quickly* so you can
start testing network performance.  The prototype need not be the real
system; it only has to match the expected network load, and provide for
measurement of throughput and response time.  This way, you can tell
your management not "we've designed a protocol that we think will work"
but "we've tested it using a real network under realistic load, and
it works".  This will save much finger-pointing between the network
people and the application people if the first working system turns
out to have performance problems.  It will also let you evaluate the
tradeoffs of possible changes, e.g. "if you'll relax this response
requirement by 20%, we can give you twice the data volume"; this will
be important for future growth, and *very* important for negotiating
changes in the event that you can't meet the full specs.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 17:29:52 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: The "U" in UDP (was: Re: UDP sequence numbers II)

In article <WEST.92Jun14233003@chance.dsg.ti.com> west@chance.dsg.ti.com (Roger West) writes:
>Well, I guess I'm one of those people.  But I don't see what is so silly in
>wanting a reliable connectionless transport protocol (especially for rpc and
>database query applications).  Wouldn't it just amount to the kernel keeping
>track of timeouts, sending retries, and rejecting duplicates, instead of the
>application?

You've just described TCP.  OK, you might have a sophisticated
application that cannot tolerate anything more than 1.5 round trips to
confirm delivery of a block of data.  But i think most people who ask
for a reliable UDP have just overlooked a simple TCP open/send/close
sequence as a way to reliably send a discrete block of data.

Of course, most implementations today would end up with an eight packet
exchange because both BSD sockets and TLI would tend to do the three
steps independently.  Has anyone implemented a "connectionless" TCP
socket that would do all three steps in response to a transmission?
Using that approach, it should be fairly simple to cut down to five
packets: SYN, SYN-ACK, ACK-DATA-FIN, FIN-ACK, ACK.

(I've always wanted to try to make the three packet exchange
SYN-DATA-FIN, SYN-ACK-FIN, ACK work, which is as good as possible for a
reliable transfer with both ends agreeing that the transfer was
successful.  Unfortunately, i think there's hangup in TCP there.  If i
recall correctly, the problem is that the receiver can't really read the
data in the SYN packet until the three-way handshake completes, so it
can't get to the FIN and respond to it in the SYN-ACK.  Perhaps this
could be fixed, but i never really looked into it.)

By the way, if you're worried about lots of TCP connections in TIME-WAIT
state, you'll have to have something similar in a reliable,
connectionless protocol if you want the receiver to know for sure that
the sender knows the receiver got the data.  (And if you don't want
that, end the TCP session with a RESET in place of the last ACK to avoid
the TIME-WAIT state.)

Now that i've shot off my mouth with absolutely no actual experience 
reliable connectionless protocols or applications, perhaps someone that
knows what they're talking about will step in and correct my mistakes...

						don provan
						donp@novell.com

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 18:01:10 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   RFCs and MUST provide?

Hello all.
I'm having trouble understanding what is probably a pretty basic point while I read these RFCs.  In RFC1122 host requirements, it says things like "the transport MUST provide" the API with ways to set time to live time and Type-Of-Service, etc..  Ok, I understand the difference between MUST and should, but what I don't understand is "where are these interfaces"?  Sockets seems to be a defacto standard that I would certainly have expected to be able to set TOS with for example - it isn't there, is it?  

To quit rambling and ask a direct question - are there ANY internet APIs out there that actually have functions to set/retrieve all the stuff that the RFCs say they MUST be able to set/retrieve?   

Thanks.  


Kent Hofer    hofer@rchland.vnet.ibm.com  

(my opinions are my own and have nothing to do with my employer

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 92 20:12:52 GMT
From:      flog@open.ch (Florian Gutzwiller)
To:        comp.protocols.tcp-ip
Subject:   Re: Secure 10BaseT Hubs

Steven Bellovin writes

> > 	4. What Secure TCP/IP protocol implementations
> > 	   are available.
> 
> Now it's my turn -- waht do you mean by ``Secure TCP/IP''?

I understand the 'secure' option to Suns NFS as one of them compared to telnet  
that passes on passwords over the net in clear text. 

It should probably better read 'secure implementations of TCP/IP application  
protocols'.

-Florian
--
Florian A. Gutzwiller	Phone:  +41-61-281-8600 
Open Systems AG		Fax:    +41-61-281-8603
Basel/Switzerland	E-Mail: flog@open.ch (NeXT)

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jun 1992 22:50:00 GMT
From:      sudarsan@nssdca.gsfc.nasa.gov (Sridharan Sudarsan)
To:        comp.protocols.tcp-ip
Subject:   request for information on state machine implementations


Hello everybody,

I am designing a finite state machine that ( somewhat roughly ) 
resembles the TCP implementation. I was unable to understand the 
FSM design from both the TCP books by Comer. I could not proceed 
further from the point where I know that each state has an event 
associated with it, and an interpreter executes the function pointer 
corresponding to each out put signal. 

Where can I get more information on the TCP implementation of the 
FSM ? What are the RFC's that he mentions and how can I get my hands 
on them ?

Kindly email your responses to me. and I will summarize the responses I get 
if there are any requests.

Thanks a lot,

Sudarsan 
------------------------------------------------------------------------
S. SUDARSAN

SUDARSAN@NSSDCA.GSFC.NASA.GOV
------------------------------------------------------------------------

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 03:29:03 GMT
From:      P85025@BARILVM.BITNET (Doron Shikmoni)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip
Subject:   Re: Routing Token Ring to Ethernet (3270 Emulation)

In article <167FD1187B.MLONG@isucard.card.iastate.edu>,
MLONG@isucard.card.iastate.edu says:
>
>>
>>
>>In our department we are using a Thin Wire Ethernet but
>>for some of our users it is necessary to use the services
>>of an IBM mainframe. The mainframe services are brought
>>via Token Ring and the PC3270 Emulation program by IBM.
>>
>>Since all of our users are connected to the Ethernet
>>but access to Token Ring is limited to two connections
>>our questions are:
>>
>>1) Is it possible to set up a local gateway between the
>>   Token Ring and the Ethernet so that every Workstation
>>   can act as an 3270 Terminal (no other services are
>>   needed from the Token Ring environment) ?
>>   I am thinking of a simple software solution for a PC
>>   connected to both, the Ethernet and the Token Ring.
 
>1. You could use OS/2 2.0 with Extended Services.  It has a SNA Gateway
>that will support your configuration (upstream Token Ring, downstream
>Ethernet).  IBM PC/3270 program will need to be used on the workstaions,
>PC 3270 V3, and 3270 Workstation Prog is not supported on Ethernet.  The
>Gateway
>would not need to be dedicated, it could also be running LAN Server, DBM
>Server, or could even be somebodys workstation as long as they did not turn it
>off:->

Indeed. Another thing you can do (I do it) is set up a PC/3270 gateway,
in which the "upstrem" connection is TR and the "downstream" connection
is Ethernet. This works fine for me - not sure about its capacity in
terms of # of terminals, I only have a few so far.

I haven't looked at OS/2 V2.0 ES yet (is it out?). I tried the OS/2
SNA Gateway back in V1.2; I then dropped it for PC/3270 gateway for
one, quite prosaic reason: The SNA Gateway didn't have the option of
defining a "default" station profile. This required me to define each
and every station to the gateway (with MAC address and stuff - think
about what happens when you replace an Ethernet card...), and then
restart the Gateway so that my changes are activated (and dropping all
connection while at it). On the other hand, PC/3270 gateway has the
ability to define a "default" profile, which applies to every station
that connects to the gateway and for which no profile has been
specifically defined.

I don't know whether this has been improved in V1.3 or V2.0. I would
be interested to know!

Doron

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 06:53:10 GMT
From:      holemans@reks.uia.ac.be (Wim Holemans)
To:        comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: emulex terminal servers

First thanks to all people who responded (more to say they have the same
problem than to provide solutions).

Our problem is solved : after going through a series of tests, I started
to suspect our transceiver. Changing it solved all our problems. I didn't
figure out if our transceiver is really broken or if it was badly attached
or I did something wrong with the SQE heartbeat settings.  I'm going to do
some testing to find out next week.

As to the question if you can change a lat server to a telnet/lat server,
I think you can but you need another Performance Pack with more memory
(1 Mb at least) and new boot software. I think you better contact your
dealer for this.

Greetings,

W. Holemans
Computer Centre U.I.A.
Antwerp - Belgium
holemans@reks.uia.ac.be



-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 08:19:26 GMT
From:      npngps@solomon.technet.sg (Ng Pheng Siong)
To:        comp.protocols.tcp-ip
Subject:   NDIS, PROTOCOL.INI, dynamic=yes

Hi.

According to several sources, the Protocol Manager is supposed to be able
to dynamically unload protocols. However, none of them told how!

How is that done?

TIA.

- PhengSiong



-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 13:19:01 GMT
From:      knox@aplexus.jhuapl.edu (Eric Knox)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Socket state detection


In attempting some dynamic socket recovery code, I have run across a
BIG problem. (OK, so maybe it's not THAT big, but...) At the moment,
I am testing from a Sun (Sparc station 2) server to a microprocessor (68040)
client. I have some signal catchers on the sun to shutdown() and close()
the connection, delay a specified number of seconds (or microseconds),
and then attempt an accept(). (Note that this particular code does not
have to be graceful enough to call select() on the accepting side,
this was just to test the microprocessor's recovery.)

Just recently, I ported the client side to the Sun as well. The same
thing is happening.

Description of the server side:

	I create a server socket with socket(), bind(), and listen().
	I use the returned file descriptor to accept() from. This way
	I do not have to create a new server every time, rather I can
	accept on the returned file descriptor multiple times.

Description of the client side:

	I create a client with socket() and then connect().
	The full process is repeated every time I bring up a client.


When the server goes down, I detect it on the client side, call
shutdown(), close(), and then I create another client. During that
client's connect(), it returns right away, NOT when the server side
has accepted. It appears that connect() returns with an OK status
when it registers in the server side's listen queue, not when the
server side has accepted and an actual connection is made. My problem is
detecting (from the client side) whether or not the server side has
accepted.

I know this to be the case because I have prints before and after
the server's accept(). The client reports it it connected before
the server prints any messages (before or after accept()).

The strange thing is, when a client that has connected writes before
the server accepts, the data is written and the server can eventually
read once it accepts. This just didn't seem right to me.

Has anyone else run into this? Does anyone out there know how to
detect when an actual socket is set up rather than a client being
connected to a non-accepted socket?

If anyone is interested, I have a couple other little things that
I came across while testing this (namely the fact that 8 clients
can connect() successfully before 1 server ever calls accept())
that I would be glad to share or hear ideas on.


Thanks for your time,
Eric G. Knox
knox@aplexus.jhuapl.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 14:21:22 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: RFCs and MUST provide?

In article <1992Jun15.180110.10338@rchland.ibm.com> hofer@rchland.vnet.ibm.com (Kent Hofer) writes:

    ... are there ANY internet APIs out there that actually have functions
    to set/retrieve all the stuff that the RFCs say they MUST be able to
    set/retrieve?   

None of the 4bsd sockets-like APIs do so.  Our "native" API for PC/TCP for
DOS allows you to specify TOS and Precedence, but you can't associate IP
Options with a TCP connection.

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

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 92 14:38:07 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

baos@caip.rutgers.edu (Bancroft Scott) writes:
> Switching to the new encoding rules will be trivial if your application uses
> an ASN.1 compiler or some other approach which totally hides from view the
> nature of the actual encodings

This isn't the only cost, however.  You then have to generate a new
version of the product, QA it, send out update notices (if you don't
decide to send it free to all your customers), package it up, update
the docs (if only describing differences in what the stuff will interoperate
with), ship it out, etc.

The only place that product updates are "free" is in software you get via FTP.


Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"I do not feel obliged to believe that same God who endowed us with sense,
 reason, and intellect had intended for us to forgo their use."  --Galileo

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 15:38:07 GMT
From:      db3l@ans.net (David Bolen)
To:        comp.protocols.tcp-ip
Subject:   RTT computation for SLIP links

Pardon me if this has been discussed recently in this group - I don't normally
follow it.  I'm writing a SLIP driver for a TCP/IP kernel that is based on
Berkeley code, and am noticing some problems with performance, and the
retransmission of data during FTP transfers.

By tracing through the kernel and my driver, I think I've determined the
problem to be the computation of rtt for the TCP control block that
represents the FTP data channel.

What I see happening is that after establishing a default rtt value for the
new TCP control block, the server and client TCP perform the three-way
handshake to establish sequence numbers.  When the FTP server machine
receives the SYN acknowledgement, it uses the rtt computed during the
handshake to set up the retransmit timer for the connection.  The problem
is that the subsequent FTP data packets are much larger than the original
handshake packets (1006 bytes vs. ~40 bytes), and therefore the rtt that
was computed from the handshake is too low.  It normally takes a timeout
or two for this to adjust properly.

To compound this, internally, the SLIP output routine has a queue of 50
elements holding segments waiting to be transmitted.  So by the time the
retransmission timeout occurs, and the TCP kernel resets snd.nxt to be
snd.una, there are a large number of packets still waiting in the SLIP
output queue for the serial driver to transmit them.

My end result is that I get terrible performance mostly because I am
retransmitting much of the information.  For small transmissions this
additional retransmit occurs largely "behind the covers" following the
actual data transmission, but it still occupies my SLIP driver and TCP/IP
kernel to discard the duplicates.  For larger transmissions, the resent
packets start interleaving themselves with the actual data, and result
in terrible transfer rates.

I have found that if I simply take out the initial rtt computation based
on the handshake round trip time, that I solve most of these problems.  In
this case, the rtt computation is adjusted from its defaults based on the
transfer time of the first data packet, which is much more representable
of the data stream.  To me this seems to plausible as the general case,
with the sole disadvantage being that if the first packet gets lost, the
default timeout may be too large and waste some time before retransmitting.

The problem with this is that it's hacking the TCP kernel to support a
particular interface which I consider pretty ugly.  Since I'm sure a lot
of TCP/IP implementations are Berkeley based and support SLIP - is this a
general problem?  

Has anyone else who has done a SLIP driver run into any similar problems?
I have more control over my driver than I do the kernel, so if there's a
way I might fix the problem at that level, I'd probably prefer it.

Any help would be appreciated.  Since I don't always follow this group, it
would helpful if any responses could be sent via e-mail to db3l@ans.net.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 16:21:25 GMT
From:      newlin@hardy.u.washington.edu (Jay Newlin)
To:        comp.protocols.tcp-ip
Subject:   How to find subnet address?

In a subnetted tcp-ip environment, how would one find the subnet that
a particular node belongs to, assuming that a station is not going to
RARP for its own IP address?  The situation is that a particular 
workstation may be moved from one subnet to another, and I want to 
confirm the subnet that the station belongs to, so that its configuration
files can be updated.  The station is used for testing purposes, so
it always uses 101 as its host IP address.


-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 16:28:44 GMT
From:      SYSNET@engvax.picker.com (Leonard A. Visconti)
To:        comp.protocols.tcp-ip
Subject:   SNMP

I am looking to purchase SNMP management software and am looking for advice.
The last time I began reseaching the market was perhaps 1.5 - 2 years ago 
and at that time the most attractive (but very costly) product was made by 
Cabletron. So far I have revisted Cabletron's Spectrum (still costly), the
offering from Synoptics and am scheduled to meet with AT&T to look at their
latest product. I would really appreciate any advice, help anyone might
offer on this subject. Thank you.

-------------------------------------------------------------------------------
|  Leonard A. Visconti 			Picker International                  |
|  Network Analyst			595 Miner Road			      |
|  visconti@picker.com			Highland Heights, Ohio  44143         |
|					(216)473-4801                         |
-------------------------------------------------------------------------------

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 19:18:50 GMT
From:      thsssxs@iitmax.iit.edu (Semir Sirazi)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   Open SNMP NMS platforms





	To all, 


	We are currently developing a network device that will have SNMP 
management capabilities. We want to develop a management console that fully
configures, manages, etc. the network device, at a very high as well as
detailed level, and will show the current status of the network device, all 
within a glitzy graphical user-interface. (Including detailed bitmaps of the
device and along with its current status.)
	What we are looking for is an open, extensible, SNMP based Network 
Management Software platform that will allow us to create a customized device 
manager. We would like to be able to ship this "device manager" without the full
blown network manager so that we can keep the cost down. However we would like 
the device manager to be part of a Network Management platform, so that if the 
customer needs network management as well as management over our network device,
there would be an integrated solution available. 
	One of the biggest factors for making a decision is the cost, we are 
not interested in getting involved in network management, we are just trying
to provide management capabilities to our products based on industry standards.
To this end, we have been looking at vendors whose products run on a variety of
platforms, such as SCO/PC as well as SunOs/Sparc. This provides a low and high-
end solution.
	So what am I getting at here? I was wondering if anybody has any
positive or negative experience doing this, and what platform did you use? We 
are currently looking at:

Digital Analysis Corp	OS/EYE*NODE
Hewlett-Packard		OpenView-Windows 3.0 product  (Sparc version too $$)
Netlabs Inc.		Dual Manager
SunConnect		SunNet Manager

	If you know of any other platforms that are out there where the emphasis
is on providing NMS for non-specific vendor's hardware, please let me know.


		Thank you for your time,

				Keith Zimmerman.

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 19:37:48 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

amanda@visix.com (Amanda Walker) writes:

>The only place that product updates are "free" is in software you get via FTP.

	It's more likely (judging from my experience) that ISVs will just
take a look at all the product upgrade options, and drop support for the
one that's making them the least money. If qualifying a product for a
set of changing technologies gets too expensive, you just stop supporting
platforms.
	This actually helps the computer industry as a whole, IMHO, since
it plays the evolutionary role of weeding out bad standards and systems
that are hard to port to and support. (except, of course, for *government*
bad standards and systems that are hard to support - like ADA and so on,
all of which would have died a quick quiet death without the multimillion
dollar club of DOD)

mjr.
-- 
	Software should never, ever, ever be capable of reducing an adult
to tears.					-notebooks of a heretic

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 20:07:15 GMT
From:      oleg@watson.ibm.com (Oleg Vishnepolsky)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Socket state detection

In  <knox.708700741@aplexus.jhuapl.edu>  knox@aplexus.jhuapl.edu (Eric Knox) writes:
>....
>
> When the server goes down, I detect it on the client side, call
> shutdown(), close(), and then I create another client. During that
> client's connect(), it returns right away, NOT when the server side
> has accepted. It appears that connect() returns with an OK status
> when it registers in the server side's listen queue, not when the
> server side has accepted and an actual connection is made. My problem is
> detecting (from the client side) whether or not the server side has
> accepted.
>
> I know this to be the case because I have prints before and after
> the server's accept(). The client reports it it connected before
> the server prints any messages (before or after accept()).

connect() returns as soon as listen() is executed (provided there is
a room in the listen queue). This is the way sockets behave on all
4.3 derived systems.

>
> The strange thing is, when a client that has connected writes before
> the server accepts, the data is written and the server can eventually
> read once it accepts. This just didn't seem right to me.

The data is queued on the other side in a recv buffer (which is limited
by the tcp window) - the write call that exceeds the window would block.
It seems right to me... This gives you an advantage of doing connect,
and sending first chunk of data without waiting for the other side to do
the accept().

>
> Has anyone else run into this? Does anyone out there know how to
> detect when an actual socket is set up rather than a client being
> connected to a non-accepted socket?

You can't detect this without application level ack - for example,
after connect() returns, you can block yourself on read or select, and
the server side after accepting the connection with accept() could
send some kind of initial message over the connection.

Oleg Vishnepolsky

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 20:21:18 GMT
From:      jlang@nic.cerf.net (Jimmy Lang)
To:        comp.protocols.tcp-ip
Subject:   KA9Q NOS dial script

Has anyone written the proper dial scripts for use with the KA9Q NOS?
I am using it to run SLIP and the raise/lower up/down scripts I had
for the previous version of KA9Q no longer work.  The version I am using
right now is NOS version 920528 (ftp'd from ucsd.edu)

Any help would be appreciated.

-Jimmy
jlang@cerf.net
-- 
-Jimmy
jlang@cerf.net

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 20:26:31 GMT
From:      davidf@spider.co.uk (David Fraser)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

Peter da Silva wrote:
>X.500 is nice. FTAM is nice. VT is nice. But how in the hell do I figure
>out what the NSAP is for an existing network with no OSI-specific
>documentation?

Has no-one had a go at answering this yet? Oh well. I'll bite.
The authorities which allocate NSAPs work hierarchically (a bit like
authorisation of Domain Name Server addresses in the TCP/IP world, I
suppose). In general, the national standards bodies are the authorities
near the top of the tree, so that wouldn't be a bad place to start 
(ANSI or GSA in the U.S.).

I could muddle on further, but why bother when there's a well written,
understandable document on the subject. Unfortunately, I'm not referring
to an ISO document - I don't know if there is one - I refer to a
certain RFC 1237 

        "Guidelines for OSI NSAP Allocation in the Internet".

I consider it a worthwhile read for anyone trying to get a handle on
NSAP addressing, regardless of whether they intend connecting to the
Internet. It was based on (amongst other things) the _draft_ version
of ISO 10589 (IS-IS) so it may have been superceeded. 

It also provides a gentle introduction to OSI routing for those interested.

Hope this helps,

David

-- 
David Fraser, Spider Software,        |       e-mail: davidf@spider.co.uk 
Spider Park, Stanwell Street,         |       abuse:  +44 31 555 5166 ext 4346
Edinburgh EH6 5NG, Scotland.       /\oo/\ "Life is uncertain, eat dessert first"

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 20:42:55 GMT
From:      davidf@spider.co.uk (David Fraser)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

I wrote:
>
>I could muddle on further, but why bother when there's a well written,
>understandable document on the subject. Unfortunately, I'm not referring
>to an ISO document - I don't know if there is one - I refer to a
>certain RFC 1237 
>
>        "Guidelines for OSI NSAP Allocation in the Internet".

Actually, there is an ISO document called ISO 8348 Addendum 2 "Network
layer addressing". But it isn't really user friendly, being theoretical
and not a practical plebs guide to allocating an NSAP. 
A _must_ for insomniacs everywhere!

David

-- 
David Fraser, Spider Software,        |       e-mail: davidf@spider.co.uk 
Spider Park, Stanwell Street,         |       abuse:  +44 31 555 5166 ext 4346
Edinburgh EH6 5NG, Scotland.       /\oo/\ "Life is uncertain, eat dessert first"

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 21:31:43 GMT
From:      rschneid@epson.com (Richard Schneider)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <BpwBoK.ML9@watserv1.waterloo.edu> eengelke@sail.uwaterloo.ca (Erick Engelke) writes:
>adnan@odin.icd.ab.com (Adnan C. Yaqub) writes:
>>
>>Ron wrote:Does any one have any info on reliably delivered UDP. 
>>
>>Dave replied: Yes, it's called "TCP".  And you probably already have it.
>>
>But if Mr. Feign wishes to write his program today and wishes to do it
>with (as he suggested) the minimal amount of effort and money, he can
>do it today with tcp, there's a better chance that he already has it.
>
>Erick

No one seems to look at a protocol that has been around for quite a
long time. Several years ago I need to implement a reliable data 
transfer mechanism on UDP. I used TFTP to provide this mechanism.
It was very easy to put together and did provide a reliable 
mechanism to transfer packets from one location to another.

Also TFTP seems to have a better thru put than its alter-ego (FTP).
Thats because the baggage is not there as it would be for TCP.

Many people use TFTP to implement the remote boot function because
it is fairly simple and small.

************Epson Research Center**********
Richard Schneider	    2250 Agnew Road
rschneid@epson.com    Santa Clara, CA 95054
408 986-0115 x 3322
-- 
************Epson Research Center**********
Richard Schneider	    2250 Agnew Road
rschneid@epson.com    Santa Clara, CA 95054
408 986-0115 x 3322

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 21:47:27 GMT
From:      brunner@adobe.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Crashing UNIX (wasRe: Explanation of loose source routing?)

In article <1992Jun11.110737.14603@stc.nato.int> koelman@stc.nato.int writes:
>>
   [excerpting part of an earlier posting on LSRR, described in rfc1122,
    "Requirements for Internet Hosts -- Communication Layers", see sections
    3.2.1.8 (c) Source Route Options, and
    3.3.5  Source Route Forwarding, also (C) IP Source Address, and more
    fully in the latest draft "Requirements for IP Routers" Philip Almquist,
    Editor, see section 5.2.4  Determining the Next Hop Address,
    which noted in passing that some hosts are less than gracefull when
    fed LSRR ip options (amongst otherthings), omitted.]

>I would appreciate receiving any info on which
>versions of UNIX on which machines can be crashed by 
>sending them certain TCP/IP features/options...
>
>--
>Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
>SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
>The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

Ton,

I'll tell you what. You get SHAPE to pay for my holidays in Brussels
and I'll be happy to drop off the sources for my router requirements
exercise code. This is overcharging, since this is nothing but ping
with damage or features, but I have no objection to NATO spending its
money on my junketing (a complex US English term relating to mindless
travel on "official business") off to Brussels and the Hague (by way
of Brugges), or to your visiting Califonia.

Wether you sell this to SHAPE management as "security" (the dreaded
denial of service attack by pointy xmass trees (but did you know there
are even more interesting things to do with source routing than just
crash hosts?)), or as check-list pre-purchase option processing (pun
intended), or as "operational interoperability" is your concern, just
send me the tickets!

-- 
#include <std/disclaimer.h>
Eric Brunner, consulting at and not speaking for Adobe
uucp: uunet!practic!brunner or uunet!adobe!brunner
trying to understand multiprocessing is like having bees live inside your head.

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 21:55:28 GMT
From:      fitz@wang.com (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

HANK@BARILVM.BITNET (Hank Nussbacher) writes:

> Someone asked "Is there anything good in OSI?"  The answer is X500.
> Other than that I can't think of one.

ANS.1 is a pretty good scheme, too.

The Internet protocols will still probably live longer than the OSI stack,
for one critical reason: it's much easier for the Internet suite to absorb
the best parts of OSI than for OSI to absorb the best parts of the Internet
suite.  After a period of mutual cannibalism, there won't be anything
worthwhile in OSI that isn't also represented in the Internet suites.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 22:25:16 GMT
From:      grpjl@iastate.edu (Paul J Lustgraaf)
To:        comp.protocols.tcp-ip
Subject:   Re: How to find subnet address?

In article <1992Jun16.162125.11323@u.washington.edu> newlin@hardy.u.washington.edu (Jay Newlin) writes:
>In a subnetted tcp-ip environment, how would one find the subnet that
>a particular node belongs to, assuming that a station is not going to
>RARP for its own IP address?  The situation is that a particular 
>workstation may be moved from one subnet to another, and I want to 
>confirm the subnet that the station belongs to, so that its configuration
>files can be updated.  The station is used for testing purposes, so
>it always uses 101 as its host IP address.
>
In a somewhat similar situation, we make our stations listen for RIP
broadcasts (assuming you use them).  The source address is always the
local router.  Just strip away the host bits and you have your subnet.

-- 
Paul Lustgraaf                "Its easier to apologize than to get permission."
Network Specialist                                        Grace Hopper
Iowa State University Computation Center                      grpjl@iastate.edu
Ames, IA  50011                                                    515-294-0324

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 92 22:51:27 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

WL> == Warner Losh <imp@solbourne.com> 

 WL> For better or worse, many people judge X.400 harshly because the
 WL> addressing scheme is too byzantine.  They think, rightly or
 WL> wrongly, that if they have to make my mailing address look like
 WL> some mutant DCL or JCL command, then they don't want to have
 WL> anything to do with it.

If I need to get bigger business cards just to put my email address on
them, it's a lose.  (If I can't fit it on a standard button, it's a
*big* lose.)  If I need a directory service because I can't remember
email addresses people give me at USENIX, it's a lose.

One of the louder proponents of X.400 sent me email about something else
once, because he remembered that I had been interested in it, and *he
remembered my address*.  I responded "good thing my address wasn't
something like /C=US/ADMD=Internet/PRMD=Alternet/O=Electronic Frontier
Foundation/S=Davis/FN=Christopher/".  (And you might need the first
name; there could be another Davis on this system...or maybe there isn't
one *now*, but would be when you finished typing the address. :)

I mean, really, X.400 addresses *are* too byzantine.  Why does it matter
what country I'm in, or what Internet provider we're currently
purchasing from?  And what if we get service from more than one, or
switch?  Time to change our PRMD?  Gack!

I once did JCL, in a previous life, to pay the rent.  X.400 makes JCL
look straightforward.  (I guess the equivalent of nobody@machine in
X.400 would have to be /PGM=IEHBR14 ;-)
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
    Samizdata isn't that different from Samizdat.  -- Dan'l Danehy-Oakes

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jun 1992 23:30:58 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

>I responded "good thing my address wasn't
>something like /C=US/ADMD=Internet/PRMD=Alternet/O=Electronic Frontier
>Foundation/S=Davis/FN=Christopher/".
>I mean, really, X.400 addresses *are* too byzantine.

	It's another one of those overcomplex standards by committee
that will hopefully go away when everyone keeps ignoring it.

	Here's a prediction:

	X.[45]00 will prove its utility by allowing some individuals to
locate others, without having their internet-style email addresses. The
first time that the mail reaches the individual, they'll "Re"ply to it
using a normal internet-style email address and never use the X.[45]00
format again, until someone else tries to reach them.

	Inside DEC we have a message routing system that will let people
mail to firstname.lastname@sitecode - this actually is somewhat useful,
since it lets people who don't know how to use email reach me the first
time - after that, I reply directly to their account.

	Of course, none of this functionality has a legitimate use
inside a mailer - just stick it in a "whois" type database and leave
my mailer alone. Thank you.

mjr. Who has many addresses, including:
	mjr@dco.dec.com		<- to my workstation
	mjr@ufp.enet.dec.com	<- via internal VMS mail (forwarded to UNIX)
	marcus.ranum@cop.mts.dec.com	<- via X.400 (forwarded to UNIX)
-- 
	Software should never, ever, ever be capable of reducing an adult
to tears.					-notebooks of a heretic

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 00:16:35 GMT
From:      mark@verdix.com (Mark Lundquist)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Socket state detection

In article <knox.708700741@aplexus.jhuapl.edu> knox@aplexus.jhuapl.edu (Eric Knox) writes:
>
>In attempting some dynamic socket recovery code, I have run across a
>BIG problem. (OK, so maybe it's not THAT big, but...) At the moment,
>I am testing from a Sun (Sparc station 2) server to a microprocessor (68040)
>client. I have some signal catchers on the sun to shutdown() and close()
>the connection, delay a specified number of seconds (or microseconds),
>and then attempt an accept(). (Note that this particular code does not
>have to be graceful enough to call select() on the accepting side,
>this was just to test the microprocessor's recovery.)
>
>Just recently, I ported the client side to the Sun as well. The same
>thing is happening.
>
>Description of the server side:
>
>	I create a server socket with socket(), bind(), and listen().
>	I use the returned file descriptor to accept() from. This way
>	I do not have to create a new server every time, rather I can
>	accept on the returned file descriptor multiple times.
>
>Description of the client side:
>
>	I create a client with socket() and then connect().
>	The full process is repeated every time I bring up a client.
>
>
>When the server goes down, I detect it on the client side, call
>shutdown(), close(), and then I create another client. During that
>client's connect(), it returns right away, NOT when the server side
>has accepted.

Yes, that's the way it works.  connect() returns when a connection has
been established, not when and if the application program on the other side
does an accept().

>It appears that connect() returns with an OK status
>when it registers in the server side's listen queue, not when the
>server side has accepted and an actual connection is made.

But an actual connection *has* been made.  That's how connect() knows
to return.  The listen queue doesn't keep track of connection requests,
it keeps track of connections that have been established and are waiting
to be given to the application program.  Or another way of looking at
it: accept() doesn't mean "All right, now go ahead and respond to a
connection request."  That is actually what listen() means.  accept() means
"Give me a handle for the next completed connection waiting in the
queue; if there isn't a connection waiting, go to sleep until there is."

>My problem is
>detecting (from the client side) whether or not the server side has
>accepted.

TCP on the server side has accepted the connection request.  You can't
tell whether anyone has done an accept(), because there's nothing in the
protocol that corresponds to that.

>The strange thing is, when a client that has connected writes before
>the server accepts, the data is written and the server can eventually
>read once it accepts. This just didn't seem right to me.
>

Not strange at all.  A connection has been established, you want to
send some data on it, so why shouldn't you be able to?  The program on
the other side will eventually use accept() to ask for a handle to the
next established connection, but when he does it is his own business,
right?

>Has anyone else run into this? Does anyone out there know how to
>detect when an actual socket is set up rather than a client being
>connected to a non-accepted socket?

Actually, the socket has already been set up at this point.  The
server program has just not gotten around to asking for a handle
to the socket.

The handshaking that TCP does for connection establishment is
concerned with setting up a virtual circuit so that data can be
exchanged.  Nothing beyond that.  It sounds like you are wanting TCP
to do some additional handshaking for you.  It doesn't, and so you
will have to do that yourself, by designing a little protocol that
incorporates the semantics you want.  You already have a protocol
layered on top of TCP, whether you know it or not, and it's defined by
the things you send and receive once your connection is set up.  You
just need to expand it to do this thing you have been expecting TCP to
do.  For instance, after the server does an accept(), you send a
little something over your socket that tells the other guy "OK, I've
done my accept()."  Meanwhile, after the client's connect returns, have
it wait to read that little something, perhaps timing out after some
interval if it doesn't get it, if that's what you want.

>If anyone is interested, I have a couple other little things that
>I came across while testing this (namely the fact that 8 clients
>can connect() successfully before 1 server ever calls accept())
>that I would be glad to share or hear ideas on.

That's right.  They can send data, too, until the peer socket's
receive buffer fills up from nobody snarfing data out of it.
You specify the listen queue depth with the listen() service.  8 is
the maximum depth.

I think the names for the socket services probably confuse a lot of
people.  I know it took me a long time to figure out what the they were
really supposed to do.  TCP "accepting" a connection and a program
doing an accept() call aren't causally related, in fact they are not
logically related at all.  The only thing coupling accept() to the
protocol is that it can't *return* until TCP has "accepted" a
connection.  This is pretty logical.  Just not very well named! :-)

Maybe in light of this you will decide that the client doesn't really
need to know whether or not the server has done an accept() after
all -- I wouldn't know for sure without knowing more about your
application, but I would suspect it.  You mentioned something about
delaying for some period of time after shutting down a connection, and
then doing another accept().  Why the delay?  You don't have to be
concerned with giving the other side a chance to do it's connect().
What's wrong with accept()ing right away?  When the client gets around
to connect()ing, then you will wake up and go from there.

Regards,
-- Mark

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 01:45:15 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun16.233058.16483@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
> 
> 	X.[45]00 will prove its utility by allowing some individuals to
> locate others, without having their internet-style email addresses. The
> first time that the mail reaches the individual, they'll "Re"ply to it
> using a normal internet-style email address and never use the X.[45]00
> format again, until someone else tries to reach them.

PLEASE. Don't lump X.500 with X.400. It's X.500 that allows people to locate
others on a global scale from a very assorted dataset. And X.500 IS widely
implemented around the world. It is not just for finding X.400 addresses. It's
for what ever information people choose toput into it. (That includes Internet
addresses.)

There is no commonality between X.500 and X.400 to speak of. It's just that you
will need X.500 to use X.400. But X.500 can stand on it's own. While X.500 has
some pretty strange things in it, they are all hidden from the user. If you
want to fine John White at Lawrence livermore National Laboratory and get his
phone #, X.500 will do fine. With a good frontend, the user can just enter the
information he has that fits the available schema (things like name country and
organization are pretty universal) and X.500 does the rest.

Personally, I don't hold much hope for X.400, but I suspect X.500 will soon be
nearly universal on the Intenet. Something has to replace DNS one of these days
and X.500 looks like a reasonable candidate.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman1@llnl.gov		(510) 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.

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 01:53:49 GMT
From:      js@gaaj.uottawa.ca (Jean-Serge Gagnon)
To:        comp.protocols.snmp,comp.protocols.tcp-ip
Subject:   What is SNMP?

Hi,
	Sorry for my ignorance, but what is SNMP? I'm sure this would be
a FAQ, so could some kind soul direct me to the FAQ? Thanks.

P.S. Where's the best place to get RFC? I'm trying to learn about SMTP,
NNTP, FTP, TCP, etc..

Thanks again.

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 03:07:14 GMT
From:      sabina@wotan.cns.nyu.edu (S. Sabina Wolfson)
To:        comp.protocols.tcp-ip
Subject:   Looking for basic TCP/IP info

Hello!

I have read a couple of "intro to TCP/IP" articles and am looking for
articles and/or books that would explain more about TCP/IP at the
beginner level (i.e., *not* rfcs (unless there are some comprehensible-
to-a-beginner ones that I overlooked)).

Please e-mail any suggestions to sabina@xp.psych.nyu.edu since I don't
think anyone else reading this newsgroup needs to read about the basics
of TCP/IP ;)

Thanks in advance,
Sabina

p.s. Sorry if there is a FAQ for this group that would answer this 
question, but I couldn't find a FAQ at the archive site I looked at.



-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 07:47:20 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip,comp.unix.sysv386
Subject:   Re: RFCs and MUST provide?

In article <920616102122@cream.ftp.com> jbvb@ftp.com writes:
>In article <1992Jun15.180110.10338@rchland.ibm.com> hofer@rchland.vnet.ibm.com (Kent Hofer) writes:
>
>    ... are there ANY internet APIs out there that actually have functions
>    to set/retrieve all the stuff that the RFCs say they MUST be able to
>    set/retrieve?   
>
>None of the 4bsd sockets-like APIs do so.  Our "native" API for PC/TCP for
>DOS allows you to specify TOS and Precedence, but you can't associate IP
>Options with a TCP connection.
>
>James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
>FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

Likewise, we use our own socket option to set TOS, TTL and IP options.
Does anyone know if and when sockets will be extended to set and get all 
the stuff in RFC1122?

ian


---
Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)
--

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 10:06:33 GMT
From:      shani@GENIUS.TAU.AC.IL (Oren Shani)
To:        comp.protocols.tcp-ip,comp.unix.admin
Subject:   Looking for MIT SNMP toolkit or something like that


  Hello. 

I am looking for the MIT SNMP toolkit... I've only heard that there is
something like that, and I guess that it might be ftp'd from somewhere in
MIT.... Anyone can help with details?

Thanks in advance,

-- 
    __    __  Oren Shani (shani@genius.tau.ac.il) 
   /  /  /    Faculty of Engineering, Tel Aviv university
  /  /   --   Israel
 /__/ . __/ . "Hold your temper" -- The caterpillar to Alice

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 15:13:38
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: How to find subnet address?

In article <1992Jun16.222516.11350@news.iastate.edu> grpjl@iastate.edu (Paul J Lustgraaf) writes:

    In article <1992Jun16.162125.11323@u.washington.edu> newlin@hardy.u.washington.edu (Jay Newlin) writes:
    >In a subnetted tcp-ip environment, how would one find the subnet that
    >a particular node belongs to, assuming that a station is not going to
    >RARP for its own IP address?

ICMP Subnet Mask Request/Reply is obsolescent, since the mask doesn't
mean much without the address it goes with, and most implementations
are very prone to the kind of problems written up in the Host
Requirements RFC (1122).  In the general case, I'd use BOOTP and get
both the address & mask.  For a homebrew site-specific hack, you
could look at RWHO, or RIP, or whatever is broadcast on that link.

    In a somewhat similar situation, we make our stations listen for RIP
    broadcasts (assuming you use them).  The source address is always the
    local router.  Just strip away the host bits and you have your subnet.

The HRRFC advises that you not write host code that depends on routers
using RIP.  The Gateway Discovery ICMP message described in RFC 1256 is
preferred, although implementations aren't as widely available...

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


-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 12:08:28 GMT
From:      maurijn@prsb.pttnwb.nl (Maurijn van Tol)
To:        comp.protocols.tcp-ip
Subject:   Looking for proxy ftp ?

A friend of mine asked me to inquire about something called
proxy ftp or iftp. I'm not exactly sure about what he means
but any info (what where how etc) is greatly appreciated.

Reply by email or post.

Thanks a lot,
	maurijn


-- 
    ____________________  Maurijn Q. van Tol
   /       / __  /_   _/  E-mail : maurijn@xirion.nl maurijn@prsb.pttnwb.nl
  / // // / / / / / /	  #include <std/disclaimer.h>
 / // // / /_ \/ / /	  Learn from your mistakes is my only advice, and
/_//_//_/____\_\/_/	  stay cool is still the main rule. - Brian Ferry

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 12:26:14 GMT
From:      aep@icd.ab.com (Alexander E. Pensky)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <1992Jun16.213143.25517@epson.com>, 
rschneid@epson.com (Richard Schneider) writes:
> 
> No one seems to look at a protocol that has been around for quite a
> long time. Several years ago I need to implement a reliable data 
> transfer mechanism on UDP. I used TFTP to provide this mechanism.
> It was very easy to put together and did provide a reliable 
> mechanism to transfer packets from one location to another.
> 
> Also TFTP seems to have a better thru put than its alter-ego (FTP).
> Thats because the baggage is not there as it would be for TCP.
> 
> Many people use TFTP to implement the remote boot function because
> it is fairly simple and small.
 
TFTP is not a "reliable" data transfer mechanism.  TFTP simply aborts the
transfer if any error is detected.  This means that your file will be
transferred correctly, or it will not be transferred at all.  That's
the same service guarantee that UDP/IP gives you on individual datagrams.

"Reliable" data transfer implies that the transfer will eventually succeed
even if transient errors (e.g. lost packets) occur.

 -----------------------------------------------------------------------------
 Alex Pensky    	(aep@icd.ab.com)		         (216)646-5211
 Allen-Bradley Company             747 Alpha Drive, Highland Heights, OH 44143
 -----------------------------------------------------------------------------

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 12:29:08 GMT
From:      knox@aplexus.jhuapl.edu (Eric Knox)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Socket state detection

I understand now that I wanted TCP/IP to do a few things that I know are
easy enough to implement. I would like to thank those people who answered
my question. It looks like my communication scheme is just going to have to
be a little bit more robust about recognizing everyone else.

Just to clarify on the original post, my delay was just to see how many
clients could register in the listen queue (that is supposedly limited to
5, not 8 [Jan. 21, 1990 man page]), and not having alot to do with my acutal
application. I was just seeing what I could do.

I would also like to point out to anyone reading this far that listen() sets
up a STACK (Last in First out), not a QUEUE (First in First out). I don't know
if that makes alot of difference to anyone, but it's just another thing I found
out.

Thanks,
Eric Knox

knox@aplexus.jhuapl.edu

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 92 13:42:27 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   OSI vs TCP/IP information & opinions requested

In article <bpykwj.lg5@wang.com> fitz@wang.com writes:

   The Internet protocols will still probably live longer than the OSI stack,
   for one critical reason: it's much easier for the Internet suite to absorb
   the best parts of OSI than for OSI to absorb the best parts of the Internet
   suite.  After a period of mutual cannibalism, there won't be anything
   worthwhile in OSI that isn't also represented in the Internet suites.

As I expounded on a subway station during the DC Interop to all who
would listen, "Just as we'll still be running FORTRAN 1998 in the
year 2000 (and it will bear almost no resemblence to the original
FORTRAN), we'll still be running TCP/IP in the year 2000...".

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice
Potsdam, NY 13676          315-268-9201 FAX

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 14:12:28 GMT
From:      pista@aszi.sztaki.hu (Tetenyi Istvan)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: SLIP over X.25?

In article <l39djoINNql8@alhena.usc.edu> ajayshah@alhena.usc.edu (Ajay Shah) writes:
>Xref: sztaki comp.protocols.tcp-ip:1292 comp.protocols.tcp-ip.ibmpc:11601
>Path: sztaki!mcsun!uunet!think.com!zaphod.mps.ohio-state.edu!usc!news
>From: ajayshah@alhena.usc.edu (Ajay Shah)
>Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
>Subject: SLIP over X.25?
>Date: 9 Jun 1992 06:47:36 -0700
>Organization: University of Southern California, Los Angeles, CA
>Lines: 22
>Sender: ajayshah@alhena.usc.edu (Ajay Shah)
>Distribution: world
>Message-ID: <l39djoINNql8@alhena.usc.edu>
>NNTP-Posting-Host: alhena.usc.edu


>I am posting this for a friend who does not have net.access.
 
>---
>Hi,
 
>I wonder if anyone is aware of any implementation of SLIP over X.25 - either
>public domain or commercial is fine. Let me describe the problem that I am
>trying to address -- maybe someone has suggestions on how to tackle it.
 
>We have an application running over a network of Sun machines and PCs 
>(some of which run SCO Unix and some MS-DOS). Basically, we need to be
>able to print to a printer attached to a PC from anywhere in the network. 
>In other words, we need lpd functionality on a PC. With TCP/IP over Ethernet
>things are fine. But we plan to migrate this to a WAN which is an X.25
>network. In the long term, IP routers will be used, but I need a quick and
>dirty solution now. Any suggestions? Will SLIP help at all?
 
>Thanks,
>-- 
 
>Ajay Shah, (213)749-8133, ajayshah@usc.edu


I have done this thing before. A BOX with a PAD port will be enough. You 
need really transparent data transfer on both ends. We use it in Hungary. It 
is fine and works.

Kind regards,
  Istvan Tetenyi

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 14:54:49 GMT
From:      casper@fwi.uva.nl (Casper H.S. Dik)
To:        comp.protocols.tcp-ip
Subject:   Re: How does portmapper allocate RPC ports?

lah@unh.edu (Lance Hartford) writes:

>I am using a network general Sniffer to analyze RPC packets on our
>network. I noticed that ports for certain RPC services such as mount
>are dynamic. A pormap request will be sent to the server, asking for
>the port number of mount, then the client will communicate through
>that port. But since the port number for mount can change, how does
>the sniffer know that a packet going to port x is an RPC packet? My
>guess is that there is a range of port numbers assigned for RPC
>programs. Otherwise the sniffer would have to keep state information
>on which ports are mapped to which services. That would get pretty
>messy.

I don't think that the network sniffer keeps state. It will simply
look at each packet and determine whether it's likely to be an RPC
packet or not.

An UDP/RPC call packet consists of  

	4bytes	xid;
	4bytes	msgtype;
	4bytes	rpcvers;
	4bytes  prog, vers, proc;

The xid is random, but msgtype is 0 (CALL), rpcvers is 2.

This is probably what etherfind(8C) does on suns.

halo% rpcinfo -n 10000 -u adam 2749274294792 63864264234

results in:
UDP from halo.fwi.uva.nl.1284 to adam.fwi.uva.nl.10000  48 bytes
 RPC Call prog 495225352 proc 0 V-560245206 [2a3cd841]

Not even sanity checking on prog/vers is attempted.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 15:10:14 GMT
From:      lah@unh.edu (Lance Hartford)
To:        comp.protocols.tcp-ip
Subject:   How does portmapper allocate RPC ports?

I am using a network general Sniffer to analyze RPC packets on our
network. I noticed that ports for certain RPC services such as mount
are dynamic. A pormap request will be sent to the server, asking for
the port number of mount, then the client will communicate through
that port. But since the port number for mount can change, how does
the sniffer know that a packet going to port x is an RPC packet? My
guess is that there is a range of port numbers assigned for RPC
programs. Otherwise the sniffer would have to keep state information
on which ports are mapped to which services. That would get pretty
messy.

Lance
--
________________________________________________________________________
| Lance A. Hartford             | Computer Science Junior              |
| RCC InterOperability Lab      | Internet: lah@unh.edu                |
| University of New Hampshire   | 32 Coe Drive, Durham NH 03824        |
|----------------------------------------------------------------------|
| "Pointer redirection is a hard thing for human beings to understand" |
------------------------------------------------------------------------


-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 15:12:58 GMT
From:      Ulmo@MCIMail.Com (Brad Allen)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

" I find it unfortunate that he (and others of his calibre) can't [or]
" won't constructively contribute to the standards process to ensure
" that their concerns about OSI are addressed, rather than to make
" money detracting it.

I agree.  (Although, they're free to do as they wish.)

I have been an active user of the Internet since 1986, and saw that
while ARPAnet (now Internet) was great, there was definitely a lot of
room for greater yet (with the technology of that time), including
distributed object oriented & relational/equational networks, security
(guarantees of privacy) and monetary needs (billing).  I tried to
participate in ISO, and when I could not I at least tried to watch its
development.  What I could glean from everything I saw is that ISO
failed to fill the abovementioned role and indeed had many
deficiencies (because of committees composed of members wanting to
keep the establishment in power 1% own 99% status quo rather than
technical ingenuity), including the abhorrent idea that non-English
people aren't allowed proper representation in the network (rather
imperialistic I think).

However, let's move on.  Instead of dwelling in the horrible history,
let's look forward and watch where we're going, or else we'll be doing
just as badly as we were ten years ago with this ISO thing.  I agree
that it is time to keep the awful past in history and instead work to
make this unfortunate up-and-coming standard as good as we can get it
before it hits us hard.

Brad Allen <Ulmo@MCIMail.Com>
X.400: G=Brad; S=Allen; DDA:ID=3197242; A=MCI; C=US

P.S. Does anybody know of small X.400 providers?  (I'm trying to find
an alternative, just-in-case, to MCI; while MCI is OK, I really want
to put my $ elsewhere.)

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 92 15:57:03 GMT
From:      trier@slc6.INS.CWRU.Edu (Stephen C. Trier)
To:        comp.protocols.tcp-ip
Subject:   Re: How does portmapper allocate RPC ports?

In article <1992Jun17.145449.19924@fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>I don't think that the network sniffer keeps state. It will simply
>look at each packet and determine whether it's likely to be an RPC
>packet or not.

The Network General Sniffer does keep some state around.  For example,
when analyzing an AFP (AppleTalk Filing Protocol) connection, it will
recognize packets as AFP only if it saw the connection open in that
capture.  Otherwise, it recognizes them only as ASP (AppleTalk Session
Protocol).

I wouldn't be at all surprised if the Sniffer's RPC module behaved 
similarly.

-- 
Stephen Trier        Dumb users manual quote of the month:
CWRU IRIS/INS         "Numeric Value Comparisons: A larger value is
trier@ins.cwru.edu     considered 'greater' than a smaller one."
                          -- _Reference_, Oracle for Macintosh version 5.1

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 16:26:01 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   TCP for IBM E9000?


	I've been asked to be part of a committee evaluating TCP/IP
software for an IBM E9000.  It's not 100% clear I'm fully qualified to be
on that committee, considering I know next to nothing about IBM mainframes.
Be that as it may, the other people on the committee know very little about
TCP/IP, so I'm sort of the expert on the topic.

	Anyway, the 3 alternatives seem to be IBM's own product, and 2
products from third-party vendors, InterLink and OCS.  All three seem to
work with yet another third-party piece of software called ANET, which
attempts to make 3270-type terminals emulate "normal" ascii character mode
terminals.  The mainframe folks on the committee are leaning strongly
towards the IBM product.

	My question is, bluntly, does the IBM product work?  We took a road
trip to IBM's NY office but the demo we saw left me not terribly convinced.
They didn't have NFS installed, so couldn't demo that at all.  They showed
us that they could sit at a 3270 terminal and connect using telnet to a
Unix box, but never managed to demonstate to my satisfaction that it worked
(i.e. we never got vi working, and they didn't have emacs on site so we
couldn't try that).  I wanted to try and do something like use ftp to
upload a binary file (say a .Z file) from a macintosh to the IBM mainframe
and then download it to a PC or Unix box, but they couldn't demo that
either.

	Do all these things actually work like they should?  Are there any
surprises we should know about?  Does the IBM TCP/IP software deal
gracefully with other machines on the network being misconfigured?  This is
an important point in my mind since it's not uncommon for somebody to buy a
new box and put it on the net with the wrong broadcast address or something
like that.  I once had somebody with PC/NFS manage to set their IP address
to the same as one of our main fileservers.  What fun.  What would happen
to the IBM product if somebody duplicated its IP address?  We don't want to
see a million dollar mainframe come to a screeching halt just because
somebody on the other side of the campus misconfigured a $500 PC and
plugged it in.
-- 
roy@wombat.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 16:49:34 GMT
From:      jfjr@mbunix.mitre.org (Freedman)
To:        comp.protocols.tcp-ip
Subject:   NOS closing down telnet session


  I have a version of NOS ported to a Sun SPARC (please don't tell me
why this is a useless hack - I have my reasones ). I telnet to some
host with it - the syn goes out, a syn ack comes back and NOS sends out
a reset immediately, closeing the telnet session. I saw a question
about this problem a few months ago - regretably I didn't save the
answer. Can anybody help me?


                                       Jerry Freedman,Jr

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 17:13:10 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun16.193748.12768@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>except, of course, for *government*
>bad standards and systems that are hard to support - like ADA and so on,
>all of which would have died a quick quiet death without the multimillion
>dollar club of DOD)

I know of at least one ISV in the TCP/IP networking arena that has
poured boatloads of $$$ into supporting various interface devices so
that certain government contracts could be won.  The amount of money
that this ISV loses due to continued support of these intefaces
boggles the mind.

Warner
-- 
Warner Losh		imp@Solbourne.COM

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 1992 17:44:35 GMT
From:      khale@camilla.Eng.Sun.COM (Abhijit Khale)
To:        comp.protocols.tcp-ip
Subject:   Re: How does portmapper allocate RPC ports?

In article <LAH.92Jun17101014@escher.unh.edu> lah@unh.edu (Lance Hartford) writes:
>I am using a network general Sniffer to analyze RPC packets on our
>network. I noticed that ports for certain RPC services such as mount
>are dynamic. A pormap request will be sent to the server, asking for
>the port number of mount, then the client will communicate through
>that port. But since the port number for mount can change, how does
>the sniffer know that a packet going to port x is an RPC packet? My
>guess is that there is a range of port numbers assigned for RPC
>programs. 

Well, the portmapper doesnt really allocate ports. The server
binds to a port and registers the port with the portmapper/rpcbind
using pmap_set() or rpcb_set(). But there is no range of port numbers
assigned for RPC programs exclusively. 

You can make a good guess that a packet is RPC, though. 

The rpc header has the following format : 

struct rpc_msg {
	u_long			rm_xid; 
	enum msg_type		rm_direction; 
 /*  msg_type is either CALL (0) or REPLY (1) */
	union {
		struct call_body RM_cmb;
		struct reply_body RM_rmb;
	}
 ....
}

struct call_body {
	u_long cb_rpcvers;	/* must be equal to two */
..
}

struct reply_body {
	enum reply_stat rp_stat;
/* rp_stat is either MSG_ACCEPTED (0) or MSG_DENIED (1) */
..
}

So one method of checking for RPC is

1) If the direction field is CALL and the version field is 2, then
its RPC.

2) If the direction field is REPLY and the rp_stat field is either 
MSG_ACCEPTED or MSG_DENIED, then its RPC. 

[ Note that all these numbers are in XDR format] 

You can filter still further by throwing out packets going to/from
well known ports which are not RPC services. 

This will sometimes wrongly flag non-RPC packets as RPC, but should work
in most cases. 

>Otherwise the sniffer would have to keep state information
>on which ports are mapped to which services. That would get pretty
>messy.

Theres no real need to keep that state if the the method I described is
used. 

There is a need, though to keep state on the transactions ids so
RPC calls can be matched to RPC replies. Since the reply doesnt
have a field indicating what procedure is being replied to, the
packet snooper cant interpret the contents of the reply packet
unless it knows what the call was. The solution is to keep 
a small cache of the xids (transaction id)  to match requests with
replies and parse the replies. [This is how NFS packets could
be snooped, for instance]. Also, this cache enables the packet filter to
flag duplicates as well (same xid). I think the sniffer uses something
similar to this. 


Abhijit
Distributed Computing Technology Group. 


-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 17:50:36 GMT
From:      michaelg@Xenon.Stanford.EDU (Michael Greenwald)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

rschneid@epson.com (Richard Schneider) writes:

>Also TFTP seems to have a better thru put than its alter-ego (FTP).
>Thats because the baggage is not there as it would be for TCP.

I'm surprised at this statement.  It certainly hasn't been true in my
experience.

Assuming any reasonable roundtrip delay, TFTP performs far worse than
TCP.  It does 512 bytes per round trip delay, while (FTP layered over)
TCP can do on the order of a window size full (say 10K bytes) in the
same period of time.

I can't imagine the processing overhead of TCP making up for this
difference.

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 18:20:54 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <1992Jun17.122614.15898@icd.ab.com> aep@icd.ab.com (Alexander E. Pensky) writes:

    TFTP is not a "reliable" data transfer mechanism.  TFTP simply aborts the
    transfer if any error is detected....

This may be true of a particular TFTP implementation, but it isn't true of
the protocol as specified in RFC 783 (amended by RFC 1123).  TFTP (the
protocol, and as Larry Allen implemented it in his Unix client/server, and
as it was implemented for PCs in PC-IP) detects data errors via the UDP
checksum, and detects missing packets via timeouts and retransmits them.
The protocol *is* lockstep (I send, you ack, I send...), which severely
limits the throughput if you aren't on a single cable.

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

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 19:17:33 GMT
From:      dwight@hyphen.com (Dwight Ernest)
To:        comp.protocols.tcp-ip
Subject:   DNS setup problem: unreachable master for reverse zone from secondary

I've just set up a standalone DNS system to get some experience with
DNS setup, in anticipation of a possible connection to CIX.  The
environment is SunOS 4.1.2 and 4.1.1.  I've configured the primary and
the secondary masters in what I feel are pretty logical ways in spite
of the rather opaque documentation in Sun's Network and System
Administration Guide.

Resolution seems to occur properly when either the primary or the
secondary servers are specified as the name servers.  But:

- Updates on the primary database don't seem to be getting propagated
to the secondary server.

- At the expiration of each retry period specified in the SOA record,
the following message appears in the /var/adm/messages file:

	Jun 17 14:55:47 support named[626]: zoneref: \
	Masters for secondary zone 92.58.192.in-addr.arpa unreachable

(Our network number is 192.58.92.  I do have a reverse zone SOA
and its children records specified in its own file, pointed to by
named.boot.)

- Only the hosts file (forward zone list) is being copied from the
primary to the secondary machine.  The reverse file is missing.  This
is probably related to the error message above.

Can anyone assist in helping me to understand what I might be doing
wrong?  It must be something pretty simple, but I've reviewed my
installation several times and can't find it.
-- 
--Dwight A. Ernest		KA2CNN			I speak only for myself.
  Publishing System Communications and Networking Consultant
  dae@world.std.com		dwight@hyphen.com

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 92 19:33:22 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <michaelg.708803436@Xenon.Stanford.EDU>, michaelg@Xenon.Stanford.EDU (Michael Greenwald) writes:
|> rschneid@epson.com (Richard Schneider) writes:
|> 
|> >Also TFTP seems to have a better thru put than its alter-ego (FTP).
|> >Thats because the baggage is not there as it would be for TCP.
|> 
|> I'm surprised at this statement.  It certainly hasn't been true in my
|> experience.
|> 
|> Assuming any reasonable roundtrip delay, TFTP performs far worse than
|> TCP.  It does 512 bytes per round trip delay, while (FTP layered over)
|> TCP can do on the order of a window size full (say 10K bytes) in the
|> same period of time.
|> 
|> I can't imagine the processing overhead of TCP making up for this
|> difference.

I agree that FTP is usually faster than tftp for file transfers but,
tftp does have its advantages.  It is easy to implement in ROM (or
EPROM) for download situations.  That is why it is recommended that 
after a bootp is performed the actual download should use tftp.  It
also works well in a network with high error rates.  Again, this is
an advantage in downloading.  Let's face it.  Most of us would rather
that a device downloads a little slower but more reliably.

It was earlier stated that tftp
aborts if an error is detected.  This is not true.  RFC783 is where
tftp is defined and in the OVERVIEW it discusses the retransmission
scheme which is "borrowed" from TCP.  In fact since tftp is based on
UDP and because only one packet can be outstanding at a time, there 
is an argument to be made that tftp works more reliably on
networks with higher error rates than FTP.  Not as much data needs
to be retransmitted when an error is detected and thus it doesn't clog
the net as much.  If the reason for the error rate being high is because
an intermediate device such as a router is overflowing its queues,
large window sizes are a problem.


-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jun 1992 22:27:24 GMT
From:      peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   GAO report on ANSI?

Does anyone remember an unfavorable report that came out a couple of
months ago from the GAO on ANSI and the U.S. standards process in
general? I remember seeing something in the trade press about it
a while ago, but after spending quite some time sorting through old
Comm. Weeks and whatnot I haven't been able to find anything about it.

Does anyone have a reference that would put me on the right track? Or is
this a complete figment of my imagination :-(

                                Peter Desnoyers


-- 

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 92 05:41 PDT
From:      Charlie Rosenberg <crosenberg@igc.org>
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP over X.25?



Anyone have any experience running SLIP under SCO Xenix that would
have some advise to offer.

Charlie Rosenberg
crosenberg@igc.org


-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jun 1992 12:19:25 GMT
From:      hcb@world.std.com (Howard C Berkowitz)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: Identifying Service Users (was: OSI vs TCP/IP)

In article <1992Jun9.214251.5168@sctc.com> smith@sctc.com (Rick Smith) writes:
>art@acc.com (Art Berggreen) writes:
>
>>I often wonder what lays beyond both TCP/IP and ISO (but my crystal
>>ball is murky at its best).
>
>I'm beginning to suspect that both protocol stacks and their
>corresponding reference models will end up in the trash can in the
>next couple of decades...

I'm not overqualified to look at the authentication 
issue, but there are certainly a numberof issues in
the models generally.  Is anyone on this newsgroup actively
involved with the OSI Reference Model <architectural
review working group--whatever it's called> with John Day
et al?

ISO does have a time-triggered review group looking at
the basic OSIRM, ISO 7498.  I've heard third-hand that there
is a lot of rethinking of the application and presentation
layers--is, for example, presentation the place to do 
common services such as ACSE.  Network layer structure
is a neverending problem.

I wonder if they are looking at the fundamental layering,
especially at the lower layers where gigabit networking
is starting to make the 2/3/4 layering questionable, and
perhaps at the physical layer, where ISDN and B-ISDN
(with their inherent physical layer multiplexing) do not
quite fit the (IMHO) single-thread (or bit stream) model
of the physical layer.

Anyone care to comment?

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jun 1992 12:26:55 GMT
From:      koelman@cuby.stc.nl (Ton Koelman)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI packet addressing scheme

In article <DRW.92Jun11131511@jordan.mit.edu> drw@jordan.mit.edu (Dale R.  
Worley) writes:
> OK, I'm really naive here (I think of the Internet as "You throw an IP
> packet overboard and it (usually) swims to the destination host."),
> but I have heard suggestions that an OSI connectionless protocol could
> be used in place of IP as the bottom layer of the Internet protocols.
> This is proposed as a way to solve the 32-bit address problem that the
> Internet now has.  Would anybody like to post a discussion of what
> this connectionless protocol is like and what its addressing system
> is, or at least post a pointer to the information?
> 

Let's do this in comp.protocols.iso.
In fact I started it already.

the standards are:

ISO 8473, ISO 9542, ISO 10589, ISO 8348

TK

--
Ton Koelman   e-mail: koelman@stc.nato.int (NeXT Mail Welcome!)
SHAPE Technical Centre, P.O. Box 174, 2501 CD  The Hague
The Netherlands  (voice: 31-70-3142429, fax: 31-70-3142111)

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 92 13:19:28 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   was OSI vs TCP/IP - What are Standards For



(dons flameproof jacket)
lets get this straight - just what are standards for?

Pro: Standards can be used to write contracts, and specifications, so
that you can compare tenders/bids, and have recourse to law if someone
doesn't meet the spec. (viz GOSIP, emphasis on procurement)

Con: No-one sells software on this basis (yet) - see every disclaimer
(we await with baited breath the day a Car Manufacturer tried to sell
a car with a disclaimer - "This car is, of course, not necerssarily
fit for driving":-)


Pro: Standards can allow you to mix vendor equipment

Con: Rich vendors can vote standards to the point where they cost it
beyond anything but niche companies (viz CDs)


Pro: Standards are like patents, in that they force ideas out in the
open instead of creating trade secrets (but are unlike patents in that
they don't guarantee (albeit limited lifespan) monopolies)

Con: Companies like patents. They dont let good inventions into the
standards arena.

Now, where does TCP/IP fit in the pro/con spectrum, and where OSI?
methinks former and latter, respectively


From another perspective, ask yourself what useful things can we get from many
vendors, are not subject to international standards, interwork, and we
can find out how?o

Cars, Banking Services, Air Travel, and hats...

-----------
removes flame proof jacket and puts on sombrero...

cheers
jon

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 92 15:26:13 GMT
From:      roger@uiscpt.UUCP (Roger Milligan)
To:        comp.unix.i386,comp.protocols.tcp-ip
Subject:   LPD for SCO Unix / source

I am looking for lpd print spooler and lpr to support it
on SCO Unix.

Where can I get this (or the lpd source)?

-- 
Roger Milligan                                roger@uiscpt.aztec.co.za

Unix Information Systems (Pty) Ltd (UIS)      Tel +27 21 4194107
Cape Town, South Africa                       Fax +27 21 252828

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jun 1992 17:08:37 GMT
From:      aep@icd.ab.com (Alexander E. Pensky)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <920617142054@cream.ftp.com>, 
jbvb@vax.ftp.com (James B. VanBokkelen) writes:
>
> In article <1992Jun17.122614.15898@icd.ab.com> aep@icd.ab.com 
> (Alexander E. Pensky) writes:
> 
>     TFTP is not a "reliable" data transfer mechanism.  TFTP simply aborts the
>     transfer if any error is detected....
> 
> This may be true of a particular TFTP implementation, but it isn't true of
> the protocol as specified in RFC 783 (amended by RFC 1123).  TFTP (the
> protocol, and as Larry Allen implemented it in his Unix client/server, and
> as it was implemented for PCs in PC-IP) detects data errors via the UDP
> checksum, and detects missing packets via timeouts and retransmits them.
> The protocol *is* lockstep (I send, you ack, I send...), which severely
> limits the throughput if you aren't on a single cable.
> 

I thinks the RFCs are a little vague about this.  RFC 783 states that
a TFTP client or server "may" retransmit its last-transmitted datagram
after a receive timeout.  RFC 1123 amends this to state that a TFTP MUST
use an adaptive timeout.  However, RFC 1123 does not indicate whether
the backoff and retransmission must continue forever, or may be abandoned
after a maximum retry count is exceeded.  RFC 783 states in a couple of
places that a TFTP must detect receive timeouts and must use them to
abort a transfer, in case an error reply from the peer was lost.  RFC 783
does not specify any rule for deciding when a TFTP should retransmit and
when it should abort following a receive timeout.

Every implementation of TFTP I have used, or implemented, has interpreted
this to mean that the transfer is aborted after some number of successive
timeouts and retransmissions has occurred.

 -----------------------------------------------------------------------------
 Alex Pensky    	(aep@icd.ab.com)		         (216)646-5211
 Allen-Bradley Company             747 Alpha Drive, Highland Heights, OH 44143
 -----------------------------------------------------------------------------

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jun 1992 18:13:51 GMT
From:      joer@inca.law.csuohio.edu (Joe Rosenfeld)
To:        comp.protocols.tcp-ip,alt.cd-rom
Subject:   CD-ROM via tcp/ip options?

Hello, all:

I am beginning to look into CD-networking for an academic law School 
library.  We would like to provide connectivity via tcp/ip and NOT novell, 
unless both were possible.

Does anyone have any information on options?  I would appreciate anything 
you could provide.  I'd be happy to summarize.

Please respond by email to: joer@inca.law.csuohio.edu

thanks!

Joe Rosenfeld
joer@inca.law.csuohio.edu

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 00:07:10 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <1992Jun16.193748.12768@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
> 	This actually helps the computer industry as a whole, IMHO, since
> it plays the evolutionary role of weeding out bad standards and systems
> that are hard to port to and support.

I see. So DOS is better than Xenix-86?
-- 
Peter da Silva                                                      `-_-'
$ EDIT/TECO LOVE                                                     'U` 
Ferranti International Controls Corporation                    Have you hugged
Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 08:04:46 MDT
From:      jrd@cc.usu.edu
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Multi packet driver progs. at once with PC/TCP & Desqview/X

In article <thacker.11.708959848@cc1.unt.edu>, thacker@cc1.unt.edu (Mark D. Thacker x2568) writes:
> HELP!  I think I want to do the impossible.
> 
> I need the ability to run multiple Crynwr (Clarkson) packet driver based IP 
> programs at once.  These programs include Trumpet (news reader), CUTCP 
> Telnet and PC Gopher II.  No, I can not simply use some other news reader/
> telnet program.
> 
> I would like to be able to have Crynwr (Clarkson) packet driver programs 
> pass their IP calls up the protocol stack so that Ftp Software's PC/TCP 
> kernal can actually execute them.  In theory this would allow me to execute 
> muliple packet driver IP programs at once since the PC/TCP kernal allows 
> multiple IP sessions.
> 
> I really want to do all of this from Desqview/X, which supports either 
> Novell's LAN Workplace for DOS or PC/TCP.
> 
> Currently, with PC/TCP installed, NO packet driver based IP program works 
> since all IP calls are trapped by PC/TCP.
> 
> A college told me that there was a program which patched the packet drivers 
> to pass their IP calls up the protocol stack...does anyone know WHERE I can 
> find such a thing or WHAT its name might be?
> 
> If there are other solutions available, please let me know.  I can not give 
> up my packet drivers!!!  I do to much development work with the above 
> programs.  I have tried Windows 3.1, OS/2 and Desqview/X and can not get 
> what I want.  Am I totally stuck?
> 
> Thanks
> 
> Mark Thacker
> 
> thacker@cc1.unt.edu
> 
> or  Mark@vaxb.acs.unt.edu
-------------
	I have the impression that maybe the story is a little upside down.
Apparently you have a kernel from FTP Inc which includes a driver for a
specific board. So that would own the board the same as any other driver.
If that's the case then stop, contact FTP Inc and obtain a version which
runs over a Packet Driver. Packet Drivers don't understand IP and all that
neat stuff, they just hand out packets.
	Next, you want a lot more than you should get. The programs cited
at the top of your msg all have their own TCP/IP protocol stacks. Attempting
to run them together (how? Windows, nah; DV, perhaps) is fratracidal in
the networking sense. Try running one at a time, nicely matching the number
of monitor screens on most PCs.
	The proper solution is the one you mentioned: one protocol stack
and multiple applications on the top of it. Alas, FTP's stack is very nice
but it does cost some money, and all of the programs you mentioned are not
built to operate that way. There are, after all, other commercial stacks too.
Just to indicate where things are heading, the commercial vendors have
recently issued a specification (document, not code) for an API for Windows,
the winsock spec, to permit a variety of protocol stacks to furnish the
same service. If this were to become accepted and widely implemented then
for Windows the neat programs could all call on that interface and use one
compliant stack beneath.
	Joe D.

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 92 04:13:54 GMT
From:      ehall@cmpny.sscnet.ucla.edu (Eric Hall)
To:        comp.protocols.tcp-ip
Subject:   Re: NDIS, PROTOCOL.INI, dynamic=yes

In order to unload protocols dynamically, you must be using a NOS that allows 
you to LOAD them dynamically (ie, LOAD TCPIP, or LOAD NETBEUI).  If this is 
the case, then simply UNLOAD TCPIP, or whatever protocol you've got loaded.  
They have to be unloaded in the reverse order of which they were loaded, BTW.

This is how LAN Manager does it.  I'm not sure about the other vendors, but 
NDIS is Microsoft's baby, so they outta be pretty similar.


--------------------------------------------------------*
Eric Hall
Director East Coast Labs
Network Computing Magazine

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 04:20:54 GMT
From:      harlick@plains.NoDak.edu (Ryan Harlicker)
To:        comp.protocols.tcp-ip
Subject:   SLIP over a TELNET Link?


I'm looking for information to determine whether a slip connection based
on the following qualifications is possible.

     I don't have access to a local number in which to connect to a slip
site.  I do have a connection to a subnet which supports telnetting to
other sites.  What I would like to do is to connect to some site through
the telnet server and then initiate a slip connection.

Example: have tip call up the local net and telnet to the slip site.
        Initiate slip and maintain connection.

I currently use this setup for my uucp connection but miss the direct
internet connection I used to have.


Also while we are at it is there someone out there who would like to
help this student find his slip connection?

References and proof of identity are available if needed for security
reasons.


Thanks,
Ryan Scott Harlicker
harlick@plains.nodak.edu
uunet!plains!prototype!harlick 

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 04:36:25 GMT
From:      peterd@merlin.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip,comp.protocols.osi
Subject:   GAO report on ANSI? [summary of replies, really OTA]


I posted a message a few days ago looking for information on a
government report on the standards process. I had been unable to find
it, even with the help of our librarian, as I had confused the GAO
with the OTA. Anyway, here's a response describing the report:

> From: "Louis Valentino" <louis@netronix.com>
> To: peterd@merlin.dev.cdx.mot.com
> Subject:   Re: GAO report on ANSI? 
> Date:      Thu, 18 Jun 1992 08:33:00 PDT
> 
> [... my question ...]
>
>    There was a short article in the Briefs section of Network World,
> April 6, 1992, v.9 n.14 pg. 2.  To quote the article:
> 
>    "U.S. standards process out of whack, report says.  The Office of
> Technology Assessment (OTA) last week issued a report titled 'Global
> Standards: Building Blocks for the Future," which concluded that the U.S.
> standards-making process is in a state of disarray, undermined by lack of
> industry funding and ruled by 'internecine warfare.'  The report said the
> weak U.S. position stands in stark contrast to Europe and Japan where
> standards-making receives government funding and guidance as a means to
> create trade advantages.  The report went on to say that the federal
> government should play a stronger role in standards-setting in the U.S.
> But the Industry Coalition on Standards and Trade rebutted OTA's findings
> and urged the government not to interfere in the voluntary U.S. standards
> efforts."

I'm not sure how you get OTA reports, but given the title I'm sure a
librarian can get a copy. (I'll hear in a day or so if our librarian
can't :-) For folks in the U.S. you might also try your local
representative's office.

				Peter Desnoyers
-- 

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 09:51:03
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC1041-Telnet 3270-Regime options

In article <2897@ariadne.csi.forth.GR> antonis@helios.ntua.gr (Antonis Kyriazis) writes:

    This is a question concerning some part of this RFC.

RFC 1041 does *not* describe current de-facto TN3270 interaction.  For this,
read the Telnet RFCs (particularly 1091) and the Telnet section of RFC 1123.

    I'm trying to debug some 'conversation' between a PC and
    a remote SNA application using either PC-NFS/adv. telnet
    or PC-TCP/tn3270, where PC-NFS fails and PC-TCP succeeds!

PC/TCP (and presumably PC-NFS's Advanced Telnet) conform to RFC 1091.  The
terminal types may be found in RFC 1060.

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


-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 05:20:53 GMT
From:      tal@Warren.MENTORG.COM (Tom Limoncelli)
To:        comp.protocols.tcp-ip,comp.lang.perl
Subject:   Perl script to check for DNS configuration flaws?

I'm about to write some code to check for configuration inconsistencies
and general "bad stuff" in files to be input to named.  (as well as
checking that reverse address stuff is consistent)

Before I do this, has anyone else written such a program?

Please email me and I'll post a summary.

Thanks in advance,

Tom
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
"Tax cuts don't do any good for someone who is out of work," Gov. Bruce
Sundlun, D-RI, said in denouncing Bush's economic rescue plan as woefully
inadequate.  "They don't need a tax cut.  They need a job." Feb 3, 1992

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 06:53:10 GMT
From:      antonis@helios.ntua.gr (Antonis Kyriazis)
To:        comp.protocols.tcp-ip
Subject:   RFC1041-Telnet 3270-Regime options


This is a question concerning some part of this RFC.
I'm trying to debug some 'conversation' between a PC and
a remote SNA application using either PC-NFS/adv. telnet
or PC-TCP/tn3270, where PC-NFS fails and PC-TCP succeeds!
So, using a sniffer, I can't decode the terminal type
subnegotiation part of that session. I need to know how
'ibm3279-3', 'ibm3279-2' and 'ibm3278-3' are defined (HEX).

thank you
+-------------------------------------------------------------------+
|     Antonis Kyriazis                                              |
| Networks & Communications       e-mail: antonis@intranet.gr       |
| INTRACOM sa                                                       |
| 19.5 km Marcopoulo Ave.          fax:   +30-1- 66 44 379          |
| Peania 190 02                           +30-1- 66 43 718          |
| GREECE                          phone:  +30-1- 66 44 961-5        |
|                                         +30-1- 88 43 715          |
+-------------------------------------------------------------------+

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 13:06:00 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP (check out TFTP)

In article <1992Jun18.170837.5314@icd.ab.com> aep@icd.ab.com (Alexander E. Pensky) writes:

    ....  RFC 783 does not specify any rule for deciding when a TFTP should
    retransmit and when it should abort following a receive timeout.

This is true.  However, I don't see how it affects my point.  RFC 793
doesn't specify this for TCP either.  Most TCPs give up after a
while, but there's at least one widely distributed TCP that *never*
gives up of its own accord.  They interoperate.  Which you prefer
depends on your requirements and your religion.

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

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 13:17:28 GMT
From:      thacker@cc1.unt.edu (Mark D. Thacker x2568)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Multi packet driver progs. at once with PC/TCP & Desqview/X

HELP!  I think I want to do the impossible.

I need the ability to run multiple Crynwr (Clarkson) packet driver based IP 
programs at once.  These programs include Trumpet (news reader), CUTCP 
Telnet and PC Gopher II.  No, I can not simply use some other news reader/
telnet program.

I would like to be able to have Crynwr (Clarkson) packet driver programs 
pass their IP calls up the protocol stack so that Ftp Software's PC/TCP 
kernal can actually execute them.  In theory this would allow me to execute 
muliple packet driver IP programs at once since the PC/TCP kernal allows 
multiple IP sessions.

I really want to do all of this from Desqview/X, which supports either 
Novell's LAN Workplace for DOS or PC/TCP.

Currently, with PC/TCP installed, NO packet driver based IP program works 
since all IP calls are trapped by PC/TCP.

A college told me that there was a program which patched the packet drivers 
to pass their IP calls up the protocol stack...does anyone know WHERE I can 
find such a thing or WHAT its name might be?

If there are other solutions available, please let me know.  I can not give 
up my packet drivers!!!  I do to much development work with the above 
programs.  I have tried Windows 3.1, OS/2 and Desqview/X and can not get 
what I want.  Am I totally stuck?

Thanks

Mark Thacker

thacker@cc1.unt.edu

or  Mark@vaxb.acs.unt.edu

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 14:39:59 GMT
From:      jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?


> I'm looking for information to determine whether a slip connection based
> on the following qualifications is possible.
>
>      I don't have access to a local number in which to connect to a slip
> site.  I do have a connection to a subnet which supports telnetting to
> other sites.  What I would like to do is to connect to some site through
> the telnet server and then initiate a slip connection.
> 
> Example: have tip call up the local net and telnet to the slip site.
>         Initiate slip and maintain connection.
> 
> I currently use this setup for my uucp connection but miss the direct
> internet connection I used to have.

As it would happen, I am looking for exactly the same thing.  I can
only call my destination (A net of SPARCs)through its terminal server
which does not seem to support SLIP. Bummer!  I figure once I get
connected I should be able to just start up something which forwards
the SLIP "packets" from the /dev/ttypXX to the net and vice versa.
All the real serial slips do it.  I am not much of a Unix hacker or I
would do it myself.

Related questions:

1) What about Compressed Slip?  Any good?  Availability?  Speed?

2) Don't laugh at this one.  Anyone have experience with X over a 9600
SLIP connection?  I am actually doing something else but it occured to
me that X would work if I get this working.  In the future we will
likely move to completely ISDN inconnects but for now this will have
to do.

Thanks in advance.  Very much appreciated.
--
ja mata, |m         -- Rollin' and a tumblin'

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 14:49:08 GMT
From:      dsbarr@modula.cs.psu.edu (Dave Barr)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC1041-Telnet 3270-Regime options

In article <920619095103@cream.ftp.com> jbvb@ftp.com writes:
>PC/TCP (and presumably PC-NFS's Advanced Telnet) conform to RFC 1091.  The
>terminal types may be found in RFC 1060.

	I have a minor pet peeve with RFC 1060.  For the vtxxx terminal
types, they are all listed as "dec-vtxxx".  It's very annoying to Unix
sites, who rarely have a termcap for "dec-vtxxx".  I know, a minor
fix for the sysadmin, but it's still an annoyance.  FTP software implements
RFC 1060 by the letter, as such it doesn't say it can emulate a "vt100"
or "vt220", only a "dec-vt100" or "dec-vt220".

--Dave
-- 
Dave Barr            | loose: v. to set free, or not securely fastened.
dsbarr@cs.psu.edu    | lose: v. to miss from one's posession.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 15:54:57 GMT
From:      hillman@sfu.ca (Steve Hillman)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Multi packet driver progs. at once with PC/TCP & Desqview/X

Get ahold of PKTMUX, located on sunee.uwaterloo.ca (pub/wattcp, I think). It
handles the muxing of multiple TCP/IP applications fairly well. It loads
on top of the packet driver and then each application that you run loads
a copy of a special "psuedo" packet driver. This driver talks to the multiplexer
instead of directly to the low level packet driver.
 
I've successfully run it under windows with a few different programs running
at once (including a WATTCP version of an SMTP server). It seems to work quite
well and is quite flexible in how you set it up.

-- 
Steve "Skillman" Hillman                "Everyone generalizes"
hillman@sfu.ca
skillman@tz.wimsey.bc.ca


-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 17:02:14 GMT
From:      smj@beta.lanl.gov (Stephen M. Johnson)
To:        comp.protocols.tcp-ip
Subject:   MacTCP & DNS & BOOTP

We're having trouble getting MacTCP to recognize the second nameserver in
the configuration. Will MacTCP try the second server listed in the even that 
the "default" server does not?

We are interested in using BOOTP to provide IP address, subnet mask, etc to our
Macs. Does MacTCP support RFC1048? 

-- 

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
smj@lanl.gov			| Aiken, South Carolina

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 19:38:00 GMT
From:      shaman@cix.compulink.co.uk (Leo Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Open SNMP NMS platdorms

thsssxs@iitmax.iit.edu (Semir Sirazi)writes..

        We are currently developing a network device that will have
        SNMP management capabilities. We want to develop a management
        console that fully configures, manages, etc. the network
        device, at a very high as well as detailed level, and will
        show the current status of the network device, all within a
        glitzy graphical user-interface. (Including detailed bitmaps
        of the device and along with its current status.) What we are
        looking for is an open, extensible, SNMP based Network
        Management Software platform that will allow us to create a
        customized device manager.

[...]

Digital Analysis Corp   OS/EYE*NODE
Hewlett-Packard         OpenView-Windows 3.0 product  (Sparc version too $$)
Netlabs Inc.            Dual Manager
SunConnect              SunNet Manager

Keith: This is something I picked up at the UK Internet Conference. I
was extremely impressed with what I saw, and the philosophy of the
guys who wrote it.

It sounds like they are trying to address the needs of people like
you.


I don't have a name or E-mail, but I do have:

The NMC 3000 Network Manager

Network Managaers
Stirling House
Stirling Road
The Surrey Research Park
Guildford
Surrey GU2 5RF

+44 483 303223
+44 483 303997 (fax)

I should check them out yourself.




-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 20:05:58 GMT
From:      drw@kronecker.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

It seems like this isn't very hard...  If you're sending true
datagrams to places (i.e., it isn't one of a series of messages to the
same destination, but a one-time-only datagram to a single recipient),
just send a UDP to the destination, including a serial no in the
datagram.  The sender archives the datagram.  The recipient sends a
confirmation back to the sender.  When the sender receives a
confirmation, it throws away the archived datagram, otherwise it
periodically retransmits it.  The recipient archives received
datagrams, so it can ignore duplicates of the same datagram.  This
could be implemented easily in user space, and I think it could be
done easily in kernel space too.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
War is an ugly thing, but not the ugliest thing:  The decayed and degraded
state of moral and patriotic feeling which thinks nothing worth a war is
worse.  A man who has nothing for which he is willing to fight, nothing he
cares about more than his personal safety, is a miserable creature who has no
chance of being free, unless made and kept so by the exertions of better men
than himself.	-- John Stuart Mill

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jun 1992 20:36:32 GMT
From:      drw@kronecker.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <CKD.92Jun16184755@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
   I once did JCL, in a previous life, to pay the rent.  X.400 makes JCL
   look straightforward.  (I guess the equivalent of nobody@machine in
   X.400 would have to be /PGM=IEHBR14 ;-)

That's IE*F*BR14.  IEH utilities handle groups of files on a volume.

God, how many neurons I must be wasting on useless information!

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
I moralized and starved until one day I swore that I would be a
full-fed free man at all costs; that nothing should stop me except a
bullet, neither reason nor morals nor the lives of other men.  I said
"Thou shalt starve ere I starve"; and with that word I became free and
great.  I was a dangerous man until I had my will:  now I am a useful,
beneficent, kindly person.  --  G. B. Shaw, "Major Barbara"

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 92 21:24:08 GMT
From:      hcb@world.std.com (Howard C Berkowitz)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   Re: OSI vs TCP/IP information & opinions requested

In article <DRW.92Jun19153632@kronecker.mit.edu> drw@kronecker.mit.edu (Dale R. Worley) writes:
>In article <CKD.92Jun16184755@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>   I once did JCL, in a previous life, to pay the rent.  X.400 makes JCL
>   look straightforward.  (I guess the equivalent of nobody@machine in
>   X.400 would have to be /PGM=IEHBR14 ;-)
>
>That's IE*F*BR14.  IEH utilities handle groups of files on a volume.
>
 
>God, how many neurons I must be wasting on useless information!


I can't resist, considering the number of complaints
about the problems caused by the complexity of OSI.

IEFBR14 has the distinction of being the only one-instruction
program I know of that had to have a defect report (i.e., 
an IBM APAR, which I think stood for Authorized Problem
Analysis Report).

"BR14" is actually meaningful for a do-nothing program.
The IBM subroutine calling convention passed, among other
things, the return address in the calling program in Register
14.  Therefore, to do  nothing, immediately branch back
to the return address (BR is the Branch Register instruction).

Not so simple.  Another part of the convention told you
your starting address in Register 15, but you were supposed
to put a completion code in register 15 on exit.  The normal
return was zero.

Version 1 IEFBR14 just did a BR 14 as its only instruction,
leaving a large address value in register 15--one usually
illegal for the calling program.  BOOM.

The fix, of course, was  to change IEFBR14 to two instructions,
the first to clear Register 15 and the second the original BR14.
This fix, of course, DOUBLED THE SIZE OF THE CODE!!!! 

And people complain how fast OSI code grows??  :-)

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Jun 1992 00:04:11 GMT
From:      johnk@gordian.com (John Kalucki)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jun19.143959.8094@kei.is.s.u-tokyo.ac.jp>, jeff@is.s.u-tokyo.ac.jp (Jeff McAffer) writes:
> 
> > I'm looking for information to determine whether a slip connection based
> > on the following qualifications is possible.
> >
> >      I don't have access to a local number in which to connect to a slip
> > site.  I do have a connection to a subnet which supports telnetting to
> > other sites.  What I would like to do is to connect to some site through
> > the telnet server and then initiate a slip connection.
> > 
> > Example: have tip call up the local net and telnet to the slip site.
> >         Initiate slip and maintain connection.
> > 
> > I currently use this setup for my uucp connection but miss the direct
> > internet connection I used to have.
> 
> As it would happen, I am looking for exactly the same thing.  I can
> only call my destination (A net of SPARCs)through its terminal server
> which does not seem to support SLIP. Bummer!  I figure once I get
> connected I should be able to just start up something which forwards
> the SLIP "packets" from the /dev/ttypXX to the net and vice versa.
> All the real serial slips do it.  I am not much of a Unix hacker or I
> would do it myself.

Note that you cannot use telnet to transport a SLIP session. Telnet
is not an 8bit clean data path and is therefore not a good choice
for transporting SLIP packets. You will need a terminal server that
supports raw TCP connections and a raw TCP listener on the Unix
box (ie not telnet on port 23).

Unfortunatly a terminal server that is feature rich enough to
support raw TCP connections probably supports slip too!


		-John Kalucki
		johnk@gordian.com

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Jun 1992 02:25:14 GMT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jun19.143959.8094@kei.is.s.u-tokyo.ac.jp> jeff@is.s.u-tokyo.ac.jp writes:
>>      I don't have access to a local number in which to connect to a slip
>> site.  I do have a connection to a subnet which supports telnetting to
>> other sites.  What I would like to do is to connect to some site through
>> the telnet server and then initiate a slip connection.
>> 
>As it would happen, I am looking for exactly the same thing.  I can
>only call my destination (A net of SPARCs)through its terminal server
>which does not seem to support SLIP. Bummer!  I figure once I get
>connected I should be able to just start up something which forwards
>the SLIP "packets" from the /dev/ttypXX to the net and vice versa.
>All the real serial slips do it.  I am not much of a Unix hacker or I
>would do it myself.

Likely the reason that this doesn't work is because on most UNIX
boxes, SLIP is implemented as a line discipline; when you put a tty in
SLIP mode, you change it to use the SLIP line discipline.  The problem
is that the SLIP line discipline doesn't work with the pty driver, as
the pty driver "knows" too much about how the normal tty line
disciplines work and these assumptions cause SLIP to break.

For those interested in why its broken and have source code, think
about how the hardware/pty driver starts up output again once its
drained the tty output clist.  Note that many pty drivers perform a
wakeup() rather than calling the start routine in the line discpline
switch table.

Now, other flavors of SLIP which are implemented in user space code
and use "tunnel" network interfaces won't have this problem since they
talk to the tty device in plain vanilla RAW mode.  e.g., Morningstar
SLIP/PPP.  Of course you pay the cost of context switchs, but that may
not be a problem..

Louis Mamakos
Purveyor of SLIP for the NeXT

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 92 05:11:16 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jun20.022514.20490@ni.umd.edu>, louie@sayshell.umd.edu (Louis A. Mamakos) writes:
> ...
> Likely the reason that this doesn't work is because on most UNIX
> boxes, SLIP is implemented as a line discipline;....


SLIP over rlogin works on Silicon Graphics UNIX, IRIX, where SLIP is a
STREAMS line discipline.  It doesn't matter that the tty is a pty.  The
author of the slip, tty, and pty code thought it would, but it doesn't.
Therefore, it might work for other STREAMSish systems, including late model
SunOS and SVR4.


Of course, 8-bit clean matters.


Vernon Schryver,  vjs@sgi.com

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 92 16:17:14 GMT
From:      schmidt@kleber.ics.uci.edu (Douglas C. Schmidt)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Semantics of shutdown(2)

Hi,

	I'm curious to know whether the BSD shutdown(2) system call is
guaranteed to perform a graceful termination of the endpoint of
communication, i.e., does it try to send any pending data that is
buffered due to flow control?  The manual page doesn't seem to say.

	Thanks,

		Doug
--
His life was gentle, and the elements so            | Douglas C. Schmidt
Mixed in him that nature might stand up             | schmidt@ics.uci.edu
And say to all the world: "This was a man."         | ucivax!schmidt
   -- In loving memory of Terry Williams (1971-1991)| (714) 856-4101

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 92 17:51:54 GMT
From:      kdn5669@hertz.njit.edu (ken ng cccc)
To:        comp.protocols.tcp-ip
Subject:   RFC for 10baseT

My apologies if this is not the correct group or if this is an FAQ (I
checked the local article list and did see anything marked as FAQ).  Is
there an RFC for 10BaseT and if so what number is it?  I got the rfc list
from wuarchive, but did not see anything obvious.  Also, what other RFCs
will be needed to learn how it works.  IE: is it really just ethernet on
twisted pair?

-- 
Kenneth Ng: kdn5669@hertz.njit.edu
"No problem, this is how you make it" -- R. Barclay, ST: TNG

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 92 20:21:59 GMT
From:      hgschulz@cs.umass.edu (Henning Schulzrinne)
To:        comp.protocols.tcp-ip
Subject:   ttcp has lower thruput than ftp, rcp?

For reasons completely beyond me, it appears that ttcp yields
significantly LOWER throughput figures than ftp or rcp, mostly when
doing tests across the Internet rather than the local Ethernet. Example:

ttcp from desperado.ecs.umass.edu to bbn.com: 307-341 kbits/sec in three
measurements (buffer length of 1460 bytes, same as for ftp);
interspersed with that, ftp transfers yielded 880 kbits/sec to 1120
kb/sec. No, this is not just a matter of mixing up kbits vs.  kbytes.
The same byte count transferred using ftp takes about a third of the
time (as clocked with a watch) than with ttcp. rcp gives about the same
thruput as ftp (as one would expect).

My version of ttcp.c reads:
 * Modified for operation under 4.2BSD, 18 Dec 84
 *      T.C. Slattery, USNA
 * Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.

Hardware: DECstation 5000, SPARCstation II (in either combination)

What's going on here?
---
Henning Schulzrinne  (hgschulz@cs.umass.edu)  [MIME mail welcome]
Dept. of CS and Dept. of ECE; Univ. of Massachusetts at Amherst
Amherst, MA 01003 - USA === phone: +1 (413) 545-3179 (EST); FAX: (413) 545-1249

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 92 21:47:37 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: ttcp has lower thruput than ftp, rcp?

In article <49580@dime.cs.umass.edu>, hgschulz@cs.umass.edu (Henning Schulzrinne) writes:
| For reasons completely beyond me, it appears that ttcp yields
| significantly LOWER throughput figures than ftp or rcp, mostly when
| doing tests across the Internet rather than the local Ethernet. Example:
|...
| What's going on here?

	Some ftp servers and rcp programs increase their send and receive
socket buffer space, resulting in greater tcp windows (and greater usage
of peer windows in the case of send space).  The ttcp program uses the
default socket buffer space.  On SunOS 4.1.1, for example, the default
send and recieve buffer spaces are both 4k.  The ftp daemon increases them
to 20k.  This can have significant performance implications, all the more
so when a long-haul network is involved.  Refer to the SO_RCVBUF and
SO_SNDBUF socket options for more information.

				Dan Lanciani
				ddl@harvard.*

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jun 1992 01:21:49 GMT
From:      DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis)
To:        comp.protocols.tcp-ip
Subject:   Bridge & router descriptions requested


	I am looking for authoritative definitions for a bridge and a router.
It is my (admittedly limited) understanding that a bridge essentially handles
Ethernet packets and a router handles protocol-specific packets.  So, for
example, LAT packets could get through a bridge, but they may or may not be
handled by a router, depending on whether or not the router was designed
(and/or configured) to route LAT packets.  If this analysis is essentially
correct, where do combination bridge-router boxes fit in?  Please reply
directly to me, and I will summarize.

							Thanks,
							 Mike
--
 Internet: davism@kcgl1.eng.ohio-state.edu |
            -or- DAVISM+@osu.edu           |   These Thoughts, They Be Mine
   BITNET: DAVISM+@OHSTMAIL.BITNET         |

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jun 1992 02:32:02 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: ttcp has lower thruput than ftp, rcp?

In article <1992Jun20.214737.22378@burrhus.harvard.edu>, ddl@burrhus.harvard.edu (Dan Lanciani) writes:
> In article <49580@dime.cs.umass.edu>, hgschulz@cs.umass.edu (Henning Schulzrinne) writes:
> | For reasons completely beyond me, it appears that ttcp yields
> | significantly LOWER throughput figures than ftp or rcp, mostly when
> | doing tests across the Internet rather than the local Ethernet. Example:
> |...
> | What's going on here?
> 
> 	Some ftp servers and rcp programs increase their send and receive
> socket buffer space, resulting in greater tcp windows (and greater usage
> of peer windows in the case of send space).  The ttcp program uses the
> default socket buffer space.  On SunOS 4.1.1, for example, the default
> send and recieve buffer spaces are both 4k.  The ftp daemon increases them
> to 20k.  This can have significant performance implications, all the more
> so when a long-haul network is involved.  Refer to the SO_RCVBUF and
> SO_SNDBUF socket options for more information.


If so, the ttcp source on sgi.com in ~ftp/sgi/src/ has an option added
to fiddle with the socket buffer sizes.


Vernon Schryver,  vjs@sgi.com

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jun 1992 04:30:40 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for 10baseT

In article <1992Jun20.175154.23742@njitgw.njit.edu> kdn5669@hertz.njit.edu (ken ng cccc) writes:
>...Is there an RFC for 10BaseT ...

No.  10BaseT, like Ethernet itself, is an IEEE standard.  IEEE will be
happy to sell you a (paper) copy of the standard; it is not available online.

Actually, if you're a novice, you probably want something a wee bit
gentler -- IEEE standards make, uh, stiff reading.  I don't have any
specific recommendations; anybody else have any?

>... IE: is it really just ethernet on twisted pair?

Sort of kind of.  The twisted-pair cable connects one (1) computer to a
specialized multi-port repeater ("hub").  Yes, you need one cable per
computer.  The combination of cabling and hub constitutes an Ethernet.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jun 1992 18:26:38 GMT
From:      ckd@eff.org (Christopher Davis)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

JM> == Jeff McAffer <jeff@is.s.u-tokyo.ac.jp> 

 JM> 1) What about Compressed Slip?  Any good?  Availability?  Speed?

This helps a lot, especially for telnet connections.

 JM> 2) Don't laugh at this one.  Anyone have experience with X over a 9600
 JM> SLIP connection?  I am actually doing something else but it occured to
 JM> me that X would work if I get this working.  In the future we will
 JM> likely move to completely ISDN inconnects but for now this will have
 JM> to do.

I tried this once (X over 9600 CSLIP).  It was sloooow, unbearably so.
I will probably try again when I get the V.32bis modem installed.  If
you can do XRemote it's supposed to be much faster.
--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
    Samizdata isn't that different from Samizdat.  -- Dan'l Danehy-Oakes

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 00:30:05 GMT
From:      ralf@wpi.WPI.EDU (Ralph Valentino)
To:        comp.protocols.tcp-ip
Subject:   RPC - how do I reply twice to one request?

I'm writing a program (client/server) that sends a broadcast rpc and
waits for results.  The client issues a clnt_broadcast().  The server(s)
(created via rpcgen) do a svc_sendreply() when they have an answer.
The answer is made up of 'n' structures of data using the _val and
_len pointers created by the .x file and are just appended to each
other at the client side.

I ran into a problem when 'n' * structure size > udp allows - it
completely ate my message (well, actually, it crashed the Ultrix
portmapper, but that's another story).  I tried breaking it up into
to parts (on a structure boundary) and calling svc_sendreply() twice,
but the second one never got through even though the svc_sendreply()
returned SUCCESS.  (each_result() was called only once per responding
host).  Cacheing should be off.

Playing with it further, I modified the xid of the first svc_sendreply()
to something else, and then restored it for the second.  This time,
the second went through.  This leads me to believe that the problem
actually exists on the client side.

Is the client caching replies and discarding the second?  How can I
get around this (without turning the client into a server itself?)

Also, I found the breakdown point of udp's to be 6 structures of 64
bytes each = 384, which is MUCH less than the expected 1400!  I
realize some is used by the _val and _len pointers, but what about the
rest?  (the structure is made up of a number of ints, longs, chars,
and two strings of <16> characters each, if that makes any difference).

-Ralph
===============
Ralph Valentino   (ralf@chpc.org)  (ralf@wpi.wpi.edu)
Hardware Engineer,  Worcester  Polytechnic  Institute
Center for High Performance Computing, Marlborough MA

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 01:30:55 GMT
From:      a9000005@tscc2.macarthur.uws.edu.au (Brian Watson)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   dis_pkt with token-ring?


Hi,
   I am attempting to get dis_pkt to work.  I am using a PS/2 55 with 
a genuine IBM token-ring card.  I have the NDIS drivers and the dis_pkt
from vax.ftp.com.  I have tried other dis_pkt with similar results.

When I try to use the Delft netcapt with this setup, it complains that
it cannot get (or set?) the packet mode.  It then captures packets but
they are corrupt.  The addresses appear to be shifted 4 bytes to the 
right and left filled with 'f' and the last 4 bytes are moved into the
'type' field.

When I try CUTCP, it recognises the packet driver but will not open any
connections.  It also reports an ethernet address of 0:0:0:0:0:0.
 
I use IBMTOKEN.COM packet driver normally, but it will not go into mode 6
to allow me to properly use the Netcapt.  I have heard that the dis_pkt
driver from FTP will do mode 6.

Any suggestions appreciated.

config.sys:
-------------------------------------------------------------------------------
device=a:\ndis\protman.sys /i:a:\ndis
device=a:\ndis\ibmtok.dos
device=a:\ndis\dis_pkt.dos
-------------------------------------------------------------------------------

autoexec.bat
-------------------------------------------------------------------------------
@echo off
prompt $p$g
ndis\netbind
-------------------------------------------------------------------------------

boot messages:
-------------------------------------------------------------------------------
MS DOS LAN Manager Protocol Manager v1.1                                        
MS DOS LAN Manager Network Driver for IBM Token Ring v2.0                       
MAC/DIS to Packet Driver converter loaded. Version 1.05                         
Copyright 1990 FTP Software, Inc.  FTP Software Inc. provides NO WARRANTY.      
MS DOS LAN Manager Netbind v1.1                                                 
A:\>
-------------------------------------------------------------------------------

CUTCP startup:
-------------------------------------------------------------------------------
Clarkson University Tcp Communication Package                                   
Clarkson University Terminal Emulator [CUTE:2.2TN/TC-D]                         
                                                                                
Alt-H presents a summary of special keys                                        
                                                                                
Packet driver (MAC/DIS converter)                                               
Class 1 Type 57 Version 5 Extended 1                                            
                                                                                
Tektronix initialized                                                           
Auto Video detects device 7 VGA                                                 
My Ethernet address: 0:0:0:0:0:0                                                
My IP address: 137.154.72.28                                                    
-------------------------------------------------------------------------------
--
Brian Watson                            | Disclaimer: Any opinions
Programmer, Computing Centre            |  expressed are my own and do not
University of Western Sydney, Macarthur |  reflect those of my employer
Internet: b.watson@uws.edu.au           |  or anyone else.

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 03:19:13 GMT
From:      kfl@access.digex.com (Keith F. Lynch)
To:        comp.unix.sysv386,comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   BOOTP or RARP under SCO Unix

Does anyone have a BOOTP or RARP available for use under SCO Unix?
SCO doesn't supply them, but we need them to load a Xyplex terminal
server.  Thanks.

Keith Lynch, kfl@access.digex.com

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 09:55:15
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <DRW.92Jun19150558@kronecker.mit.edu> drw@kronecker.mit.edu (Dale R. Worley) writes:

    It seems like this isn't very hard...  If you're sending true
    datagrams to places (i.e., it isn't one of a series of messages to the
    same destination, but a one-time-only datagram to a single recipient),
    just send a UDP to the destination, including a serial no in the
    datagram.  The sender archives the datagram.  The recipient sends a
    confirmation back to the sender.  When the sender receives a
    confirmation, it throws away the archived datagram, otherwise it
    periodically retransmits it.  The recipient archives received
    datagrams, so it can ignore duplicates of the same datagram.

The point is that this isn't "connectionless".  Here's a discussion I
sent a year or two when the subject last came around (I tried to mail this
through nic.ddn.mil, but it's been a week, and I haven't seen it on the
NNTP side yet - if anyone actually sees this twice in June 1992, let me know).
-----
    apple.com!erekose@apple.com  (Erik Scheelke):
    >     Does anyone know of a reliable connectionless datagram protocol that
    >     runs on top of UDP?  Is so, is there a library out there I can get?
    
    postel@VENERA.ISI.EDU writes:
    >Hi.
    >
    >"Reliable Datagram" is an oxymoron.
    
    Very funny.  Really.  I would guess, however, that Erik is referring to a
    connectionless protocol that preserves message boundaries and guarantees
    delivery but not necessarily sequencing or non-duplication.  I'm sure such
    beasts exist somewhere.

What Jon said was the very, very condensed summary of an issue that he has
no doubt seen hashed over far too many times.  Even though I've been over
it twice as many times on the phone to customers as I've seen it discussed
here, I'll try my hand at laying it out in long form.

"Datagrams" are defined as single messages.  Sometimes you send one and you
don't expect an answer.  Sometimes you kind of hope for a reply, but the
transaction you are attempting isn't worth the overhead of setting up a
connection; if you don't get an answer, the request may have been lost, the
server may be down, or the reply may have been lost.  You don't care, there
are many servers, and your timeout handler has just sent a duplicate query
to another of them...

"Connectionless" means that there is no state at either the source or the
destination of the message.  Thus, a connectionless protocol cannot
guarantee delivery.  If the sender keeps enough state and includes enough
information in each message to guarantee delivery (e.g. some sort of
unique ID, and a timeout if the guaranteed response doesn't arrive), you
only need to add a little state to the receiver to allow sequencing and
non-duplication.  If the application must keep track because the
transport doesn't, it still looks like a connection to me...

So, every time this came up in the past, the next stage was to ask the
person looking for a "reliable connectionless protocol" or somesuch what
was really needed.  The most frequent goal has been some sort of transport
for a little machine, or a new one for which there is no networking
software yet.  The searcher doesn't want to implement all of TCP, and sees
"datagrams" as being easier, particularly on a single Ethernet.  Another
common goal has been to get very high throughput by avoiding the "excessive
overhead" of TCP, but Van Jacobsen's research has more or less laid that
one to rest.  A third one has been "preservation of message boundaries".

There are a number of 'reliable' alternatives to TCP, including NETBLT
(optimized for block transfers over lossy links), ISO TP, RDP and others.
Those I'm familiar with offer built-in functionality for preserving message
boundaries, along with varying approaches to connection establishment and
acknowlegement.  However, it does not appear that they provide enough extra
functionality, or require enough less effort to develop that they (except
for ISO TP) will ever become very widespread.

Frequently, having been made aware of the alternatives, the searcher reads
the specs and decides that he won't save anything.  Sometimes the next stage
is a complaint about excessive complexity containing the assertion "I never
see *any* packet loss between my Frobozz boxes on my FooNeT".  Whereupon
a large number of people jump down the complainer's throat, mostly network
maintainers suffering the slings and arrows of trying to make protocols
designed for 'little' nets run on 'big, bad' nets...

In summary, if you need reliability in an "internet" protocol, those "in
tune with the Tao of the Internet" assert that you need a connection, flow
control and an end-to-end data integrity check.  If all of your
transactions are guaranteed to fit in one packet, you can replace the
connection state with server idempotency.  If not, message boundaries are
best not tied to packet boundaries, lest you fall afoul of differing
MTUs and fragmentation (see RFC 1001/1002 Netbios over TCP for an example
of a header/length-based scheme).  If you leave the integrity check out,
that's your and your customers' risk, but leaving the flow control out
could get hosts ostracized by offended backbone router operators...

"Those who do not understand TCP are doomed to re-invent it..."

(??? who said that ???)

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


-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 08:00:52 GMT
From:      roe@Unibase.SK.CA (Roe Peterson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

louie@sayshell.umd.edu (Louis A. Mamakos) writes:

>Likely the reason that this doesn't work is because on most UNIX
>boxes, SLIP is implemented as a line discipline; when you put a tty in
>SLIP mode, you change it to use the SLIP line discipline.

"Most" unix boxes?  What about all the STREAMS boxes out there?
IE: all System 5 Rel. 3 and up?

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 12:15:22 GMT
From:      fmv@eniac.inesc.pt (Fernando Marques Videira)
To:        biz.sco.general,comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   Device Driver to connect IP to an interface board ???


 hi all,

I wonder if there is anyone that can help us on the following subject:

 - we have an ISDN Primary Rate Interface board to connect to the PC-AT.
   The PC is running the SCO the SCO UNIX V operating system with and the
   SCO Development Systen.
 - what we want is to deevelelop a STREAMS device driver to route IP 
   packets through the board.
 - so far we didn't get any information on the Service Interface between 
   the IP Stream and the lower Streams. In other words, there is no
   information on the messages the IP Stream send down, is it only IP
   datagrams or it also includes some control messages ????.


            Thank-you in advance for your help.

Fernando.

PS: Sorry if you receive this message twice. I didn't get the ACK of the
first transmission.
---------------------------------------------------------------------
Fernando Marques Videira (fmv@eniac.inesc.pt)
INESC - Instituto de Engenharia de Sistemas e Computadores
Rua Alves Redol, 9
Apartado 10105
1017 LISBOA CODEX
PORTUGAL
Tel: 351.1.310 00 00    Fax: 351.1.52 58 43
---------------------------------------------------------------------

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 12:16:45 GMT
From:      st12w@menudo.uh.edu (John D. Carse)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Ultrix 4.2

I've been trying to get a slip connection to my local Ultrix 4.2 Unix, but
all the slip implementations I've seen on archie are Sun, which don't seem
to compile on this machine (lots of unknown .h files and constants).

Are there any good implementations?  Has anybody gotten it to compile on an
Ultrix?  If so, could somebody send me a copy of the headers that you had
to find?  (sockio.h, etc.)

(neither cslip nor slip-4.1 wants to compile on this system)



-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 14:38:00 GMT
From:      jdham@col.hp.com (Jim Hammond)
To:        comp.protocols.tcp-ip
Subject:   Top TCP/IP networking problems ??

 I want to solve your networking problems! I am working on a 
TCP/IP network troubleshooting tool and need to generate 
customer requirements. If you could send me a list of your 
top 1-20 TCP/IP networking problems (optionally with company
name and approx. number of users) it would be greatly 
appreciated and may be addressed by a future product. 

 If you could post responses directly to me I will summarize
the responses in a week or so. Thanks in advance.

                  jdham@col.hp.com


-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 14:42:42 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In <920622095515@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes:

| "Connectionless" means that there is no state at either the source or the
| destination of the message.

This has to be the most bizarre definition of connectionless I've
ever seen - sounds more like a definition of stateless.

There may be somewhere where "connectionless" is defined that way, but
it can hardly represent what most people expect the term to mean - which
is that there is no requirement to set up some kind of "connection"
before sending traffic - or if you like, there's no need to tell anyone
that you're planning to send data, you simply send.

If we accept that connectionless and connection-oriented together
represent the universe (if there's a third contender, I've not come
across it), then your definition would have SNMP, DNS (using UDP) and
even ARP classified as connection oriented protocols (they all keep
state at at least one end).   That's weird.

| So, every time this came up in the past, the next stage was to ask the
| person looking for a "reliable connectionless protocol" or somesuch what
| was really needed.

My impression is that many (though certainly not all) people who ask for
this really don't cae about the protocol at all - what they want is a trivial
way at the program interface level to send a single reliable message
to some destination in (what to me is) a connectionless way - that is,
they package the address with the data, however the local interface
expects to find it, and do one OS call to send it.  From that point they'd
like the message delivered reliably - often they don't care a lot about
sequencing, and sometimes not about duplicate delivery, they just want
the message delivered (or an effor returned) - without either needing to
make a connection (do any preparation) at the application level, or keep
any state/times for retransmit at the application level either.

Much of this is probably inspired by the socket model (though I believe
TLI is much the same) where each "connection" takes a file descriptor,
and several OS calls to get the thing ready, whereas "connectionless"
communications require just one simple setup cal to get a socket to send on,
then one simple call per message to send, regardless of the destination
of the message.

kre

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 15:43:59 GMT
From:      cauble@cbnewsj.cb.att.com (Troy Cauble)
To:        comp.protocols.tcp-ip
Subject:   Well known ports and bad clients (abortive disconnect)

Hi,

I need some help with the following scenario:

1)  Server listens on a well known port.  Client connects.
2)  Client then does something annoying like getting blocked,
    going into an infinite loop, sleeping  forever, etc.
3)  For unrelated reasons, Server is then killed and restarted.
4)  The restarting Server gets EADDRINUSE trying to bind it's
    well known port.  Utilities show the well known port stuck
    in FIN_WAIT_1 or FIN_WAIT_2 (because the old Client never
    handled it's end of the shutdown).

How can I make this Server robust against bad client behavior?
How can I COMPLETELY close/dismantle the Server's well known
port without the cooperation of the Client?

I've seen mention of abortive disconnects in protocol books,
but I can't find anything in the socket interface.  I thought
SO_LINGER was the answer, but I've had no luck there.

It's for an HP_UX 8.0 system, if it makes any difference.


Thanks,
Troy Cauble

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 15:47:22 GMT
From:      timm@void.ncsa.uiuc.edu (Coffee Junkie)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

Robert Elz writes
> In <920622095515@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen)  
 writes:
> 
> | "Connectionless" means that there is no state at either the source or the
> | destination of the message.
> 
> This has to be the most bizarre definition of connectionless I've
> ever seen - sounds more like a definition of stateless.
>

I dunno.  I liked it, and thought it both straightforward and useful.

> | So, every time this came up in the past, the next stage was to ask the
> | person looking for a "reliable connectionless protocol" or somesuch what
> | was really needed.
> 
> My impression is that many (though certainly not all) people who ask for
> this really don't cae about the protocol at all - what they want is a  
 trivial
> way at the program interface level to send a single reliable message
> to some destination in (what to me is) a connectionless way - that is,
> they package the address with the data, however the local interface
> expects to find it, and do one OS call to send it.  From that point they'd
> like the message delivered reliably - often they don't care a lot about
> sequencing, and sometimes not about duplicate delivery, they just want
> the message delivered (or an effor returned) - without either needing to
> make a connection (do any preparation) at the application level, or keep
> any state/times for retransmit at the application level either.
> 
> Much of this is probably inspired by the socket model (though I believe
> TLI is much the same) where each "connection" takes a file descriptor,
> and several OS calls to get the thing ready, whereas "connectionless"
> communications require just one simple setup cal to get a socket to send on,
> then one simple call per message to send, regardless of the destination
> of the message.
> 

Along this lines, I've written C++ objects which do just this (albeit at the  
TCP level), which allows one to create an object with a constructor that can  
specify the host, optionally a socket type (UDP/TCP), optionally a port, and  
optionally something to send.  The lifetime of the connection is defined by  
the lifetime of the object, so it does in fact implement a "reliable  
connectionless" facility, although it does of course use connections.
Perhaps this is the sort of functionality people are looking for.

--
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
timm@ncsa.uiuc.edu|
(217)244-0015     |


-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 1992 16:21:11 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.unix.internals,comp.unix.programmer,comp.protocols.tcp-ip
Subject:   Re: 50 thousand TCP connections on Solaris 2.0/SVR4 - is it possible?

[I've redirected followups to comp.protocols.tcp-ip.]

In article <1992Jun22.131816.11980@spider.co.uk> ian@spider.co.uk (Ian Heavens) writes:
>I don't believe it is necessary to allocate a full window size of memory
>unless you are actually filling that window, which presumably is only
>true for a small fraction of the TCP connections.

The window is supposed to indicate how much data the TCP level is willing
to buffer up.  So, if 1000 connections each advertise an 8KB window, you're
claiming that you're prepared to buffer up 8MB.  I suppose you can be
optimistic that most senders won't actually get that far ahead of the
receiving processes, so the total of all the window sizes will be less than
the amount of space reserved.

Actually, I suspect many TCP implementations do this.  They use dynamic
allocation of buffers (e.g. Unix mbufs), rather than allocating a separate
buffer for each, and have a global constant that is the per-connection
window size.  This brings up the question of how meaningful the window
really is in such implementations?  If most of the receiver processes stop
reading their input (perhaps they're all waiting for some resource to
become available), the buffer pool might be exhausted before many of the
windows are filled.  At that point I guess the system can simply close all
of the windows.  One problem with an optimistic scheme like this is that it
can result in deadlock if the common resource most of the receivers are
waiting for is held by a process that's waiting on another TCP connection
(this is similar to overallocation of disk quota: if the disk fills
completely, you can't compress files to make room because you temporarily
need space for both the compressed and uncompressed versions).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 92 18:08:19 GMT
From:      ccg@tcdsp1.mmm.com ("Charles Ganzhorn")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP for IBM E9000?

I went through an evaluation process which included OCS and IBM's TCP/IP and
ended up with the IBM product.  Both products are good but I think one should
really look at the problem you are trying to solve rather than what is the best
TCP.

That is, you probably aren't really trying to get the greatest TCP/IP in the
world but are trying to give "blue" access in a non-blue environment that is as
good or better than the "blue" attachment methods.  You need local printing,
HLLAPI support, LU 6.2 support, IND$FILE transfers, and some sort of RJE.

As it turns out, most of this issues are relatively independant of the TCP/IP
implementation you use.  What is more critical is what client side software you
use:  HLLAPI, IND$FILE, and local printing depend much more on the TN3270 you use
than on the mainframe side.  LU6.2 and JES queue interaction are items where the
mainframe side is the important factor.

In our case, we liked the performance of and support for the IBM product.  They
are noticeably weak in the area of LU6.2 and they have a rudimentary JES
interface.

The OCS product deals with LU6.2 and remote printing better in my opinion.  The
downside of OCS's LU6.2 support is that it is proprietary.

I will most likely wait for a supportable APPN to answer LU6.2 issues.

As far as the ANET problem, I would hope that you are eliminating dumb 3270 tubes
and going to networked intelligent devices.  It seems silly to me to use a
mainframe as a terminal server to get access to TCP/IP services.  But that's just
the IP bigot in me talking.

Charles.
--
Charles Ganzhorn			E/Mail:  ccganzhorn@mmm.com
3M IS&DP Network Services		AT&T:	 +1 612 736 7122
St. Paul, MN				FAX:	 +1 612 736 7689

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 18:44:46 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   RDP implementation available for anonymous FTP

[there have been some notes suggesting that sending to tcp-ip@nic.ddn.mil
isn't getting through so I'm posting this directly. Apologies if some folks
get a duplicate].

    An implementation of the Reliable Data Protocol (RDP) as specified
in RFCs 908 and 1151 is now available by anonymous FTP.  RDP is a
connection-oriented reliable transport protocol like TCP, but unlike
TCP it preserves segment boundaries end-to-end, and can deliver segments
out of order if the application wishes.

    This implementation was done as my Master's Thesis project at Harvard
in 1987.  The code implements RDP in the 4.2/4.3 BSD kernel and was
tested on both a VAX and SUN workstations.  It has not been seriously 
used since 1987.

    I would like to thank my employer, Bolt Beranek and Newman, Inc., for
allowing me to make this distribution available.  (Since I was a BBN
employee at the time I wrote the code, BBN owns it).  Please observe the
following notice which is also included in the source code:

/**************************************************************************/
/*       Copyright(c) 1987, 1992 by BBN Systems and Technologies,         */
/*         A Division of Bolt Beranek and Newman Inc.                     */
/*                                                                        */
/*       RDP implementation for 4.2/4.3bsd by Craig Partridge             */
/*                                                                        */
/*  Permission to use, copy, modify, distribute, and sell this software   */
/*  and its documentation for any purpose is hereby granted without fee,  */
/*  provided that the above copyright notice and this permission appear   */
/*  in all copies and in supporting documentation, and that the name of   */
/*  Bolt Beranek and Newman Inc.  not be used in advertising or           */
/*  publicity pertaining to distribution of the software without          */
/*  specific, written prior permission. BBN makes no representations      */
/*  about the suitability of this software for any purposes.  It is       */
/*  provided "AS IS" without express or implied warranties.               */
/**************************************************************************/

    The source code can be retrieved by anonymous FTP from nnsc.nsf.net.
The source code is available in both a regular and compressed TAR file:

        rdp/RDP.tar.Z   -- compressed (31 Kbytes)
        rdp/RDP.tar     -- regular (90 Kbytes)


    As a project completed in early 1987, this code lacks a number of
features of a modern transport protocol implementation.  These missing
features include:

    * Karn's algorithm for round-trip time sampling

    * Jacobson's round-trip time estimation algorithm

    * slow-start

    * header prediction

As the RDP code is structured, one cannot simply borrow the appropriate code
from a TCP implementation.  Note too, that the code is for 4.2/4.3 BSD and
will require modification to run with 4.4BSD or streams.  Porting and
putting in the missing features might be a fruitful Master's degree
project.  In any case, if anyone does propose to do this work, I'd like
to know, so I can tell you what little thinking has been done already and
so that if more than one person is working on the problems, I can put
you in touch with each other.

Craig Partridge

E-mail: craig@aland.bbn.com or craig@bbn.com

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 92 20:26:23 GMT
From:      hsu@nic.funet.FI (Heikki Suonsivu)
To:        comp.protocols.tcp-ip
Subject:   PC-route with many interfaces

I would like to get a version of pc-route compiled with 2 packet interfaces
and 2-4 slip interfaces.  Anybody have, or able to compile such a version?

Does pc-route work, if any of the interfaces configured is not actually
used, the packet driver or the serial port is not there?

-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@{otax.tky.hut,cs.hut,clinet}.fi  +385-0-8031121
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI,
mcsun!hutcs!hsu, riippu SN, Email preferable.


-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 92 20:47:58 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <9217500.8256@mulga.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes:

    In <920622095515@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes:
    
    | "Connectionless" means that there is no state at either the source or
    | the destination of the message.
    
    This has to be the most bizarre definition of connectionless I've
    ever seen - sounds more like a definition of stateless.

This is the definition used by both the Internet world and the OSI world.
IP and CLNP are "connectionless", and don't have state for the hosts they
are in communication with.  CONS over X.25 does have state.  I think of the
best abstraction of "connection" as being the TCB or whatever you keep the
state in - it's what has to be created and destroyed, and consumes resources
while it exists.  When it gets created, and whose address space it gets
created in are implementation details.
    
    There may be somewhere where "connectionless" is defined that way, but
    it can hardly represent what most people expect the term to mean - which
    is that there is no requirement to set up some kind of "connection"
    before sending traffic - or if you like, there's no need to tell anyone
    that you're planning to send data, you simply send.

If you want reliable delivery, and some indication of success/failure
afterwards, there's a limit to what you can hide.  You could do a TCP
API where you specified both the address and the first (or only) data
segment on a single call.  However, you'd have to either block in that
call for as long as you're willing to keep on retrying, or you'll have
to use the 'handle' it returns to call again later and get status.
Whether this would take more packets or round-trip-times to implement
using TCP, UDP or protocol X will vary with the quantity of data and
the phase of the moon.
    
    If we accept that connectionless and connection-oriented together
    represent the universe (if there's a third contender, I've not come
    across it), then your definition would have SNMP, DNS (using UDP) and
    even ARP classified as connection oriented protocols (they all keep
    state at at least one end).   That's weird.

You can have some state at each end, like TCP.  Or, as I said in the first
posting, you can substitute server idempotency for state.  DNS and ARP aren't
good examples, since the server is read-only, but with SNMP 'set' you'd better
do a 'get' afterwards and check, and hold onto your hat if two NMSs try at
once.  The state has to exist somewhere, or the protocol can't be reliable.
    
    My impression is that many (though certainly not all) people who ask for
    this really don't cae about the protocol at all - what they want is a
    trivial way at the program interface level to send a single reliable
    message to some destination in (what to me is) a connectionless way -
    that is, they package the address with the data, however the local
    interface expects to find it, and do one OS call to send it.  From that
    point they'd like the message delivered reliably - often they don't care
    a lot about sequencing, and sometimes not about duplicate delivery, they
    just want the message delivered (or an effor returned) - without either
    needing to make a connection (do any preparation) at the application
    level, or keep any state/times for retransmit at the application level
    either.

These are API issues, not protocol issues.  See Sun's or Apollo's RPC API
for examples of this sort of thing.  They can handle either stream or
datagram transports more or less transparently, and the user doesn't care.

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

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 21:11:47 GMT
From:      eengelke@sail.uwaterloo.ca (Erick Engelke)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

kre@cs.mu.oz.au (Robert Elz) writes:
> jbvb@vax.ftp.com (James B. VanBokkelen) writes:
>
>| "Connectionless" means that there is no state at either the source or the
>| destination of the message.
>
>This has to be the most bizarre definition of connectionless I've
>ever seen - sounds more like a definition of stateless.

For the readership he was targetting, I think James was right
on the money.  

It is possible to do a stateful connectionless protocol, and it's
often done for certain implementations of remote proceedure calls.
(Not ONC RPC's, but several proprietary ones.)  In those cases the
datagram service can select correct timeouts, MTU's and other 
facts known about its peer.  Often the session data is also tied
to the network data, but that's a design issue.


>they package the address with the data, however the local interface
>expects to find it, and do one OS call to send it.  From that point they'd
>like the message delivered reliably - often they don't care a lot about
>sequencing, and sometimes not about duplicate delivery, they just want
>the message delivered (or an effor returned) - without either needing to
>make a connection (do any preparation) at the application level, or keep
>any state/times for retransmit at the application level either.

They don't cary about sequencing or duplicate delivery until they
experience it.  Then they find all the assumptions they made based
on their belief about what a reliable datagram protocol provides.


Erick

-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 21:27:24 GMT
From:      ronald@gate.demon.co.uk (Ronald Khoo)
To:        comp.unix.sysv386,comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: BOOTP or RARP under SCO Unix

kfl@access.digex.com (Keith F. Lynch) wrote:

> Does anyone have a BOOTP or RARP available for use under SCO Unix?
> SCO doesn't supply them, but we need them to load a Xyplex terminal
> server.  Thanks.

A long while back, I think it was Chip Rosenthal who posted a set of
patches to make bootpd work on SCO XENIX.  I built a binary of it in /tmp
and it worked fine.  So I deleted the source :-)  Two weeks ago, I
installed that same binary in my client's client's system (:-)
which runs SCO UNIX 3.2.4 with SCO TCP 1.1.3 and that xenix binary
seems to work fine there.  No warranty, but you can have that binary
if you like -- the binary is now on ftp.ibmpcug.co.uk [192.68.174.65]
as /pub/unix/ronald/bootpd.sco.

[ In view of the current state of the cancel wars, I guess I'd better 
  mail this too :-( ]
-- 
Ronald Khoo <ronald@demon.co.uk> <ronald@ibmpcug.co.uk> <ronald@robobar.co.uk>
BTNet: +44 71 229 7741                    | Brambles are the order of the day.

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jun 1992 22:34:53 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.unix.sysv386,comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: BOOTP or RARP under SCO Unix

In article <1992Jun22.031913.22996@access.digex.com>, kfl@access.digex.com
 (Keith F. Lynch) wrote:
>Does anyone have a BOOTP or RARP available for use under SCO Unix?
>SCO doesn't supply them,

The latest SCO TCP/IP for SCO UNIX has a BOOTP server, but I don't
know if this version of SCO TCP/IP is being sold separately from
the SCO ODT server package yet.

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 02:20:55 GMT
From:      peter@cujo.curtin.edu.au (Peter N Lewis)
To:        comp.protocols.tcp-ip
Subject:   Re: MacTCP & DNS & BOOTP

In article <1992Jun19.170214.9892@newshost.lanl.gov>, smj@beta.lanl.gov (Stephen M. Johnson) writes:
> 
> We're having trouble getting MacTCP to recognize the second nameserver in
> the configuration. Will MacTCP try the second server listed in the even that 
> the "default" server does not?

This is one of those entertaining puzzles the MacTCP designers included for
user ammusement :-)

What you have to do is make your MacTCP DNR definition (in the Control
Panel) look like this:

Domain               IP                        Default
curtin.edu.au      primary DNR server IP        YES
                  primary DNR server IP         NO
                  secondary DNR server IP       NO

Where primary DNR server IP is the ip number of your main DNR server and
secondary is your backup server.  Obviously you should use your own domain
instead of "curtin.edu.au".  And the dots in the other domain names are
required.

> We are interested in using BOOTP to provide IP address, subnet mask, etc to our
> Macs. Does MacTCP support RFC1048? 

No idea, sorry,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      peter@cujo.
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: +61 9 367 8141



-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 1992 03:15:57 GMT
From:      khale@camilla.Eng.Sun.COM (Abhijit Khale)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC - how do I reply twice to one request?

In article <1992Jun22.003005.12742@wpi.WPI.EDU> ralf@wpi.WPI.EDU (Ralph Valentino) writes:
#I'm writing a program (client/server) that sends a broadcast rpc and
#waits for results.  The client issues a clnt_broadcast().  The server(s)
#(created via rpcgen) do a svc_sendreply() when they have an answer.
#The answer is made up of 'n' structures of data using the _val and
#_len pointers created by the .x file and are just appended to each
#other at the client side.
#
#I ran into a problem when 'n' * structure size # udp allows - it
#completely ate my message (well, actually, it crashed the Ultrix
#portmapper, but that's another story).  I tried breaking it up into
#to parts (on a structure boundary) and calling svc_sendreply() twice,
#but the second one never got through even though the svc_sendreply()
#returned SUCCESS.  (each_result() was called only once per responding
#host).  Cacheing should be off.
#
#Playing with it further, I modified the xid of the first svc_sendreply()
#to something else, and then restored it for the second.  This time,
#the second went through.  This leads me to believe that the problem
#actually exists on the client side.
#
#Is the client caching replies and discarding the second?  How can I
#get around this (without turning the client into a server itself?)

The client doesnt really cache replies, but it does keep the transaction id
of an outstanding RPC call. A normal RPC server will use the same transaction
id in the reply. The client checks the reply to make sure that it has the
same transaction id. This is to ensure that old replies arent accepted by
mistake. So, yes, the client will silently discard replies with the wrong xid. 

But in this case, the reply probably doesnt even get as far as the
client. Calls using broadcast RPC (and replies to the same) are
forwarded by the portmapper, which will also discard a reply with
the wrong xid.

#Also, I found the breakdown point of udp's to be 6 structures of 64
#bytes each = 384, which is MUCH less than the expected 1400!  I
#realize some is used by the _val and _len pointers, but what about the
#rest?  (the structure is made up of a number of ints, longs, chars,
#and two strings of <16# characters each, if that makes any difference).
#

Well, I cant speak for the Ultrix implementation, but in standard ONC
RPC, the size limitation on the broadcast RPC call is based on the 
size limitation of broadcast UDP packets (typically = MTU on most BSD based 
systems). But thats on the call (which is a broadcast), not on the reply.
The size limitation on a reply should be the standard 8 K bytes. 
You should probably try and use an xdr_sizeof() to see how much space
your structures actually consume. 

Abhijit
Distributed Computing Technology Group

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 92 04:06:36 GMT
From:      lyndon@ampr.ab.ca (Lyndon Nerenberg)
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Where are the Clarkeson Packet Driver *Source* Files?

Can someone point me at a site that has the source for the Clarkeson
packet drivers? I need enough bits to be able to rebuild the 8250 based
SLIP driver.

TIA.

--lyndon

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 10:09:36
From:      jbvb@vax.ftp.com  (James B. VanBokkelen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: dis_pkt with token-ring?

The DIS_PKT we released as freeware was v1.05, which only supported CLass 1
(Ethernet) and didn't do match-all.  Joe Doupnik and others have modified
it, assigning versions up through 1.10; I'm fairly sure that at least Dan
Lanciani's version supprots Class 3 (802.5).  Meanwhile, the version we
ship (and support) with our "generic" PC/TCP is 1.25, and it supports
both "match all" and Classes 1, 3 and 11.

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


-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 09:04:32 GMT
From:      DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge & router descriptions requested


In article <1992Jun21.012149.14005@magnus.acs.ohio-state.edu>, I wrote:

>
>	I am looking for authoritative definitions for a bridge and a router.
>It is my (admittedly limited) understanding that a bridge essentially handles
>Ethernet packets and a router handles protocol-specific packets.  So, for
>example, LAT packets could get through a bridge, but they may or may not be
>handled by a router, depending on whether or not the router was designed
>(and/or configured) to route LAT packets.  If this analysis is essentially
>correct, where do combination bridge-router boxes fit in?  Please reply
>directly to me, and I will summarize.
>

	Thanks to the multitude who responded!  My descriptions turned out to
be fairly accurate, with the following notes:

	 - a bridge need not be limited to Ethernet; it could just as
	   easily bridge token-ring, FDDI, etc.

	 - a router cannot be configured to route LAT, since LAT carries
	   no routing information; LAT can only be bridged

A combination bridge-router (a.k.a. brouter) routes protocols its designed and
configured to route, and bridges protocols which can't be routed.

							Thanks,
							 Mike
--
 Internet: davism@KCGL1.eng.ohio-state.edu |
            -or- DAVISM+@osu.edu           |   These Thoughts, They Be Mine
   BITNET: DAVISM+@OHSTMAIL.BITNET         |

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 17:11:35
From:      fks@vax.ftp.com  (Frances K. Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for 10baseT

In article <Bq6Hv5.IDM@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

    In article <1992Jun20.175154.23742@njitgw.njit.edu> kdn5669@hertz.njit.edu (ken ng cccc) writes:
    >... IE: is it [10BaseT] really just ethernet on twisted pair?
    
    Sort of kind of.  The twisted-pair cable connects one (1) computer to a
    specialized multi-port repeater ("hub").  Yes, you need one cable per
    computer.  The combination of cabling and hub constitutes an Ethernet.

The packet header is identical to DIX ethernet, but the net is arranged in
a star topology, rather than a bus topology. 

--

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


-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 92 13:28:49 GMT
From:      larryp@sco.COM (Larry Philps)
To:        comp.unix.sysv386,comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: BOOTP or RARP under SCO Unix

In <1992Jun22.031913.22996@access.digex.com> kfl@access.digex.com (Keith F. Lynch) writes:

> Does anyone have a BOOTP or RARP available for use under SCO Unix?
> SCO doesn't supply them, but we need them to load a Xyplex terminal
> server.  Thanks.

Both are available in SCO TCP/IP 1.2, which is part of ODT 2.0, which
is now shipping.

---
#include <std/disclaimer>

Larry Philps,	 SCO Canada, Inc.
Postman:  130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
InterNet: larryp@sco.COM
UUCP:	  {uunet,utcsri,sco}!scocan!larryp
Phone:	  (416) 922-1937

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 92 13:29:43 GMT
From:      nelson@crynwr.com (Russell Nelson)
To:        comp.protocols.tcp-ip
Subject:   Where are the Clarkeson Packet Driver *Source* Files?

In article <78@ampr.ab.ca> lyndon@ampr.ab.ca writes:

   Can someone point me at a site that has the source for the Clarkeson
   packet drivers? I need enough bits to be able to rebuild the 8250 based
   SLIP driver.

They're in the same place as the executables, simtel20.army.mil (and
its many mirrors).  Here's how to get them (look for driver1.zip and
drivers2.zip):


		The Crynwr packet driver collection

Availability

The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem.  The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.

Mail:

Columbia University distributes packet drivers by mail.  The formats
are 9-track 1600 bpi tapes in ANSI, tar, or OS SL format, or PC
diskettes (360K 5.25" and 720K 3.5").  The exact terms and conditions
have yet to be worked out, please call (212) 854-3703 for ordering
information, or write to:

  Kermit Distribution, Dept PD
  Columbia University Center for Computing Activities
  612 West 115th Street
  New York, NY  10025

or send e-mail to kermit@watsun.cc.columbia.edu (Internet) or
KERMIT@CUVMA (BITNET/EARN).


FTP/email:

The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>.  The drivers are there, along
with many free programs that use the packet drivers.

SIMTEL20 files are also available from mirror sites OAK.Oakland.Edu
(141.210.10.117), wuarchive.wustl.edu (128.252.135.4), ftp.uu.net
(137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7) or archie.au (139.130.4.6), or by e-mail
through the BITNET/EARN file servers.

Modem:

If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956.  DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP).  This is a subscription system
with an average hourly cost of 17 cents.  It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial.  New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.

CD-ROM:

Public, private or corporate institutions and libraries interested
in the SIMTEL20 MSDOS collection in CD-ROM format bundled with
library card-catalog type access and duplication software can contact
Coyote Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307
or by FAX at (313) 651-4071.  Others who do not need the access and
duplication software should send e-mail to rab@sprite.berkeley.edu
(Robert Bruce) or telephone (510)947-5996 for details on his CD-ROM
offer.

UUCP:

The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr.  See UUNET.DOC for details.

-russ <nelson@crynwr.com>  I'm proud to be a humble Quaker!
Crynwr Software            Crynwr Software sells packet driver support.
11 Grant St.               315-268-1925 Voice   [ if mail bounces, forward it ]
Potsdam, NY 13676          315-268-9201 FAX     [ to uuadmin@uu.psi.com.      ]

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 92 15:23:36 GMT
From:      forman@hq.barco.su
To:        comp.protocols.tcp-ip
Subject:   Variable subnetmask for BSD 4.3 networking release 1

Has anyone married reno radix code for variable subnet masking with
BSD 4.3 networking release 1 ? Please reply here as I do not have
a reliable e-mail access.

Alex Forman

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 16:21:28 GMT
From:      gold@saturn.sdsu.edu (Dan Gold)
To:        comp.protocols.tcp-ip
Subject:   4.4 header prediction in 4.3-tahoe

In the interest of speeding up a 4.3-tahoe TCP/IP implementation, I grabbed
the header *prediction* (NOT compression) code from the 
4.4 tcp_input.c, and put it in the 4.3 tahoe version (In the same
place it's located in the 4.4 code).  This handy little
snippet of code is designed for uni-directional data transfer (i.e.
ftp).  I modified it for bi-directional (ACK and data in the same packet),
and run it on a server.  

Clients connect and data is transferred (much faster too!), but eventually
throughput decreases and the re-transmit timers on the client side time
out, and connections are dropped.  This happens long (minutes) after
data has stopped being sent.  I tried debugging with tcp_trace() and a
Lanalyzer and things "appear" normal.

Any ideas/suggestions as to why this is happening are welcomed.
Can it work, or is there some other underlying difference in
the 4.3/4.4 sources ?  Has anyone else done anything similar ?  

           	As usual, thanks in advance,
		            Dan		

                gold@sdsu.edu  
                {nosc,crash,your-favorite-gateway...}!sdsu!gold

				"Ah, it's great to be young and insane"
						-Michael Keaton, "The Dream Team"


-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 92 16:25:31 GMT
From:      pbrain@spider.co.uk (Source Control)
To:        comp.protocols.tcp-ip
Subject:   Re: 50 thousand TCP connections on Solaris 2.0/SVR4 - is it possible?

In article <124ulnINNhfi@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>[I've redirected followups to comp.protocols.tcp-ip.]
>
>In article <1992Jun22.131816.11980@spider.co.uk> ian@spider.co.uk (Ian Heavens) writes:
>>I don't believe it is necessary to allocate a full window size of memory
>>unless you are actually filling that window, which presumably is only
>>true for a small fraction of the TCP connections.
>
>The window is supposed to indicate how much data the TCP level is willing
>to buffer up.  So, if 1000 connections each advertise an 8KB window, you're
>claiming that you're prepared to buffer up 8MB.  I suppose you can be
>optimistic that most senders won't actually get that far ahead of the
>receiving processes, so the total of all the window sizes will be less than
>the amount of space reserved.
>

To support 10,000 to 50,000 connections, I think you have to....also,
basing memory requirements on statistical usage doesn't seem too rash
in this case.  I imagine that something else would break first if they
were all used in earnest (NB I wasn't claiming that this is the only
problem with supporting this number of connections).  
 
>Actually, I suspect many TCP implementations do this.  They use dynamic
>allocation of buffers (e.g. Unix mbufs), rather than allocating a separate
>buffer for each, and have a global constant that is the per-connection
>window size.  This brings up the question of how meaningful the window
>really is in such implementations?  If most of the receiver processes stop
>reading their input (perhaps they're all waiting for some resource to
>become available), the buffer pool might be exhausted before many of the
>windows are filled.  At that point I guess the system can simply close all
>of the windows.  One problem with an optimistic scheme like this is that it
>can result in deadlock if the common resource most of the receivers are
>waiting for is held by a process that's waiting on another TCP connection
>(this is similar to overallocation of disk quota: if the disk fills
>completely, you can't compress files to make room because you temporarily
>need space for both the compressed and uncompressed versions).

True, some kind of deadlock avoidance or recovery is needed (how to do 
this without aborting connections is another question, although priority 
based memory allocation schemes might help).  The likelihood of this 
happening decreases as you allocate more memory, so there is a tradeoff 
here.  Again, surely 20,000 data sinks is going to break something
somewhere, so we have to assume that most of these connections will be
idle. 

I guess it depends on whether the offered window must indicate memory
available and previously allocated.  In that case, the only way of 
supporting large numbers of connections would be to dynamically reduce the 
offered window for idle connections (somehow detecting this and avoiding 
window shrinkage), I suppose.

The above is speculation rather than a considered opinion, but it's
an interesting subject.

ian


---
Ian Heavens				ian@spider.co.uk                 
Spider Software
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4346)
--

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 17:29:46 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.unix.sysv386,comp.unix.questions,comp.unix.admin,comp.protocols.tcp-ip,comp.dcom.lans.ethernet
Subject:   Re: BOOTP or RARP under SCO Unix

>kfl@access.digex.com (Keith F. Lynch) wrote:
>> Does anyone have a BOOTP or RARP available for use under SCO Unix?

In article <Bq9nLr.KI4@gate.demon.co.uk>
	ronald@gate.demon.co.uk (Ronald Khoo) writes:
>A long while back, I think it was Chip Rosenthal who posted a set of
>patches to make bootpd work on SCO XENIX.

It was.  The patches work on SCO UNIX, too.  If you want them, drop me
a line.  I believe SCO TCP/IP 1.2 includes `bootpd', but if you want
`bootpd' on 1.0 or 1.1 you'll need to pickup the CMU bootp server
source (uunet has it, among other places) and apply my patches.

The messiest part of the port is that the SIOCSARP ioctl()s are a
little twisted in 1.0 and 1.1.  I've heard a rumour that they are more
BSDish in 1.2.

-- 
Chip Rosenthal  512-482-8260 | Let the wayward children play.  Let the wicked
Unicom Systems Development   | have their day.  Let the chips fall where they
<chip@chinacat.Unicom.COM>   | may.  I'm going to Disneyland.  -Timbuk 3

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 18:41:24 GMT
From:      bob@astph (Bob Ford)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   SLIP and Kernal Panics

Our set-up is a 486-33 EISA running ISC/Sunsoft 3.0.  We can get SLIP up
over a  leased line, and it works fine for a few days, then a Type E
Kernal panic!  Bad news, to say the least  :(  We are running out of ideas.
Sunsoft thinks it is the Digi C/Con system we are running through.  The
basic path of the signal is out through the Digi box, into a Micom 1K,
over the 56K leased line, into another  Micom, another Digi, and into the
remote CPU.  This remote machine is virtually identical, but has never
experienced the panics we have (oh, the remote machine is a 386, not a
486.  Also, the remote system is not loaded nearly as heavily as ours
is).   BTW, when we removed SLIP, the Kernal panics went away.

So, is anyone out there running a direct connect SLIP (using slattach)
through  a Digi C/Con system at 38400?  Do you have any idea about what
line settings we should be using for the SLIP lines?  The reason I ask
is that we have observed that telnet doesn't work on lines that have
the fastcook option turned on.  Our first thought is to try to turn off
fastcook via the ditty command, and turn on flow control on the Digi
ports that have the SLIP line.  The Micom doesn't have cts and rts flow
control, only DTR or XON/XOFF.  Of course, the Digi box and flow 
control issues may not be the problem at all......

Any ideas you might have for us would be appreciated.
-- 
Bob Ford                           (814) 234-8592x36
INTERNET: astph!bob@attmail.com     UUCP: attmail.com!astph!bob
Philadelphia Phillies

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 92 20:22:05 GMT
From:      sat@tridom.uucp (Stephen Thomas)
To:        comp.protocols.tcp-ip
Subject:   Multicast Transport Protocol

Anyone know of any implementations (commercial or public domain) of 
the Multicast Transport Protocol (RFC 1301)?

Thanks,
Stephen Thomas (sat@tridom.com)

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 92 20:35:34 GMT
From:      chad.w.german.1@nd.edu (Chad W. German)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Telnet 2.305B

I'm having problems with Telnet v. 2.305 B with IBM PS/2 with monochrome 
monitor (ps/2 mod 30/286)....... When launching the telnet.bat, my screen 
blanks out before I can even perform the Alt-A for the machine name to 
telnet to...... Within the config.tel fire I have changed the colors scheme 
to black and white but I think this is for after you connect to a host...... 
TN3270 application works just fine.......  Any suggestions.....

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jun 1992 23:44:25 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for 10baseT

In article <920623171135@desire.ftp.com> fks@ftp.com writes:
>    ... The combination of cabling and hub constitutes an Ethernet.
>
>The packet header is identical to DIX ethernet, but the net is arranged in
>a star topology, rather than a bus topology. 

The similarities go much deeper than having the same header.  The contention
protocol for network access, for example, is also the same.  At the AUI
port, you can't tell which kind of network you have.  10BaseT acts exactly
like traditional Ethernet as far as the hosts are concerned.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 01:51:38 GMT
From:      tru@kddnews.kddlabs.co.jp (Tohru Asami)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP for Ultrix 4.2


Since I cannot send a mail to st12w@menudo.uh.edu from here, I'll
post it here again.

In article <1992Jun22.121645.18566@menudo.uh.edu> you write:
>I've been trying to get a slip connection to my local Ultrix 4.2 Unix, but
>all the slip implementations I've seen on archie are Sun, which don't seem
>to compile on this machine (lots of unknown .h files and constants).
>
>Are there any good implementations?  Has anybody gotten it to compile on an
>Ultrix?  If so, could somebody send me a copy of the headers that you had
>to find?  (sockio.h, etc.)
>
>(neither cslip nor slip-4.1 wants to compile on this system)

I have same problem. One of the alternative is to use the
SLIP program in the ULTRIX Unsupported Software subset. I have
succeeded installing it into my DECstation 3100, 5000/200. However
we have one DECstation under ULTRIX 4.0, on which I failed to run SLIP.
The SLIP in the 4.0 kit cannot run properly.

So I have been trying to get a PD SLIP for ULTRIX in a source code.
If you have any response on this, please let me know.

Regards,

Tru


--
Tru (Tohru Asami)
Artificial Intelligence Group, KDD R&D Labs.
2-1-15 Ohara Kamifukuoka-shi, Saitama 356, Japan
Phone: +81 492 66 7383 FAX  : +81 492 66 7512

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 02:49:38 GMT
From:      drw@nevanlinna.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <920622095515@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes:
   "Connectionless" means that there is no state at either the source or the
   destination of the message.  Thus, a connectionless protocol cannot
   guarantee delivery.

True, but absolute connectionlessness isn't necessarily the important
criterion.  RPC-type protocols normally keep transaction IDs around
for any transactions that have been sent recently enough that
retransmissions might be seen.  But that state times out pretty
quickly, so there's no long-term state to be maintained.  That's a
good tradeoff if the amount of data sent to any one server at any one
time is quite small.

The TCP approach requires a number of packets to be exchanged just to
set up the connection, plus state that must be maintained for the
entire duration of the connection.  Thus, to send small amounts of
data to a host at infrequent intervals either requires paying for the
connection continuously or paying the setup/breakdown overhead for
each transmission.  (But that's a good tradeoff if there is going to
be lots of data sent over a short period of time.)

The difference isn't that one is truly stateless, but that each is
optimized for different usage characteristics.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
--
Let us go back to the old term "Women's Liberation".  It expresses the
essence of the situation better -- men are free, women are enslaved.
Let us free women to succeed or fail by their own efforts, to conquer
or be conquered.

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 03:08:18 GMT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

In article <1992Jun22.080052.5547@Unibase.SK.CA> roe@Unibase.SK.CA (Roe Peterson) writes:
>louie@sayshell.umd.edu (Louis A. Mamakos) writes:
>
>>Likely the reason that this doesn't work is because on most UNIX
>>boxes, SLIP is implemented as a line discipline; when you put a tty in
>>SLIP mode, you change it to use the SLIP line discipline.
>
>"Most" unix boxes?  What about all the STREAMS boxes out there?
>IE: all System 5 Rel. 3 and up?

I guess "most" is relative.  At my shop, "most" of the UNIX boxes are
BSD derivatives without streams.  

louie



-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 03:10:21 GMT
From:      ddl@burrhus.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: dis_pkt with token-ring?

In article <a9000005.709176655@tscc2>, a9000005@tscc2.macarthur.uws.edu.au (Brian Watson) writes:
| 
| Hi,
|    I am attempting to get dis_pkt to work.  I am using a PS/2 55 with 
| a genuine IBM token-ring card.  I have the NDIS drivers and the dis_pkt
| from vax.ftp.com.  I have tried other dis_pkt with similar results.

	There are several different issues here:

| When I try to use the Delft netcapt with this setup, it complains that
| it cannot get (or set?) the packet mode.

	Most Token Ring NDIS drivers make it difficult to put the
board in promiscuous mode and this is what netcapt would like to
do.  As far as I know, the genuine IBM cards simply don't let you
do this at all.  The 3c603 requires a special argument to the NDIS
open_adapter function and my version of dis_pkt on hsdndev.harvard.edu
is set up to perform the necessary close/open sequence when the
packet driver setreceivemode is invoked.  It is possible that other
boards based on the TI chip set will work also.

| It then captures packets but
| they are corrupt.  The addresses appear to be shifted 4 bytes to the 
| right and left filled with 'f' and the last 4 bytes are moved into the
| 'type' field.

	This is because netcapt does not understand Token Ring frame
formats.  A Token Ring frame has two bytes of control information
followed by the addresses.  (Are you sure it was 4 and not 2 bytes of
shift?)  Perhaps the authors of netcapt could be persuaded to add
Token Ring support.

| When I try CUTCP, it recognises the packet driver but will not open any
| connections.  It also reports an ethernet address of 0:0:0:0:0:0.

	CUTCP doesn't seem to support Token Ring packet drivers.

| I use IBMTOKEN.COM packet driver normally, but it will not go into mode 6
| to allow me to properly use the Netcapt.

	It is very unlikely that this could ever work:  IBMTOKEN.COM
is isolated from the card by many layers of adapter software so setting
promiscuous mode isn't implemented.  Even if it were, IBMTOKEN.COM would
have to support mapping for any Token Ring frame that you were interested
in seeing.

				Dan Lanciani
				ddl@harvard.*

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 08:26:19 GMT
From:      ian@spider.co.uk (Ian Heavens)
To:        comp.protocols.tcp-ip,comp.unix.internals
Subject:   Re: 50 thousand TCP connections on Solaris 2.0/SVR4 - is it possible?

In article <1992Jun23.162531.1859@spider.co.uk> ian@spider.co.uk (Ian Heavens)
) writes:
>In article <124ulnINNhfi@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>[I've redirected followups to comp.protocols.tcp-ip.]
>>
>>In article <1992Jun22.131816.11980@spider.co.uk> ian@spider.co.uk (Ian Heavens) writes:
>>
>>The window is supposed to indicate how much data the TCP level is willing
>>to buffer up.  So, if 1000 connections each advertise an 8KB window, you're
>>claiming that you're prepared to buffer up 8MB.  I suppose you can be
>>optimistic that most senders won't actually get that far ahead of the
>>receiving processes, so the total of all the window sizes will be less than
>>the amount of space reserved.
>>
>
>I guess it depends on whether the offered window must indicate memory
>available and previously allocated.  In that case, the only way of 
>supporting large numbers of connections would be to dynamically reduce the 
>offered window for idle connections (somehow detecting this and avoiding 
>window shrinkage), I suppose.
>

Allocating buffer pools for TCP windows from virtual memory would fix
this one; currently, this can only be done if TCP runs as a user process 
(follow ups back to comp.unix.internals).  Virtual memory seems the right
paradigm for offering 200 Mbytes of guaranteed memory; the 'working set'
should be in the low megabytes, with a lot of handwaving.

Otherwise, I think a well tuned TCP implementation would have to
be very conservative and dynamic about offered windows, detecting when the 
offered window is not being filled and winding it down and up appropriately, 
which current implementations lack. One half of an ftp data connection (the 
sending side) never gets any data (just SYNs, FINs) into its window; it still 
seems like overkill to use 4K of real memory.

ian


---
Ian Heavens				ian@spider.co.uk                 
Spider Software
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4346)
--

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 11:05:15 GMT
From:      claude@bauv106.informatik.unibw-muenchen.de (Claude Frantz (RZ))
To:        comp.protocols.tcp-ip
Subject:   Routing Question about UNIX

Hello !

Assuming a classical UNIX host having an Ethernet Adapter Card
connected to a LAN with the following command:

ifconfig interface 155.77.88.99 netmask 0xffffff00 broadcast 155.77.88.255

Assuming on the same Ethernet LAN, there is another subnet having
the address range 155.77.33.* (the same netmask applies).

Assuming there is a host with address 155.77.33.6 which should
be the default routing gateway for all the traffic outside of
the TWO mentioned subnets.

What are the correct entries for the "route" command ?

Many thanks to all the people helping me !

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 13:47:34 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   Dialups and virtual devices

I have a couple of problems I'm trying to get solved.

1)  How to set up a slip (or PPP) line for an AT&T 3b2 600.
   -  preferably ppp since I need something that will be ftp tcp/ip layer
	based for the pc.

2)  Specifications for 10net plus so that we can make advertised pc devices
attach to our at&t 3b2
   -  Just the printers actually.  We want to be able to lp to some user's
	printer from unix

Any help with the following problems would be greatly appreciated

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 14:54:48 GMT
From:      kelly@searchtech.com (Kelly Thompson)
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc
Subject:   PCNFS 4.0, 3COM,& NDIS drivers

I would like to run both the 3com netbios protocol and PCNFS tcp-ip protocol
simultaneously.  The PCNFS manual says that it should be possible to use NDIS
drivers.  I am currently using XNS and dis_pkt.dos from FTP with winqvt. 

Seems like this should be a fairly simple switch, but it hasn't been.
If you are doing this successfully could you send me email.

Thanx.  Kelly.
-- 
-----------------------------------------------------
 ////====  Kelly Thompson (kelly@searchtech.com)    |
||||	         Search Technology, Inc.	    |
=========  4725 Peachtree Corners Circle, #200	    |

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 92 15:03:57 GMT
From:      ptrubey@netcom.com (Phil Trubey)
To:        comp.protocols.tcp-ip
Subject:   AIX and PC-NFS LPR interoperabilty?

We have been experiencing some interoperability problems between
AIX on an RS/6000 and PC-NFS running on PCs.  Specifically, we
are trying to send print jobs *from* the RS/6000 to the PCs
using the LPR protocol.  Basically, it doesn't work.  Has anyone
else run into this type of problem before, either with AIX
or with PC-NFS?

As always, thanks for any info.

-- 

Phil Trubey                   | Internet: ptrubey@netcom.com
Systemhouse Inc.              | Voice:    415-243-8100 (day)  
                              | Fax:      415-243-0471

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 92 20:07:35 CDT
From:      jlw@improb.cls.com (Jeff Wannamaker)
To:        comp.protocols.tcp-ip
Subject:   Does TCP/IP support broadcast packets?

I've been reading manuals trying to circumvent receiving RTFM comments,
but still have not found out yet whether TCP/IP supports broadcasting
packets using sockets.  At work we are trying to figure a way to reduce
network traffic on a token-ring network by sending global database
updates to all processors in a specific subnet.  By addressing updates
to specific nodes, we will quickly saturate the network as more
functionality is implemented into the system.

I know that UDP datagrams support broadcasting, but fear implementing
at that level since we would also have to do our own buffer sequencing
and error detection.  Can anyone tell me if this can be done using
TCP/IP or are there plans in-the-works for supporting broadcasting
within the realm of TCP/IP?

Any other information related methods for global or masked broadcasting
would be greatly appreciated.

--
Jeff Wannamaker,  jlw@improb.cls.com  OR  ...!uunet!cls!improb!jlw
Talk is cheap.  Not in Congress.

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 15:25:24 GMT
From:      dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small)
To:        comp.protocols.tcp-ip
Subject:   netbios and unix boxes

I'm trying to do things a little backwards from normal.  

We're wanting to be able to print to a PC printer (using 10net, on top of
pc netbios, trw's netbios (an ftp clone, I think)) from a unix box (at&t
3b2).

I have rfc 1001 and 1002, but I was hoping that someone else has already
gone down this road....

Any suggestions?

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 16:05:13 GMT
From:      lbroda@s.psych.uiuc.edu (Larry Broda)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   HELP: bootp response from remote subnet ignored

We are trying to to configure the PCs in our departments to get their
NCSA/Clarkson telnet (or FTP TCP/PC) configurations via bootp, and
this works fine if the server is on the same subnet.  However, we have
four subnets; there are connected to each other and the world via a
Proteon gateway box which has been configured to pass bootp packets
across the gateway to other servers if the server on the PC's subnet
doesn't respond.  Our aim is to provide some redundancy in case of
system crashes.  However, the PCs refuse to acknowledge the bootp
responses that don't come from their own subnet.  I've monitored the
packets and know they are being routed across the networks correctly.
Any ideas?  Is a special bootp configuration required. 

(The servers are Suns running bootp 2.1 under SunOS 4.1.1).

Thanks in advance,

Larry Broda
Department of Psychology,
University of Illinois
email: lbroda@s.psych.uiuc.edu

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 16:27:41 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for 10baseT

In article <1992Jun20.175154.23742@njitgw.njit.edu>, kdn5669@hertz.njit.edu (ken ng cccc) writes:
|> My apologies if this is not the correct group or if this is an FAQ (I
|> checked the local article list and did see anything marked as FAQ).  Is
|> there an RFC for 10BaseT and if so what number is it?  I got the rfc list
|> from wuarchive, but did not see anything obvious.  Also, what other RFCs
|> will be needed to learn how it works.  IE: is it really just ethernet on
|> twisted pair?
|> 
|> -- 
|> Kenneth Ng: kdn5669@hertz.njit.edu
|> "No problem, this is how you make it" -- R. Barclay, ST: TNG
10baseT is defined by the IEEE.  It is one of the options for 802.3.
Be aware that most vendors only run the physical layer defined here.
The protocol running on the network is the same as ethernet.  RFC1042
shows how IP is run over the different IEEE lan specs.

If you are new to this you might want to check out some entry level
books from a technical book store.  The James Martin books are pretty
good in this area and give a good background.  If you need it for
doing wiring, I like to look at the 2 to four pages of information
offered in some of the cabling cataloges like "Black Box".

For an academic need, get the actual specs.  They really aren't that 
difficult and you can limit yourself to the areas you need to know.

Welcome to the Klub.

-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 17:50:42 GMT
From:      mwr@tridom.uucp (Mark Reardon)
To:        comp.protocols.tcp-ip
Subject:   Re: reliably delivered UDP

In article <9217500.8256@mulga.cs.mu.OZ.AU>, kre@cs.mu.oz.au (Robert Elz) writes:
|> In <920622095515@cream.ftp.com> jbvb@vax.ftp.com (James B. VanBokkelen) writes:
|> 
|> | "Connectionless" means that there is no state at either the source or the
|> | destination of the message.
|> 
|> This has to be the most bizarre definition of connectionless I've
|> ever seen - sounds more like a definition of stateless.
This is the definition I have used for about years.  I didn't question
it because it was given to me as a definition.  I learned long ago not
to question teacher's definitions.

|> 
|> There may be somewhere where "connectionless" is defined that way, but
|> it can hardly represent what most people expect the term to mean - which
|> is that there is no requirement to set up some kind of "connection"
|> before sending traffic - or if you like, there's no need to tell anyone
|> that you're planning to send data, you simply send.
I also accept this.  Example; With SNMP over UDP there is no session 
at the UDP layer.  The NOC sends a message and the managed device responds.
It does not keep track of the message except that it should update the
snmp MIB.  The managed device and the NOC keep no record of the UDP
transactions.  The SNMP data can however be used to drive a state machine
in the NOC.  This means UDP is connectionless but SNMP is not.  This makes
sense to me.

|> 
|> If we accept that connectionless and connection-oriented together
|> represent the universe (if there's a third contender, I've not come
in my recent readings of 802.2 there is talk of types 1, 2 and 3.  They
are called connectionless, coneection oriented and acknowledged 
connectionless.  I need to request the spec. so I can read this over.

|> across it), then your definition would have SNMP, DNS (using UDP) and
|> even ARP classified as connection oriented protocols (they all keep
|> state at at least one end).   That's weird.
I don't find this weird at all.  Most things communicate for a purpose.
The knowledge requested and transfered are used by the requesting end for
some purpose and knowledge of where the information is requested from is
maintained.  This sounds to me like a connection.  In this context it is
hard to imagine a completely connectionless information exchange.  On the
other hand, it is perfectly plausible to use connectionless protocols at
the lower layers to eliminate unwanted overhead.

|> 
|> | So, every time this came up in the past, the next stage was to ask the
|> | person looking for a "reliable connectionless protocol" or somesuch what
|> | was really needed.
|> 
|> My impression is that many (though certainly not all) people who ask for
|> this really don't cae about the protocol at all - what they want is a trivial
|> way at the program interface level to send a single reliable message
|> to some destination in (what to me is) a connectionless way - that is,
|> they package the address with the data, however the local interface
|> expects to find it, and do one OS call to send it.  From that point they'd
|> like the message delivered reliably - often they don't care a lot about
|> sequencing, and sometimes not about duplicate delivery, they just want
|> the message delivered (or an effor returned) - without either needing to
|> make a connection (do any preparation) at the application level, or keep
|> any state/times for retransmit at the application level either.
|> 
|> Much of this is probably inspired by the socket model (though I believe
|> TLI is much the same) where each "connection" takes a file descriptor,
|> and several OS calls to get the thing ready, whereas "connectionless"
|> communications require just one simple setup cal to get a socket to send on,
|> then one simple call per message to send, regardless of the destination
|> of the message.
|> 
This reminds me of a request for preforming credit card authorization 
over an X.25 network using fast select.  The customer was charged by the
packet and this method used less packets but it churned the PDN.  It
was eventually dropped as the customer found the PDN didn't support fast 
select (I wonderwhy :-)).
|> kre
 
-- 
Mark

---------------------------------------------------------------------
| Mark Reardon           |  AT&T Tridom                             |
| mwr@eng.tridom.com     |  840 Franklin Court                      |
|                        |  Marietta, GA 30067                      |
---------------------------------------------------------------------
 

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 18:44:24 GMT
From:      knutson@mcc.com (Jim Knutson)
To:        comp.protocols.tcp-ip,comp.lang.perl
Subject:   Re: Perl script to check for DNS configuration flaws?


Doc was written by Steve Hotz (hotz@isi.edu) and Paul Mockapetris
(pvm@isi.edu).  It's available on the internet somewhere.  I made some
mods to it to allow it to be run from a script which in turn is run by
cron.  It works reasonably well.  However, doc and the scripts are not
written in perl.  If anyone wants a copy, let me know.

-- 
Jim Knutson
knutson@mcc.com
cs.utexas.edu!milano!knutson
Wk: (512) 338-3362

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jun 1992 18:52:44 GMT
From:      knutson@mcc.com (Jim Knutson)
To:        comp.protocols.ppp,comp.protocols.tcp-ip
Subject:   SLIP/PPP setup questions

I have some questions getting this going correctly.

1) Is there an RFC or something somewhere that describes the hows and
   whys of IP address assignment for use in SLIP/PPP connections?  More
   specifically, is it required that each SLIP/PPP connection use a
   different subnet or are point-to-point connections a different type
   of beast as far as routing goes.

2) Is there a simple gated config file somewhere for just adding these
   type connections to a host?

-- 
Jim Knutson
knutson@mcc.com
cs.utexas.edu!milano!knutson
Wk: (512) 338-3362

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 22:29:26 GMT
From:      ken@bridge.COM (Ken Hardy)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Source Code

I'm looking for any and all potential sources of source code for TCP/IP
kernels, whether they be public or commercial.  All that I'm currently
aware of is PC/IP (?) for DOS.  Can anyone point me to other
resources?  Many thanks.

If you care to reply via e-mail, I'll post a summary.

Ken Hardy
ken@bridge.com  (racerx!ken)

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 92 23:19:53 GMT
From:      ss0r@ns1.cc.lehigh.edu (SHEN SHENG )
To:        comp.protocols.tcp-ip
Subject:   Help:Can Not Connect To Host



We are trying to run NCSA/Clarkson telnet (or FTP) to carry out the file
transfer between the pc and the Tek 4317. There is 3c501 etherlink board from
3com on the pc , the Tek 4317 is running Utek 3.0 which is unix-bsd clone. For
some reason we  don't have access to the globle internet.The problem is how
can we give proper addesses to these two compters to make them communicate.
(it could be considered as a small 2-node lan ). How do we make the workstation
recognize the pc?

 Thank-you in advance !!

 ss0r@ns1.cc.lehigh.edu

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 11:06:52
From:      mrl@uai.com (Mark R. Ludwig)
To:        comp.arch,comp.protocols.tcp-ip
Subject:   Re: Big Endian to Little Endian Conversion in Data Structures

In article <aj_lc#f.rcain@netcom.com> rcain@netcom.com (Robert Cain) writes:

   chris@visionware.co.uk (Chris Davies) writes:
   : Oh yes, there's now a reasonably good Nutshell book about RPCs which is
   : well worth getting and reading in conjunction with the relevant RFCs.

   Yes?  And it is...   :-)

Probably:

   Bloomer, John.  _Power_Programming_with_RPC_.  Sebastopol, CA:
   O'Reilly & Associates, Inc., 1992.  ISBN: 0-937175-77-3.

There are some well-known errata.$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
  "AIX overall is weird with a beard.  But I like smit."  -- Chip Salzenberg

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 07:48:49 GMT
From:      romkey@asylum.UUCP (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP support broadcast packets?

jlw@improb.cls.com (Jeff Wannamaker) wrote about broadcasts and TCP/IP;

IP supports the notion of broadcast datagrams on physical networks that
support broadcast. UDP will operate over broadcast. However, TCP supports a
one-to-one connection, not a one-to-many connection, and is not intended
to operate using broadcast packets. I doubt you'll find a TCP implementation
*anywhere* that could handle broadcast, one-to-many communication properly.

Somebody else more up-to-date on other protocol work will have to answer
about what you might consider using instead.
-- 
	- john romkey	  ELF Communications	 romkey@ELF.com

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1992 09:05:54 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing Question about UNIX

In article <claude.709383915@bauv106> claude@bauv106.informatik.unibw-muenchen.de (Claude Frantz (RZ)) writes:
>Assuming a classical UNIX host having an Ethernet Adapter Card
>connected to a LAN with the following command:
>
>ifconfig interface 155.77.88.99 netmask 0xffffff00 broadcast 155.77.88.255
>
>Assuming on the same Ethernet LAN, there is another subnet having
>the address range 155.77.33.* (the same netmask applies).
>
>Assuming there is a host with address 155.77.33.6 which should
>be the default routing gateway for all the traffic outside of
>the TWO mentioned subnets.
>
>What are the correct entries for the "route" command ?
>
>Many thanks to all the people helping me !

For hosts on the 155.77.33 subnet, you should use

route add 0.0.0.0 155.77.33.6 1

For hosts on the 155.77.88 subnet, you haven't supplied enough information.
You need a router between the 88 and 33 subnets, or you need to configure
155.77.33.6 to have an address on the 88 subnet as well (how you do this
is dependent on the version of Unix -- at worst you would have to add
another interface).

Remember, IP deals only with logical subnets.  The fact that the 33 and 88
subnets are on the same physical wire is invisible to IP.  Only hosts on
the same logical subnet can communicate directly, and you can only talk to
a router on your own subnet.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 15:12:59
From:      ljm@vax.ftp.com  (leo j mclaughlin iii)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <JH.92Jun2201955@etana.funet.fi> jh@etana.funet.fi (Juha Heinanen) writes:

>I have found that most current router implementations (and also
>routing protocols) don't match very well with the fact that a single
>physical interface can consist of several logical interfaces each
>possibly with their own IP address and metrics, eg. access speed.
>This problem doesn't only show up in FR, but also in X.25, SMDS, and
>ATM.  Based on my experience I have got the feeling the whole old
>internet routing model and routing protocols needs major revision.
>

While I am more than willing to agree that IP could use some work, I don't
accept the arguement that the current ATM technologies are a driving force
behind that work.

If ATM doesn't work well with TCP/IP and doesn't work well with Netware
and doesn't work well with NetBEUI and doesn't work well with Decnet and
doesn't work well with SNA, I have to wonder to whom the ATM vendors expect
to sell product.

It seems much more likely that the existing 'new wave' of hardware will
change to meet users needs then the users will change their needs to meet
the hardware.

enjoy,
leo j mclaughlin iii
ljm@ftp.com


-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 11:49:14 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP support broadcast packets?

check gregorio.stanford.edu:vmtp-ip/ipmulti-sunos411.tar.Z
It includes documentation and patches for IP Multicasting on SunOS
4.1.1. Also - Solaris 2.0 will support multicasting.

Multicasting allows a packet to be sent to several machines without
broadcasting to the entire network. It uses the Internet Class D addresses.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 12:21:52 GMT
From:      dabbous@pax.inria.fr (Walid Dabbous)
To:        comp.protocols.tcp-ip,comp.protocols.misc
Subject:   Info about IP multicast on dec station needed

Hello,

I am looking for a binary release of the Ultrix 4.2A kernel with
the IP multicast extensions. We have a patch file corresponding
to this version updating some *.c files while we only have a 
standard release of Ultrix.

please reply by e-mail: dabbous@sophia.inria.fr

Thank you in advance.


Walid Dabbous
INRIA Centre de Sophia Antipolis        

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 13:37:32 GMT
From:      tom@dickens.com (Tom Gillman)
To:        comp.protocols.tcp-ip
Subject:   Re: netbios and unix boxes

In article <1992Jun24.152524.28925@nmrdc1.nmrdc.nnmc.navy.mil> dsc3jfs@nmrdc1.nmrdc.nnmc.navy.mil (Jim Small) writes:
>I'm trying to do things a little backwards from normal.  
>
>We're wanting to be able to print to a PC printer (using 10net, on top of
>pc netbios, trw's netbios (an ftp clone, I think)) from a unix box (at&t
>3b2).
>
>I have rfc 1001 and 1002, but I was hoping that someone else has already
>gone down this road....
>
>Any suggestions?

There is an excellent package which does just that, as well as many other
DOS<-->UNIX interoperability functions. It is called POWERFUSION/POWERLAN
by Performance Technology. Their info number is 1-800-PC-2-UNIX
However, I'm not sure if they run on a 3B2.
later,
  -- Tom
--
Tom Gillman                                  | Internet:  tom@dickens.com
Systems Integration - Dickens Data Systems   | uucp:   ...uunet!ddssuprs!tom
"HELP!!! It says 'Press any key to continue', and I've looked everywhere on the
 machine, but I can't find the <ANY> key" - This really happened to me, honest!
-- 
Tom Gillman                                  | Internet:  tom@dickens.com
Systems Integration - Dickens Data Systems   | uucp:   ...uunet!ddssuprs!tom
"HELP!!! It says 'Press any key to continue', and I've looked everywhere on the
 machine, but I can't find the <ANY> key" - This really happened to me, honest!

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 13:59:05 GMT
From:      J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: 50 thousand TCP connections on Solaris 2.0/SVR4 - is it possible?



 >Otherwise, I think a well tuned TCP implementation would have to
 >be very conservative and dynamic about offered windows, detecting when the 
 >offered window is not being filled and winding it down and up appropriately, 
 >which current implementations lack. One half of an ftp data connection (the 
 >sending side) never gets any data (just SYNs, FINs) into its window; it still 
 >seems like overkill to use 4K of real memory.

hmmm,

surely a 1 way applicatrion could setsockopt the window down to zero -
in fact unless the applciation issues a read...you could default that
way...

by the way, just what is user space these days?:-)

 >Spider Software

and what's the difference betwixt spider systems anbd spider software
- a web of intrigue (i think we should be told)?

 jon

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 14:45:58 GMT
From:      innocente@sissa.it
To:        comp.dcom.sys.cisco,comp.sys.dec,comp.protocols.tcp-ip,comp.os.vms
Subject:   New DEC DECNIS routers


	It seems that within a few months we will have to cross
	some of the new Digital DECNIS 500/600 routers to reach
	our national backbone.
	I don't have too many details about their architecture:
	it seems they are using a CVAX processor and the FutureBus+.
	They are speaking about 100 kpackets/sec as troughput.
	They will be configured as dual routers, supporting 
	the Decnet/OSI and tcp/ip protocols using the dual is-is
        routing.
	Snmp scheduled but not yet available.
	Can anyone comment on 
	- the performance of such routers in a tcp-ip environment
	- their compatibility with Ciscos ( is dual is-is  available
          in the forthcoming release of Cisco's software ?) in a
          Decnet IV/V - TCP/IP environment
        - the scheduled plans for OSPF, snmp,sna support for the DECNIS ?

	Thanks in advance.
	If you mail me, I will summarize for the net.

	Roberto Innocente
	

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 15:08:32 GMT
From:      atul@yoko.rutgers.edu (Atul Sharma)
To:        comp.protocols.tcp-ip
Subject:   Public domain network interface driver?


I am new to the newsgroup and don't know whether it is a FA(stupid?)Q.
Excuse me, if it is. I couldnot wait till FAQ list is posted and didnot
know where it is archived.

Well, the question is:

Are there any public domain network interface (not necessarily Ethernet)
drivers (for Unix) that one can look at? 

Any help regarding this shall be greatly  appreciated. Thanks in Advance.

--Atul
-------------
atul@paul.rutgers.edu

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 16:15:43 GMT
From:      MLYNCH@cmsa.gmr.com
To:        comp.protocols.tcp-ip
Subject:   Wollongong vs. TGV vms tcpip


   Could someone provide me with some information on how TWG's and TGV's tcpip
products compare?  I know TGV is substantially cheaper that TWG's.  Does this
mean there are features that aren't in TGV's product that are in TWG's?  We
have been using TWG's tcpip for a couple of years, but are considering TGV's
because it is cheaper and we are upgrading systems.  We also have written some
socket based programs with TWG's tcpip.  Has anyone ever converted a TWG socket
program to run on TGV's tcpip?  How do the telnet, ftp, etc. interfaces and
options compare?  Also, I have written LPD filters to enable users to specify
different forms and setups to queues on the vax.  Does TGV's product have the
same capability?  Thanks in advance for any information!!


                              Mary Lynch
                              mlynch@cmsa.gmr.com

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 1992 22:55:10 EDT
From:      hobbit@vax.ftp.com (*Hobbit*)
To:        comp.protocols.tcp-ip
Subject:   routing redirect question

I just slogged through RFC1009 [gateway requirements] and played with some
routers locally, and something seems severely amiss to me.  Envision the
following setup:

I have an organizational spine that is connected to two "clouds" via two
separate routers.  I am behind a third router on this spine, and I want to
reach another site that is in one or the other cloud but I'm not sure which.

Let's assume that the router for cloud A has a huge RIP table telling it
how to reach just about everything inside of cloud A.  Since other destinations
must be in the other cloud someplace, the router for A has the router for 
cloud B as its default gateway.  The third router, the one I'm coming through,
has to have SOME default gateway, so it's arbitrarily been assigned router A.

My connect attempt is thus sent to router A who suddenly realizes that where
I'm going is not in cloud A, passes my packet to router B, and tries to send a
redirect telling me to use router B instead.  But I'm behind the third router,
with my hosts's gateway set to that very same third router, on a different
subnet, and I can't do squat about that redirect.  The third router, if I read
RFC1009 correctly, doesn't have to pick up the redirect.  So every packet I
send is not only being emitted by the third router onto the spine, every one
of them causes router A to *re*-emit it onto the spine along with a useless
redirect that will never be heeded.

Questions:

	Why are routers not required to hear ICMP redirects?  This is never
	made clear in 1009.

	Is a router really allowed to send a redirect to a host not on its own
	subnet?  I suspect the answer is "no" per the RFC, but I've observed
	redirects crossing routers on a fairly regular basis...

	How can I avoid this dismally inefficient state of affairs, given
	that I have no access to the configurations of A or B?

Reply directly, pleeze; I'll sift and summarize for others who are curious.

_H*

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 19:16:09 GMT
From:      pmetzger@snark.shearson.com (Perry E. Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP support broadcast packets?


jlw@improb.cls.com (Jeff Wannamaker) writes:

   I know that UDP datagrams support broadcasting, but fear implementing
   at that level since we would also have to do our own buffer sequencing
   and error detection.

TCP is by its very nature a point to point system; it has no notion of
broadcast. 

I understand the fear of building a broadcast system based on UDP
yourself, but you don't need to build the system yourself. Get a
package like ISIS to handle the integrity of the data distribution for
you.

Check comp.sys.isis out if you want details.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 19:38:22 GMT
From:      ava@bcrka486.bnr.ca (Anthony VanAlphen 1572587)
To:        comp.protocols.tcp-ip
Subject:   Packet Driver for National DP83 Chips

Does anyone have any experience with packet drivers for
the National Semiconductor DP83 series single ethernet
chips. Specifically for interface to a 68000 based micro.
I am looking for C code/libraries etc.

--
-----------------------------------------------------
Anthony Van Alphen       
Bell-Northern Research       Phone:    (613) 763-5101
P.O. Box 3511 Stn. C.        Fax:      (613) 763-7155
Ottawa, Ontario K1Y 4H7      Internet: ava@x400gate.bnr.ca
-----------------------------------------------------

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 92 19:42:47 GMT
From:      bwilliam@symphony.cc.purdue.edu (Brenda Williams)
To:        comp.protocols.tcp-ip
Subject:   SNMP agent.

I have what may turn out to be a faq on snmp.
I was wondering if there was a pd snmp Unix
agent? I will be using SunNet Manager later
this year, but thought I would work on figur-
ing out how the agent works now.

Thanks in advance for your help.

 Best Regards,

 Rich  Williams    |  Internet bwilliam@symphony.cc.purdue.edu
          On a fairly good road in rural Indiana.
               #include <std/disclaimer.h>
 "The whole of science is nothing more than the refinement of
                  everyday thinking." Einstein

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 20:02:03 GMT
From:      phil@mdl.com (Phil Usatine)
To:        comp.protocols.tcp-ip
Subject:   SLIP line reliability problems


I am running SLIP 4.1-beta on a Sparc under SunOS4.1.2 to
establish a connection with a commercial net. I am able
to successfully establish connections lasting up to several
hours (even days occasionally), but eventually the line will
drop for no apparent reason. I have checked line quality on
my T3000 modem when the line was being dropped repeatedly and
always found line quality to be in the 98-100 range, and the
modem configuration has been poured over by myself and the
people of the connecton provider (PSI) several times.
The only apparent pattern I can find is that the line shows
a greater tendency to drop under heavy load, and at these
times a may get a vmunix:slipencode overrun message from the
kernel.
Has anyone seen this problem or have any ideas on dealing with
it?

Reply via e-mail and I'll post a summary.

Thanks in advance,
phil

--
/***********************************************************************/
        Any opinions expressed were my own last time I checked.
Philip B. Usatine		    
Micro Dynamics                              e-mail : phil@mdl.com
8555 16th St. , 7th Floor                   voice: 301 589 6301
Silver Spring, MD 20910                     fax  : 301 589 3414



-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jun 1992 21:24:51 GMT
From:      donp@novell.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: 50 thousand TCP connections on Solaris 2.0/SVR4 - is it possible?

In article <2711@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
>surely a 1 way applicatrion could setsockopt the window down to zero -
>in fact unless the applciation issues a read...you could default that
>way...

Oh, no!  Not again!  While you *could* set the window to zero, do us
all a favor and set it to at least 1 so there's space for the FIN when
it's time comes.  Otherwise we'll have to have another fight about
whether or not your TCP code should accept a FIN sent into an empty
window.  I'd rather not see us get into *that* again... :-)

						don provan
						donp@novell.com

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 02:07:12 GMT
From:      merce@xenitec.on.ca (Jim Mercer)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   bootpd for AT&T 3B2 WIN TCP (request)

has anyone ported a bootpd to 3B2 WIN TCP?

does anyone know of a place to get extended docs for WIN TCP?

seems my port of CMU bootp is getting hung up on SIOCGIFCONF or
something like that, it don't like the parameters.

i got no docs for this call, and a bunch of other stuff.

i would like to know what anyone out there has ported to WIN TCP and
maybe some pointers to ftp sites.

thanx

-- 
[ Jim Mercer   Reptilian Research  merce@iguana.reptiles.org  +1 519 893-6085 ]
[             I don't want to work for a company that has a CIO.              ]
[              Disclaimer! I don't need no stinking Disclaimer!               ]

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 08:15:10
From:      mrl@uai.com (Mark R. Ludwig)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

In article <1992Jun2.201125.23128@midway.uchicago.edu> wag5@quads.uchicago.edu (john peter wagner) writes:

           If the hacker is caught [...]

I would greatly appreciate it if you used a different word from
"hacker."  I'm a hacker (i.e., "computer enthusiast"), and I like to
think I'm one of the Good Guys.  The General Media have given "hacker"
a bad name, and though I hold little hope of correcting their misuse
of the word, at least in a computer medium such as this I'd like to
see its use corrected.

Please use "cracker" instead.  I've shamelessly taken the term from
_Practical_UNIX_Security_; see it for more insight and motivation.$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
  "AIX overall is weird with a beard.  But I like smit."  -- Chip Salzenberg

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 04:41:07 GMT
From:      bmanning@is.rice.edu (William Manning)
To:        comp.protocols.tcp-ip,comp.lang.perl
Subject:   Re: Perl script to check for DNS configuration flaws?

In article <1992Jun24> knutson@mcc.com (Jim Knutson) writes:
>
>Doc was written by Steve Hotz (hotz@isi.edu) and Paul Mockapetris
>(pvm@isi.edu).  It's available on the internet somewhere.  I made some
>mods to it to allow it to be run from a script which in turn is run by
>cron.  It works reasonably well.  However, doc and the scripts are not
>written in perl.  If anyone wants a copy, let me know.
>
Nifty trick. I would like one. The DOC that I run depends on DiG, and
is only used to verify configurations, not build them.

-- 
Regards,
Bill Manning         bmanning@rice.edu        PO Box 1892
 713-285-5415         713-527-6099	       Houston, Texas
   R.U. (o-kome)       			        77251-1892

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 1992 07:55:45 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Does TCP/IP support broadcast packets?

In article <cZgwmB1w165w@improb.cls.com> jlw@improb.cls.com (Jeff Wannamaker) writes:
>I've been reading manuals trying to circumvent receiving RTFM comments,
>but still have not found out yet whether TCP/IP supports broadcasting
>packets using sockets.

I think you're phrasing your question badly.  I think you mean to ask "does
TCP support broadcasting?", since "TCP/IP" usually refers to the entire
Internet protocol suite (which includes at least IP, TCP, UDP, and ICMP,
and also is often meant to include the common application protocols).

TCP/IP supports broadcasting, but TCP doesn't, since it doesn't fit into
its notion of connections (if you broadcast a packet, how do you know when
you've received acknowledgements?).  There are some experimental reliable
multicast-based protocols; look for them in the RFC Index or data
communication journals (they're too new to be in books or manuals).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      26 JUN 92 10:37:31
From:      dorl@vms.macc.wisc.edu (Michael (NMI) Dorl)
To:        comp.protocols.tcp-ip
Subject:   ISDN Support

I'm curious to know what support exists for primary rate
ISDN.  Do any term server or router manufacturers support
a single primary rate interface to multiple basic rate
ISDN connections?  Is there any software available to handle
this on Unix hosts?

Michael Dorl              (608) 262-0466  fax (608) 262-4679
dorl@vms.macc.wisc.edu    MACC / University of Wisconsin - Madison
dorl@wiscmacc.bitnet      1210 W. Dayton St. / Madison, WI 53706

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 12:49:27 GMT
From:      brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein")
To:        comp.protocols.tcp-ip
Subject:   informal notice of two IESG decisions

This message has 25 sections, each quite short but together a lot to
take in. Sorry for the length. Why so much? Because I'm exposing a
year-long pattern of corruption within the IESG. I now have a large
collection of electronic, verbal, and written evidence that the IESG has
blatantly violated several requirements in RFC 1310. These abuses are
documented below. (Skip to pattern ^25 for the quick summary.)


1. Reason for the informal notice

RFC 1310 states that anyone can submit a standardization proposal to the
IETF Chairman or an appropriate IETF Area Director, who in turn lets the
IESG review the proposal. RFC 1310 outlines a few procedures for dealing
with tricky proposals---for example, commissioning a special review
committee, or creating a working group for ``evaluation and refinement''
of the protocol spec. It then says: ``The IESG shall determine whether a
specification satisfies the applicable criteria for the recommended
action (see Sections 3.2 and 3.3 of this document) and shall communicate
its findings to the IETF to permit a final review by the general Internet
community.'' RFC 1310 goes on to say that the notification is by email
to the IETF list.


2. The informal notice

On 15 July 1991 I submitted a protocol specification to Steve Crocker,
requesting that it be published as a Proposed Standard RFC. At the time
the protocol in question, which came into existence in early 1990 and
was derived from a much older protocol, did not have a distinguishing
name; I have recently begun calling the protocol ``TAP.'' (This, like
``TELNET,'' is a capitalized name, not an abbreviation for some official
name.) Anyway, Crocker is the IETF Security Area Director. Phill Gross,
the IETF Chairman, informed me in May that Crocker had rejected my
request in March.

On 18 April 1992 I requested of Gross that a newer, pruned-down TAP
specification be published as a Proposed Standard RFC (or at least that
a working group be created to discuss it). Gross informed me in mid-May
that the IESG had just rejected my request, primarily because TAP has
the same function as a still-not-yet-defined protocol named Ident,
currently stuck in the Ident WG. (It is worth noting that the Ident WG
chairman, Mike StJohns, has refused to allow discussion of TAP on the
Ident list, although he does not deny that TAP is within the Ident
charter.)


3. Comments about the notice

According to RFC 1310, the IESG was required to notify the IETF mailing
list of the two decisions listed above, to permit community review. It
appears that the IESG failed to do so, hence violating both the letter
and the spirit of this rule. If in fact the IESG sent out timely
notifications which I missed, I'm sorry; I asked the IESG recently
whether such notifications had been sent, and I received no response.

The remainder of this message gives you further information about the
protocol in question and its history within the IAB. Everything I say
here (except, in some cases, my comments about what I was thinking at a
given time) can be verified from the transcripts of my dealings with the
IAB, which I plan to publish in SIGCOMM CCR, or from other objectively
verifiable sources. You will be forced to wonder, as you read through
these progressively more and more damning pieces of evidence, whether
the IESG is attempting to take control of the IAB standards series away
from the community. Why else would it keep its decisions secret, and
violate RFC 1310 in the many other ways documented below?


4. Chronology I: early history

TAP came into existence in February 1990. I took the dead protocol
documented in RFC 931 and implemented a variant of it. I distributed the
result in my ``auth'' package, which never really caught on. A year
later I distributed ``authd,'' a new TAP implementation which did catch
on because of various technical features. authd serves TCP port 113; in
effect it announces ``username shmoe connected from this host's TCP port
12345 to host H's TCP port 7654'' to anyone on host H who asks about
those port numbers. (It can be used for things other than usernames,
though, just as finger can be used to transmit weather information.)

Three client TAP implementations (for BSD talk, NNTP, and SMTP) were
distributed in early 1991. I began to worry about ways to guarantee
future interoperability. In June I documented the TAP protocol, along
with the existing applications and some suggested applications, in RFC
format. I also commented extensively on the exact security added by TAP.
On 15 July, as noted above, I submitted the document to Crocker for
publication as a Proposed Standard RFC.


5. Chronology II: Delay Period 1 (15 July to 14 September)

After my submission I was told nothing for two months. I sent Crocker a
list of some sites running TAP. Then Crocker wrote back: ``Naw, two
months is not unreasonable. The time has been used for coordination...
There is moderate agreement that this should indeed go on the standards
track. However, the wording about the relationship to security needs to
be changed. It's one thing for hosts to supply information about the
user associated with a particular connection, but it's another matter to
assert that this information supplied is particularly trustworthy or
strongly related to security. You get first crack at fixing up the
document. If you need clarification of the issues, we can set up a
dialog.'' That was 14 September.

Nowhere in the security section did I assert that the information
supplied was in particularly trustworthy or strongly related to
security, and I did not understand what changes Crocker wanted me to
make, or who the ``we'' was. I told Crocker so on 15 September. I asked
exactly what wording he considered inaccurate, misleading, or
incomplete, and said: ``Since I don't understand which statements you're
objecting to, I guess I need clarification. Dialogue with whom?'' (As I
learned later, ``we'' meant some subset of the SAAG group.)


6. Chronology III: Delay Period 2 (15 September to 20 November)

Crocker did not respond to my request for further information, and
didn't come through on ``we can set up a dialog.'' I sent messages to
him on 3 October and 19 October attempting to elicit a response. He
didn't respond until 20 November, more than four months after my
submission. In those four months, the ball was in Crocker's court every
day except 14 September.

In the meantime the world continued to turn. Peter Eriksson wrote a new
implementation; unfortunately there was an interoperability problem. I
heard about the problem from Simon Leunen. By 4 November, Peter had
fixed the problem and read through the TAP specification. The
specification would not have permitted the problem if it had been
available to Peter.  In mid-November I created the rfc931-users list
``for people who want to use RFC 931 to solve problems.'' The list
quickly swelled past 100 subscribers, and Peter's ``pauthd'' continued
to grow in popularity.


7. Chronology IV: technical discussion

On 20 November Crocker finally gave me some indication of what he (and
apparently some SAAG members) didn't like about the document. I
responded with a list of ten issues, on most of which we seemed to
agree. Crocker responded on 22 November: ``I think we're in basic
agreement, modulo detailed discussion over what words are in the RFC
regarding security and the name of the protocol.'' (He had mentioned
that the current name---``Authentication Server,'' just like RFC 931---
was, in the eyes of the SAAG, inappropriate; this was one of the issues
I listed.)

At the end of November I sent some initial messages to the rfc931-users
list. Discussion ensued on the security section of my document. This
discussion continued, in various threads on rfc931-users and the SAAG
list, through the beginning of January. During that time I produced
several revisions of my document in response to SAAG criticism.

On 2 January Jim Galvin of SAAG sent me a message, reminding me of the
name-change issue raised in late November. ``It is the opinion of those
SAAG members who have been carefully tracking this effort that the
protocol should be renamed as the "Identity Server" (or something
similar)... If you agree you will need to revise your document
accordingly, after which we will push it on to the "standards track" as
expeditiously as possible.''

I asked rfc931-users whether the name change would be okay, and how we'd
deal with the problems of changing the name of an established protocol.
The answers were satisfactory, so I agreed.

On 4 January I made a new draft available; it had the new name
``Identity Server'' and addressed various security concerns. There was
no further discussion. I waited for Galvin to live up to his statement
``we will push it on to the "standards track" as expeditiously as
possible.''


8. Chronology V: Delay Period 3 (4 January to 8 March)

There was no discussion after my 4 January draft. On 15 January, six
months after the submission, I sent Crocker, Galvin, Jeff Schiller, and
StJohns a message. I pointed out that I had addressed the issues raised.
I reminded them of Galvin's 2 January promise. Galvin immediately wrote
back and promised a response within a week.

On 22 January Galvin wrote back saying two things. ``First, the
reviewers have not reached consensus on how to respond to the review.
Until we do there is nothing that can be said at this time.'' Second, he
told me about the existence of Internet-Drafts and recommended that I
submit my document as an I-D. On 25 January I wrote back complaining
about the delay and the lack of feedback. But there was nothing I could
do: the ball was in ``the reviewers'' court and the reviewers weren't
telling me anything.

I wrote to Galvin on 6 February. ``You have stretched my patience beyond
its limits. Are there any remaining problems with my RFC 931 revision?
If so, then for the last month you've been concealing them from me. Is
my RFC 931 revision going to be published, NOW? If not, then you are
censoring a supposedly open document series. Is my RFC 931 revision
going to be published as a proposed standard protocol, to become a
recommended standard by December if there is no objection from the
community? If not, then the IETF is costing thousands of system
administrators many thousands of hours of time and effort tracking
system crackers. Is my RFC 931 revision going to be published as is,
with none of the insane editing that marred RFC 1143? If not, then the
IETF is violating copyright.''

I asked for a quick response. I quoted the section of RFC 1200 where the
IAB ``strongly recommends'' that people use its standards process ``to
maximize interoperability.'' I implied that this was a lie: ``When push
comes to shove, the IAB doesn't want to even begin standardizing a
protocol which isn't its own pet project---even if hundreds of sites
around the Internet are using that protocol.''

I hoped that if I reminded Galvin of the IAB's promises to the community
then he would wake up and start acting in accordance with those
promises. I received no response. Around this time I found Vint Cerf's
December draft of what is now RFC 1310. I was pleased to see that the
draft made quite a few statements about the IAB standards process which
were in line with how I thought the process should work.

So on 9 February I sent an informal complaint to Vint Cerf about SAAG's
handling of TAP. I emphasized how, according to his draft of RFC 1310,
TAP was in perfect shape to become a Proposed Standard. Cerf
acknowledged receipt of my message but didn't respond. I complained to
him again on 2 March. I didn't receive any other messages from the IAB
or its suborganizations in the meantime---except for a private e-mail
exchange with Steve Kent in mid-February which confirmed my beliefs
about why the SAAG was censoring TAP. (In the exchange Kent admitted
that his comments were out of date; he didn't raise any specific
objections to my document; and he didn't come through on any of the
IAB's promises. He did imply that he considers himself an ``important
individual'' [his words] in the standardization process.)

Summary of the three two-month delay periods: For a total of six months
out of eight, people acknowledged my messages, promised responses, even
admitted that the ball was in their court, but didn't tell me anything
and didn't live up to their explicit promises---let alone the promises
in RFC 1200 and RFC 1310. During this time the IAB accomplished nothing.


9. Chronology VI: post-Cerf summary

On 8 March Vint Cerf finally responded to my complaints. ``It would be a
loss if you gave up at this point since I had thought progress was being
made at last.'' (Huh? It had been two months since Galvin had promised
to move TAP along the standards track. Absolutely no progress was made,
and Galvin didn't come through.) ``The impression I have is that the
fundamental questions revolve around how to characterize the services of
the protocol proposed. In particular, the degree to which one could or
should trust the results from any particular host that responds.''
(Absolutely. No disagreement here.)

Although Cerf wasn't formally running the IAB at that point, it was
amazing how quickly things moved once he got involved. Days after Cerf
``thought progress was being made at last'' Mike StJohns sent out an
extensive revision of the TAP spec, claiming that his rewrite reflected
SAAG's concerns (which had been kept completely hidden since 4 January).
After this things got very complicated, and I won't try to give a
complete play-by-play account of what's happened between then and now.
The following sections have just a few highlights.


10. Historical summary: the pure TAP spec

On 12 March it struck me that there had been essentially no disagreement
on the technical aspects of TAP. So, I thought, why not split the
document into two pieces: a pure TAP protocol description, and a
discussion of security and applications?

The next day I distributed the pure (``wimpy'') TAP spec. I stated my
high hopes that the pure spec would be acceptable to SAAG---after all,
it didn't make any claims about security and didn't talk about any
applications. It just defined the protocol. The new security section
said essentially ``This document makes absolutely no guarantees about
security.''

Beyond minor wording changes and a couple of extra technical notes that
spec hasn't changed. Several people (including Vint Cerf) have stated
their comfort with the document. The only technical objection raised is
that the (ridiculously simple) grammar is expressed verbally rather than
with a BNF; I've stated that I'd be glad to include a BNF if someone
wants to do the work of writing one, but apparently nobody's seen a real
need to do this.

It is this spec which was the subject of my 18 April request to the
IESG. (You can get the most recent published revision as
draft-bernstein-tap-00.txt from any I-D directory.) As noted in
section 2, Gross informed me in mid-May that the IESG had just rejected
my request, primarily because TAP has the same function as Ident.


11. Historical summary: cutting me out of the process

As you will recall, there was my draft from 4 January, then StJohns's
11 March rewrite with a radically different security section, then my
13 March pure revision with the security section removed entirely.

On 16 March Steve Crocker sent me a message: ``You said in your note to
Vint that you want your latest revision to be considered an official
submission. I think we skipped a step. I saw Mike's draft and I saw
your response, but I didn't see any dialog indicating discussion and
reconciliation. It's not evident to me that your submission meets the
requirement for consensus.''

What a load of crap. First of all, except in the security section,
StJohns's draft was essentially the same as mine; and the whole point of
my rewrite was that we should split off the security section into a
separate document. So what exactly was there the lack of consensus on?
The only person who's refused to admit that splitting off the security
section is a good idea is Ted Ts'o, who also refuses to admit that TAP
has a constituency or that Kerberos is less than 100% secure. (Will the
sun rise tomorrow, Ts'o?) Given that StJohns's changes were in sections
that no longer appeared in the document, what was there to discuss?

Second, every accusation that I had ``skipped a step'' can be thrown
back at StJohns. To imitate Crocker: ``I saw my January draft and I
saw Mike's extensive rewrite, but I didn't see any dialog indicating
discussion and reconciliation.'' It is StJohns who didn't check his
rewrite with anybody, who didn't have any history of agreement on his
document. Why can IAB flunkies make any changes they want without
checking with the community, then accuse *me* of not seeking out
consensus?

To make a long story short, by 18 March Steve Crocker had announced that
Mike StJohns was now running ``the effort.'' He excused this exercise of
dictatorship---which he didn't even check with SAAG---by saying ``It has
become evident that these discussions are not converging.''

I leave it to you, my readers, to evaluate the truth of Crocker's
statement. The technical discussions which weren't converging were the
security discussions---and it wasn't my fault that, after January 4,
nobody in SAAG could find a single thing to complain about in my draft.
At this time the discussions still haven't converged; Mike StJohns has
adopted the policy of ignoring them entirely, on the grounds that I am
supposedly the only one disagreeing with SAAG. Other people have
explicitly stated the same disagreements but StJohns still has the same
policy.

Anyone involved in those first eight months of TAPgate knew that the
security section was the only thing holding TAP back. Nearly every
message dealing with technical aspects of TAP was on security issues.
My solution was to let the TAP protocol specification proceed by
admitting that we didn't know what to say about security. Crocker's
``solution'' was to cut me out of the process---and use StJohns's
security section, which certainly isn't anywhere near consensus.

On 18 April, immediately after my second formal request to the IESG
(actually, right after I denied Crocker's right to exercise his personal
authority and reject the request, since it was directed at Phill Gross),
Crocker removed me from the SAAG mailing list. I hadn't sent any
messages to the SAAG list in a while; outside the TAP efforts I had
contributed an idea (which I think was accepted) to a mail-checking
protocol and hadn't said much else on the list. Yet Crocker came up with
a lie and threw me off the list. (``Open processes depend on the good
will of the participants. There is a line between pursuit of honest
differences of opinion and determination to interfere with the work of
the group. In my opinion, your efforts are not constructive, and I have
removed you from the SAAG mailing list.'')

I requested to be put back on. I had thought that the SAAG was an open
list---an official IETF list, in fact. But Crocker refused. It turned
out that Galvin, who had added me to the list originally, works for
Crocker. What excuse is there for such an exercise of personal control
over IAB business? Why do these people think they have the God-given
right to run the Internet any way they damn well please? I never
interfered with SAAG business, and I have five SAAG mailing list
recipients willing to swear to this in court, in case personal SAAG
archives aren't enough.


12. Historical summary: copyright issues

I had mentioned copyright on 6 February. RFC 1143 had been extensively
modified immediately before publication, in violation of copyright law;
I didn't want this to happen again. In March, after an attempt by a
certain IAB flunky to steal my writing, I pointed out once again the
automatic existence of copyright. On 29 March I offered to place my
document into the public domain; several times before that I offered to
transfer copyright to IAB the moment after my document was published.


13. Historical summary: tone issues

Cerf and Crocker complained about the ``tone'' of the first pure
revision of the TAP spec. I asked them repeatedly exactly what they were
talking about. They didn't say for over a week, though I did hazard a
guess which turned out to be correct. After they told me I removed the
statements in question. Why weren't they specific in the first place?

Kent and Ts'o have thrice stated that certain passages are not in
conformance with ``RFC style.'' I---and others---have asked what this
style is and where it's documented, as well as for examples of the
style, as well as for some explanation of how the passages would have to
be changed so that they have the proper style. Neither Kent nor Ts'o has
elaborated---yet they continue to claim that various passages are
inconsistent with ``RFC style.''


14. Historical summary: mailing list issues

I created the rfc931-users mailing list in November, chartered to serve
the users of the protocol. (I now regret my mistake in not choosing the
name TAP last year and creating a tap-users list.) During March Crocker
and others sent messages to the list which, in my judgment and in the
judgment of various readers of the list, were not appropriate for the
list. I repeatedly told Crocker to stop abusing the list.

Crocker stated in mid-March that rfc931-users was the ``official mailing
list'' for ``this effort.'' Yet he didn't explain how the effort had
suddenly become official, or how it had suddenly acquired a mailing
list---in particular, a mailing list with an entirely different charter.
I thought that official IAB actions were announced on the IETF list. He
also stated for the first time that he ``required'' a mailing list ``for
every effort.'' He had never brought up this requirement before.


15. Historical summary: cutting TAP out of the process

By late March, in response to my complaints about the abuse of the
rfc931-users list, Crocker had created an official list: ident. For a
few days after that people on both sides of the issues were happily
discussing the TAP spec. I kept a public list of open issues; a few
minor issues were raised and a few were resolved. (The character set
issue, for example, was brought up for the first time.) I estimate that,
with a week more of work, we would have had a perfectly satisfactory
spec which nobody would have objected to.

Then the floor fell out. On 29 March Mike StJohns sent a message to the
rfc931-users and ident lists. ``The "ident" protocol - where we are and
where we're going... Attached at the end of this note is a redraft of
rfc931, hopefully reflecting the current implementation state of the
protocol. This draft with subsequent changes if any is what will be
moved onto the standards track... Mr Bernsteins draft has been removed
from consideration for cause - primarily due to his threats to assert
copyright. His draft will not be considered further as a contribution to
the standards process... we had come to an impasse with Dan and this
looks like the only way to get the effort moving.'' (This, after six
months of inexcusable delay on Crocker's part.)

Again, I leave it to you, my readers, to judge StJohns's actions. I
recently ran a survey of the ident list: apparently StJohns didn't check
with *anybody* in the group before cutting TAP out.

After StJohns' exercise of dictatorship the Ident group was created as a
formal IETF WG, chartered to ``define a protocol'' to transmit certain
information. It's been going for nearly three months now. There's still
a security section, and there are still huge open issues surrounding
that section. StJohns recently took it upon himself to invent extensions
to the protocol, as usual without checking with anybody. (According to
his much more complex, and implementation-free, protocol definition,
UNIX usernames are limited to 8 characters. What a surprise for users of
UNIX systems allowing longer usernames. Why would someone add this sort
of idiotic limitation to a protocol, if not in an attempt to damage the
protocol irreparably?)


16. Standards process issue: perversion of requests

On 15 July 1991 I requested that the IAB move a protocol along the
standards track. As indicated above, the request was (apparently)
refused in March by Steve Crocker, though this refusal was not announced
for review by the IETF community, in clear violation of RFC 1310.
Anyway, Crocker sent me at least two messages along these lines: ``You
asked that we move this protocol forward. We are doing that, via the
Ident effort. What are you complaining about?'' He tried to act
similarly in response to my April 18 request, though he had no right to
do so, as my request was directed at the IETF Chairman.

It's easy to answer Crocker's question. Many of TAP's users believe that
the current Ident draft (1) does not reflect current practice; (2) has
not achieved consensus, or even come close; (3) is far too complex; (4)
has some unacceptable restrictions in the security section; (5) contains
false and misleading information. If it weren't for these flaws we
probably wouldn't be complaining.

But the larger issue is that Crocker has perverted my requests into
something other than what they are. When I ask, following RFC 1310, that
something be moved along the standards track, I expect my request to be
evaluated the way RFC 1310 says it should be, and either accepted or
denied on that basis. I'm not asking that some vague ``effort'' be set
up to standardize a roughly similar protocol, or even the same protocol;
I'm asking that this protocol spec be standardized right now. It is a
perversion of the request to interpret it as something other than what
it is.

I believe that RFC 1310 should explicitly deny the IESG the right to
pervert requests. If the IESG wants to say ``We deny your request, on
the basis of the following criteria in RFC 1310: ... By the way, you
might want to set up a working group to try to put together a better
protocol definition,'' then that's fine. But the IESG should not have
the right to wilfully misinterpret requests in pursuit of its own goals.
If it has no reason to refuse a request then it must accept the request.

In the meantime we should all recognize that Crocker's actions were not
sanctioned by RFC 1310.


17. Standards process issue: copyright

The copyright issue is, from a factual point of view, a non-issue in
this case. I've offered to put my document into the public domain. We
should all recognize that Crocker and StJohns are lying when they claim
anything like ``There are unacceptable copyright restrictions on this
document.''

But there's a larger issue here. RFC 1310 does not list copyright
transfer as a condition for standards to be published. In fact, it
doesn't mention it even as something to be considered. After all, the
IAB has never required copyright transfer before, and under the Berne
convention (which is now U.S. law) there are some hundreds of RFCs which
are automatically copyrighted. So how can the IESG make decisons on the
basis of copyright? RFC 1310 simply does not condone the way that TAP
was removed from consideration.

I'm happy to see that copyright is now listed as an issue to be dealt
with in future RFC 1310 revisions. Certainly, although Crocker and
StJohns were overstepping their authority, there was a grain of reason
behind their incompetent handling of the copyright issue: the IAB can't
be expected to publish standards for the community if the community
doesn't have the right to revise the standard later. Perhaps the IAB
should require that every RFC be placed into the public domain the
moment it's published. The IAB can protect the sanctity of its document
series by trademarking the name ``RFC.''


18. Standards process issue: IETF notice

This deserves repetition: The IESG has, twice, violated RFC 1310's
explicit requirement that its decisions be announced for review by the
entire IETF. I believe that the IESG's failure demands further
requirements. The IESG should be required to summarize each and every
request it receives, immediately, for the IETF's information. We as a
community cannot permit the IESG to escape public review. TAP was
handled incompetently, including more than half a year of inexcusable
delay; why did the IESG try to keep its actions secret?


19. Standards process issue: the job of the IESG

Let's review the RFC 1310 quote on the IESG's job. ``The IESG shall
determine whether a specification satisfies the applicable criteria for
the recommended action (see Sections 3.2 and 3.3 of this document) and
shall communicate its findings to the IETF to permit a final review by
the general Internet community.''

Notice that the IESG is commissioned quite explicitly to decide whether
the request at hand satisfies certain criteria. The criteria in sections
3.2 and 3.3 are quite specific and quite short. They simply say what a
Proposed Standard is, what a Draft Standard is, and so on.

The IESG does *NOT* have the job of deciding between two competing
protocols: if both protocols fit the criteria in RFC 1310 sections 3.2
and 3.3 then both *MUST* be recommeded by the IESG. But I have Gross
recorded as saying that the IESG refused my 18 April request exactly
because, in the IESG's opinion, TAP would compete with Ident.

The IESG does *NOT* have the job of deciding things on the basis of its
hidden thoughts about what's good for the community. But that's exactly
what Steve Kent and Ted Ts'o say it should be doing: they say, for
example, that TAP should not be standardized because it does not have
security as strong as cryptographic protocols.

RFC 1310 does *NOT* sanction the IESG considering *ANY* criteria other
than those listed. But Crocker's refusal of my July 15, 1991 request was
explicitly based on such issues as copyright. And Gross stated that
``duplication of effort'' was the primary reason for the IESG's refusal
of my 18 April request. Even worse, Kent has implied that, even if the
IESG recommends that TAP become a Proposed Standard, he personally will
reject the TAP spec because of its ``style.''

I don't have any suggestions for how RFC 1310 should be modified to
handle these problems. The IESG has violated RFC 1310's rules so
blatantly that I see no recourse other than direct appeal to the
community.


20. Factual notes

The current TAP specification is stable and well-understood: about 85%
of it is word-for-word the same as a draft which has been available
since last June, and the rest is formality; also, the protocol which it
describes has not changed since February 1990. The spec and protocol are
technically competent: to put it simply, they *work*, and the spec says
exactly what's necessary to guarantee future interoperability. There are
multiple independent interoperable implementations with considerable
operational experience: for example, my authd, Peter Eriksson's pauthd,
and the popular wuarchive ftpd. The spec and protocol enjoy some public
support: I have published a list of literally hundreds of IP addresses
running the server, and I have statements from nine people asking the
IAB to get the spec published as an RFC. TAP is not only recognizably
useful in some parts of the Internet; it's being *used*---the statistics
for the NSFNET T1 backbone show many tens of thousands of TCP port 113
packets per month.


21. Is TAP appropriate for the standards track?

RFC 1310 states: ``In general, an Internet Standard is a specification
that is stable and well-understood, is technically competent, has
multiple, independent, and interoperable implementations with
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.''

So, given the facts noted in the last section, the TAP spec seems to
satisfy the characterization of Internet Standards in RFC 1310.
Certainly one could argue that ``only'' a couple hundred sites doesn't
constitute ``significant public support,'' or that the spec isn't
perfectly stable. But then again, I'm not asking that TAP become a
Standard yet---all I've been asking since last July is that this be
published as a Proposed Standard. RFC 1310 imposes nearly another year
delay before a Proposed Standard can advance through Draft Standard to
Standard; that'll be more than enough time for the public support and
stability and so on to become obvious.


22. Does TAP embody the goals of the standards process?

RFC 1310 identifies four goals of the procedures of the standards
process: high quality, prior implementation and testing, openness and
fairness, and timeliness. The first two goals were met in this case by
people working outside the IAB---but the goals of openness and fairness
and timeliness can be met only by the IAB. In this case the IAB fell
flat. Steve Crocker claimed in March that he requires a mailing list for
``every'' effort: so what was he doing between July and March with the
TAP effort? Delay Periods 1, 2, and 3 add up to six whole months during
which Crocker did nothing.


23. Does TAP need a working group?

RFC 1310 states: ``In most cases, a specification resulting from an
effort that took place outside of an IETF Working Group context will be
submitted to an appropriate Working Group for evaluation and refinement;
if necessary, an appropriate Working Group will be created.'' This isn't
always applicable, and I don't think there's any need for a TAP group;
but I still suggested this as an option in my 18 April request. The IESG
didn't take this option.

Remember the request perversion issue. If the IESG does create a working
group for TAP then it had better be in conformance with RFC 1310---it
had better be a group to ``evaluate and refine'' the TAP spec. Another
group like Ident, chartered to ``define a protocol,'' simply doesn't cut
it. Ident does not satisfy the IESG's obligations towards TAP.


24. Does TAP satisfy RFC 1310's criteria for being a Proposed Standard?

The IESG's job was to answer the question of this section's title. It
didn't live up to its duties so I'll address the question. RFC 1310
states: ``The entry-level maturity for the standards track is "Proposed
Standard". A Proposed Standard specification is generally stable, has
resolved known design choices, is believed to be well-understood, has
received significant community review, and appears to enjoy enough
community interest to be considered valuable.'' It also states one extra
criterion: ``A Proposed Standard should have no known technical
omissions with respect to the requirements placed upon it.''

The TAP spec---and the protocol it documents---are, as noted above,
quite stable and well-understood, and enjoy more than enough community
interest to be considered valuable. It has received far more community
review than the vast majority of IAB standards efforts, by virtue of
having been incorporated into a number of widely distributed programs.
I resolved all design choices a year ago, and the protocol I defined
then has not been shown to have any technical problems. (I don't claim
that every decision I've made is necessarily optimal, though on the
basis of the last year of protocol development and discussion I do
believe I made good decisions; I claim only that the choices have been
resolved. That's the criterion listed in RFC 1310.) As for technical
omissions, the TAP spec omits nothing. It contains all features
necessary to satisfy the requirements placed on it by its users. (And
there are no requirements placed on this protocol from the outside; it's
not as if TAP was designed to fill the IAB's stated need for a protocol
to do anything in particular. It just transmits uninterpreted octet
strings from one host to another.)

So TAP meets every single criterion in RFC 1310 for being published as a
Proposed Standard. I see no excuse for the IESG to have failed to accept
it---if, that is, the IESG had actually considered the criteria it was
supposed to consider, rather than shirking its duties in violation of
RFC 1310.

RFC 1310 goes further. ``Usually, neither implementation nor operational
experience is required for the designation of a specification as a
Proposed Standard. However, such experience is highly desirable, and
will usually represent a strong argument in favor of a Proposed Standard
designation.''

So not only does TAP meet the criteria for being a Proposed Standard. It
also has both an implementation and operational experience. So if the
IESG had any doubts about TAP, it should have been swayed by the
strong argument that TAP is a protocol *in use*! In fact, TAP has
*multiple* interoperable implementations---more implementations than
most existing Proposed Standards. How strong does this argument have to
be before the IESG gives in?

Note that the TAP spec is, at this point, solely a Technical
Specification, with only a very broad statement of its domain of
applicability. It does not include an Applicability Statement. So it
gets only a maturity level like ``Proposed Standard,'' not a requirement
level like ``Recommended.'' I didn't realize this until I read RFC 1310.


25. What now?

TAP is fully ready to be published as a Proposed Standard. The current
draft is technically sound; now that the security discussions have been
replaced by a disclaimer, there's little if any argument over the
document. Yet---for almost twelve whole months---SAAG and IESG have
refused to let TAP proceed through the standards process.

Permit me to speculate a bit. I think I know why Crocker, Kent, et al.
don't like TAP. They have a shining vision of global cryptographic
authentication. If we had that sort of security on the Internet then
nobody would find TAP useful. But exactly the opposite is true: TAP is
the best in its class right now, and hundreds of people are using it.
Crocker et al. don't like being reminded that their vision is little
more than a far-off dream. If they let TAP be standardized then they'd
be admitting to the whole Internet community that it'll be years before
their vision becomes reality.

Unfortunately for them they weren't able to find any good reason to hold
TAP back. So they started acting unfairly. Let's review the examples
documented above, in roughly increasing order of unfairness:

(A) During a total of six months---Delay Periods 1, 2, and 3---Crocker
and friends did nothing in public and said nothing.

(B) Crocker cut me out of the process, with the excuses that I was
supposedly ignoring a document (which had appeared less than a week
before), and that the discussions weren't converging (as if that were my
fault).

(C) StJohns has adopted the policy of ignoring my objections to the
security section of his document, with the excuse that I am supposedly
the only one raising objections (although other people have supported my
position).

(D) Crocker suddenly declared in March that the rfc931-users list was an
``official mailing list'' for ``this effort''; what a surprise for the
readers of the list. How can something be ``official'' if it hasn't even
been announced on the IETF list?

(E) Crocker claimed in March that he ``required'' a mailing list ``for
every effort''; he had never brought up this requirement in the eight
months before that.

(F) StJohns threw the TAP spec out of consideration at the end of March,
despite the fact that people on both sides of the issues were discussing
it at the time. His excuse was copyright.

(G) The Ident group, which was supposedly created in response to my
request from eight months before, was not chartered to handle that
request.

(H) According to Phill Gross, Crocker refused my 15 July 1991 request
sometime in March. He didn't announce this on the IETF list for
community review.

(I) The IESG refused my 18 April 1992 request in May. They did not
announce this on the IETF list for community review.

(J) The IESG decided between two competing protocols (and then decided
in favor of the vapor protocol).

(K) Crocker's refusal of my July 1991 request was based on such issues
as copyright, not on any technical issues. (And it was a personal
refusal, not one espoused by the relevant working groups.)

(L) The IESG's refusal of my April 1992 request was based primarily on
the issue of ``duplication of effort.''

Scary list, isn't it? To support these unfair actions they engaged in
lies, some of which are documented above (examples: ``we can set up a
dialog'' [Crocker], ``we will push it on to the "standards track" as
expeditiously as possible'' [Galvin, speaking for SAAG], the response
``within a week'' in January [Galvin], ``your efforts are not
constructive'' [Crocker]), and petty exercises of personal power (e.g.,
throwing me off the SAAG list [Crocker]). But words don't hurt; what
hurts is that the IESG has, for a year, censored a perfectly good
protocol, and caused documented cases of interoperability problems and
loss of time and money.

Fortunately I have two weapons to combat the unfair actions of the IESG.
My first weapon is RFC 1310, the IAB's official documentation of its
standards process. With RFC 1310 I can stop shouting ``unfair'' and
start shouting ``fraud.'' RFC 1310 describes exactly what the IESG
*should* have done in response to my requests, and what criteria the
IESG should have considered. By those criteria TAP passes with flying
colors---it's got a larger constituency, more public review, better
consensus, better technical development than the vast majority of
existing Proposed Standards, and multiple interoperable implementations
to boot. Although it's tricky to use e-mail as evidence, I'm seriously
considering suing the IAB for fraud on the basis of the IESG's flagrant
violations of RFC 1310.

My second weapon, my much more powerful weapon, is the will of the
community. Some of you out there must be shaking your heads in
disbelief, saying ``I never thought the IESG would betray the community
in this way!'' We all lose when the IESG doesn't follow its own rules,
ignores its own criteria, and then tries to hide its mistakes from the
community---especially when the result is outright censorship of a
protocol which *needs* to be documented in the standard series to
prevent interoperability problems.

I beg you, my reader: Say what you think. You don't have to trust my
summaries: the transcripts of TAPgate are a matter of public record. You
can do an incredible amount of good by raising your voice in outrage at
the IESG's attempt to wrest control of the standards series away from
the community. Pass around copies of this message, tell other people to
read it, send your opinions or suggestions to the tcp-ip or ietf lists,
talk about TAPgate at IETF meetings, tell me what you think (and please
say if you wouldn't mind my quoting you---every bit helps). Pick up the
TAP spec (draft-bernstein-tap-00.txt) and read it. FTP some of the
implementation work (thanks to Peter Eriksson) from ftp.lysator.liu.se.
And remember that this is a long message: just because you've made it
through doesn't mean other people will, even though they might be very
interested. Summarize, quote, complain. (Also make sure that Crocker
can't get away with denying what happened---please publicize any
relevant behind-the-scenes claims by summarizing them on the IETF list.)

It is time to force the IESG back into the position of serving the
Internet community rather than secretly directing its future. RFC 1310
makes clear that the Internet Engineering Steering Group must always
check its actions with the community, and derives its power from the
will of the community. *We* have final say. We can start by giving TAP
the fair and open treatment it deserves. I wish we hadn't lost a year---
we'll still have to wait another year for TAP to advance from Proposed
Standard to Standard. But maybe it'll be worth it if we make sure that
these abuses don't happen again.

---Dan Bernstein, brnstnd@nyu.edu, 26 June 1992 
(These are personal opinions. I have no official affiliation with NYU.)

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 14:51:19 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Well known ports and bad clients (abortive disconnect)

In article <1992Jun22.154359.20240@cbnewsj.cb.att.com> cauble@cbnewsj.cb.att.com (Troy Cauble) writes:
> 1)  Server listens on a well known port.  Client connects.
> 2)  Client then does something annoying like getting blocked,
>     going into an infinite loop, sleeping  forever, etc.
> 3)  For unrelated reasons, Server is then killed and restarted.
> 4)  The restarting Server gets EADDRINUSE trying to bind it's
>     well known port.  Utilities show the well known port stuck
>     in FIN_WAIT_1 or FIN_WAIT_2 (because the old Client never
>     handled it's end of the shutdown).

Sounds like a UNIX problem, not a TCP/IP problem. The simplest solution
is to avoid #3. If you use inetd (or tcpserver or anything similar) then
there will rarely be a reason to kill or restart the server.

---Dan

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 92 15:51:54 GMT
From:      weare@bostech.com (Ged Weare)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Validation Testing

Does anyone know of any PD or commercial software that tests implementations
of TCP/IP for conformance with the RFCs or the MIL-STDs?  One can always
write some test drivers, but are there any already written, and which hopefully
are accepted "officially"?  What does "officially" mean, anyway?  Are there
any agencies that certify TCP/IP implementations like COS does for OSI?

Are there any black boxes that can be attached to an ethernet and assist
with this?  I know of LAN analyzers that can decode TCP/IP and which can
be programmed.  Are there any packages that could be run on an analyzer
to help testing of an implementation?

Please email to weare@bostech.com.  I will summarize any useful replies.

Thanks.

----
Jed Weare                      weare@bostech.com
Boston Technology              (617) 246-9000 x3519
100 Quannapowitt Parkway
Wakefield, MA 01880.

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 16:09:29 GMT
From:      hofer@rchland.vnet.ibm.com (Kent Hofer)
To:        comp.protocols.tcp-ip
Subject:   Re: Well known ports and bad clients (abortive disconnect)

In article <17909.Jun2614.51.1992@virtualnews.nyu.edu>, brnstnd@nyu.edu (Dan Bernstein) writes:
|> In article <1992Jun22.154359.20240@cbnewsj.cb.att.com> cauble@cbnewsj.cb.att.com (Troy Cauble) writes:
|> > 1)  Server listens on a well known port.  Client connects.
|> > 2)  Client then does something annoying like getting blocked,
|> >     going into an infinite loop, sleeping  forever, etc.
|> > 3)  For unrelated reasons, Server is then killed and restarted.
|> > 4)  The restarting Server gets EADDRINUSE trying to bind it's
|> >     well known port.  Utilities show the well known port stuck
|> >     in FIN_WAIT_1 or FIN_WAIT_2 (because the old Client never
|> >     handled it's end of the shutdown).
|> 
|> Sounds like a UNIX problem, not a TCP/IP problem. The simplest solution
|> is to avoid #3. If you use inetd (or tcpserver or anything similar) then
|> there will rarely be a reason to kill or restart the server.
|> 
|> ---Dan


For which TCP states does the socket option SO_REUSEADDR allow the 2nd bind() to complete ok?

Kent Hofer    hofer@rchland.vnet.ibm.com  

(my opinions are my own and have nothing to do with my employer)

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 16:26:38 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: IP over partial mesh Frame Relay

In article <920625151259@leather-lace.ftp.com> ljm@ftp.com writes:
>If ATM doesn't work well with TCP/IP and doesn't work well with Netware
>and doesn't work well with NetBEUI and doesn't work well with Decnet and
>doesn't work well with SNA, I have to wonder to whom the ATM vendors expect
>to sell product.
>
>It seems much more likely that the existing 'new wave' of hardware will
>change to meet users needs then the users will change their needs to meet
>the hardware.

But remember, it's customer requirements that evetually drive the
development of the technologies.  If the customer's requirements move
toward large-scale connectivity via common carriers, with high-speed,
bandwidth-on-demand service, then ATM based networks may make perfect
sense.  If the current generation of protocol families won't deal
gracefully in this environment, then they will probably evolve or be
replaced.  When you get down to basics, it's utimately economics.
How do you get the largest national/military/corporate advantages for
the least investment?  Most of the consumers of networking products
today don't have any particular fondness for the underlying technology,
but they do have a large need to quickly and efficiently move information
around.  It is the information that is valuable, not the means used to
move it.  Technology will continue to be driven to find the most cost
effective way to provide it, when needed.

>enjoy,
>leo j mclaughlin iii
>ljm@ftp.com

Art

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 16:41:12 GMT
From:      solomon@becks (James Solomon)
To:        comp.protocols.tcp-ip
Subject:   Sequence preservation at layer 2 Regarding TCP


Greetings Internet Wizards:

The advantages of using a sliding window in the data link layer over
error-prone physical links are pretty well understood:  reliability and
throughput can be improved, and flow-control can be implemented.  For
simplicity, assume that one data link frame corresponds to one IP datagram in
the discussion which follows.

If one is running TCP/IP over an internet in which at least one link has a high
error rate, is it useful for the data link layer of this high error rate link
to preserve sequence?  That is, should the data link allow frames received
error-free to be delivered to a client (in this case IP) even if there is a
previous frame which has not yet been received correctly (as determined by
sequence numbers)?  Or, should the data link delay the delivery of such a frame
until the previous frame has been received?

The way I understand this phenomenon, it depends a great deal on the transport
protocol (and its implementation).  In a transport layer in which the receiver
informs the transmitter of *all* successful transmissions (including those
arriving out-of-order), it would seem that sequence preservation at the data
link would not only be unnecessary but would also be detrimental.

The basic question I would like answered is:  Under what circumstances (i.e.
what types of transport layers) would sequence preservation at the data link
layer be advantageous?  When would it be disadvantageous?  If my analysis is
all wet, don't hesitate to point out why!

Thanks much,
--
Jim Solomon (solomon@comm.mot.com)
Disclaimer:  It's my fault, not Motorola's.

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 17:26:31 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   API issues (Re: reliably delivered UDP)

In article <920622154759@cream.ftp.com> jbvb@ftp.com writes:
> These are API issues, not protocol issues.  See Sun's or Apollo's RPC API
> for examples of this sort of thing.  They can handle either stream or
> datagram transports more or less transparently, and the user doesn't care.

How about this API:

	fd = tcpopen(host, socket);

	read(fd,...); write(fd, ...);

	close(fd);

Why does the socket API require anything more than this?
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 18:46:35 GMT
From:      Liz%Eng%Banyan@HIPPO.BANYAN.COM
To:        comp.protocols.tcp-ip
Subject:   BYTE TCP benchmark tests

I just downloaded these from BIX.  I have successfully compiled the server 
program, but I can't get the client to build properly.  Has anyone had any 
problems with this?

(By the way, I'm building on SCO Unix.)

Thanks,

Liz
lizb@banyan.com


-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 19:47:58 GMT
From:      rcaliari@su5v.ess.harris.com (Richard Caliari)
To:        comp.protocols.tcp-ip
Subject:   Simulating ftp data

I would like to send data being received via a comm link to a
remote computer and store it in a file. Is there a way that I
can simulate ftp to send the data to the remote machine and store
it in a file without stroing it on my local machine? Any experiences/
sample code to do this would be appreciated.

Rich Caliari


-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 19:50:31 GMT
From:      drw@zermelo.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   ATM (was: IP over partial mesh Frame Relay)

For us newbies:  Just what *is* ATM?  It's supposed to be the newest,
hottest networking technology, but it's still vaporware as far as I
can tell...

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 20:33:45 GMT
From:      reece@eco.twg.com (Reece R. Pollack)
To:        comp.protocols.tcp-ip
Subject:   Re: Wollongong vs. TGV vms tcpip


In article <168119E5F.MLYNCH@cmsa.gmr.com>, MLYNCH@cmsa.gmr.com writes:
|>   Could someone provide me with some information on how TWG's and TGV's tcpip
|>products compare?  I know TGV is substantially cheaper that TWG's.  Does this
|>mean there are features that aren't in TGV's product that are in TWG's?  We
|>have been using TWG's tcpip for a couple of years, but are considering TGV's
|>because it is cheaper and we are upgrading systems.  We also have written some
|>socket based programs with TWG's tcpip.  Has anyone ever converted a TWG socket
|>program to run on TGV's tcpip?  How do the telnet, ftp, etc. interfaces and
|>options compare?  Also, I have written LPD filters to enable users to specify
|>different forms and setups to queues on the vax.  Does TGV's product have the
|>same capability?  Thanks in advance for any information!!

I've helped some customers go the other way, and the socket libraries are
fairly similar. Of course, it wouldn't be a standard interface if they were
that much different. The LPD filters and other non-standard enhancements may
not be a simple matter, however.

If you have technical issues, feel free to post your comments to our news
group 'vmsnet.networks.tcp-ip.wintcp', or send me email directly. If price
is your main concern, I'd suggest you contact our sales group.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
Email: reece@eco.twg.com

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 92 21:07:37 GMT
From:      art@acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ATM (was: IP over partial mesh Frame Relay)

In article <DRW.92Jun26145031@zermelo.mit.edu> drw@zermelo.mit.edu (Dale R. Worley) writes:
>For us newbies:  Just what *is* ATM?  It's supposed to be the newest,
>hottest networking technology, but it's still vaporware as far as I
>can tell...
>
>Dale Worley		Dept. of Math., MIT		drw@math.mit.edu

Sure it's one of those machines outside banks... ;-}

(Serious mode on)

Short synopsis:

ATM (Asynchronous Transfer Mode) is a switching/transmission technique
where data is transmitted in small, fixed sized cells (5 byte header,
48 byte payload).  The cells lend themselves both to the time-division-
multiplexing characteristics of the transmission media, and the packet
switching characteristics desired of data networks.  At each switching
node, the ATM header identifies a "virtual path" or "virtual circuit"
that the cell contains data for, enabling the switch to forward the
cell to the correct next-hop trunk.  The "virtual path" is set up
through the involved switches when two endpoints wish to communicate.
This type of switching can be implemented in hardware, almost essential
when trunk speed range from 45Mb/s to 1Gb/s.

ATM is a technology, not a product in itself.  But many companies
are betting lots of R&D dollars that it is an appropriate technology
to base new products on.

Art

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jun 1992 23:35:53 GMT
From:      restock@srv.PacBell.COM (Bob Stockwell)
To:        comp.protocols.tcp-ip
Subject:   Portmapper

How does one go about managing the assignment of TCP and/or UDP ports.
I would like to provide a number of "services" on one machine and
assign a unique port number to each.  These services will not come
under the heading of "well-known".  I have two problems: 1) How do you
assign the port numbers so that there won't be any conflicts within
the machine (other than manually), and 2) How would a remote machine
determine what the port number is for a particular service.  In other
words how do I do a remote getservbyname?

I am particularly interested in doing this in a standard (RFC??) way,
if that is possible.  The services would be running on a Tandem
Guardian (non-Unix) host.  I don't think Tandem has any way to do
this, but if there was a standard we could ask them to implement it.

I used the title "Portmapper" because I recall a service for Sun by
that name, but I couldn't find any info in the RFC index.
-- 
Bob Stockwell
Pacific Bell
pacbell.com!ptsfa!res

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 04:20:50 GMT
From:      karn@qualcom.qualcomm.com (Phil Karn)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: SLIP over a TELNET Link?

I've also toyed with the idea of running SLIP over Telnet, and for the
same reason. I occasionally visit a certain city where I have a guest
account on a local Internet host, but the associated Annex terminal
server that I use to reach it isn't configured for SLIP (hello Louie!)

Ahem. Anyway... my idea was to encode IP datagrams as lines of
printable ASCII characters, one packet per line. Something like
uuencode or binhex encoding would work. You'd probably have to limit
your MTUs to whatever will fit in the line buffers along the way.

If all of the encoding and decoding is done as part of KA9Q NOS, no
changes would be required in any of the intermediate hosts -- which is
after all, the basic idea here. You log into your local UNIX system,
telnet to a special host back home that serves as your SLIP/Telnet
gateway, switch to "asciified slip mode" and you're off and running.

I don't know whether to be proud or ashamed of this idea. We do seem to
be getting closer and closer to the legendary "TCP/IP on tin cans
and a string" all the time...

Phil



-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 06:10:40 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC1041-Telnet 3270-Regime options

In article <Bq3L5w.DCL@cs.psu.edu> dsbarr@cs.psu.edu writes:
|
|	I have a minor pet peeve with RFC 1060.  For the vtxxx terminal
|types, they are all listed as "dec-vtxxx".  It's very annoying to Unix
|sites, who rarely have a termcap for "dec-vtxxx".  I know, a minor
|fix for the sysadmin, but it's still an annoyance.  FTP software implements
|RFC 1060 by the letter, as such it doesn't say it can emulate a "vt100"
|or "vt220", only a "dec-vt100" or "dec-vt220".
|
|--Dave
|-- 
|Dave Barr            | loose: v. to set free, or not securely fastened.
|dsbarr@cs.psu.edu    | lose: v. to miss from one's posession.

I also have a beef with this, but I blame the U*ix vendors, not RFC1060.
If the vendors insist on using the string returned during the TERMTYPE
negotiation as a direct mapping to TERM in the environment, they might have
at least made sure that the legal strings a la RFC 1060 were understood by
whatever terminal type mapping (termcap, terminfo, etc) they use.

On the same topic, I ran across a client with an IBM RS/6000 that was failing
to start a connection for our Telnet client. Turns out that the RS/6000
Telnet REQUIRED a valid TERMTYPE for the option negotiation to proceed.
It requested "DO TERMTYPE", we replied "WON'T TERMTYPE", it replied
"DON'T TERMTYPE" and promptly stopped sending or accepting anything else.
The only way to get it to connect successfully was to cludge a successful
TERMTYPE negotiation into the Telnet client. Sheesh.


-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 92 06:56:17 GMT
From:      MRC@panda.com (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   re: informal notice of two IESG decisions


     In answer to Daniel J. Bernstein's megaflame against the IESG and request
for the opinions of others, I will state my opinions:

     1. RFC-931 is a terrible idea, and by extension any idea based upon it is
a terrible idea as well.  RFC-931 was useful in the ARPAnet and the Milnet,
where PSNs (formerly called IMPs) dictated addressing.  This is not the world
in which we live today.  RFC-931 was a half-assed non-solution, and in today's
world it is not a solution at all.  The best thing that can be done to RFC-931
and all ideas based upon it is to bury it.

     2. It is the height of sleeze for Daniel Bernstein to babble about
copyright with regard to Internet RFC's.  It is disgusting and disgraceful,
and reflects a fundamental lack of character in Bernstein.

     3. Equally deplorable is Bernstein's throwing of a public temper tantrum
against Mike StJohns.  Mike is the *author* of the original RFC-931.  Simple
courtesy, which Bernstein lacks as well as character, dictates that Mike have
the say in the disposition of RFC-931.  Such courtesy to authors has not
always been shown in the IETF, but that does not excuse discourtesy when it
occurs.

     In recent months, Bernstein has been clogging mailing lists and
newsgroups touting his garbage.  He repeatedly bad-mouths the efforts of
others, e.g. PEM.  Nor can he tolerate criticism; when I labelled RFC-931 on
the alt.security newsgroup as being a non-solution, Bernstein responded with
abusive invective.

     Bernstein claims to have `exposed corruption within the IESG.'  In fact,
what Bernstein has exposed are:
 a) the reasons why Daniel J. Bernstein is a total loser
 b) the reasons why the IESG did the right thing in rejecting his demands
 c) the invaluable and often thankless task the IESG does in filtering wheat
    from the chaff.


-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 11:58:04
From:      cws@vax.ftp.com  (Cris Shuldiner)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBMTOKEN - (ethernet over tokenring)

In article <1992Jun26.195351.14774@unx.ucc.okstate.edu> ben@datacomm.ucc.okstate.edu (Ben James) writes:

    Right now I am working on a frustrating problem I am trying to
    keep my server connection active (logged on) when I use the
    IBMTOKEN packetdriver from Clarkson.  When I start IBMTOKEN it
    seems as though it takes over the board.  This is unacceptable
    since I am connecting to the novell file server through this card
    also. 

    Or better yet has anyone modifyed this one so that it doesn't
    take controll of the board?  

My guess is that IBMTOKEN is taking over the LANSUPs single SAP when
you start it up.  The only way around this would be to enable more
SAPs.  The SAP (as far as I know) can't be shared, and so either
Novell has it or IBMTOKEN has it.  To enable more SAPs, you must run
dxmt0mod.sys with the ES command line option. (I am assumming we are
talking IBM LANSUP, and not another vendors implementation.)  This is
documented in the LANSUP readme file.  Unfortunately, this does mean
that you are using up extra memory for dxmt0mod.
    
--

Cris Shuldiner						Technical Support
cws@ftp.com						FTP Software, Inc.
Ph: (617) 246-2920					Fax: (617) 245-7943


-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 08:58:03 GMT
From:      oneworld!charles (Charles W. Cooper II)
To:        comp.protocols.tcp-ip
Subject:   Re: ATM (was: IP over partial mesh Frame Relay)

Art Berggreen writes
> In article <DRW.92Jun26145031@zermelo.mit.edu> drw@zermelo.mit.edu (Dale R.  
 Worley) writes:
> >For us newbies:  Just what *is* ATM?  It's supposed to be the newest,
> >hottest networking technology, but it's still vaporware as far as I
> >can tell...
> >
> >Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
> 
> Sure it's one of those machines outside banks... ;-}
> 
> (Serious mode on)
> 
> Short synopsis:
> 
> ATM (Asynchronous Transfer Mode) is a switching/transmission technique
> where data is transmitted in small, fixed sized cells (5 byte header,
> 48 byte payload)...
 
> ATM is a technology, not a product in itself.  But many companies
> are betting lots of R&D dollars that it is an appropriate technology
> to base new products on.
> 
> Art

Well thank you Art,

 I read Communications Week and that was the one term they failed to define in  
over a year of reading that publication.  Every other acronym they eventually  
got around to saying what it meant.  

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 12:42:09 GMT
From:      scoggin@daisy.udel.edu (John K. Scoggin, Jr.)
To:        comp.protocols.tcp-ip
Subject:   RFC931 (again and again and again ...)

Just how long are we going to flog this dead horse?  If you want to run
RFC931-compliant services, by all means knock yourself out.  Nobody is stopping
you.  If the SAAG believes that it is not worthwhile pursuing, I would tend
to accept that - they certainly have a lot better credentials than most of
the bellyachers.  Personally, I will place a lot more faith in PEM, for  
example.  And Kerberos might be OK if someone would explain how inter-Realm
authentication can be accomplished safely to me.

I'm just a poor, dumb network manager-type, but it seems to me that Mr.
Bernstein and the other players should sit down at the next IETF, face to face,
and hash this out.  And please, keep it off USENET - the S/N ratio is low
enough, IMHO.

Just my opinion.  We return you to your regularly scheduled threads. (I hope).

		:-)

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 92 19:37:23 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

In article <1992Jun27.124209.28848@udel.edu> scoggin@daisy.udel.edu (John K. Scoggin, Jr.) writes:
> Just how long are we going to flog this dead horse?  If you want to run
> RFC931-compliant services, by all means knock yourself out. 
> Nobody is stopping you.

Hundreds of us *are* running TAP-compliant services. We've gotten
together and agreed on a document describing the protocol we're using.
Why is the IESG preventing us from publishing that document in their
standards series?

I agree with what you say about PEM and Kerberos. Give me a PEM
implementation (together with the necessary infrastructure to support
it) and I'll gladly use it and trust it much farther than TAP. Same if
you give me a Kerberos implementation which works between realms. (I
contributed the replay cache code for Kerberos v5; what have you done to
help?)

In the meantime I can't afford to ignore security problems. Can you?

---Dan

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 20:09:15 GMT
From:      scoggin@daisy.udel.edu (John K. Scoggin, Jr.)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

In article <21736.Jun2719.37.2392@virtualnews.nyu.edu> brnstnd@nyu.edu (Dan Bernstein) writes:
>
>I agree with what you say about PEM and Kerberos. Give me a PEM
>implementation (together with the necessary infrastructure to support
>it) and I'll gladly use it and trust it much farther than TAP. Same if
>you give me a Kerberos implementation which works between realms. (I
>contributed the replay cache code for Kerberos v5; what have you done to
>help?)
>

Actually, we performed beta-testing of a commercially available firewall
system (Eagle from Raptor Systems).  This cost my company some money and
quite a bit of my time.  Does this meet with your approval? :-)

>
 In the meantime I can't afford to ignore security problems. Can you?
>

Certainly not.  But a security system which provides information which is
questionable is of no value to me.

My point is that the issue would be better resolved in a face-to-face
meeting between all parties involved.  I don't personally know all of the
parties involved, but I do know Steve Crocker.  I believe him to be a man of 
integrity and certainly a expert in the field.  It is difficult to believe
that he is carrying on some kind of personal vendetta against your RFC.
Might I suggest that a BOF be set up at the next IETF meeting so that the
SAAG and yourself can meet to iron out these issues?  Short of pistols at
20 paces, I believe that this is the only way of settling the situation...

>---Dan

	- John

-------------------------------------------------------------------------
John K. Scoggin, Jr.			Email:   scoggin@udel.edu
Supervisor, Network Operations			 scoggin@delmarva.com
Delmarva Power & Light Co.		Voice:	 302-451-5200
P.O. Box 6066				Fax:	 302-451-5321
Newark, DE 19714-6066
-------------------------------------------------------------------------
Your milage may vary.  Void where prohibited by law (or common sense).

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jun 1992 20:35:46 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.unix.sysv386,comp.protocols.tcp-ip
Subject:   BOOTP server for SVR4 UNIX

Hi,

Does anyone know of a free BOOTP server which works on SVR4
(System V Release 4 UNIX)?

Thanks in advance for any pointers.

...Sam
-- 
<skl@wimsey.bc.ca>
-- 
<skl@wimsey.bc.ca>

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 03:18:57 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

In article <1992Jun27.200915.8110@udel.edu> scoggin@daisy.udel.edu (John K. Scoggin, Jr.) writes:
> My point is that the issue would be better resolved in a face-to-face
> meeting between all parties involved.

It's too late for that. I personally have wasted many thousands of
dollars of my time dealing with Crocker et al. Among other things,
Crocker rejected a standardization request without communicating his
findings to the IETF to permit final review by the community. That is a
blatant violation of RFC 1310. He also explicitly based his rejection on
criteria not listed in RFC 1310. That's what your ``man of integrity''
has done. Read all 25 sections of my message for more details.

What would I get out of a face-to-face meeting with a snake? I think
it's time for the people involved to explain their actions to the
Internet community.

> Certainly not.  But a security system which provides information which is
> questionable is of no value to me.

It makes no sense to question the information provided by TAP since the
protocol per se does not assign any extrinsic meaning to the identifiers
it transmits. In other words, if you get the identifier ``!@#$%^&'' from
a host you've never heard of before, you can simply record the fact that
you received that identifier. What's questionable about that?

Say the remote host is malfunctioning, and the identifier happens to say
which component of the system is responsible for the malfunction. You
can tell the remote host's sysadmin ``!@#$%^&'' and you've done a good
deed without ever receiving ``information which is questionable.'' As a
special case, suppose the ``malfunction'' is a user on that system who's
doing bad things. Once again you've let the sysadmin locate the problem
within his system, without ever having to interpret the identifier for
yourself.

(Note that there's no issue of you lying to the sysadmin about what his
TAP server said---he can encrypt the identifiers in a secret key if he
wants.)

---Dan

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 06:56:00 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

A few points/questions:

1) Even suppose everything you are saying is correct, then if we look to
"what is best for the community" it is to stop this bickering and get an RFC
published.  That is what ident is doing.  Or are you more interested in seeing
your name on the RFC then in seeing the RFC published?

2) In section #13 you discussed the matter of tone.  If your long notice
(which I did read from beginning to end) is any indication of the tone of
your proposed RFCs or notes, then I understand why the entire IESG is
against you.

3) You state you are not afffiliated with NYU.  What exactly do you do and
who do you work for?  This would give me a better chance to determine whether
you have any vested interests in which way the RFC goes.

4) I haven't been living in the USA for the past 10 years but your system
is called kramden.  Isn't that from the Honeymooners? Ralph ("To the moon,
Norton!") Kramden?

And I thought I was gonna be kind of bored at the IETF :-)
Oh by the way, feel free to quote me on anything from section #4 above.

Hank Nussbacher
Israel

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Jun 1992 10:11:24 GMT
From:      linstee@dutecaj.et.tudelft.nl (Erik van Linstee)
To:        comp.protocols.tcp-ip
Subject:   How many people actually use token ring?

Hi,

I'm trying to find out how many people use token ring networks
and how many use ethernet or arcnet. If you have any statistics
I would like to know.

Erik van Linstee   |   linstee@duteca.et.tudelft.nl   |   I'll be back ... 

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 16:53:37 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Opinions on Telnet option 200 sought

While debugging a telnet implementation I came across something strange -
The telnet server on a certain IBM RS/6000 attempted to negotiate a Telnet
option 200 - the RS/6000 sent "WILL (200)". Option 200 does not appear in
any of the relevent RFCs that I can find - does anyone know anything about
what the IBM machine might be trying to do, or what IBM are up to?

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 18:43:48 GMT
From:      atkinson@itd.nrl.navy.mil (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)


  The "solution" being pushed endlessly by Bernstein in fact does not
add any security whatsoever to the network.  In fact it is probably
harmful because it erroneously causes people to think they have
enhanced security when in fact it is not enhanced.

  Bernstein's uncivilised behaviour on the net speaks for itself.  I
normally ignore Bernstein as best I'm able to since he doesn't
restrict himself to the truth and nothing but the truth wrt this
protocol...

  The IESG has done The Right Thing here...

Ran
atkinson@itd.nrl.navy.mil

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 18:44:30 GMT
From:      richb@kronos.com (Rich Braun)
To:        comp.security.misc,comp.protocols.tcp-ip
Subject:   Re: tcp-ip security question

mrl@uai.com (Mark R. Ludwig) writes:
>I would greatly appreciate it if you used a different word from
>"hacker." ...  The General Media have given "hacker"
>a bad name ... Please use "cracker" instead.

Too late.  Never call yourself a 'hacker' these days.  I called myself
a computer hacker up until about 1985, and since then it's had too many
negative connotations.

The term became obsolete roughly on the same date MIT-AI, an old PDP-10
which served as a nerve center of the Arpanet, was decommissioned.

-rich

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 92 20:07:28 GMT
From:      ahalim@ics.uci.edu
To:        comp.protocols.tcp-ip
Subject:   how to monitor tcp connection?


I need to write a 'monitor' program that basically can analyze the
data sent/received on both end of a tcp connection between server-client.

The server and client programs were written using socket. An easy implementation
of the monitor program is to have both server and client to send of copy
of message every time they send out to the monitor program (via udp). But
this would slow down the serve-client connection performance. A better
way is to have a completely independent monitor that can 'tap' into the
tcp line and reports the conversation going on there. How is this achieved
at the socket-level? This monitor is sort of similar to the 'netstat'.

Thanks
/aha


-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Jun 1992 20:33:34 GMT
From:      mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

>  The "solution" being pushed endlessly by Bernstein in fact does not
>add any security whatsoever to the network.  In fact it is probably
>harmful because it erroneously causes people to think they have
>enhanced security when in fact it is not enhanced.

	I'm inclined to agree. I'd rather not have any information at
all, than something I couldn't really trust. This is why on my gateway,
it doesn't trust anything it can't figure out for itself.

	I think the term "half assed" that was applied to TAP was maybe
a bit harsh, but "solution" isn't the right word for it either.

mjr.

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 03:54:49 GMT
From:      drw@kronecker.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Maturity (people's, not TCP's)

When I was but a callow youth, I had this idea that the world worked
(or *should* work) according to *rules* -- rules that said what you
had to do, rules that said what *they* had to do.  But as I got older,
I realized that nothing really works this way, except possibly buying
packaged goods from the grocery store -- there the rules are pretty
clear, you pay the money, you take goods.

The way the world really works is based on "karma points" -- every
time you do a good deed, or be nice to someone, you get a karma point.
Every time you need someone to do you a favor, or need a rule bent in
your favor, or most importantly, need consideration from someone who
has no real reason to give you consideration, you spend karma points.
If you run out of karma points, then people will give you (at most)
only what the rules say you should get, which is enough to let you
survive, but not enough to really succeed in any way.  Thus, a smart
person keeps a surplus of karma points, just like he keeps a surplus
of money -- you never know when you'll need some extra.

Now there is a special breed of people, commonly called "assholes",
who don't work to get karma points.  What they don't realize is that
they spend all their karma points, so when they actually need
consideration, they find themselves shut out.  They, of course,
complain mightily that they are being discriminated against, when, in
reality, anyone else who acted the same way would be treated in the
same way.

What relevance is this, you say?  I will share with you one of the
best jokes I ever saw on Usenet:

	dbwm -- the window manager that argues with you for ten
	minutes before resizing your window

The details of the application I leave to the reader...

Dale

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 13:47:29 -0500
From:      imhw400@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: ISDN Support

In article <1992Jun26.154116.23125@macc.wisc.edu>, dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes:
> I'm curious to know what support exists for primary rate
> ISDN.  Do any term server or router manufacturers support
> a single primary rate interface to multiple basic rate
> ISDN connections?

It's called an AT&T 5ESS switch.  Get ready to write a biiiiiiiiiiiig check.

The idea of (for example) a cisco AGS with I.430 and I.431 interfaces and an
ISDN routing process, is intriguing.  But I wonder whether they would be
interested in entering the packetized-voice field (against established players
the size of Northern Telecom, Siemens, Alcatel, and Ericsson), or have a viable
product if they chose to ignore voice/video/other-digitized-analog traffic.

What are you trying to do?
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:03:04 -0500
From:      imhw400@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: ATM (was: IP over partial mesh Frame Relay)

In article <1992Jun26.210737.16466@acc.com>, art@acc.com (Art Berggreen) writes:
> In article <DRW.92Jun26145031@zermelo.mit.edu> drw@zermelo.mit.edu (Dale R. Worley) writes:
>>For us newbies:  Just what *is* ATM?  It's supposed to be the newest,
>>hottest networking technology, but it's still vaporware as far as I
>>can tell...

and then goes on to give a nice summary.  Concerning the viability of ATM, over
in comp.dcom.isdn of late there hath been brave disputation.  Check the
archives for plenty of arguments pro and con.  The sense I made of it was that:
(1) ATM sounds like a really good idea if you think like a voice carrier;
(2) ATM sounds really dumb if you think like a datacomm user; and (3) it
probably doesn't matter as much as some people think.

I believe that, if ATM comes at all, for a long time we won't know.  The
carriers will use it within/among themselves as appropriate, and present us
with whatever interfaces we've demanded.  Most of us won't want to be bothered
about their internal network, and rightly so.
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 10:59:02 GMT
From:      paul@atlas.abccomp.oz.au (Paul Brooks)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)

In article <id.Z5ZQ.145@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|In article <920622154759@cream.ftp.com> jbvb@ftp.com writes:
|> These are API issues, not protocol issues.  See Sun's or Apollo's RPC API
|> for examples of this sort of thing.  They can handle either stream or
|> datagram transports more or less transparently, and the user doesn't care.
|
|How about this API:
|
|	fd = tcpopen(host, socket);
|
|	read(fd,...); write(fd, ...);
|
|	close(fd);
|
|Why does the socket API require anything more than this?
|-- 
|Peter da Silva                                               `-_-'

It doesn't, really - I've been advocating a much simpler interface than
a Berkeley or SysV sockets-compatible interface for a while. Unfortunately
people seem to want a DOS PC libary that will allow them to compile a
source file intended for Berkeley sockets completely unchanged and have it
work exactly as it would on a Unix host. This bunkum since the BSD sockets
interface has grown in a haphazard way as various facilities were added to
the internet protocol suite, and now some of the functions have absolutely
no real purpose. The TCP protocol provides a reliable byte stream, just
like a file, and the stdio interface for files makes a reasonably good fit
to use with TCP.
	Issues like this started to be hammered out a few months ago, with
people trying to determine what is the minimum API required to get reasonable
TCP functionality, in the hope that a minimum API could be decided upon
for DOS in much the same way that vendors seem to have done for Windows, to
avoid the problems with applications requiring a particular stack to work
because the API's were different. The discussion petered out when it become
obvious that one person's "minimum" was anothers "bloated", and some stated
that the "minimum" API had to have the ability to provide all the functionality
of BSD sockets anyway, and then some.
	It seems heresy to some that TCP/IP and BSD or SysV sockets are not
glued together, and that there might be advantages to doing things differently,
especially on machines with a much different OS & architecture.

	The API to my/our TCP kernel is very similar to what Peter described
above - although if enough customers bleat I will be forced to implement
a library to emulate BSD sockets as best as possible, which will use the
simpler interface to actually talk to the kernel. That way all the unnecessary
code overhead is in your application, not my lean/mean kernel.

(sorry about the soapbox - I recently spoke to a potential customer who refused
to purchase our kernel on the basis it didn't have a BSD-compatible sockets
library. He didn't know what he was going to do with it, but it was something
he thought he would miss if he couldn't get it.)

Viva simplicity.

-- 
Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 13:20:22 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Maturity (people's, not TCP's)

Wake up, Dale: I've contributed literally hundreds of thousands of lines
of code to the net, a lot of which even gets used---and computers are
just a hobby for me. I've got more people on ``my side'' than I can
count. We would be perfectly happy if the IESG would do *nothing more*
than follow the rules. Sure, it's all a game---but when you make
promises you've got to follow the promises or people won't like you.

Some people find TAP useful. Some people don't. Why should the latter be
able to prevent the former from publishing the protocol spec in the
IAB's standards series?

If you---any of you out in this jungle we call a network---think that
the IESG is making popular decisions, then can you explain why it kept
its decisions secret from the community? Even if you're in the camp that
doesn't see any point to TAP, you should think about this question. Why
was the IESG afraid to subject its decisions on TAP to final review by
the entire IETF?

---Dan

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 13:48:44 GMT
From:      thurlow@convex.com (Robert Thurlow)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

In <9206261749.AA20685@KRAMDEN.ACF.NYU.EDU> brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein") writes:

>I wrote to Galvin on 6 February. ``...
>Is my RFC 931 revision going to be published as is,
>with none of the insane editing that marred RFC 1143? If not, then the
>IETF is violating copyright.''

...

>12. Historical summary: copyright issues
 
>I had mentioned copyright on 6 February. RFC 1143 had been extensively
>modified immediately before publication, in violation of copyright law;
>I didn't want this to happen again. In March, after an attempt by a
>certain IAB flunky to steal my writing, I pointed out once again the
>automatic existence of copyright. On 29 March I offered to place my
>document into the public domain; several times before that I offered to
>transfer copyright to IAB the moment after my document was published.

I find your comments on copyright to be bizarre and contradictory.  If
you were as willing as you say to place the document in the public
domain, why is it so unclear to me what you were demanding from the
IETF in return?  Clearly you wanted something, and if you haven't told
us, I find it quite possible that the IETF never heard it clearly,
either.

As for RFC 1310, it doesn't explicitly say that standards can't be
stolen during a mugging, either, but the laws of the land probably
apply to the IETF as well as any other entity.  I find some of the
purported actions of the IESG less than wonderful, but rejecting it in
preference to having copyright problems with you is _not_ one of them.

Rob T
--
Rob Thurlow, thurlow@convex.com
Heaven knows / No frontiers
And I've seen heaven in your eyes			- Jimmy McCarthy

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 13:48:50 GMT
From:      rypma@waterloo.hp.com (Ted Rypma)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: HELP: bootp response from remote subnet ignored

lbroda@s.psych.uiuc.edu (Larry Broda) writes:
: We are trying to to configure the PCs in our departments to get their
: NCSA/Clarkson telnet (or FTP TCP/PC) configurations via bootp,
: ...
:                  However, the PCs refuse to acknowledge the bootp
: responses that don't come from their own subnet.
: ...
: Thanks in advance,
: 
: Larry Broda

Since no suggestions have yet appeared, I'll jump into the void...

The bootp clients running in your PC's must have the intelligence to pick the
gateway IP address field out of the response frame and the bootp server must
be aware that it is sending through a gateway and fill in the field (or the
field must be statically set up to contain the correct gateway IP address).

I suggest you check your response frames to ensure the correct information is
there... if no, add it; if yes, fix the bootp clients.

Ted Rypma
HP Panacom Division

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:03:50 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   TCP ARP entry aging?

The environment we work in is:
    - approx. 50 computers from various vendors (SGI, Sun, Motorola)
    - most running Unix
    - some running a real-time system called PSOS
    - all communicate via TCP/IP
My question is:
    In all of our systems the ARP appears to reset the ARP table entry
    timer on each send to a host.
    If the host being sent to has crashed or has been powered off
    and there is an entry in the ARP table for that host
    the sending host will never realize it because the table entry
    never ages to deletion (if the rate of sending is less than
    the 20 minute age period).
    The RFC for this (and, I believe, the Comer book) indicates that the 
    timer entry should NOT be reset on sends.
    We have had to add code to allow us to force an ARP table entry
    deletion when we have had a physical address change
    (we cannot reboot our entire system to clear all tables).
    Do you know if this is a common occurrence or an error in the TCP
    implementations?
    If it is not common should the vendors consider it a problem with
    their protocol that should be fixed?
    So far, each vendor has said that they purchased the protocol
    and it works as spec'ed and they do not consider this a problem.

Please mail responses and I will post useful replies.
any information that you can provide is appreciated
thanks
Doug Toppin
uunet!melpar!toppin
703-560-5000, x4731

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:04:54 GMT
From:      johnc@msc.edu (John D. Cavanaugh)
To:        comp.protocols.tcp-ip
Subject:   Internet Access in Asia

Someone called me last week and asked if I knew where he could
find Internet connections in Asia.  He's interested in the following
cities:
	Singapore
	Bankok
	Kuala Lumpur
	Jakarta
	Taipei

I took a quick look through 'whois', and couldn't find anything.  If you
know of any Internet-connected sites in these cities, please send me
email;  I'll compile a list and return this guy's call.  If there's interest,
I'll also post the list to the network.

Thanks.
-- 
John Cavanaugh                              EMail: johnc@msc.edu
Minnesota Supercomputer Center, Inc.        Phone: +1 612 626-0277
1200 Washington Ave. S                      FAX:   +1 612 624-6550
Minneapolis, MN  55415

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:05:51 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   How to fake a TCP multicast

The environment we work in is:
    - approx. 50 computers from various vendors (SGI, Sun, Motorola)
    - most running Unix
    - some running a real-time system called PSOS
    - all communicate via TCP/IP
My question is:
    Of our systems, only the SGI (Silicon Graphics) supports the
    multicast ability (broadcast datagrams to a group only).
    We have a need to send multicast from a PSOS system to the SGIs.
    We have been able to construct and send a 'fake' multicast packet
    from the Motorolas and have the SGIs receive it (the Motorola
    did not realize that the packet being sent was multicast format).
    So far, we have experienced no problems in doing this but it was
    an interesting exercise.
    It appears to be as simple as setting the correct destination
    Internet address (224.0.0.250) and the matching physical address
    (01:00:5e:00:00:fa).
    Is generating a multicast ICMP packet via a raw socket a valid
    thing to do?
    Are you aware of any side effects in doing this?
    Is it a common occurrence to do this sort of thing?

Please mail responses and I will post useful replies.
any information that you can provide is appreciated
thanks
Doug Toppin
uunet!melpar!toppin
703-560-5000, x4731

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:09:40 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   How does TCP linger work?

The environment we work in is:
    - approx. 50 computers from various vendors (SGI, Sun, Motorola)
    - most running Unix
    - some running a real-time system called PSOS
    - all communicate via TCP/IP
My question is:
    We cannot allow a crashed or hung-up destination application
    to hang a sending application.
    Therefore, we have had to experiment with using SO_LINGER and no linger.
    In the book Unix Network Programming it is mentioned that the
    timeout value specified with SO_LINGER is ignored but which systems
    ignore it and which support it is not specified.
    In our experience, the Motorola Unix did support the linger
    timeout value.
    On the SGI and the Sun, any value under 30 seconds resulted in a 30 second
    linger, any value higher than 30 seconds caused a delay of
    an unpredictable amount greater than 30 seconds or an indefinite delay.
    We saw an apparent data loss when the linger timeout was set to 0
    the socket was opened, data written, and then immediately closed.
    We saw no data loss when the default linger setting (we assume
    that linger is the default) was unchanged or we set it to not linger and
    the socket was opened, data written, and then immediately closed.
    What we are interested in is exactly what happens when the linger
    timeout expires?
    When the linger timeout is reached are resources allocated to the
    socket immediately released?
    What happens when the linger timeout is set to 0?
    What happens when no linger is specified?

Please mail responses and I will post useful replies.
any information that you can provide is appreciated
thanks
Doug Toppin
uunet!melpar!toppin
703-560-5000, x4731

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:23:12 GMT
From:      barnett@grymoire.crd.ge.com (Bruce Barnett)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

I think TAP is a good idea because it is easy to install and allows
cooperation between sites concerned about crackers. 

I have reported break-in attempts on our gateway to other sites. Many
times they cannot tell me which account attempted to break into our
machine. If they installed TAP, then I could log the account name when
I detected an attempt. They can use this information and either find a
cracker or find an insecure account.

It's true that if a cracker broke into a root account, TAP wouldn't
help you at all, except it is one more thing a cracker must cover up
along with system logs, etc..... and they may forget to hide their
tracks.

But not all attempts to break in are done from someone who has root access.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:27:58 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)

In article <id.Z5ZQ.145@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

    How about this API:
    
            fd = tcpopen(host, socket);
    
            read(fd,...); write(fd, ...);
    
            close(fd);
    
    Why does the socket API require anything more than this?

My own personal opinion is that the extra features of more elaborate
APIs are worth my effort in remembering the details - I think they
let me write more functional applications, with better error
reporting.  However, it appeared to me that what was being asked for 
was "one-function networking", something like:

	status = net_do_it(service_name, in_arg_p, out_arg_p);

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

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 14:28:24 GMT
From:      jbvb@vax.ftp.com (James B. VanBokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC931 (again and again and again ...)

In article <1992Jun28.203334.28352@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:

            I think the term "half assed" that was applied to TAP was maybe
    a bit harsh, but "solution" isn't the right word for it either.
    
When I first noticed what the "Ident" WG was up to, I wondered why it was
felt to be of importance - now I know.  However, I must say that TAP is not
by any means the most "half-assed" protocol being considered by the IETF.
Regrettably, my candidate for first place has the backing of A Very Big
Computer Company, and seems to be going forward...

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

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 16:05:54 GMT
From:      elin@digi.lonestar.org (Eddy Lin)
To:        comp.protocols.tcp-ip
Subject:   Help to get rfc documents


I am sorry if this is not the right group to post this question.
I was able to get rfc documents from info-server@sh.cs.net. But
I have not got any response since two weeks ago. Can somebody tell 
me where and how can I can get rfc documents from other server since
I don't have ftp access. Thanks in advance.

--
Eddy Lin             
elin@digi.lonestar.org

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 16:19:26 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

Rob Thurlow asks about my position on copyright. I guess I didn't make
it clear in my first message that my position changed over time. Before
RFC 1143 was published I didn't even think about copyright. When RFC
1143 was suddenly published---with a number of serious last-minute
changes that nobody checked with me---I became justifiably angry and
began to think about copyright issues. Eventually I came to the
conclusion that the IAB should require that anything in its standards
series be placed into the public domain immediately upon publication as
an RFC---but before that should permit authors the dignity of being
allowed to write and revise their own documents, just as journals do.
(Obviously if an author doesn't come to terms with the IAB then his
document won't be published anyway.)

That's the position I stated through March. In late March, seeing how
StJohns was suddenly making such a fuss over copyright, I threw up my
hands and offered to place my document into the public domain
immediately. Here is the exact wording of my first offer to StJohns and
Crocker:

: I understand and appreciate the view that all standards documents should
: be free for the IETF to change. I will declare my authd protocol spec
: public domain if you two swear, on your honor, that you will make sure
: that the views of the user community are accurately reflected by the
: standard; that you will not claim to be documenting the protocol in use
: within the Internet community unless, in fact, you are doing so; and
: that you will give me the chance to remove my name from anything you
: publish. Is that reasonable?

They didn't agree. In April I offered a few times to place my document
into the public domain with no strings attached, but in retrospect, Rob,
you might be right that these later offers weren't ``heard clearly.''
But the first offer was perfectly specific. You can judge for yourself
whether it was reasonable for me to ask that Crocker and StJohns not lie
to the community, and whether I'm Crispin's type of ``sleeze'' [sic] for
even considering copyright issues.

That offer still stands, by the way, though I'm not sure how I'd react
now to Crocker swearing on his ``honor.'' I suppose I'd accept Cerf as a
substitute.

I hope this answers your questions, Rob. Please consider this as an
appendix to my original message. I'll mention it in my summary message
to the IETF list at the end of this week.

---Dan

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 16:28:46 GMT
From:      restock@srv.PacBell.COM (Bob Stockwell)
To:        comp.protocols.tcp-ip
Subject:   Summary: Duplicate IP Addresses

Some time ago I posed a question to the net.  I received several good
responses.  Thanks everyone for your input.  This message is a summary
of the responses.

Here is my original query:

>What are the consequences of configuring two hosts with the same IP            
>addresses, accidentally?  If I understand ARP correctly, they would            
>both reply to an ARP request, and the ARP requestor would update the           
>ARP table with the last reply.  This could cause a lot of confusion.           
>Does anybody have experience with this problem?  Is there a suggested          
>way of avoiding and/or detecting the problem?  We are moving from a            
>NetBIOS network to an IP network.  In NetBIOS you must broadcast your          
>intention to use a NetBIOS name, before using it.  Is there a similar          
>protocol for IP, which would broadcast within a subnet?                        
--------------------------------------------------------

As you can see there are two questions: 1) what happens when you have
duplicate IP addresses and 2) how do you prevent it.

People responded to those two questions.

What happens:
--------------------------------------------------------
Mike Long (mlong@isucard.card.iastate.edu) says:

>This happened at our location on DecStations 2100 running Ultrix.  I was not
>really involved with the problem, but when one would come up, it would totally
>lock the other unit up.  Then when that unit would be restarted it would
>totaly lock the other unit up.

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

Ed Wilts (ewilts@galaxy.gov.bc.ca) says:

>We did once on two Vax/VMS systems running MultiNet.  TCP/IP traffic heading to
>one of the systems (I forget which one) hung.  It cost us a system reboot :-(

--------------------------------------------------------
Dylan (dylan@ibmpcug.co.uk) says:

>Bad idea.  We did that accidentally once. Never again. Not only it crash
>the two NCSA Telnet's, but it crashed the TCP/IP on the Xenix machine
>they were connecting to.

--------------------------------------------------------
Bruce Hafford (bruce@gordian.com) says:

>Typical symptoms also include TCP/IP connections that start ok,
>but fail right before or after the login step (as in Telnet).  Also,
>having one session run fine, closing it, immediately trying
>to reconnect and having it fail is a sign.... I'd look for an analyzer that
>can understand IP addresses and just have it running for the first
>x weeks...

--------------------------------------------------------
Glen Herrmannsfeldt (gah@oldhood.hood.caltech.edu) says:

>I have seen duplicate IP addresses.  As soon as the new host comes,
>its ARP's get into all the other tables, and the old host is lost.
 
>Probably some arp tables will start to get the old host back, but
>it is slow.  Most packets go to the newer host.

--------------------------------------------------------
Roger Hunen (rh0083b@medtronic.com) says:

>Duplicate IP address will result in BIG problems (thoughyour network will
>probably not go down :-)). Packets will be routed to the wrong host,
>connections will be dropped, diskless workstations are going to hang, etc,
>etc, etc.
--------------------------------------------------------
Bob Fillmore (fillmore@emr1.emr.ca) says:

>Duplicating some addresses can have spectacular effects.
>We had a user who configured his PC with the address of the cisco router
>used to connect us to the Internet.  Before long all the local Internet
>traffic was directed at his PC (which acted as a black hole).
--------------------------------------------------------
Joe D. (jrd@cc.usu.edu) says:

>        While I agree with everything folks have said about "Don't even
>think about it" I did run some tests. The tests were to log into various
>local machines from PCs with a duplicate PC IP address. Depending on whether
>one went through a NW 3.11 server acting as an IP router or not the results
>differed. Basically it seems to be more of a test of arp caches than anything
>else. Some replace old entries with new ones, others keep the old and reject
>the new (until timed out). I think that covers the possibilities. In any
>case all that happened was connections died, there were no routing snarls
>because RIP ignores clients.
>        I have an EXOS 205T Ethernet board, the smart kind with a cpu chip.
>That board senses something and when warm reset it generates a new Ethernet
>address each time according to some algorithm. Hmmm, big hmmmmm. Well, when
>that occurs it takes a dozen or so outgoing packets from the PC to cause
>arp caches of name server and local target host to believe the new Ethernet
>address (hectoring into submission I suppose).
--------------------------------------------------------
To which Matthew J. D'Errico (doc@magna.com) responds:

The point was multiple *hosts* with the same IP address...  The description
to which you are replying mentioned multiple *servers* which would have
significantly different impact(s) than would multiple *clients*...

--------------------------------------------------------
***********************************************************************

To summarize, all heck breaks loose when you have duplicate IP
addresses.  By the way, the original question came from a coworker who
did have a duplicate IP address, with the effect that current sessions
stopped working.

***********************************************************************

Now to the solutions:

--------------------------------------------------------
Barry Margolin (barmar@think.com) says:

>Many systems send out an ARP request for their own address when they're
>booting.  If they get a reply then they report "duplicate IP address" and
>don't enable the interface.
 
>In addition to detecting duplicate IP addresses, this also sometimes
>detects machines configured with the wrong subnet in their IP address.  If
>you have a router that does proxy ARP, it will respond to any ARP requests
>for an IP address on a different subnet.

--------------------------------------------------------
Bruce Hafford (bruce@gordian.com) says:

>Many devices arp for an IP address before using it.  It's still
>the exception, not the rule.
--------------------------------------------------------
Mike Black (black@seismo.css.gov) says:

>Sounds like you may want to consider 'rarp' which will broadcast its'
>ethernet address and someone on the net will tell it its' ip address.
>Most versions of tcp/ip support this.
--------------------------------------------------------
Roger Hunen (rh0083b@medtronic.com) says:

>Many IP implementations are paranoid enough to ARP for their own IP address
>to detect this problem and complain about it. My suggested way to avoid
>this problem is to maintain a central database with IP addresses for your
>site. When somebody needs an IP address, he must ask his network
>administrator. If your site is large, hand out complete IP subnets to local
>administrators. I'd suggest that you setup DNS (Domain Name Service) and
>give it the same authority structure that you use for handing out IP
>addresses (ie. the network administrator who is authorized to hand out an
>IP address, will also be responsible to include the corresponding records
>in the DNS).
--------------------------------------------------------
Stephen C. Trier (trier@slc6.ins.cwru.edu) says:

>That's a good idea.  We rely on our BOOTP tables and host registration
>database to give a list of "valid" Ethernet-to-IP address mappings, then
>continuously check the packets on the net by using NNStat to build lists
>of all active IP-Ether address pairs.  It's not pretty, but it does work. :-)
--------------------------------------------------------
Bob Fillmore (fillmore@emr1.emr.ca) says:

>We are now much more sensitive to that possibility, and we are building
>a list of IP addresses with corresponding ethernet addresses (using
>etherhostprobe) so that we can locate the offender quickly.
--------------------------------------------------------

***********************************************************************
Again to summarize:

The solutions seem to come in two flavors: 1) Some implementations ARP
their own address to be sure its ok.  Because this is not universal it
would only have limited success, and 2) Don't let the host choose the
address, instead store the addresses remotely, then use BOOTP or RARP.

***********************************************************************
Thanks everybody for your help.
-- 
Bob Stockwell
Pacific Bell
pacbell.com!ptsfa!res

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 16:47:11 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

I suppose I shouldn't help continue a flame war, but resisting such temptation
has never been one of my strong points...

{ much deleted }
>Mark, if you don't understand TAP, you can feel free not to use it.
>There are hundreds of people and a growing number of applications which
>use it. Why don't we have the right to document the protocol we use in
>the IAB's standards series?
 { more deleted }
>Besides, Ident is *not the same protocol* as TAP: the existing TAP
>implementations don't comply with the current Ident draft in several
>important ways. How dare you stifle a protocol in use at hundreds of
>sites in favor of a vapor protocol which isn't even compatible?
{ yet more deleted}

Dan,

For the most part I'll confine my comments to the neighborhood of the above
snippets from your message.  The personal attacks in all directions should
simply be ignored as inappropriate.

I haven't been involved in any of the dispute over the Ident protocol and only
marginally know what it's about, so I'm really speaking to meta-issues
involving people who I respect and a process that I believe works pretty well.

One of the jobs of the IAB and the IESG, whether it says so in RFC 1310 or
not, is to discourage ill-advised protocols.  This can be very difficult and
sometimes subjective.  When an opinion is based on intuition it can be very
difficult to defend, and this can lead to hiding behind more objective
procedures and delaying by process hoping the problem will go away.  Perhaps
this happened, at least to some extent.  I condone or defend doing things that
way.  I'm simply proposing a possibility.

To get to the snippets, acceptance and use by lots of people does not make
something good.  Standardization of a bad thing does not make it a good thing.
The majority is more often wrong than right.  The Internet is not a democracy
and it shouldn't be.  I have worked with many of the people you are accusing
of corruption and conspiracy.  At worst, I believe they are guilty of not
being clear when they should have been.

A well-respected former boss of mine once observed that I'd rather be right
than president.  I take that as a compliment.  I'd rather be clear of word an
conscience, disliked, and considered by some to be high-handed and unfair,
than ambiguous, polite, and misunderstood.  As long as I find agreement from a
few people who I respect, I'm satisfied.

My reading on this situation, based on what little I know of the technology
involved and the bit more I know about the people that have stood in its way,
is that the idea you're pushing shouldn't be on the standards track simply
because it's a bad idea.  If lots of people want to use it and be happy with
it, I wouldn't mind seeing an informational RFC that helps them all do it the
same way.  This is sort of a free country, and sort of a free network.  I
believe people should be free to hurt themselves as long as I don't have to
pay to fix them and I haven't helped mislead them into feelings of false
security.  With a warning that some people consider the technology potentially
harmful and misleading, documenting this protocol should be no less
appropriate as an RFC than humor and poetry

	Bob
	

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 17:59:03 GMT
From:      roy@alanine.phri.nyu.edu (Roy Smith)
To:        comp.protocols.tcp-ip,comp.mail.misc
Subject:   Star-9


	Has anybody heard of a company called Star-9?  We're currently
evaluating multi-platform mail packages and are trying to make sure we
havn't missed any (we know about all the big ones).  It was mentioned that
somebody called Star-9 had a product, but I've never heard of them.
Anybody know who they are or how to get in touch with them?
-- 
roy@wombat.phri.nyu.edu (Roy Smith)
Public Health Research Institute
455 First Avenue, New York, NY 10016, USA
"This never happened to Bart Simpson."

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 18:05:41 GMT
From:      weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT])
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBMTOKEN - (ethernet over tokenring)

paul@atlas.abccomp.oz.au (Paul Brooks) writes:
>ben@datacomm.ucc.okstate.edu (Ben James) writes:
>|Right now I am working on a frustrating problem I am trying to keep my server 
>|connection active (logged on) when I use the IBMTOKEN packetdriver from 
>|Clarkson.  When I start IBMTOKEN it seems as though it takes over the board.  
>|This is unacceptable since I am connecting to the novell file server through 
>|this card also.
 
>Yes, IBMTOKEN takes over the card. It is a packet driver, so it is supposed
>to take over the card, and all protocol stacks are supposed to contact
>the IBMTOKEN driver to send/receive packets. Note that while many people
>use the IBMTOKEN driver it is not recommended for production use - the
>"alpha version" message on startup is not just for show, and the RX/TX  
>message in the bottom corner are residual messages left for debugging.
>If you have access to a Borland assembler you could re-assemble the code
>with the messages disabled.

Hm. The most recent Version (10 2) doen't contain this "alpha message" nor
does it produce debugging output.

>|From what I have read this driver simulates something simular to an 
>|[ethernet 3c501 driver] over TokenRing.  Does anyone know something 
>|simular that I could try?
 
>After running the IBMTOKEN driver, try using PDIPX.COM or the BYU packet driver
>IPX - these are Netware IPXs that talk to the packet driver instead of directly
>to the card. You should be able to run CUTCP and Netware simultaneously.

No, he won't. Sorry to say this so abruptly, but this is definitely the
wrong way. The IBMTOKEN driver does certain things with TR packets -
this works ONLY with TCP/IP.
But - it sits on top of the IBM Lan Support Program, which has packet 
multiplexing abilities as well. So generate a linked IPX for the Lan
Support Program and start that after the IBMTOKEN driver. 
That definitely works here.

>|Or better yet has anyone modifyed this one so that it doesn't take controll of
>|the board?  
>|What I would really like is a combination of this and odipkt that would route 
>|threw ODI instead of takeing over and bypassing ODI like IBMTOKEN seems to do.

I never understood why, but the above mentioned method doen't work with the
LANSUP ODI driver.

[...]
>IBMTOKEN transforms the token ring (IEEE 802.5/802.2) headers into EthernetII
>headers, and effectively "fakes" an ethernet interface. ODIPKT preserves
>the 802.5/802.2 headers, so you would need a TCP/IP stack that understands
>IEEE format frames to use the ODI driver. CUTCP expects to see an Ethernet_II
>packlet driver, and as far as I'm aware will not recognize a token-ring
>packet driver interface.

Unfortunately, basicly all free available packet-drtiver-based software 
refuses a Token-Ring-class ODI-Driver.

>|My goal is to be able to login with the IPX protocol and telnet with the IP
>|protocol simultaneously while using the LANSUP program.  
>|Is that asking for too much?  Probally but It's what I need. 

No. It works here. But stay away from those IPX-over-packet-driver
stuff. It will not run with the IBMTOKEN.

>|As soon as I start the IBMTOKEN driver I loose my drives on the server.
 
>Thats right - IBMTOKEN wants to control the hardware, and be the bottom driver
>for every other protocol stack.

No. The bottom drivers are the IBM stuff. IBMTOKEN only has a little bit rude
way of announcing itself to them. 

Regards

Christoph Weber-Fahr

-- 
  Christoph Weber-Fahr                  |  E-Mail:  weber@rhrk.uni-kl.de 
  Universitaet Kaiserslautern,  KIT/IVS |  S-Mail:  Postfach 3049
  Tel. 0631/205-3391                    |           D-6750 Kaiserslautern
--------------------------  My personal opinion only    ---------------------

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 18:25:33 GMT
From:      gerard@netlabs.com (Gerard Horan)
To:        comp.protocols.tcp-ip
Subject:   Re: Well known ports and bad clients (abortive disconnect)

In article <17909.Jun2614.51.1992@virtualnews.nyu.edu> brnstnd@nyu.edu (Dan Bernstein) writes:
>In article <1992Jun22.154359.20240@cbnewsj.cb.att.com> cauble@cbnewsj.cb.att.com (Troy Cauble) writes:
>> 1)  Server listens on a well known port.  Client connects.
>> 2)  Client then does something annoying like getting blocked,
>>     going into an infinite loop, sleeping  forever, etc.
>> 3)  For unrelated reasons, Server is then killed and restarted.
>> 4)  The restarting Server gets EADDRINUSE trying to bind it's
>>     well known port.  Utilities show the well known port stuck
>>     in FIN_WAIT_1 or FIN_WAIT_2 (because the old Client never
>>     handled it's end of the shutdown).
>
>Sounds like a UNIX problem, not a TCP/IP problem. The simplest solution
>is to avoid #3. If you use inetd (or tcpserver or anything similar) then
>there will rarely be a reason to kill or restart the server.
>
>---Dan
I used to have problems like this under ISC 2.2 TCP/IP 1.2. The company 
I was working for started to use AIX and these problems disappeared.

My 2 cents.

gerard

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 18:25:59 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

In article <9206281611.AA00969@KRAMDEN.ACF.NYU.EDU>
brnstnd@KRAMDEN.ACF.NYU.EDU ("Daniel J. Bernstein") writes:
[ lots of stuff ]

I've had enough of this whining out in the technical newsgroup
comp.protocols.tcp.ip and related mailing list?  Please take the
personal attacks, the childish whining and the petty bickering else
where.  Aren't there formal procedures to go through when one has a
grievance with the process?  I'm sure that posting the gory details
here isn't part of of those procedures...

Warner "I'm an engineer, not a politician" Losh
-- 
Warner Losh		imp@Solbourne.COM
"I think we'd get fewer weird bug reports if we stopped selling our
 software off planet."  sm at shorty's

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 19:31:06 GMT
From:      brnstnd@nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

In article <BqMDvB.A30@solbourne.com> imp@solbourne.com (Warner Losh) writes:
> Aren't there formal procedures to go through when one has a
> grievance with the process?

No, damn it, there are not. I sent Cerf et al. an informal complaint in
February, then a formal complaint, then another complaint and another
request, and over all these months none of them have been able to point
out anything wrong with the protocol except that they're too blind to
see how it's useful. About the only way they responded to my complaints
was by adding a note to RFC 1310 saying that maybe they should have a
formal grievance procedure. Thanks a whole lot, guys. Real helpful.

To all of you who suggest publishing this as an informational RFC: I
considered that possibility. But when I asked Jon Postel in mid-May how
I would go about doing that, he didn't even respond. I've asked several
IESG people whether they thought this was really appropriate for
Informational status rather than Proposed Standard, and not one of them
has said yes. So much for that.

Those of you who say TAP is useless should consider the fact that the
IESG supports it strongly enough to have a working group---Ident---to
standardize a functionally similar protocol. Even Crocker stated that he
thought TAP was appropriate for the standards track. You can't have it
both ways.

---Dan

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 19:47:40 GMT
From:      drw@nevanlinna.mit.edu (Dale R. Worley)
To:        comp.protocols.tcp-ip
Subject:   Re: Maturity (people's, not TCP's)

Dan, is anybody on this newsgroup other than you complaining that the
IESG is not doing things properly?  Now given that you are asking that
"the IESG would do *nothing more* than follow the rules", why would
people not do so?  I suggest it's because you piss them off.  I will
grant that you've contributed hundreds of thousands of lines of code
(although I don't know of them personally), that's *much different*
from being a pleasant person to do business with.  Being pleasant gets
you things that merely being extremely competent will not.

While you're at it, you might want to check into how the IESG really
works, rather than how it officially works, and see if you've worked
within the unofficial rules.

Dale

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 92 03:16:38 PDT
From:      nader@cup.portal.com (Nader - al-Twaijri)
To:        comp.protocols.tcp-ip
Subject:   Terminal server (IP/Ethernet,etc)

 
I am having some trouble locating companies that provide terminal servers; I 
don't know if this is the right place to post this, but please send me some
information on your terminal servers (IP/Ethernet, etc), price, ports, etc..
I would like to hook it up to a NeXTstation.... 
                                                -Thank you.
...following address:
                        Nader al-Twaijri
                           P.O. Box 5171
                             13052 Safat
                                  KUWAIT
 
if you can, please fax literature/pricing to +965 2463067... (I must make
decision fast) -thanks.

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 92 20:56:33 GMT
From:      amanda@visix.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: informal notice of two IESG decisions

Whatever the merit of your complaints, Dan, you have not done yourself any
service.  Throwing a temper tantrum, however formally phrased, only makes me
*less* inclined to take your complaints seriously.  Your contentious and
accusatory tone leads me to speculate that is not the IETF and IESG which have
abused the process.

From your own description, I would have rejected your proposal myself on
purely technical grounds.  RFC 931, and the successor to it that you have
developed, provides no additional security over the current status quo, and is
thus only useful in situations where its deployment is unknown and unexpected
("security through obscurity").  Given this, combined with your consistent
arrogance over the past several years concerning this issue, I feel that the
IESG acted appropriately in the interests of the overall Internet community.


Amanda Walker						      amanda@visix.com
Visix Software Inc.				    ...!uupsi!visix.com!amanda
-- 
"The concept is simply staggering -- pointless -- but staggering."
		---Doctor Who

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 21:03:51 GMT
From:      jap@acsu.buffalo.edu (James A. Perreault)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBMTOKEN - (ethernet over tokenring)

You have a slight misunderstanding in how IBMTOKEN works.

It doesn't take control of the board.  It communicates to the board via
IBM's LAN Support Program.

paul@atlas.abccomp.oz.au (Paul Brooks) writes:

>After running the IBMTOKEN driver, try using PDIPX.COM or the BYU packet driver
>IPX - these are Netware IPXs that talk to the packet driver instead of directly
>to the card. You should be able to run CUTCP and Netware simultaneously.
>|

As a consequence the BYU packet driver won't work.  I haven't tried PDIPX but
I don't think it will, either.

You need to load the IPX that is generated for the LAN Support program,
instead of the one generated that speaks directly to the TR board.  You also
need the LAN support program loaded.

You don't need ODI.  I think what Ben was trying to do was to run IPX through
the IBMTOKEN interface.  This didn't work, probably because it was only 
designed to work with the CUTCP package.

						Jim Perreault
>|Or better yet has anyone modifyed this one so that it doesn't take controll of
>|the board?  
>|What I would really like is a combination of this and odipkt that would route 
>|threw ODI instead of takeing over and bypassing ODI like IBMTOKEN seems to do.
 
>If you are currently running an ODI driver for the token ring card, you
>can get ODIPKT.COM which is a shim that provides a packet driver interface
>that sits on the ODI driver. This won't help you run PDIPX.COM on top
>of it, because PDIPX.COM expects to see an ETHERNET_II packet driver, and
>ODIPKT looks like a TOKENRING_SNAP packet driver.
 
>IBMTOKEN transforms the token ring (IEEE 802.5/802.2) headers into EthernetII
>headers, and effectively "fakes" an ethernet interface. ODIPKT preserves
>the 802.5/802.2 headers, so you would need a TCP/IP stack that understands
>IEEE format frames to use the ODI driver. CUTCP expects to see an Ethernet_II
>packlet driver, and as far as I'm aware will not recognize a token-ring
>packet driver interface.
 
>|My goal is to be able to login with the IPX protocol and telnet with the IP
>|protocol simultaneously while using the LANSUP program.  
>|Is that asking for too much?  Probally but It's what I need. 
 
>Its not too much, but you need to give up the ODI driver. First load
>IBMTOKEN - this gives you an EthernetII packet driver. CUTCP will work
>over this. Then load PDIPX.COM (or a BYU similar IPX), then your NETx.COM
>Netware shell. The two should then co-exist fairly happily.
 
>Note that IBMTOKEN is really a bit of a cludge - the better solution would
>be to find a TCP/IP stack that understands IEEE frame format. I'd plug
>my own implementation, but it aint free, and this IS the Internet :-)
 
>|As soon as I start the IBMTOKEN driver I loose my drives on the server.
 
>Thats right - IBMTOKEN wants to control the hardware, and be the bottom driver
>for every other protocol stack.
 
>|Also If you have any ideas on other methods of going about please drop me a note.
>|Also please email me dirrectly if possible at
>|ben@datacomm.ucc.okstate.edu  
 
>I will send this direct as well as post - its been a while since IBMTOKEN was
>discussed!
 
>Hope this helps you and others trying to use freeware TCP/IP stacks over
>token ring networks...
 
>-- 
>Paul Brooks               |paul@atlas.abccomp.oz.au|LIFE is a bowl of cherries:
>TurboSoft Pty Ltd         |pwb@newt.phys.unsw.oz.au|  sweet at first, until you
>248 Johnston St. Annandale|pb@aaocbn.oz.au         |  reach the pits.
>Sydney NSW 2038           |ph: +61 2 552 3088      |  

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jun 1992 22:08:22 +0000
From:      ronald@gate.demon.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip,comp.protocols.ppp
Subject:   Re: SLIP over a TELNET Link?

[ Newsgroups edited somewhat ]

karn@chicago.qualcomm.com wrote:

> I've also toyed with the idea of running SLIP over Telnet,
> Ahem. Anyway... my idea was to encode IP datagrams as lines of
> printable ASCII characters, one packet per line. Something like
> uuencode or binhex encoding would work. You'd probably have to limit
> your MTUs to whatever will fit in the line buffers along the way.

I'm confused now.  Other than inefficiency, why isn't PPP any good for
this purpose ?  Is its character transparency mechanism inadequate or
am I missing something obvious ?

Thanks.

-- 
Ronald Khoo <ronald@demon.co.uk> <ronald@ibmpcug.co.uk> <ronald@robobar.co.uk>
BTNet: +44 71 229 7741                    | Brambles are the order of the day.

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 92 22:20:12 GMT
From:      ltran@sjecc1.wdl.loral.com
To:        comp.protocols.tcp-ip
Subject:   Re: Seeking Terminal Servers that SLIP

In article <1992Jun26.210955.29463@news.arc.nasa.gov> mcmahon@tgv.com (John
'Fast-Eddie/FuzzFace' McMahon) writes:
>
>
>I'm looking for a list of vendors that build IP terminal servers that
>can act as a SLIP gateway to an Ethernet.  Please reply to me,
>when I build up the list I'll post it.
>
>Thanks in advance!
>--


Xyplex's terminal server.  I am configuring my terminal server port to do that
right now...


Linh Tran					ltran@sjecc1.wdl.loral.com

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 00:09:42 GMT
From:      rfranken@mcs213i.cs.umr.edu (Richard Brett Frankenberger)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBMTOKEN - (ethernet over tokenring)

Since IBMTOKEN runs on top of the IBM LAN Support Program, and you use a
LAN Support Program generated IPX instead of a Packet Driver Generated IPX,
is it possible to use ODI for providiing the IPX protocol?  (i.e. load
IBM LAN Support Program in CONFIG.SYS, then load IBMTOKEN, LSL, LANSUP,
IPXODI, NETX, other ODI protocol stacks, in AUTOEXEC.BAT).

     - Brett   (rfranken@cs.umr.edu)

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 10:24:40 -0500
From:      imhw400@indyvax.iupui.edu
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)READ/NEW/FOLLOWUP

In article <1992Jun29.105902.2180@atlas.abccomp.oz.au>, paul@atlas.abccomp.oz.au (Paul Brooks) writes:
[deletia]
> It doesn't, really - I've been advocating a much simpler interface than
> a Berkeley or SysV sockets-compatible interface for a while. Unfortunately
> people seem to want a DOS PC libary that will allow them to compile a
> source file intended for Berkeley sockets completely unchanged and have it
> work exactly as it would on a Unix host. This bunkum since the BSD sockets
> interface has grown in a haphazard way as various facilities were added to
> the internet protocol suite, and now some of the functions have absolutely
> no real purpose. The TCP protocol provides a reliable byte stream, just
> like a file, and the stdio interface for files makes a reasonably good fit
> to use with TCP.

I'd have to agree that the Berkeley socket library is somewhat unorganized and
contains some fossils.  But please (bleats the potential customer) remember
that customers may *already* have large piles of code that were written to the
socket library, and would be tremendously expensive to re-engineer.  It is
arguably more efficient to engineer one piece of code (the library) ab initio
than to retrofit hundreds or thousands of applications, even if the requested
interface *is* grody-to-the-max.

> 	Issues like this started to be hammered out a few months ago, with
> people trying to determine what is the minimum API required to get reasonable
> TCP functionality, in the hope that a minimum API could be decided upon
> for DOS in much the same way that vendors seem to have done for Windows, to
> avoid the problems with applications requiring a particular stack to work
> because the API's were different. The discussion petered out when it become
> obvious that one person's "minimum" was anothers "bloated", and some stated
> that the "minimum" API had to have the ability to provide all the functionality
> of BSD sockets anyway, and then some.
> 	It seems heresy to some that TCP/IP and BSD or SysV sockets are not
> glued together, and that there might be advantages to doing things differently,
> especially on machines with a much different OS & architecture.

Simplicity is admirable, but simplicity that is incompatible with finished work
is often not worth the cost.  If you would offer *both* APIs, new code would
probably use the new one and old code could be easily fitted to the old one. 
The problem with offering *only* the simpler approach is that it has a
significant hidden cost for many customers.

> 	The API to my/our TCP kernel is very similar to what Peter described
> above - although if enough customers bleat I will be forced to implement
> a library to emulate BSD sockets as best as possible, which will use the
> simpler interface to actually talk to the kernel. That way all the unnecessary
> code overhead is in your application, not my lean/mean kernel.

I don't think that you will get many customers without doing that.  It is a
shame that customers always seem to want what they need, rather than what you
want to sell them.  :-)
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 03:20:42 GMT
From:      peterd@merlin.dev.cdx.mot.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: ISDN Support

imhw400@indyvax.iupui.edu writes:

>In article <1992Jun26.154116.23125@macc.wisc.edu>, dorl@vms.macc.wisc.edu (Michael (NMI) Dorl) writes:
>> I'm curious to know what support exists for primary rate
>> ISDN.  Do any term server or router manufacturers support
>> a single primary rate interface to multiple basic rate
>> ISDN connections?
 
>It's called an AT&T 5ESS switch.  Get ready to write a biiiiiiiiiiiig check.

Actually, you could probably buy a Teleos switch equipped with say 1 PRI
and 4 or 8 BRIs for $40K or less. 

However, the article seems to be asking about a router that would
support a single PRI interface and handle multiple incoming 64kb/s data
calls, no doubt originating from BRI interfaces on workstations somewhere.

(calling these "basic rate connections" is confusing at best. By the
time the call gets to you, you don't care what hardware the calling
party is using.)

Anyway, it shouldn't be any more difficult to support PRI than BRI. As
far as I can tell, the actual interface hardware for one PRI shouldn't
cost much more than that for one BRI. The limiting factor would no doubt
be the lack of tariffed PRI service from RBOCs, the cost of bypass to
get PRI from an interexchange carrier, and other such issues that would
conspire to make it difficult for customers to use such a feature.

I don't know of a single case where anyone has implemented such a thing,
however. Does anyone else?

				Peter Desnoyers
-- 

-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 06:27:46 GMT
From:      pwb@newt.phys.unsw.oz.au (Paul W. Brooks esq.)
To:        comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: IBMTOKEN - (ethernet over tokenring)

In article <BqML6G.FJJ@acsu.buffalo.edu>, jap@acsu.buffalo.edu (James A. Perreault) writes:
> You have a slight misunderstanding in how IBMTOKEN works.
> 
> It doesn't take control of the board.  It communicates to the board via
> IBM's LAN Support Program.
> 
> paul@atlas.abccomp.oz.au (Paul Brooks) writes:
> 
> >After running the IBMTOKEN driver, try using PDIPX.COM or the BYU packet driver
> >IPX - these are Netware IPXs that talk to the packet driver instead of directly
> >to the card. You should be able to run CUTCP and Netware simultaneously.
> >|

Thats what I get for posting without actually trying it. I was treating
the Token Ring hardware and IBM LANSUP drivers as a "black box", so the
rest of the posting referred to "hardware" when it should not have. Go
with the other post's solutions, not mine. They know what they are
talking about. Mea Culpa.

[James writes:]
> You need to load the IPX that is generated for the LAN Support program,
> instead of the one generated that speaks directly to the TR board.  You also
> need the LAN support program loaded.

Paul Brooks        |Internet: pwb@newt.phys.unsw.edu.au
Uni. of N.S.W.     |If you have trouble sleeping, try lying on the end of
Kensington NSW 2033|   your bed. With a little luck you'll drop off. 
AUSTRALIA          |                              - Mark Twain. 

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 09:23:06 GMT
From:      kent@solomon.technet.sg (Yap Kim Kok)
To:        comp.protocols.tcp-ip
Subject:   Ping source code

Hi, does anybody has  public domain source code for ping ? Would
appreciate if somebody could help.


-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 09:38:49 GMT
From:      michel@neptunus.rivm.nl (Michel van Best)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   netbios emulator

Hello,

Does anybody know where to find a public domain netbios emulator for tcpip?


Thank you, Michel


-- 
                            Michel van Best		
EMAIL: michel@rivm.nl      Phone: +31 30 742984          FAX: +31 30 742971
      National Institute of Public Health and Environmental Protection
              P.O. Box 1, 3270 BA, Bilthoven, The Netherlands

-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 11:45:59 GMT
From:      claude@bauv106.informatik.unibw-muenchen.de (Claude Frantz (RZ))
To:        comp.protocols.tcp-ip
Subject:   Routing Question about UNIX


Please allow me to return to my past request here, in this newsgroup,
thanking all the people for their responses:

> Newsgroups: comp.protocols.tcp-ip                                          
> Subject: Routing Question about UNIX                                       
> Message-ID: <claude.709383915@bauv106>                                     
> Keywords: UNIX tcp-ip routing internet                                     
> Date: Wed, 24 Jun 1992 11:05:15 GMT                                        
>                                                                            
> Assuming a classical UNIX host having an Ethernet Adapter Card             
> connected to a LAN with the following command:                             
>                                                                            
> ifconfig interface 155.77.88.99 netmask 0xffffff00 broadcast 155.77.88.255 
>                                                                            
> Assuming on the same Ethernet LAN, there is another subnet having          
> the address range 155.77.33.* (the same netmask applies).                  
>                                                                            
> Assuming there is a host with address 155.77.33.6 which should             
> be the default routing gateway for all the traffic outside of              
> the TWO mentioned subnets.                                                 
>                                                                            
> What are the correct entries for the "route" command ?                     

Please allow me to formulate an amendment to these questions:

1) It appears to me that ONLY the interface has an attached NETMASK, 
not the entry in the routing table. Is this correct ?

2) In which manner will an entry in the routing table be tested in 
order to find if it should be used, especially will a mask be used ? 
In which manner ?

3) Where can I find the source code of the UNIX routines involved with 
the routing processing ?

4) It seems that I cannot formulate routing table entries in UNIX, 
in order to reach the routing gateway, in the case of the example 
above, although the routing gateway is reachable on the Ethernet (OSI 
level 2) which should be sufficient in the sense of the IP protocol. 
Is this correct too ?

Many thanks again to you all !
Claude

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 12:27:04 GMT
From:      dedgar@mta.ca
To:        comp.protocols.tcp-ip
Subject:   Need TCP/IP Market Info

Hello Net

I am doing a survey of the market for TCP/IP based communications software 
and really need sources of information.  If you know of the whereabouts of
any of the following types of information I would sure appreciate your 
sharing that knowledge with me.  

Magazine or journal articles which discuss (even in part) the number of
networks using TCP/IP, estimated numbers of machines (of all flavours) 
running TCP/IP, estimated market for PC (DOS & Windows) based TCP/IP
packages, projected growth in the UNIX market, projected growth in the
number of TCP/IP based articles or anything else on this topic.

Studys done by government agencies, related to the TCP/IP networks & their
projected growth.

Marketing studies done by academic institutions, thesis & etc.

Have any private companies which have done this sort of market survey be
willing to share this information?  Even slightly dated
studies would be useful.

I am particularly interested in which sectors (business, governement, 
educational, consumer) of the market are experiencing the most growth and
on what platforms.  I will post a summary of the findings to this list.
  
Thank You Very Much

						- Dale Edgar
                                                  Cybernetic Control Inc.

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 15:13:17 GMT
From:      mvm@cbnewsb.cb.att.com (michael.v.murphy)
To:        comp.protocols.tcp-ip
Subject:   Question about TLI on SUN SparcII


 I am running into problems using tli on a Sun SparcstationII. After a t_open
(/dev/tcp) and a t_bind, the t_connect call causes the system to lock up. I am
running SunOS 4.1.1 on a sun4c. The software works fine on an ATT 3b2 machine
(with minor library changes), and there are no looping structures in the code.
I cannot use dbx because no core is created. Any suggestions as to the cause
or possible solutions would be greatly appreciated.

							Mike Murphy

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 15:43:04 +0000
From:      ronald@gate.demon.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip
Subject:   Re: Maturity (people's, not TCP's)

drw@nevanlinna.mit.edu (Dale R. Worley) wrote:

> While you're at it, you might want to check into how the IESG really
> works, rather than how it officially works, and see if you've worked
> within the unofficial rules.

Hi.  I wonder if you could be persuaded to expand on this for those
of us who don't get to go to IETF, etc.  Specifically, we tend to depend
upon the published rfcs and drafts.  If you're telling us that
we mustn't believe the RFC that documents the standards procedure,
then how are we supposed to figure out what RFCs we are supposed to
take seriously ?

I can understand the point of view that says "The IESG is right to
discourage a protocol that is, in its view, ill advised".

I will agree with the viewpoint that "Bernstein is argumentative
and has an extremely annoying writing manner, at least in public
electronic correspondence".

What I cannot understand is what either of these two points has to
do with Bernstein's disappointment with IESG's conformance (or lack
thereof) to its own RFCs.  Neither Bernstein's personal manner nor
the merits of the proposals that he backs should affect the procedures
in themselves.  If the proposals fall down on technical merit, then
let them do so within the framework of those procedures.

If it's just Bernstein himself that causes the IESG to shudder and
ignore the proposals that he backs, perhaps they should say so once
and for all so that he can know to step back and let someone with
greater diplomatic skills do the parlaying.

Alternatively, if the IESG is going to give those proposals "special
treatment" outside the provisions of those procedures, I would be very
grateful if they would say so publicly so that "outsiders" like myself
can know not to spend time following those propsals -- I personally
would then not waste my time examining those proposals (and the sample
implementations).  I've already spent more time than I would have liked
hacking his rfc 931 authd to work on an unsupported platform (SCO XENIX).
If there are good reasons why proposals backed by Bernstein are
unlikely to follow the documented standards procedures, then I'd
really like to know so I can avoid wasting time looking into them.

I'd also like to see some arguments against Bernstein that concentrated
on answering his charges against the procedures followed rather
than lambasting him for his manner or his attacks on various
personalities involved.  Something to do with the other lesson
learnt from the fable of the boy who cried `wolf':  No matter how
often someone cries `wolf' falsely, it's worth investigating the
next time -- because the next time might be different.

-- 
Ronald Khoo <ronald@demon.co.uk> <ronald@ibmpcug.co.uk> <ronald@robobar.co.uk>
BTNet: +44 71 229 7741                    | Brambles are the order of the day.

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 16:33:48 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: API issues (Re: reliably delivered UDP)

In article <920629102758@cream.ftp.com> jbvb@ftp.com writes:
> In article <id.Z5ZQ.145@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>     How about this API:
 
>             fd = tcpopen(host, socket);
 
>             read(fd,...); write(fd, ...);
 
>             close(fd);
 
>     Why does the socket API require anything more than this?
 
> My own personal opinion is that the extra features of more elaborate
> APIs are worth my effort in remembering the details - I think they
> let me write more functional applications, with better error
> reporting.

So would, perhaps, a file I/O API that worked like this:

	fib = malloc(sizeof(struct FileInfoBuffer));
	fib->fib_clean = 0;
	initialize_fib(fib);
	fib->fib_name = filename;
	getfileinfobyname(fib);
	if(fib->fib_attr & FIB_CONTIGUOUS) {
		getaccessrights(fib->fib_volume, fib->fib_start, fib->len);
		read_block(fib->fib_header, fib->fib_volume, fib->fib_start);
		for(i = 0; i < MAXALLOC; i++)
			if(fib->fib_header->fh_alloc[i] > 0) {
				read_block(buffer, fib->fib_volume, fib->fib_start + i);
				process(buffer, fib->fib_header->fh_alloc[i]);
			}
	} else
		ftn$write(6, "A*", "File not contiguous");

But most of us prefer operating systems that hide this sort of detail for
the general case, and provide an escape (ioctls) for more complex operations.

If you want OS/360, you know where to get it...
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 16:36:18 GMT
From:      geranen@phx.mcd.mot.com (Scott Geranen)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: HELP: bootp response from remote subnet ignored

In article <BqM11F.EtA@waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:
>lbroda@s.psych.uiuc.edu (Larry Broda) writes:
>: We are trying to to configure the PCs in our departments to get their
>: NCSA/Clarkson telnet (or FTP TCP/PC) configurations via bootp,
>: ...
>:                  However, the PCs refuse to acknowledge the bootp
>: responses that don't come from their own subnet.
>: ...
>: Thanks in advance,
>: 
>: Larry Broda
>
>Since no suggestions have yet appeared, I'll jump into the void...
>
>The bootp clients running in your PC's must have the intelligence to pick the
>gateway IP address field out of the response frame and the bootp server must
>be aware that it is sending through a gateway and fill in the field (or the
>field must be statically set up to contain the correct gateway IP address).
>
>I suggest you check your response frames to ensure the correct information is
>there... if no, add it; if yes, fix the bootp clients.
>
>Ted Rypma
>HP Panacom Division

Are you sure that you are even getting responses from the other side of the
gateway?  The BOOTP client broadcasts the bootrequest and broadcasts are
not propagated by gateways.  

--
Scott Geranen                    Internet: geranen@phx.mcd.mot.com
Motorola Computer Group	         uunet:    uunet!unisoft!mcdphx!geranen
2900 S Diablo Way (DW220)        FAX:      (602) 438-3836
Tempe, Az  85282                 phone:    (602) 438-3238

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 16:45:29 GMT
From:      peter@ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.dcom.lans.misc
Subject:   inetd

Is there a freely available inetd implementation that will work over a
minimal TCP implementation (a several year old Excelan design)?
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 17:20:32 GMT
From:      skl@cs.sfu.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping source code

In article <1992Jun30.092306.15003@nuscc.nus.sg>, kent@solomon.technet.sg
 (Yap Kim Kok) wrote:
>... does anybody has public domain source code for ping?

Try ftp.uu.net:packages/bsd-sources/sbin/ping/ .

Not exactly "public domain", but rather "Berkeley copyright".

...Sam
-- 
Samuel Lam <skl@cs.sfu.ca>
Network Support Group, Centre for Systems Science
Simon Fraser University, Burnaby, B.C., Canada

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 18:48:32 GMT
From:      toppin@melpar.UUCP (Doug Toppin)
To:        comp.protocols.tcp-ip
Subject:   Taking advantage of bootp/tftp?

We have a number of Motorola 680xx systems on our network that
run a memory resident real-time operating system that supports TCP/IP.
These systems require a disk drive only for the purpose of loading
the applications software.
I am interested in learning more about using bootp or tftp to
load these machines from another host on the network so we can
eliminate the disks on these machines.
I am particularly interested in finding out about any vendors that
have ready-made prom sets for the 680xx for this purpose.
I would very much like these machines to load software exactly
as an X-terminal or diskless workstation would.
This is a new area for me so sorry if I am phrasing the question
or information incorrectly.

The environment we work in is:
    - approx. 50 computers from various vendors (SGI, Sun, Motorola)
    - most running Unix
    - some running a real-time system called PSOS
    - all communicate using TCP/IP on FDDI

If you can provide any information or point me in the right direction
I would appreciate it.
Please mail responses and I will post useful replies to this group.
thanks
Doug Toppin
uunet!melpar!toppin
703-560-5000 x4731

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jun 1992 20:21:22 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: informal notice of two IESG decisions


I've read the notes on this subject in some puzzlement.  I was part of the
IESG until about a year ago and helped with some early versions of 1310
and did not remember that the IESG had ever had any obligation to announce
decisions *not* to forward a standard.

So I went and re-read RFC 1310.  My conclusion is that the clause cited:

    ``The IESG shall determine whether a specification satisfies the
    applicable criteria for the recommended action (see Sections 3.2
    and 3.3 of this document) and shall communicate its findings to the
    IETF to permit a final review by the general Internet community.''

was only intended to imply that no document could be proposed as a standard
without public review, *not* that documents that were not to be promoted
should receive public review.  (This is what I'd remembered).

Lest I be accused of reading text to conform to my faulty recollections, some
supporting notes:

    * The document suggests that specifications satisfying the recommended
    action will typically receive both e-mail review and be publicly
    presented to the IETF plenary.  Clearly there's no point in a review
    much less a public presentation if a specification is being rejected.

    * Sections 3.2 and 3.3 only indicate status possible for standards
    (or past standards).  Thus "to satisfy the applicable criteria" can
    be read as meaning "if the document is deemed appropriate for
    standardization."

    * the paragraph at the end of 2.6 indicates that following IAB approval
    of the IESG action, the I-D will be published as an RFC.  Again,
    the only IESG-IAB approved decisions that result in RFCs are positive
    decisions.

So I think the right step here is to point out that the phrase about
recommendations should be clarified to indicate what happens to rejected
proposals.  (I actually think that they *should not* be publicly announced,
except, perhaps at the request of the author.  No point in embarassing hard
working folks if their proposal gets rejected, unless they request publicity).

Craig Partridge

PS: I'll note that the IESG also appears followed proper procedure on all
other issues.  Mr. Bernstein submitted a document which after considerable
review and work by his community became an I-D (RFC 1310 sect 2.4 says
documents viewed as completed may become I-Ds).  The IESG is entitled to
ask committees to review the I-D -- apparently they did (the SAAG).

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 1992 09:33:26 -0700
From:      tli@skat.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re: HP Probe - What is it?

In article <2728@ucl-cs.uucp> J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) writes:
    
    can anyone enlighten me as to the purpose of the HP Probe
    packet/protocol?
    
HP Probe is basically a Swiss Army knife.  It contains elements of
what we normally consider ARP, Router discovery, and DNS (and proably
more that I'm not thinking of).  The ARP functionality is by far the
most commonly used. 

-- 
Tony Li - Escapee from the USC Computer Science Department          tli@usc.edu
		       The net is not what it seems.

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 92 23:34:45 GMT
From:      gsa@easyaspi.udev.cdc.com (gary s anderson)
To:        comp.protocols.tcp-ip
Subject:   re: informal notice of two IESG decisions

In article <1992Jun30.202122.3351@sics.se>, craig@sics.se (Craig Partridge) writes:
|> 
|> I've read the notes on this subject in some puzzlement.  I was part of the
|> IESG until about a year ago and helped with some early versions of 1310
|> and did not remember that the IESG had ever had any obligation to announce
|> decisions *not* to forward a standard.
|> 
|> So I went and re-read RFC 1310.  My conclusion is that the clause cited:
|> 
|>     ``The IESG shall determine whether a specification satisfies the
|>     applicable criteria for the recommended action (see Sections 3.2
|>     and 3.3 of this document) and shall communicate its findings to the
|>     IETF to permit a final review by the general Internet community.''
|> 
|> was only intended to imply that no document could be proposed as a standard
|> without public review, *not* that documents that were not to be promoted
|> should receive public review.  (This is what I'd remembered).

Although your memory and intent is probably genuine, I think the
verbage does not define the "rejection" case.  Consequently, the
inference made by Mr. Bernstein is not "out-of-line".

There is a more disturbing issue, which has been brought to light
in the midst of this thread.  There appears to be a trend in the IETF
community which is yielding an image of politics.  Individuals citing
personal vouchers for peers versus presenting technical knowledge to
promote their position, and character qualifications being cited
as key requirements for technology acceptance, are two of the
unseemly images.  One hopes that these are merely ill-formed
images on my part, and not a problem in the current
IETF infra-structure.

A second issue is the size of the IETF and the potential loss of focus.
The internet community has thrived on the standardization of "existing
practice".  This standardization lends itself to the next level of 
technology which ultimately becomes the next standard.  This evolutionary
cycle has been extremely effective and public contributions have been
the backbone of the success story.  If the IETF starts writing standards
for tomorrow's technology, one sees visions of another ill-fated
standard's body.  One hopes that the "effective model" is not lost
in the large-scale committee movement.

Back to the real issue, security (I think):

Technology rejection because an existing security solution is not
perfect seems weak.  No security technology is perfect, each has its
weak points.  The real key is to understand the weak points in order
to define cascading security solutions or, worst case, define local
policies in order to shore up the security.

If a security system clearly defines what it covers and what is not
covered then the market will determine whether or not this is an
acceptable solution.

As for the pending case (Bernstein vs. IETF), I have no comment
because we (the Internet Newswire clan) have only been privy to
the rhetoric.


Security is a perception of your enemy.........

END OF DOCUMENT